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.