HZ: C++ Engine Code Overview

View.cpp/VConsole.cpp: a view painting heirarchy class structure, my goals
for this were to make it fast, and static. So the views precompute their
screen coordinates at "instantiate" time. There are generic things like
a MultiView (for the pane switching in a tab view type setup), a "power
bar" and a text "ConsoleView". 

The consoleview needed a rewrite because while the font rendering stuff 
is halfway decent, every time you write 
to the console it does font rendering, even if the console is offscreen.
It does scrolling just by literally scrolling the bitmap output, not 
particularly good. I have meant to fix this so it stores the characters
and then always generates the current screen of text when you switch to
it.

Map.cpp: not particularly clean, and guilty of premature optimization. I
originally wrote this in C and then "slurped" it up into a class. The
only thing nifty about it is the way the data orginization works for
the sprites. There is a pointer for every "tile" on the map (where a
tile is just an arbitrary size which happens to correspond with the
ground tile size) That pointer points to a list of the objects whose
upper-left corner is on this tile. This is my space partitioning to 
quickly do collision detection, on-screen decisions for rendering
sprites, and some other things.

The code that handles drawing the map to the screen is in here too,
in a class called ViewPort. I have the code which keeps the ship
"in the box" in here in ViewPort::doFollowTick(). I'm not sure
that it really belongs here.

BTW: I think the biggest thing you are missing in your "window
scrolling" to make it feel like HZ is this: you need to stop
having the background pane scroll when you let go of the 
movement keys.

Net.cpp: mostly contains the directplay access stuff, it just allows me
to enumerate and setup direct play connections, not much else

Game.cpp: this is where I export hooks to the Lua (script) language

Sprite.cpp: the game sprites :) Alot of this code started out in the
C donuts demo. I slurped it up into a class, and the boundaries are
pretty fuzzy and poor. Lots of public variables in the class (bad).
There are static object types (which no longer apply), Lua objects
are all theoretically generic objects. There is code in there for
handling what I call "mirrors"

Every object in the world has a C representation and it's script-side
"mirror". The two objects are connected and interrelated. When the
game is running, every object alive in the world has an entry in the
"objects" table in the script language. 

Sprites are stuck into a cross-linked web. Every sprite is connected to:

- the tile it's top-left corner is on (and all the other sprites there)
- all other sprites via a "SpriteList"
- the "SpriteType" object which defines the sprite type's
characteristics

There are many vistigal things in the Sprite instance data, like the
direct draw surface for the sprite, which now comes from the 
sprite type object instead.

Spritet.cpp: this is the most recently written, and thus the better 
code there. It includes the code to parse my "lua sprite
representation", and the associated data structures to store it
in the C side. check out spritet.h, the data structures there are
useful.

HndlMgr.cpp: a crappy thing I worked up to make sure GDI handles get
deallocated when the program exits.