[b]gyro::Transform Parenting[\/b]<\/p>\n
Transform parenting is a very important aspect of the transform matrix. It allows us to create an entity (such as a sprite, collidable region, etc) whose location is [i]relative[\/i] to another entity. In our engine, each entity is basically a rectangle. When you attach something like a “sprite” its transform becomes parented by the entity’s transform. This enables the sprite to move around based on where the entity is located. Collidable regions work similarly. Some entities might have collidable regions that aren’t the same as their sprite or rect regions. These collidables can have their own local position that serves as an offset from the parent transform.<\/p>\n
Mathematically, this is implemented by transforming a transform by its parent (3×3 Matrix multiplication in 2D). For the behavior to be as we would expect, the child’s transform must be [i]relative[\/i] to the parent’s. This actually becomes quite a pain in the ass and is the reason I’m not yet done.<\/p>\n
So what if we have a transform heirarchy? The child’s parent has a parent? Well, we must traverse the hierarchy upwards and examine each parent to determine value’s for the child that is relative to each. It’s technically a O(n) traversal every time we want to screw with a child’s transform. (Sounds smart, huh?) I have yet to implement that functionality. <\/p>\n
Here is what I have of the Transform2D class. It is a bunch of ugly ass linear-algebra math. It’ll be much uglier when I move this to assembly on the Dreamcast or PSP. <\/p>\n
class Transform2D: private Matrix3x3 { private: \tbool updateTransform; \tVector2 position; \tVector2 size; \tVector2 scale; \tfloat orientation; \tfloat z; \tTransform2D *parent; public: \tinline Transform2D(): Matrix3x3(), parent(NULL), position(0, 0), size(1.0f, 1.0f), scale(1.0f, 1.0f), orientation(0.0f), z(50.0f), updateTransform(true) {} \tinline Vector2 getPosition() { return position; } \tinline void getPosition(float &x, float &y) const { x = position.x; y = position.y; } \tinline void setPosition(const Vector2 pos) { position = pos; updateTransform = true; } \tinline void setPosition(const float x, const float y) { position.x = x; position.y = y; updateTransform = true; } \tinline float getZ() const { return z; } \tinline void setZ(const float p_z) { z = p_z; updateTransform = true; } \tinline Vector2 getSize() const { return size; } \tinline void getSize(float &x, float &y) const { x = size.x; y = size.y; } \tinline void setSize(const Vector2 &p_size) { size = p_size; updateTransform = true; } \tinline void setSize(const float x, const float y) { size.x = x; size.y = y; updateTransform = true; } \tinline Vector2 getScale() const { return scale; } \tinline void getScale(float &x, float &y) const { x = scale.x; y = scale.y; } \tinline void setScale(const Vector2 &p_scale) { scale = p_scale; updateTransform = true; } \tinline void setScale(const float x, const float y) { scale.x = x; scale.y = y; updateTransform = true; } \tinline float getOrientation() const { return orientation; } \tinline void setOrientation(float angle) { orientation = angle; updateTransform = true; } \tinline Matrix3x3 getMatrix3x3() { UpdateMatrix3x3(); return *this; } \tinline void setMatrix3x3(const Matrix3x3 &tr) { *((Matrix3x3*)this) = tr; updateTransform = false; } \tinline void setParent(Transform2D &p) { parent = &p; } \tinline void Rotate(float angle) { orientation += angle; updateTransform = true; } \tinline void Move(const Vector2 &dist) { position += dist; updateTransform = true; } \tinline void Move(const float xdist, const float ydist) { position.x += xdist; position.y += ydist; updateTransform = true; } \tinline void Scale(const Vector2 &amount) { scale *= amount; updateTransform = true; } \tinline void Scale(const float xamount, const float yamount) { scale.x *= xamount; scale.y *= yamount; updateTransform = true; } \tinline Vector2 Transform(const Vector2 &vec) { \t\tUpdateMatrix3x3(); \t\tif(parent) parent->UpdateMatrix3x3(); \t\treturn (!parent)? (*((Matrix3x3*)this) * vec) : ((*((Matrix3x3*)this) * (*((Matrix3x3*)parent)))) * vec; \t\t\/\/return (*((Matrix3x3*)this)*vec); \t} \tinline void UpdateMatrix3x3() { \t\tif(!updateTransform) return; \t\tVector2 relativeSize = size*scale; \t\tCalculateTransform(orientation, relativeSize, position); \t\tupdateTransform = false; \t} }; <\/pre>\n[b]CameraSystem[\/b]<\/p>\n
![\"\"](\"http:\/\/elysianshadows.com\/updates\/wp-content\/uploads\/2010\/05\/ES016.jpg\")
<\/p>\n
The camera system is currently NOT done. The plan was to be able to set an entity’s transform as the camera transform’s parent. This would allow the camera to follow any entity without having to be constantly passed a position every frame. If a script needs to manipulate the camera directly, it can set the camera’s parent to NULL, and directly manipulate the transform’s position, rotation, and scale. This is useful for cutscenes especially. I need to finish parenting functionality completely before I can do this, though.<\/p>\n
[b]New Scripting Hierarchy[\/b]<\/p>\n
![\"\"](\"http:\/\/elysianshadows.com\/updates\/wp-content\/uploads\/2010\/05\/ES017.jpg\")
<\/p>\n
First of all, note that the “script” inheritance hierarchy has changed a little bit. Components that are built-in to our engine are simply inheriting from component (sprite, collidable, warp, rigidbody, etc). <\/p>\n
The next level down brings us to a “behavior.” This is what I referred to as a “script” before. A behavior has a group of trigger functions like OnHit(), OnTalk(), OnMove(), OnUpdate(), etc that are called when a specific event occurs.<\/p>\n
Any compiled C++ behavior simply inherits from this level (with it’s own editor and engine implementation). It simply overwrites each virtual trigger that it wishes to implement for a particular behavior.<\/p>\n
On the other end of the spectrum, we have a LuaBehavior, or a “script.” The LuaBehavior’s implementations of these virtual functions simply invoke functions from the Lua Script. So you can almost think of the Lua scripts as virtually inheriting from LuaBehavior.<\/p>\n
[b]Dynamic C++ Behavior Registration[\/b]<\/p>\n
This is going to be difficult to explain… it is really just a solution that I found to help further separate user-defined C++ behaviors from our actual “engine.” It’s a pretty, object-oriented solution. <\/p>\n
The “Entity” class will contain a static vector of “allocator” functions. An allocator function basically provides an integer for its corresponding component, receives a file-handle, and allocates\/deserializes its respective component. <\/p>\n
This way each new C++ behavior will not have to be some hardcoded addition to the Entity::Load()’s component switch statement. Entity simply calls the allocator (in its internal static array) that corresponds to the component index. The entity allocator gets passed a file handle, and returns its respective component (which is then polymorphed back up to a behavior and added to the entity’s list of behavior’s).<\/p>\n
Don’t worry if I’ve confused you. Just know it’s very pretty.<\/p>\n
[b]Conclusion[\/b]<\/p>\n
Everything that I have done so far is in my repository. It all builds perfectly with a fresh version of Visual Studio 2008 (provided that you set the correct working directory). [b]All that it does is render a map[\/b] through the TerrainSystem currently. You will notice plenty of “could not load” errors in your console when you run the engine. This is because we have yet to save\/load or handle things like rigidbodies, warps, enemies, etc. and the level function is expecting them.<\/p>\n
I will next be working on command-line arguments so that Marcel’s level editor can easily invoke the engine with a current Level and Area. Hopefully this will be an easy-to-access File->Run Current that allows you to seamlessly test your levels as you develop them. Peace, gents.<\/p>\n","protected":false},"excerpt":{"rendered":"
Originally posted in our Private Development forums on 5.1.10.<\/strong><\/p>\nThis is going to be my final gigantic post\/update until after finals. I purposely worked my ass off all during the week, so that I would be able to contribute (and have all weekend to study). I have finals next week and the Monday\/Tuesday after that. I intend to study my ass off, so you might not see me around quite as much.<\/p>\n
[b]TerrainSystem[\/b]<\/p>\n
![\"\"](\"http:\/\/elysianshadows.com\/updates\/wp-content\/uploads\/2010\/05\/ES015.jpg\")
<\/p>\n
The terrain system is pretty much done. This is the system that renders and facilitates access to the terrain (when I say terrain, I’m referring to object\/tile layers 1 and 2). This system will also be responsible for animating the tiles. While the level itself contains the actual tileset and objectset, the TerrainSystem contains a “currentset” for each, which is the tile that is currently occupying the space (tile 3 might swap to 2 and back when animating. The actual map contains 3, but the current array could have 2 or 3). This also allows me to update tiles based on simply swapping indeces rather than iterating through the map (which would be completely fucktarded).<\/p>\n","protected":false},"author":1,"featured_media":278,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-281","post","type-post","status-publish","format-standard","hentry","category-underlying-technology"],"_links":{"self":[{"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/posts\/281","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/comments?post=281"}],"version-history":[{"count":0,"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/posts\/281\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/media\/278"}],"wp:attachment":[{"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/media?parent=281"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/categories?post=281"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/tags?post=281"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}