 |
|
|
|
Monday, September 30, 2002
More thoughts on collision detection in the past week - I have designed the approach that I am going to take, it is all in theory at the moment but it should work in practice. The problem that I have is that I want all robots in the game, ie both those controlled by the player and those controlled by the ai to be fundamentally the same, so that for instance if I want to play one of the enemy robots the game should handle that. This means that the collision detection algorithm must be run for every robot that is being processed at the time. If there are 20 robots on the map then the collision should be run for all 20 against the map. Shortcuts may be possible but to start with I want to implement it in this way - it should be relatively easy to add multiplayer then if I choose to do so.
Here is some technical info:
There are a number of optimisations that can be made, such as determining which rectangles to test for a tile. My thoughts are to use a list or tree structure that will allow me to determine the areas to test for a particular side of the tile, plus the order of rectangles will be significant - the list or tree should present the rectangle(s) closest to the edge first, so that the destination coordinates can be adjusted to prevent overlap. Off-screen robots will potentially only need their bounding rectangles checked, as if no one sees whats happening then who cares about being pixel perfect. I won't have anything less than pixel collision detection for on-screen objects though. Holiday soon so I may not have another chance to post for 2 weeks or so. I must say thanks to NeHe for the mention of Paradroid on his site, although it will be some time before anything playable is released from here. Listening to: RobbFritt - Ultimate (heard on scene radio SceneMusic.net) Occasionally Playing: Jedi Outcast, Medal of Honour: Allied Assault Wednesday, September 25, 2002
Cleaned up a few more bugs in the engine, not much else recently. I'm heading off on a cruise to the South Pacific for a two week holiday shortly, and work has been taking up a lot of time getting things finalised to I can go. Doesn't look like I will get time to enter NeHe's halloween competition now, unfortunately, but by the time the next one comes around I should be ready... Oh and I bought a Hercules TFT monitor so I can now code with dual monitors which makes debugging much easier.
Thursday, September 19, 2002
Well now I have the engine mostly done I went back to my todo list that I did back in January before the 6 month break. Surprisingly, I have managed to stick to the list so far with the exception of the level editor that I should have written by now but I am putting off for a while yet. I can get by with test data for a while (especially as my test data is a deck from the original game ;) ).
So according to the new revised todo list I have the following to do:
It is still a long list but nowhere near as daunting as it was before, and most of the stuff will be interesting work. Wednesday, September 18, 2002
Tuesday, September 17, 2002
I had a bit of time today to clean up the code a bit and incorporate support for the compressed file library. On compiling a test release version I noticed a number of bugs caused by elements of the animation structures not being correctly initialised when they are loaded. They are fixed and I have compiled a test version of the current code which is available here. Note that in the current code, the doors snap open at the start (there is no collision detection at the moment, so I just activate all of the game objects) and the only controls at the moment are the arrow keys and escape.
If anyone tries it, feedback would be helpful ;)
Some major revisions to the code last night to remove the need for a frame manager. "Frames" in the context of the engine are basically a set of spatial and texture coordinates for the top left and bottom right of a texture - an animation consists of multiple frames that are played back in sequence. An object can now inherit the frame code to provide the ability to quickly render a portion of a texture. This of course meant some changes to the file formats and revisions to the loading code to support the new ability. Next up, I am going to change the rendering so that everything doesn't have to render via the same interface - I want to render the map to the screen via a vertex array rather than as a series of immediate mode commands as there are some assumptions that can be made about the number of quads that are displayed on the screen at start time, so that should speed up the rendering there.
PS the logo for the page seems screwed. I re-did it in photoshop yesterday so I must have stuffed something up. Monday, September 16, 2002
Lander blog is here. Nehe is running a halloween programming contest that I may also decide to enter, using tech from the lander demo (if I get time).
Mostly minor changes to the code over the weekend - I don't like to waste too much time sitting behind a computer on the weekends. I did create a nice craft for use in my "Lander/Zarch" project, a blog for the game will appear soon along with a web site revision.
Game-wise, the OpenGL implementation works a treat but there are some things which need to be fixed before I will be happy (if I will ever be happy - eventually I might just have to draw the line so I can start coding the game itself :) ). For a start, a call to the sprite drawing routine went through around 6 layers of code before any OpenGL code was called. This was nice from an architecture viewpoint but a bit too much overhead for a single sprite in the game, given there will be lots of them with the particles and all in there (although they may not be sprites). I have scribbled down some changes to relieve these problems and I will start implementing them later on today. Other changes include the addition of my tga loading code so I can easily read the images out of the compressed file system. Thursday, September 12, 2002
The game is now able to start using OpenGL in either windowed mode or full screen mode now (thanks in part to the great NeHe). There are no graphics rendered as yet apart from a black screen as I have to write a texture loader using libpng. Hopefully the game will be running properly in OpenGL before too long.
I removed the guts of the Direct3D code today so the game was basically just a white window on the screen. I was able to take advantage of this to fix a couple of problems I had uncovered with the basic Win32 application that sits underneath everything:
Firstly, I am using multiple threads within the engine, and the input thread was not terminating when the close button was clicked (yet it was when escape was pressed). Secondly, when minimising the application, it refused to restore. Interestingly, the thread related problem was due to a problem with the window (the window handle was being dissolved before the thread was terminated, thereby releasing it off on its own merry business), and the window minimising problem was caused by the thread (a DirectInput issue). I added a logging system that writes to a file rather than to the debuggers output window. Using this I was able to determine that I had forgotten to release one type of objects (a buffer of clipping rectangles for textures) - oops (one less memory leak at least) So now, I have a blank window, so its on to the OpenGL initialisation code. Wednesday, September 11, 2002
Now thats all done I am happy with the internal structures of the engine. Its time to start on porting the rendering to OpenGL and then it will be off the engine for a while to get the editors for the game done. Might muck around with some 3D stuff too while I am at it, as the engine should handle that relatively easily too, talk on the Llamasoft forums has got me thinking about heightmaps and the Archimedes game Zarch (or Virus on the other platforms). Might make a good simple 3d demo.
Finally the map code is working properly and multiple maps can be loaded in simultaneously, allowing me to link them via the elevators. You can even get to the corners of the map now (and until the collision detection code is in you can get past them to infinity and beyond if you want) :).
More work on the map items and a monster debugging session last night. I had to painstakingly revise the map item xml files by hand to fit the new format (~200 lines for the demo level). I don't know how Andrew Braybook et al used to cope with keying in all of their map data from graph paper in hex. Blech. The map item manager can now recognise and load its own data and then destroy it when it is no longer needed to free memory. On testing, I found a few problems in the code caused by me forgetting that a static variable in a base class is the same in all parent classes, causing my item handles to increment strangely and get out of synch with the data they represent - whoops! Once I got that figured out things went fairly smoothly in the debugging process until the data now loads and unloads properly.
I have also moved most of the rendering code into its own wrapper class to allow me to move more easily to OpenGL. This also allows me to add more features and optimise the rendering code without buggering up the game code. Tuesday, September 10, 2002
Started changing the map item code over to use the new frame factory and basic sprite classes. I has happy to find that I could inherit from the basic sprite class and most of the code in the map item class was redundant, so off that went. The only major change for now is to override the load method to properly handle the map item data format, which will have different requirements to the sprite data (collisions etc). Once I have it working there are a couple of classes that were written six months ago that are replaced by better code now so they can go as well.
I have become dissatisfied with my font routines in general - they work in a relatively crude way, but do not take into account the different widths of characters. A tool called Bitmap Font Builder (see the links page) lets this information be extracted along with a tga texture of the font(s), so I am going to use this. Its not that big a deal but it should make font rendering look a bit better. I also need to implement a decent print function to output strings and perhaps a basic console to control the game at run time. Winamp 3 has been removed until a new version is released, and Winamp 2 has been resurrected. I like the visualisations that come with Winamp 2 although they may be the same. At least they are better than the ones that come with Windows Media Player. Grabbed the WildTangent Spiderman visualisation while I was at it, that Spiderman mesh is sweet. Listening to: John Frusciante "Someones" Monday, September 09, 2002
BTW I hate the influence device sprite in the screenshot below - its too big and not the same as the C64 version. The first task tonight will be to spend some time in VICE and Paint Shop Pro creating a better version. Might try one of my own design for testing too...
Listening To: Fishbone - Bonin' in the Boneyard (well I was before Winamp crashed - as much as I love Nullsofts products, I think Winamp 3 could have done with another cycle of beta testing. At least they could have got rid of that awfully buggy media library until it works properly :P right - where is WinAmp 2.)
Not much progress code-wise over the weekend, I did find a bit of time to update the design document - its still pretty out of date but it is not too bad. I also generated some documentation using doxygen to ease the migration of the map code to the new classes. Still a lot to go in the doc-comment department too.
On reviewing the design document and code I am wondering if it would be prudent to move the rendering over to OpenGL now rather than continue coding for DirectX which may have another wholesale change when DirectX 9 is released (although I could keep it DirectX 8). I like the idea of using OpenGL for rendering purposes as it will be easier to port the code and there will not be too much impact at this stage apart from the png file loading which can be taken care of with libpng. So, out with the Red Book for a quick review (its been a while) and it would be simple to represent a "sprite" as a textured quad, as described by Mason McCuskey in Game Programming Gems 1 - and I could perhaps use different blending functions for sprite effects (hmmmm...) More thinking is required... Thursday, September 05, 2002
 Oooh yeah, thats a fully animated sprite! Another painful session in Visual Studio resulted in the sprites finally appearing on the screen, well technically _a_ sprite appearing on the screen but its a start and there should be no reason why the others wont appear. Had to debug the entire sprite and animation system that I wrote earlier this week but haven't been able to test until today. The sprite system supports multiple types of animation systems and multiple animation sequences for those systems, all defined using xml files so as to be nice and flexible - in fact I can change the sprite size, source bitmap, number of frames and sequence of frames all without recompiling. The doors aren't working in the screenshot above as the collision detection hasn't been done yet, but they do work (you will just have to believe me). Next step is to change the map tiles over to the new animation system and remove a whole lot of redundant code, but I may not get time to work on it until next week... Other things I have to do when I get time: - Redo the influence device sprite graphics, replacing the 'borrowed' ones in the test data (any volunteers to draw some (non-C64) graphics?) - Add fullscreen support to the engine (I was going to wait until I get a second monitor). - Implement support for recreation of lost surfaces and textures (blech). - Find out why the input thread is left running occasionally when the close button is clicked on the main window (still). - Test support on different machines (any volunteers?) Exact Audio Copy is 95% through Up For the Down Stroke, only 3 hours to copy it so far and 5 tracks to go :)
