ThesiusXIII - Forest Blast Tech

[kevin]

Update V008

    I've been tinkering away this the past couple of afternoons on clean up duty.  A lot of this was simply throw together to get something on screen quickly.   So i've set up the program to start, play and finish a a very basic game.  Calling it a game is bit of overstatement really,  while you can play, and die,  the aliens are user generated at this point.  Ie. press F1 to get attacked..  :)     So i think that can be this afternoons little task.

    For aliens, i'm just going to throw in something to spawn convoy types at pre determined points throughout the level.   The spawning i think i'll making fairly random.  So while they're generated once you reach point X, perhaps their origin, direction, or number could differ.   Some objects could have predetermine paths, behaviors though.   Which I think would make a for a better mix of  game play in terms of the replay factor.  It's a difficult genre to make replaying not so samey thought. 

    The example now features some visual scalability also.  What I mean by that, is that display routines now can use some simple Mip Mapping when rendering the environment (the buildings in this case).  This means that objects that are further away from the camera (which is fixed in space) use a lower quality version of their texture.   Most textures have 3 sizes.   Full,  Mid (1/2 size), Small(1/4size)   So near objects render the highest quality version, mid objects render the 1/2 size version, and far objects use the 1/4 sized version.

    The end result is pretty much the same image quality, but it takes the computer less time and effort to render the mid/low quality versions of the environment objects.   The reason is that smaller textures fit in the cache better, which means the pixels are faster to access, faster to access means faster drawing. 

   You can also set the environment quality.    This scales the Hi Quality versions down by a factor of whatever you set.   The mipmaps are then generated from this smaller version to begin with.    The more you reduce the hi-quality versions though, the more finer detail and blocky near objects become.  But, it does reduce the work load for slower computers. 

   I think i'll also add a 'quality' tag on environment def's (the environment stuff is just randomly spawned atm).    So the user could select what backdrop quality they want.  This would allows the display engine to only display the important objects and remove any objects that are just window dressing to the scene.   I wanted to have tuffs of grass/reeds for example, but i couldn't find any.  But that stuff would be ideal for removal as well as building that are just there for something to fill out space.   

   Performance wise, since the game play runs at an predetermined rate,  so it's still playable as low as 10 physical frames per second.   My Duron 800 mhz system for example is struggling in highest detail,  but can get up to 15->20fps by reducing the quality.   It's never going to be super smooth on it, but still quite playable.   

   Other ideas to improve scalability would be to add quality reduction to objects.   For the much the same reason, the smaller the texture, better old computers can deal with it.  Do this we'd 1/2 the texture size, then Mult the sprites scale by 2.  So the object appears to be same screen size, just a little chunkier.    This will also improve the performance of things like pixel prefect collision.  For the same reason.  Small textures = faster to access the pixels.   

   Anyway,  I was going to post video of the demo running , the quality of video is horrible (captured on my little digital camera that's why - which needs LOTS of light of get a clean image..  ) , but you should be able to get some idea of what it looks like running in my secret lair.  Spooky  :)

[kevin]

 Pic,

  In this pic i'm just toying with a lazer beam type effect.   


 

[kevin]

                                     Movie                                 

 Here's the movie thing mentioned above. it's few days old now, but you'll get the idea

Watch Thesius XIII Tech Demo on youtube.

Download Forest Blast Movie  (6meg)

[Ian Price]

That's looking excellent :)

[kevin]

Yeah,  It's getting there.  It's mostly a bunch of pretty media slapped in front of the camera.   I'm actually rather enjoying something 'different' to play with actually, but will no doubt have to get back to more pressing issue very soon..

[Ian Price]

I presume that you are using the new 3D sprites from the PB betas for some of those effects?

[kevin]

Nope...

[kevin]

Mock Up V010

   Had less than a couple of hours to invest on this today, which i've mostly spent trying to find some alien artwork, so I can at least have a few different aliens types for the mock up level.    Annoyingly the trillion pack is incomplete, and really only comes the player ship and the few buildings you see here.   It'd be great if it had ships,  at least then they match the style somewhat.   In this picture i'm just trying some other tidbits i found sitting around.  I had to change the perspective slightly so that the crab like ships (on the floor) appear to be walking on the ground within the scene.  But ya get that.

   Also, improved the level definition loading by 7 seconds just by using the replacement load textfile function thing - What a coincidence :)
   

