Elysian Shadows

Invoke Engine, Entities, Components, and Falco’s Wrath

[b]Pristine Project Repository[/b]

As you all probably know by now, the project repository has had a bunch of random, half-assed, half-working levels that may or may not load with the current AssetIO configuration. While these pieces of shit really helped me make the AssetIO (and engine and toolkit as a direct result) bulletproof, they began to just be a serious pain in the asshole. I have done a bit of house cleaning, and now every level/area should be pristine and ready for the Toolkit/Engine. Also, I have ported over several old levels for your own personal enjoyment (INCLUDING the gay bar, whose map is preeeetty fucked up, since we have since changed formats (bitch at Peter to write a converter Perl script for it. ;) )).

[b]Engine Dialog[/b]

This is honestly my favorite new addition. It just feels so snazzy, responsive, and useful. We are now able to seamlessly invoke the engine from the toolkit yet again. It currently saves your current level/area before sending to the engine. In a future build, I would like to create a temporary save when you invoke engine, just in case you didn't actually want to save your changes before doing so (maybe you were tweaking something or testing how you like certain changes). 

The log window is capturing any and all output from the engine's standard output and is writing it all to a log for your viewing pleasure. This data includes all serializations for loading, internal debug data, and also any data a level developer/scripter writes to the console/adventure Log. This may actually wind up being a scripter's best friend. 

The X and Y fields are for supplying the initial x, y starting location for the player upon the engine's invoking. These (along with the level and area to load) are passed from the Toolkit to the Engine as command-line arguments. This dialog will supply a front-end for all future command-line arguments and switches. There will surely wind up being several to aide in debugging (render collision layers, disable adventure log wrapping, etc).

I am also planning to have "invoke engine" buttons in the main toolbar on the top of the Toolkit. I would like to have buttons for current platform (Windows, Nix, OSX), Dreamcast, PSP, and iPhone/Pad and have all of their output still be logged in the window. If we could pull that off, our SDK would be sooo fucking sexy. Even Unity doesn't handle that very gracefully.

[b]Component View Redesign[/b]