I'm working on a relatively dull VB app for my real job at the moment, and in the background I have been slowly encoding my CDs to Ogg Vorbis format using Exact Audio Copy. Got to one of my favourite Parliament CD's and it looks like there is a problem with the last few tracks - got to track 8 and the error correction went into overdrive and took about an hour to get to 71%. Looks like a task to run overnight :|
I've been checking out Sol's Compressed File Library which I intend to use in Paradroid at some stage to tie all of the media files together into one big compressed file. I will have to have a look at the possibilities of streaming music from said library at some stage, as I have someone creating some music for the game for me - Ogg Vorbis seems the logical option for compression but I am not sure how easy it will be from the CFL. I have read through the info in Gems 3 and understand the streaming functions so it is just a matter of applying them to the library. From reading Sols page it _should_ be possible by storing the ogg files in the archive without compression, but I will have to play with it more when I have time. I am getting ahead of myself with this anyway. Oh and I added a links page to the site, might as well plug my favourites. Listening to: George Clinton and the P-Funk Allstars "Live... And Kicking"
Midway through the rewrite, and I am much happier with the code now. The fonts, sprites and maps will all use the same framefactory class to subdivide and render textures to the screen. A resource manager class is responsible for loading the xml documents and then passing the elements on to the other manager classes for object creation. Most objects now use handles rather than pointers.
Listening to: Violent Femmes "Violent Femmes" Tuesday, September 03, 2002
Another coding session has produced the flexible sprite and animation engines for the game, and the start of a manager interface to oversee the allocation and destruction of the sprites and associated data structures.
Spent some time thinking about the most flexible way to specify the sprites in xml, and I have decided that I need to make some slight changes to the way textures are specified in xml and allocated internally. There is no limit (apart from memory) to the number of animation frames and sequences the engine will allow for a given sprite, but due to texture size limitations on older cards frames will need to be spread over a number of textures - not possible with the existing system. Of course, these changes will impact the map tiles as well, but it is for the better as tiles for the maps will be able to be spread over multiple textures. I have come up with a method to use for the collision between the sprites and the tiles, which should allow pixel-level collision without using up too many CPU cycles and be easy to specify in the map editor. Speaking of which, it is getting close to the time when the editor and other tools will need to be written. |
