I'm at the stage in my program where I'm developing the underlying game play of the game. How everything is going to interact with the end user, and one thing I don't want to do is apply a generic model on the game, because from my experiences this leads into massive and unpolished code as well as recompiling every 2 minutes to change small things.

I'm never written a collision detection system, which is partly why I'm stuck on it. Actually, it is the reason I'm stuck on it. I have no clue how to go about doing this, and I'll probably be doing the same thing I did when learning the Direct X API. Posting a lot of non-sense about increasing performance, or good practices instead of actually implementing a design myself and playing with it. Hell, with the amount of stuff this game is going to draw on the screen even the most inefficient way (recursive OBB checking) would do the job well. But yet, my mind gets boggled as to where I should start. Now where would that be? Should I start with the Quad Tree so I can utilize spatial partitioning, or should I implement a small interface then improve on that design? I don't know if I should "jump the gun" or start basic, and it really drives me nuts.

Animated sprites are simply an interpolation amongst multiple frames, so as long as time is kept that is fine. Storing the frames, and how they act with a small physics matter is a whole different thing in its self. What I could do is have the sprite manager do all the nitty gritty work of creating and buffering the sprite data. But also have sprite data accessible to the games draw class, which will handle connecting the physics class and the sprite manager. The physics class will deal specifically with the Quad Tree and handle collision. The only problem with this model is I shift a lot of the calculations on the CPU, since all sprites are recalculated to a certain extent. Oh well.

This model puts more stress on the CPU though, but what's it going to matter anyhow. It's not going to resemble anything after 1995 to begin with, and these days CPU is a lesser concern for older style games.

My application was running at 2fps on an Asus Geforce 3 TI 500, I spent two hours trying to figure out what was wrong. Turns out it was the driver. Now it runs at 60. (I never understood why nVidia cards get stuck at 60 either)


A wise main once said, "Forgiveness is divine, but never pay full price for late pizza".