Elysian Shadows

Elysian Physics Sandbox Part 1

Combining Terrain and Object Layer Collision Primitives
After I got all of the collision primitives implemented within the Engine, I decided to go ahead and implement an "optimization" of sorts. So since we have two layers, each containing an object and terrain layer, each tile location technically requires two collision passes (since terrain and objects can both have independent solidity types). This is pretty damn wasteful. So I began the painstaking endeavor of creating a 20x20 LUT for combining Tile::COLLIDER_TYPEs. I was able to narrow it down to an arithmetic function (spatial complexity, it's constant time) by being a little clever with indexing and using a jump table/switch statement. It's still a fucking beast, though.

We are now supporting every non-angled type that Chrono Trigger supports, and then some. Here is the COLLIDER_TYPE enumeration for now... More angles on the way.

[code] enum COLLIDER_TYPE {
COLLIDER_NONE, COLLIDER_FULL,
COLLIDER_HALF_E, COLLIDER_HALF_N, COLLIDER_HALF_W, COLLIDER_HALF_S,
COLLIDER_QUAD_SE, COLLIDER_QUAD_NE, COLLIDER_QUAD_NW, COLLIDER_QUAD_SW,
COLLIDER_L_SE, COLLIDER_L_NE, COLLIDER_L_NW, COLLIDER_L_SW,
COLLIDER_QUADS_SE_NW, COLLIDER_QUADS_SW_NE,
COLLIDER_45DEG_SE, COLLIDER_45DEG_NE, COLLIDER_45DEG_NW, COLLIDER_45DEG_SW,
COLLIDER_MAX
} colliderType;[/code]

Since we are now dynamically combining the terrain and object layers for a single collision pass, we had to support a few other combinations that Trigger didn't bother with. Namely quadrant collision with two diagonal corner solidity.

Due to the sheer magnitude of the combination function, this is going to need some serious testing from Tyler... It's possible that I may have accidentally screwed up a few tile combinations. Not a big deal, but we need to test the living shit out of this...

Toggling Solidity in Gamma
For the sake of debugging physics, I have added more layer toggles. In addition to toggling the rendering of each layer with buttons 0-4, you can now use buttons 5-7 for solidity toggles:
5 - Toggle Render Terrain Solidity
6 - Toggle Render Object Solidity
7 - Toggle Render Combined Solidity

A few things to note. This is for the "current layer." So if the player is on layer 1, it's rendering layer 1 solidity. If he's on layer 2, it's rendering layer 2 solidity. Toggling Combined solidity disables independent Terrain/Object solidity for the sake of sanity.

A useful application of this would be to toggle Terrain, then toggle Object. Since it's blue and transparent, you can see the overlap regions. Then when you switch to "combined," you should be able to see the geometry properly combine itself into a single layer.

Anyway, the physics sandbox area I have been creating has grown quite a bit more complex. I also threw several more entities in there to really stress test the engine and physics algorithms. Stacking shitloads of entities does indeed work, and collision resolution is correct. It can start to get a bit jittery when you chain a bunch of shit together, but the resolution is still correct. This is a very common issue with impulse-based physics engines (ESPECIALLY with stacked objects being affected by gravity), and I will wait to address it until we're further along in development, since it is quite stable and still completely accurate. Just making you gents aware that it's on the backlog...

Exposing Tile Collider Primitives to ESTk
I'm still not done with this, and Tyler is going to be helping me. As with other "selectables," tile attributes are to be modified within the SelectionView. Unfortunately Qt's default property representation within its views only supports booleans (checkboxes), integers (spinboxes), and strings (line edits). I had to create a relatively complex new Qt Delegate within the Toolkit (I will spare you the details) to represent tile collider types (its an enumeration). It will show up as a string name and an icon.

Tyler is going to have to draw 20 little 16x16 icons for this field and the DropDown menu. The angel is just a placeholder.

But anyway, this already fully works. You can change the attributes for each object and tile, lay them ontop of each other, then see the resulting collision layer within the Engine.

Once we finish implementing the icons, I am going to also give the Toolkit the ability to render the solidity layers. There will be an option for enabling it within SheetView (so you can see per-tile) and one for enabling it within MapView (so that you can see it on the map for your current layer).

Toolkit Default/Startup Tile Layer
When the Toolkit started up or levels were changed, the default layer was always Object 2. This started to piss me off so much when I began really using it closely with the engine, since Tile 1 is the main layer that you will probably be editing... Modified this behavior.

Tyler
Tyler, if you want to get a head start on icon production, have a look at Engine/assetio/include/elysian_tile.hpp. We will need one for each entry into the Tile::COLLIDER_TYPE enumeration. Just name them whatever they're called in the enum with a .png extension. 16x16 as usual. I would make them blue and transparent (since we're rendering it as blue in the Toolkit and Engine).

Anyway, I'm excited as shit for this next update. All we need after we expose all this shit to the Toolkit is to properly handle Z ordering and implement layer-swapping (ladders, stairs, ropes, etc), and the "exploration/environment" portion of the engine is 100% go. Explore your levels in-game as you make them... It will be time to focus on gameplay.

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.