About this blog
Stuff I am doing. Mostly work on either Dravanti or Titan
Entries in this blog
I have done very little programming on either Titan or Dravanti in the last 4 months, hence no update in the journal. I got sidetracked after I went outside one night and saw the stars. I then went back in and dusted my telescope off and have been playing with astronomy again since.
One of the reasons it has taken so long to get back to the PC is that I hit a brick wall when trying astro-photography. My mount is not as accurate as it could be so long exposure images have star trails instead of points. I needed to correct this error and it involved building an electronic device (documented here) to compensate for the errors in the worm gear that drives the mount. So I learnt microcontroller programming using a PIC chip. I now have a device using one microcontroller, an LCD screen, and EEPROM chip and a connection to both a PC and the telescope. After so many years programming PCs it was invigorating trying to write 8-bit assembly to fit an entire protocol emulator and control software into less than 4k of program memory. I intend to keep expanding the device to have more functions such as digital setting circles (displays the current coordinates of the telescope), motorised focusser and maybe a few more bits and pieces. My attempts up to now at astrophotography using an old Quickcam VC webcam can be seen here.
All I have done on Titan recently is to continue writing the .3ds mesh loader. I can load multi-object geometry ok now (needs testing with more files yet though) and I am starting on the material system.
No work on Dravanti as I need the new Titan features first, along with an upgrade to the VirtualFile library that they both use. I have been doing a lot of thinking about the design of the Atrium engine behind Dravanti though. To make it easier for the designer to play around with menus and how the game handles as a whole, I am going to bring scripting in at an earlier stage than I was planning to so that everything is controlled (but not necessarily run) from a script. This will make it more customisable and therefore open the way to people making mods for it as well.
Here I will be documenting the progress of two of my projects, Dravanti and Titan.
Dravanti is a survival horror game currently in development, there are some screenshots of an old test version in the screenshots section of the website just mentioned. I keep a developer journal there as well, but only for that project so I will update this with the latest entry. The engine behind it is what I am working on now and it is named Atrium.
Titan is a programming library that currently loads and saves Jpg, PNG, TGA, BMP and PCX images and is aimed at game/demo development. I am halfway through the next stage for a 2.1 release though which adds 3d mesh handlers as well. The fomats supported for that release will be 3DS and OBJ. I know similar libraries are available (such as Devil), but mine is focussed more on game formats, plus the addition of mesh, sound and animation formats will hopefully keep it ahead of the pack.
Anyway, on with the journal
For the Atrium engine the two renderers (OpenGL+Direct3D) look the same, but when I started working on this test tool I quickly noticed that it was because I am still doing fairly simple stuff. When I try anything half complicated as a test they are very different. I have spent a lot of time the last couple of weeks trying to get them both acting the same, and it is pretty time consuming.So, I am going to do what I considered in an earlier post and put the Direct3D renderer on hold for a while. This will let me continue on with the actual game engine and stop being sidetracked by things like this. Once a playable version is done and we start working with artists/scripting I can use my time to bring it back into play again but for now it is in hibernation.
So, my next milestone is to get a 3d character moving around in the game and a menu. This involves a couple of things -
* The menu. This will be a simple 'New game', 'Settings' or 'Quit' when the game first starts. Settings will probably be empty for now though and just there for effect, but I might put a couple of bits in there.
* A static model loader/renderer. I have started this weekend implementing the model loader into Titan, I will get that loading .3ds and .obj files before I do anything else on the engine and release Titan 2.1.
* Collision detection. I am going to evaluate ODE for this as it seems to be a reasonable system to use, and will hopefully speed up the integration of this part.
* Upgraded Keyboard support. I need to be able to switch the keyboard focus around to anywhere in the game. This is working in the GUI system, but not elsewhere at present. This means that dialogues/menus can be modal or modeless and still work ok without the tons of checking and if statements that would be needed otherwise to check which state the game was in.
Once those bits are done, I can start the next milestone, an animated character and some scripting. This will mean that doors can be gone through, items used, stuff like that. It should be in roughly the same state then as the original mockup and I can start on the cool stuff like NPCs and an inventory.
Thats the plan anyway, things never seem to go that simply :)
Since the 2.0 release I have made a couple of changes to the main codebase. PCX has been dropped as it isn't really useful as a modern format in a game engine. I replaced the linked list code in the Image core with a std::vector to try and keep any bugs out. I have written the core of the Mesh system and have a 3DS loader written that just loads vertices and faces, I am working on loading UV coordinates and materials now. Rich has started adding a DDS Image loader for the DirectX format which is working for uncompressed files at the moment and he is about to start on the compressed formats.
DDS gave us an interesting challenge. The reason for storing textures in DXT1-5 compressed formats is partially to save memory on the video card, but if Titan loads it, it would normally uncompress it meaning that feature would be useless. Also, several different images can be stored in the file (Texture, Mip-maps, Cube map), so how do we handle this? We decided that rather than pollute the normal loading API, there should be a modifier system. This is a state-based thing much like using glEnable() in OpenGL. So all modifiers will have a default state to uncompress DDS files and load the texture image, but by calling TitanModifier(TITAN_UNCOMPRESS_DDS, false) or TitanModifier(TITAN_LOAD_DDS_CHANNEL, TITAN_DDS_MIPMAP_LEVEL_3) you can change the way the handlers work. There will also be some global modifiers for things such as whether to return 3d coordinates in a right-handed or left-handed way.
There will most likely be a pre-release of 2.1 with the new DDS, 3DS and OBJ handlers loading only so that it can be tested while we write the saving routines.
Sorry for the large first entry, let me know if you want more or less detail or generally if you think I am following the right or wrong route with either project.