Hello, I know that for the most part, Games aren''t exactly strict on C++ and classes. I also know that quite a few frameworks exit out there. Most are, IMO a bit MORE than I''d like. I prefer (personally) just having a few helper classes and some helper .cpp files (like the ones in TANSTAAFL''s book). One thing though. For supporting FullScreen and Windowed (and for debugging, windowed mode is a nice thing), the code can get hairy. I was thinking of making a Screen class to encapsulate all that ugly stuff. What I''m fishing for here is opinions on what constitutes ENOUGH. I don''t want to bloat a class to the point where it''s a bottleneck in performance, but I would love to have a wrapper to handle setting up modes (and clippers) and switching them easily. I''d imagine that some logic to Restore surfaces would go into it, but that''s about all the further I''ve gotten on this chain of thought. If nothing else, the thought of how far people go on frameworks (from none to, say the level of CDX) is an interesting topic of discussion. Eboz Outside of a dog, A book is man''s best friend. Inside a dog, It''s too dark to read anyway. -G. Marx p.s. Bragging rights to the person who can identify where I got my net name from.

My ideal Screen class would let me use GDI, DirectX or OpenGL else that can be used to render to the screen. It''s actually not that hard with 1 exception, you have to wrap all the functionality of all those APIs into generic function calls.

I started to do this on one of my graphic engines because I wanted to place the graphic library in an external DLL. It worked surprisingly well. All I really needed to implement were some basic features such as:
HSURFACE (a handle to generic surface information)
CreateSurface
FreeSurface
ClearSurface
BitBlt
TextOut (which simply used BitBlt to blt text on the screen)
SetPixel/GetPixel

The DLL initialized a function table struct and it returned a pointer to that struct to the module that loaded it. Very cool and surprisingly quick. Of course it''s not as quick as if it were compiled in the executable (dereferencing the functions in the function table takes an extra clock cycle or 2), but for a tile-based game it ran fast enough.

With just these few functions and 1 new typedef (HSURFACE), I was able to render isometric tile-based screens with no problem.

I think with just these basic features and maybe a few extras, then you can have yourself a nice portable screen emulation class.

---

Dino M. Gambone
Good judgement is gained through experience. Experience, however, is gained through bad judgement.

---

in DX8Graphics, it is a rather simple matter to switch from a fullscreen to a windowed environment. the only difference is the present parameters you use to set up your device.

i have written(not for the book) some classes that will work with DDraw7, and allows for construction of a primary surface and back buffer in either windowed mode or fullscreen. naturally in windowed mode, the back buffer isn''t a true back buffer, but a double buffer that is blitted to primary surface. i set up my classes so that you could just use Flip, and it would, depending on fullscreen or windowed either flip the buffers or just copy from the double buffer to the primary surface, without a need to change any of the code other than how you are creating your CDisplay object(which wraps up the functionality of the IDirectDraw7 COM interface).