I have decided to redesign the component view. The new design uses the "QToolBox" widget to enable me to dynamically add tabs to the view for each component. The entities themselves have some simple data (transform, color, texture) that is also represented as its own tab (even though it isn't a component).

As you can see, I am creating tabs for each component (as they are all being read in with the entity), but there is not yet a front-end GUI for these tabs. Currently, the only tab with any kind of implementation is Entity (although we'll be doing the rest fairly soon).

[i]Entity/Component Design Talk[/i]

I wanted to talk briefly about the design that I have chosen for the Component View, since this is where 99% of future development on the toolkit is going to be happening. Attaching components to entities in the engine is how we change their characteristics. These entities and components are also part of the AssetIO (at the "editor" level, so just data, no runtime characteristics). 

In the toolkit, this entity/component data is "encapsulated" by toolkit entities. A toolkit entity contains an elysian::entity as well as GUI components and provides wrapper accessor methods for manipulating this data. A toolkit entity has methods like setPosition(), setScale(), setOrientation(), etc that update the corresponding elysian::Entity AND also update the GUI (so that everything stays in-sync).

[b]Entity Tab[/b]

As I said previously, the entity tab of the component view is currently the only completed tab. I'll briefly explain what all of the fields are as well as what they do.

[i]Position[/i]

Position is the x,y location of the entity in the scene. Position is the CENTER of the entity, NOT the top-left

[i]Size[/i]

Size is the base-size of the entity in pixel length.

[i]Scale[/i]

Scale is a multiplier that is applied to size to give the size of the entity in the scene.

[i]Orientation[/i]

Orientation is the angle of rotation of the entity in the scene. The Toolkit allows -360 to 360 degrees and converts them to radians for the engine. 

[i]Renderable[/i]

This checkbox toggles whether the entity will be rendered by the engine or not. When this is unchecked, all color and texture data (below) will be disabled. This does not necessarily mean that the entity cannot be rendered by the engine. From Lua, you can call setRender(true) on the Entity and manually set its corresponding color/texture data. This is more of a "renderable by default" kind of deal.

[i]Textured[/i]

Disables or enables all texture data.

[i]Vertex Colors[/i]

Allows you to set custom coloring/transparency for each vertex of the entity. The values range from 0 (none) to 1 (full). You can also opt to use my fancy-ass color swatches for picking out colors:

[i]Texture Location[/i]

This field supplies the location of the texture to be applied to the current Entity. You may browse any texture you like. If the texture is not within the Project directory, you are notified, then the toolkit copies it over the Area folder (all assets need to be somewhere within Project). 

[i]Sheet Size[/i]

These are the actual image dimensions of the texture browsed. The toolkit sets this for you once you select your texture.

[i]Sprite Size[/i]

This is the size of each individual sprite frame within the sheet. If it is just a single image (not a sprite sheet), just set these equal to the sheet size.

[i]Starting Frame[/i]

This is the sheet location of the first sprite to apply to the entity. 

[i]Reload Sheet[/i]

This causes the toolkit to deallocate, reallocate, reload, chop up, and reapply the texture to the entity.

[b]Screwing With Our First Entity[/b]

So enough talk. I'll walk you through screwing with your first entity. Unfortunately, Marcel has not yet added an "add entity" option to the file menu, so I will be manipulating an existing entity (and there is always the option of manually editing the text file to add the entity). First, we will set its location to 300, 300. Then we will set its size to 100x100 and scale to be 2x2 with orientation of 45 degrees. We now have a box rotated 45 degrees with a size of 200x200 pixels at location 300,300. Make sure renderable is unchecked. Lets invoke the engine.

As expected, there is no entity at that location. We did not specify that it was "renderable." However, if it had any attached components, these would still be updating/functioning normally, despite the fact that nothing is being rendered.

Now lets enabled rendering and fuck with the color swatches to give some fancy coloring to our entity before reinvoking:

As you can see, we now have a colored, semi transparent quad representing our entity. Please note that this will not show up in the toolkit, yet. I have not yet added functionality for vertex shading, so you will only be able to see this in the engine. I hope to add that to the toolkit relatively soon.

Finally, lets check "Textured" and supply texture data for our entity. I'm going to literally texture a giant-ass screenshot of the engine. I'm going to set the sprite dimensions to be the same as the sheet (so the image will not be split up). Pushing reload texture in the toolkit will cause the texture to be rendered:

And finally invoking the engine shows our entity textured and colored as we'd expect:

Just keep in mind that you should only ever texture images whose dimensions are powers of 2. It works on the PC builds of the engine (glPNG pads the images), but that would cause the DC/PSP/iOS to shit their pants. Hopefully I will be able to make the toolkit pad the image (but we really still shouldn't ever have to texture a non power of 2 for anything other than screwing around).

[b]Load Times[/b]

Everybody who has tested the previous build of the Toolkit on Windows (even though there wasn't one, you smartasses all build it yourself) bitched about the UNGODLY load times. You were right, it was unforgivable. Marcel and I just didn't notice, because our dual-core Macbook Pros were able to load it in literally under a second while quad-core top-of-the-line Windows 7 machines literally choked on a cock... I still don't know what the fuck is up...

Anyway, there is no longer ANY loadtime upon initialization. Items are now only being added to the scene as you open/activate levels. Then, as you switch back and forth between bigger levels, this data is cached. For example, opening a 15x20 map at first will cause 15x20 scene items to be added to the current scene. Then when you switch to a bigger map (100x100), 85x80 scenetiles are added. Then when you switch between maps that are of the same size or smaller, there is absolutely no initialization time.

Levels are also cached. When you first open a level, the sheet must be chopped up and allocated which may take a few seconds. Then, switching back to a level that has already been open should be instant. Caching like this helps us keep initialization time down while also allowing the toolkit to remain responsive when you're continually switching back and forth between maps.

Depending on how quick your PC is (it was instant on Tyler's), these initial loadtimes may or may not take a few seconds. I would still really like to implement some sort of modal loadbar so that the toolkit feels more responsive, but this is fine for the time being.

[b]Multi-Platform-ness[/b]

Everything that I have shown here has been tested and works equally well on Windows and OSX. There's no reason that it shouldn't also on a flavor of Linux, but I will be testing as well. 

[b]Future Plans[/b]

There's still quiiite a bit of work to be done on the toolkit. Unfortunately, I'm still not putting a build of the Engine/Toolkit into the repository just yet. Marcel still has not finished giving us the ability to lay tiles/entities, so the toolkit isn't useful for much more than fucking with some pre-existing entities. I've been bitching at him every single day to get this done, so hopefully sometime soon he may actually do it.

Once he does that, all we have left is hooking up some simple menu items (save, load, import level, import area, new entity, etc), a tiny bit of debugging, and I think we will be ready for our very first stable build of the new toolkit.

At this point, I'm going to have to back off of Toolkit duty for a few and get my ass to work on getting the PSP and iOS builds (with M_D_K) up and ready for the video.

ANYWAY! Back to fucking work with me. Please post your thoughts, gents. I've been slaving away on this.

Discussion Topic

Falco Girgis
Falco Girgis is the founder and lead software architect of the Elysian Shadows project. He was previously employed in the telecom industry before taking a chance on Kickstarter and quitting his job to live the dream. He is currently pursuing his masters in Computer Engineering with a focus on GPU architecture.