flipCode - Tech File - Victor Ho [an error occurred while processing this directive]
Victor Ho
Click the name for some bio info

E-Mail: mindspace@bigfoot.com



   03/20/2001, All Good Things


Hey fellow flipcoders, I’m writing this tech file a little over one year from my last entry. Been pretty busy, but anyway here’s what I’ve got to ramble this time round.

Data Loss is a good thing (sort of)


Try3 development has been set back because the partition that held all my source code was formatted over by accident. I had backups, but they were a month old and the worst thing was that the Max plug-in source code was not part of the backup set.

So that basically leaves me with an engine that has no test data available. Cest la vie, but on the bright side, going back into various sub-systems of the engine to re-implement all of that months work, allowed me to improve on a lot of design aspects. It’s amazing how after you’ve worked on a problem and then later re-visit it, so much more seems obvious.

So by the time Try3 is back to it’s original level of capability, the engine should be a lot more elegant to work with. Not to mention the structure is greatly simplified

One of the observations I made when going through the engine code was inconsistent data path for resources used by the engine. Sound data, model meshes and textures were all being handled by different code that was in some ways similar (all had to access the virtual file load up and manage memory) and in some ways different (textures had to be downloaded to HW texture memory) etc.

This reason it turned out this way is because I had no idea in the beginning exactly how I wanted to handle each of the resources my engine would use. Now that almost all the resource types are in place, I’ve decided it time to implement…



A Resource Manager, which is a good thing


Resource managers are good things and if you haven’t got one in your engine, you should seriously consider it. A resource manager allows you centralized control over how data is located, how memory to store that data is allocated and most of all it enforces a consistent interface for coding all the different resource handlers I haven’t found much information out there about how to go about coding a resource manager for a game, other than what Chris Hargrove wrote about in his COTC columns on loonygames (www.loonygames.com ).

But my implementation basically consists of 2 layers. The first layer is the primary resource manager that the rest of the engine interfaces; it takes 2 parameters, a resource type id and a string that refers to the exact piece of data. The second layer, which is hidden from the rest of the engine, is made up of all the specific resource handlers. If any one wants to discuss the exact mechanics of how the whole thing runs, send me an e-mail.



Storing data is text format is a good thing


I’m here to tell you, storing data in plain text is way better than storing it as a binary format. Test files are easily portable, no need to worry about padding and endianess. It also speeds up development time since you don’t have to write all the accompanying utilities like file dumpers, just fire up notepad and you can see exactly what’s going on. This has another advantage; the file format is self-documenting. Open up the file in any text editor and you are basically looking at the file specs.

I implemented my new 3d model exporter to write out text files instead and the whole process of getting up and running was like 2 hours. And right now if I want to play around with the file format a bit, or insert some additional data that I can’t get out of 3DSMAX, like a D3D shader script, I can just do it in notepad! No need to write any custom data massager while I haven’t fully fleshed out the exact format yet; which saves a great deal of tool development and maintenance for a lone programmer like me.



Switching between APIs is a good thing


Boy am I glad I don’t have to do switch to D3D in order to exploit all the vertex and pixel shader tech. NVidia’s OpenGL SDK is finally out and I fully expect nVidia’s implementation on OGL to be adopted by the ARB. But in-between the time DX8 launched and the OGL SDK came out; I had considered switching APIs and thus made the necessary changes to abstract out the API from my core code.

I also started taking another look at D3D. D3D or DirectGraphics if you prefer is very much better now and well worth a look at. I still prefer texture objects to surfaces and simple arrays over index buffers, but on the whole I think it worth becoming proficient in both APIs now.



Scene Graphs are a good thing


I have been spending most of my time looking into scene graphs lately because I’m convinced that a scene graph is the only effective way to work in 3D. To those of you that have developed your own scene graph, you know what I mean. For those you are plain content to use simple arrays of actors and loop through them on each frame, I strongly urge you to look at scene graphs, they are highly OOP in nature and pretty much leave you lots of flexibility for expansion of your engine’s feature set.



Design Patterns are good things


Get the bible on it. I recently did as I found my code coalescing more and more into classes. My early experiences with C++ or OOP is general was very frustrating. I designed objects only to have them come back to bite me later. The object’s interface becomes clumsy to use, or internal data becomes a pain to get at, the list of agonies goes on….

Over time of course my design skills have improved, but it’s taken a long time and for a long time I had kept classes at the fringes of my code base, creating very lightweight classes that did very very specific things.

But I’m beginning to embrace objects more and more now and reading about design patterns has helped greatly. It ‘s really nice to finally see your own design validate against a design pattern. I’ve been a big fan of the strategy pattern but it was only last week that I finally had a name to put to it. If you’ve just finished reading a beginner book on C++ and go read up on design patterns, it’ll save you lots of pain down the road.



Finding the right kind of work is a good thing


Well one of the reason for not updating my tech file (ok, I admit, it’s an excuse J) was that I finally got out of school and into a real job( gotta “pay the rent”). Since Singapore has absolutely almost no game development houses, I ended up at a company that creates on broadband products. But recently I actually uncovered a graphics company that is making some inroads into game development, needlessly to say I decided to hop onboard. I’ll be starting my new job about a month from now. You can expect to hear more about what this job is like in my subsequent tech files.



Having an ending to make way for a new beginning is a good thing


Ok, that’s about all I’ll ramble about from now on (otherwise this tech file will continue to sit around for another year). Next tech file, maybe I talk about some patterns I’ve applied in the Try3 engine.

Until then…





  • 03/20/2001 - All Good Things
  • 07/03/2000 - Hmmm, 4 subsystems in 4 weeks, is that good or bad? : )
  • 06/16/2000 - It started with a big bang.....

  • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    [an error occurred while processing this directive]