I ran the game constantly for over 5 hours last night with no noticeable problems - I also fixed the display of the y-coordinate on the map. The latest pre-alpha test demo version is available for download here - It is totally unsupported though.

Any feedback would be appreciated.


posted by at 8:22 AM (Link)

 The problem may be solved - it appears that either heat or something dubious with my Windows 2000 installation may have been the problem after all. After trying to isolate the problem, removing routines and implementing a memory manager to record allocations and deallocations I can safely say that my game engine is not leaking memory or doing anything dubious. By cleaning the dust out of my PC and installing Windows XP the problem appears to have disappeared - I will leave the game running for a few more hours to see how it goes. I was using an old version of the Nvidia Detonators (31.40 I think - Freedom Force is unfortunately incompatible with newer sets but I just won't bother with that until they fix it), so it may have been something there.

It did seem strange that the simple things that I am doing in the game could cause Windows 2000 to lock up tight. Time will tell.

posted by at 5:46 PM (Link)

 Further investigation into the lock-up bug have not been encouraging :) The application locks up both itself and Windows 2000 including the mouse and keyboard after running for around 5-20 minutes with no debug or ctrl-alt-del available - I was tempted to put it down to processor heat and/or a less-than-satisfactory power supply, but benching Quake 3 Arena has so far not produced the freeze so I may have to accept that it is indeed my code that is breaking windows. I will try benching Q3A again after the system has been running for a while.

I will start debugging the code by the tried and true method of commenting out routines and running it until it does not lock up, then putting them back in one by one until I am certain I have traced the problem source.

posted by at 9:07 AM (Link)

 I have temporarily removed the download for the latest test version as there appears to be a problem that causes it to lock up occasionally. I believe that I have traced it to the code that highlights the collision areas, and I need to investigate further to find out why. I will post the download again when I have fixed it.

posted by at 7:08 PM (Link)

 More work on the base code today, I rewrote the resource manager class to incorporate a number of such classes that I have been using, so rather than having to access game objects via 5 separate singleton classes I only need to use the one. I rewrote the font rendering to properly handle the textures generated by the Bitmap Font Builder tool, I can now use both character sets from the texture.

I changed the map rendering to draw a border around the areas that have special meaning to the collision code and added the tile coordinates from the map data to the screen for debugging purposes. I can now see at a glance whether the engine is checking the correct tiles for collisions, at the expense of performance (runs ok on my GeForce 4 ti but i doubt many cards will handle it). The performance will improve when I optimise the rendering code.

The latest pre-alpha test demo version is available (download removed temporarily). Totally unsupported tho.





posted by at 3:12 PM (Link)

 I can now define different types of collision areas so I will be able to use them to activate the doors and other objects. In the screenshots below there are six areas defined - blocked (green), elevator (red), terminal (blue), recharger (yellow), vertical door (magenta) and horizontal door (cyan). Next up is to add the code to detect when the player moves over one of the areas.





posted by at 4:11 PM (Link)

 More work on the collision detection - I can now load in multiple areas per tile that will be collision areas. I still need to add a little more functionality to the areas to allow me to use them as switches for the doors, elevators, rechargers etc. At the moment the areas are being loaded from the xml definitions into the required objects and I am rendering them to the screen as transparent green quads over the tiles, as in the screenshot below. I might make this an optional function of the engine as it will make the levels easier to debug, especially in the editor.




posted by at 3:15 PM (Link)

 Nearly at the end of the 4 week project for work, so I should have some more time to devote to more interesting projects such as Paradroid soon. Whilst I have been away from the Paradroid code I have been thinking about other projects I could put the engine to use for - I was going to look at doing a conversion of Repton 3, but with Superior Interactive starting back up and producing the official conversions to Windows I don't think that should or will happen now. I will probably look at doing a conversion of my next favourite game - Wizball, especially since there hasn't really been a good version of the game released since the C64 original as far as I know. Retrograde is another of my favourite C64 games but it would be a rather large undertaking with the different styles and large levels involved.

posted by at 10:54 AM (Link)

 Started putting in the collision detection for the tiles last night. I manually added the collision rectangle data for the tiles to the xml document for a tile set (see this post for a description on how I am handling sprite-map collision detection). More thought needs to be given to the actual storage of the rectangles within the game engine however as the engine uses "map items" which are in turn a collection of references to frames. Each frame will have its own collision map so I need to store a pointer or handle to the relevant collision map alongside each frame reference within the map items - a dynamic array of pointers to the list of rectangles for each frame will do for now. To test it I will modify the tile rendering routine to overlay the collision rectangles after drawing the tiles. At least then I can check that my maps were entered correctly! If I can get all that done tonight I will post a screenshot and possibly even a new download to test.

Listening to: Mike Oldfield - Tubular Bells

posted by at 9:54 AM (Link)

 I have finally got a robot sprite that I am happy with - it is partially borrowed from somewhere else though :) I tried blender but I had to disable most of the windows acceleration of my geforce 4 card before it would work and by the time I got that far I couldn't really be bothered learning much more. Anyway the sprite that I have will do for now.



I had a brainwave this morning of building the map editor into the game (or at lease use the game engine to render the editor) - that way I can take advantage of the map and tile rendering abilities of the engine that I have created already. The editor will be completely OpenGL and therefore oldskool in that it won't have a standard windows interface but who cares if it makes it easier to create maps. Repton 3 (on the BBC at least) did this and it was very successful. I must update the design document again so all these ideas aren't lost.

posted by at 9:05 AM (Link)

 Just ordered Game Programming Gems 2 to complete my set as a break from writing SQL using visual notepad :P I absolutely recommend these books to anyone from a programming background that is interested in writing games - the articles provide me with inspiration to code equivalent routines myself. Right - back to work :)

posted by at 11:17 AM (Link)

 More work on the graphics last night, but nothing I am particularly happy with in game so I will probably scrap them and resort to the C64-style display. No screenshots either :) I am going to try rendering some simple robots rather than drawing them, which may produce a better result. Blender looks the business so I will download it tonight and give it a go when I have got to grips with it. I am also about to start implementing the collision detection and planning the actual game logic. I like to write games as state machines (see Game Programming Gems for more information) as it makes the logic easy to understand and extend. It does require planning in advance though - it is high time the game was made playable though.

EDIT: www.blender.org looks to be the site to download Blender rather than www.blender3d.org which appears to be a portal.

posted by at 9:12 AM (Link)

 Work has started on Paradroid again. I have been working on some designs for the robots in the game but I am unsure whether to go for a more realistic style representation of the robots (as in the Amiga/ST versions) with a hud-type overlay to identify them or to use a simple representation like the C64 version. As the engine can easily handle either style I will probably just end up prototyping both styles to see but if anyone has an opinion on this they can email me at the address below. If I get time to add the new designs into the game I will post some shots tonight.

I am also looking for interested beta testers to test the compatibility of the game engine on various systems. If you are interested then send me an e-mail along with some information on your system, os, video card etc and I will compile a list of possible testers. Please only send mail if you are interested in testing various iterations of the engine and sending feedback.

Listening to: Jamiroquai - A Funk Odyssey (still!)

posted by at 9:27 AM (Link)