I figured out what was wrong with my system, and I can hardly believe the truth. I had given up, formatted, and reinstalled windows. I was installing the latest graphics drivers when I decided to turn off my firewall (and unplug the cat-5) because it kept giving me Allow/Block options and slowing the install process. To see if the new drivers solved my freezing issue, I launch VC++ and run my app- it works! It seemed the drivers fixed the problem, but left me wondering if my hardware was bad because these were the same drivers I had tried before. So I re-enable my firewall, check email, and when I run my app the next time, it freezes again!! I found my problem: the firewall. More specifically, I'm using the PC Tools Firewall and it has a "Enable Enhanced Security Verification" setting that was causing all my problems! (and its enabled by default) I never thought a firewall could cause my system to freeze like that. I feel kinda dumb for not finding it sooner, but I won't be bitten by experimental firewall settings ever again! Onward!



The level editor is coming along nicely. It has the drag-and-drop feature I mentioned before for placing objects. I load and save levels with an EditText box, and my crappy resource manager finds the file for me. I haven't written a filebrowser like I planned because there's no time. I'm sure theres a cross-platform filebrowser I can use somewhere, but it'll have to wait. I forgot to mention this last post, but I've abandoned the idea of merging the level and sprite editors this time around because of the work involved, considering its unneccesary anyway.

Now I don't want anyone to think I copying Aardvajk, but my editor has a 'Simulation' mode that updates the Box2d world so that objects can come to a rest before you export the level. I've had this option for a while, so its kinda funny we came up with the same solution right around the same time. It seems to be a neccessity when using Box2d to "bake" your objects into their resting positions.

Theres a 'Launch' button that starts the playtest mode. This will start the player at a spawn point when I implement them, but for now you start at the origin. Also, objects don't move back to their initial positions after playtesting, but I think this will be easy to correct by storing the objects' state when positioned/rotated.

I've implemented rotational snapping for objects, expressed as a division of PI. This is neccesary for consistency with how my entities orient themselves. Without snapping, its difficult to return objects to their previous rotation because the rotation value accumulates a little extra each time. This way, all rotations will be in consistent division of PI, and not rigidly bound to the mouse-drag vector. It doesn't drag as smoothly as I'd like, but it works damnit, it works. The snap interval is hard-coded as ( PI / 16.0f ) for the moment, which is around 12 degrees:


The background image is easily changed with the given text box. Sprites will be supported soon.

There are five hardcoded layers in the levels/editor at the moment. I can select the active layer in the editor with the given spinner, and isolate it with the checkbox (square next to it). It would be nice to be able to add/remove and edit layers and their properties directly in the editor, but I'm not sure it would be worth the time. Because I'm not using a scripting language, unique levels will need to subclass the basic level class anyway, and changing the layer params directly in the class won't be too limiting.

Below the main panel is the sprite panel. I haven't put arrows on the spinners or added any proper UI textures yet.

The "Layer" spinner changes the selected object's layer freely, but any object with a collision model should remain on Layer 0 because it will scroll at a different speed than it's collision shapes, making them invisible. I could put in a restriction for this later. The "Render" spinner changes (what I call) the object's "render layer", which is really just a value that the sort algorithm for the layer uses to determine render order. The player's layer and render layer are always 0. The spinner labeled "pixel density" effectively changes the size of the selected sprite. I'm using this spinner to determine what pixel densities I'll use for each layer, and then I'll make pixel density a property of a layer instead of each sprite.

Below the pixel density spinner you'll see a droplist that holds all the available actions for the selected sprite. This is useful for scenery that needs to have variation. It gives me an easy way to change what the sprite looks like without creating a new sprite for each look. For instance if a tree sprite has many tree variations in a single image file, each variation would be a separate "action", and I can pick which one I like from this droplist.
I have yet to automate the creation of a sprite's action list; I'll set up a button in the sprite editor to do this automatically. In this image, the same hallway sprite can be used for many different hallway variations.



The possible number of variations for a sprite will multiply if I set up the sprite with a bunch of pivots, and attach separate parts of the sprite's image to those pivots. For example, the hallway could have pivots on the ceiling and walls, and any number of doodads in the image file. I can then generate all the possible "actions" based on the number of pivots * doodads and have them ready to use in the editor! I'll try to have a working example of this by next week. There's so much to do!

I'm starting to experiment with the gameplay and controls, and I think its going to take me a few weeks to find something acceptable. This process will be much more productive than when I started because of the GUI and editors I've built. If you look in the images for a spinner labeled "Run:", you'll see the beginning of a GUI panel that will let me change all of the player's parameters (once I have it set up) such as run speed, jump height, wheel speed, mass, etc. (more on that later)

As of this weekend I have 9 weeks remaining until my self-imposed deadline on June 30th. It looks like I'll have a playable prototype, but not much more by that time. I'm definitely going to keep working on it after that, who knows for how long? I'm wondering how complete the demo needs to be before I can submit it to the GD Showcase.



This screen is of the level being played directly without the editor. Those crappy photoshop clouds in the background scroll sideways for unparalleled realism!