[kevin]

 
   Finally found out who made the Trillion artwork, it was guy called Pincho Paxton from the DB community.   He also did the artwork for a number of Amiga games.  The Amiga port of Armalyte comes to mind. 

[kevin]

  Update V011

     Previously the game played from a fixed view.  It was fixed in order to keep the water alpha/wave illusion working.  As if the camera move up (above the water height) for example, then this would break the water/effect.    Since demo it was set up to draw the world in cross section. 

    So In another rather whimsical edit session today,  i've been experimenting with expanding the a players play area to be higher than the screen.  This not only means adapting the scenes perspective, but it changes the feel of the controls since their mouse based.  Which i'm not so sure i like atm.

     While I like the perspective change (even though it took a little longer than I wanted)  it breaks the original water illusion. Since it was plane masked in front of the camera.    The problem is that the player can now move from within the water to above it and vice versa .  When your above it, we need to render the top.  Which creates few little gottcha's, the result (when in this mock up)  does seem worth the effort.  So i can't complain too much.

[kevin]

And after a few more tweaks, you can go from above to bellow and vise versa

[kevin]

Update V012

     With each edit session this example is slowly transforming from a tech demo into a playable game.    The past few sessions i've been implementing some bonus stuff like a front end to the demo, plus the core nuts and bolts of some basic  behaviors for the objects.    There's only four alien objects (that's all the gfx i have :) ).  Which are the outrigger (the big star thing),  crab (green things under water), spin mines and homing missiles.   In keeping with the cut and paste nature of the demo, the homing missiles code was cut and paste from one of clever coder programming challenges.    Initially the missiles were classed as bullets,  which meant you couldn't shoot them.   This seemed a bit too unfair though, so they've been re-classed as alien objects.   Which feel betters, but still rather challenging to avoid them !

     In the shot you can see the homing missiles and that i've been experimenting with the player bullet count.  So now you fire 5 bullets at once.  The extra bullets aren't aligned to the ship, they're just spawned at some fixed offset.  It's just to get an idea of the potential  load the player might place on the demo if they had more weapons.     I've got some weapon pick up graphics that i might as well throw in to complete the frame work.   

     I really wouldn't mind making a full level out of it, i'm pretty happy with the feel of it, even though it's impossibly hard ATM :)..   but I really shouldn't waste too much more time on it now. Maybe later...

[kevin]

Added RawImage Animation Library

  Yesterday's session started out as a quick tinker to implement Power Ups, but soon turned into building an impromptu image animation pack format.  Which is something i'd been meaning to implement into this demo for while, but hadn't got around to it.   Previously image animation sequences were stored as a series of frames on common images (BMP,PNG) . To load them, we're load the image and cut out the fixed size frames. While this is a adequate enough approach, it's just not very optimal in terms of render speed (lots of dead pixels) or memory !

  To quickly demonstrate my point, imagine we have a 32 frame animation of the a character running.  You can no doubt picture that some frames will be wider or higher than others in the sequence (i.e when the character is at full stretch will no doubt be wider than when the character is standing).  But to make our lives simpler we'll often store all the frames as 128x*128y cells.     So regardless of how wide/height the actually graphics of a frame are, all frames will be 128x*128y pixels.

i.e

Code Select Expand



    --------------------------
   |                          |
   |          WWWWW           |
   |          o   o           |
   |            -             |
   |          \___/           |
   |          __|__           |
   |        /|     |\         |
   |        ||     | |        |
   |        ||     | |        |
   |        ||     | |        |
   |       **|=====| **       |
   |         |     |          |
   |         |  |  |          |
   |         |  |  |          |
   |         |  |  |          |
   |       ***** *****        |
   |                          |
    --------------------------





   Beautiful ASCII huh :) , anyway, if we imagine the above is one cell from our character animation. You can clearly see the actual graphic is only using about a 1/2th of the frame area.   The rest ends up as transparent pixels (wasted space).   While we won't see extra area when we render this frame (with a colour mask), this extra rendering (even though it's transparent) it will effect the speed of rendering.   Why ? - It's simple, every pixel you draw costs a pretty fixed amount of processing time.   So the more pixels you draw (the bigger the image), the more time the computer must invest in rendering this image.  The other factor is memory. The bigger an image gets the more memory it will require.  The more memory, the muscle the machine need to the deal with it.

    So for comparison sake, lets say the above frame actually is 64x*128y pixels, so rather than grabbing the entire 128*128 block, what if we just grab the used area instead ? Obviously, we'll be saving ourselves memory and this smaller frame will be easier for the computer to render.

   Original Frame size 128*128 = 16384 pixels in this frame 16384 *4 = 65536 bytes 64k)

   Clipped Frame size 64*128 = 8192 pixel in this frame 8192*4 = 32768 bytes 32k)


   That's a 50% saving, which is pretty considerable since we're only looking at one frame. While we probably wouldn't get the same level of saving on every frame in our character animation, we've no doubt be able to reduce the majority of them. It's not uncommon to get 25% saving on average.   Which really adds up.

   For example, if we have 32 frames of 128*128, that requires (32*65536) 2,097,152 bytes (about 2 Meg )

    If we trimmed the anim frames and reduced the animation to 75% of it's original size (a 25% saving) the trimmed animation would only require (2,097,152 * 0.75)= 1,572,864 bytes (about 1.5 meg) - That's a 500k saving for just a little effort. 

   
    Which finally gets me back to my topic,  so knowing that we can improve performance and save memory by optimizing our images for dead pixels.   I decided to write a simply library that would take pre-drawn, or dynamically created animations (stored in an array), trim the frames down and save them out  in a simple pack file format.   This has added advantages over the loading and separating method also.   The main one, is that it's far more efferent in terms of memory during loading, it's can also be faster (assuming your loading FX images).   Previously, if you stored many animation frames on a single image, this meant you need to load (and decompress) the image into memory first.  Next you'd grab the require frames and delete the loaded version.   During the grabbing  period though,  you've effectively got two copies of the image data in memory.     While this isn't a big problem on modern systems, it can make all the difference when running your application on older systems with less system and video memory.   

    So to recap the benefits of  trimming our animations of dead pixels,

    *) Faster Rendering due to reduction of pixels

     *) Faster Collision due to a reduction of pixels

     *) Minimizes the amount of memory each frame requires.  (This also has the added benefit of being more cache friendly on older machines - i.e can help with speed also)

     *)  Faster & more memory efficient direct to surface loading       

     The  main negative is the pack files aren't compressed, so they are larger on disc when compared to their compressed counterpart.   This is negated when the files are zipped into a package though,  as the resulting files generally (+ or - a few K) come of the same size. 

     Anyway, you'll find the RawIMage library ( HERE or the Forest blaster source.   
 

[kevin]

Raw Image Pack File Library

    Here's a version of the pack file library that I mentioned above.  It's been tweaked a bit since last week and now includes a rough as guts palette mapped format also.  This could be improved, I really can't be bothered!    As for how to use it, there's basically four main functions,  a pair to load/save single images and pair to load/saves animations stored in an array().

   This is recommended for use with PB1.63 or above, but is compatible with older version also.

[kevin]

While working on the 1.63h release blend modes I ran into this error in 16bit mode.. Sorta liked it, so here it is :)