Further progress

Not a lot to show this time, but rest assured that work is progressing. 

 

I’ve spent the previous few days implementing the level manager (and entertaining visitors, which explains the lack of updates) – this is the code that controls levels and their associated layers. It’s the thing that does the rendering of the level to the bitmap, and manages the scrolling. Callbacks are implemented both pre-and post-layer rendering, so you can processing the image of the game area as it’s built should you choose to do so.

The demo I posted in my first post was basically the layer manager and tile manager being used to mock up a level, and this code now wraps all that up into one unit. The aim here is to reproduce that demo using the level manager to make sure things all work as they should.

 

A level is basically a list of TLayerinfo types, which describe the layer to be drawn, and the offset x/y that it should be drawn at. Layers, as have been seen previously, do not have to be any set size (though being at least the size of the viewable area is good if they don’t wrap), and have a few values associated with them –

callbacks – these are fired off into user-code before and after the layer is rendered

Offsets – used to render the layer at the correct position

Scroll scalars – used to modify the offsets above by a set amount (float values) to perform scrolling. This will all be wrapped up by the LevelManager.ScrollLevel() procedure. 

Flags – this value is a 32bit DWord which hold boolean values on each bit for flags such as wrapping and collision/notifications.

I’m currently considering allowing a list of “states” to be specified for each level, where each layer’s position is stored – this would make it easier for the user to specify how a level will look when for example, a player enters that level at different points in the level. However, that’s for another day :)

Now I have to get the level editor done – a tool that allows you to visually set layers up and move them around relative to one-another. The asset loading and saving code is done for the level manager, so it should be a pretty easy job to get this done.

When all that is complete, I can start of Sprites and how they interact. This is gonna get pretty messy – as I mentioned previously, if  a sprite is moving at 3 pixels horizontally per frame (quite fast) and hits a wall, then the collision will fire only when the sprite is actually intersecting the object it has collided with. Obviously, if you just want the sprite to stop when it hits something, you don’t want it to appear to be buried inside whatever it hit! This is just one of the problems I can foresee, and will take some figuring out.

Suggestions on how to deal with this problem would be gratefully accepted – my current methods as planned will consume a not inconsiderable amount of CPU to implement, especially as there could be hundreds of sprites per frame with this checking enabled… Of course, not all sprites have to collide but in a bullet-hell type shmup, you’ll want a lot of collision to be checked. Or not, if you render the bullets first (with no collision) and then the player sprite(s) with collision. It’s this sort of thing I can’t accelerate with hardware support.

Ooh, the possibilities :)

Advertisements

3 Responses to “Further progress”

  1. “Of course, not all sprites have to collide but in a bullet-hell type shmup, you’ll want a lot of collision to be checked. Or not, if you render the bullets first (with no collision) and then the player sprite(s) with collision. It’s this sort of thing I can’t accelerate with hardware support.”

    You might be able to, using the depth buffer and other such trickery :)

    Bill

  2. This is true, Bill. I suspect that if I really wanted “good enough” collision detection for masses of objects (which just happen to be circular), a simple coordinate+radius check would do :)

    Anyhoo, my first test game of this engine will be a small remake of the Amiga shmup, “Star Ray” as the amount of parallax layers in there will be useful to test with. And it’s a defender clone, so everyone wins…

    D.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: