Object-Oriented rendering logic question

Whatever you do, try and localise the code. Since this code will only be used within the hbStaticBitmap class, I think it is safe to put it in there.

From a pure OO perspective, the hbStaticBitmap class is considered a class, meaning it only holds information to be used by other classes. Assuming your follow redwyre''s advice (which is a good suggestion) you should have some type of manager or controller object responsible for rendering and it should render the various types objects in your program.
To put it in the hBStaticBitmap class would mean that in any other renderable resource (i.e. 3D model) it to should render itself. This would be bad, so to say. For example, when you change the rendering api to DirectX you would have to modify the code of each resource (static bitmap, anim bitmap...) instead of creating a directX based rendering manager and swapping out your OpenGL rendering manager. Just a suggestion but, it would make things easier for maintenance in the future.

maknowles


==============================
Matt Knowles
Programmer/Game Developer
www.mak-tech.com
==============================

I had a similar question and, in the interest of supporting multiple API's in your program, try something like this:

hbStaticBitmap::Render(CGraphics &p_Graphics)
{
p_Graphics.RenderBitmap(this);
}

This way, for a given bitmap, you can just call bitmap->Render(graphics), where graphics is a rendering context (a series of functions written in either DirectX or OpenGL). The graphics object contains all the function calls that perform the rendering.

Also, from a design pattern standpoint, look up Visitor.

[edited by - Waverider on January 15, 2003 12:21:13 PM]

I tried to modify my previous post but the server wouldn''t complete it so I meant to say:

From a pure OO perspective, the hbStaticBitmap class is considered a "Model" class ....


==============================
Matt Knowles
Programmer/Game Developer
www.mak-tech.com
==============================

quote:

---

To put it in the hBStaticBitmap class would mean that in any other renderable resource (i.e. 3D model) it to should render itself. This would be bad, so to say. For example, when you change the rendering api to DirectX you would have to modify the code of each resource (static bitmap, anim bitmap...) instead of creating a directX based rendering manager and swapping out your OpenGL rendering manager

---

Not if you make some sort of rendering class that can handle both DirectX and OpenGL.

Renderer myRenderer = new Renderer(RenderType.DirectX);
or
Renderer myRenderer = new Renderer(RenderType.OpenGL);

The hBStaticBitmap should have a reference to myRenderer. Then you can just call myRenderer to render.

Thanks for the great suggestions!

I was faced with a similar problem not that long ago, and I actually spent several days trying a lot of different approaches. The final approach may not feel like perfect OOP, but it''s very efficient and clean. It''s also kind of tailored to my specific situation (FYI, this is for Widelands, a Settlers 2 like game - since it''s open-source, you can have a look at the source at http://www.sf.net/projects/widelands/ ):
- I wanted to make multiple rendering backends possible (16-bit software, 32-bit software, OpenGl, whatever)
- you had to be able to blit images loaded from disk as well as animations to the screen
- you had to render the pseudo-3D terrain
- rendering to off-screen surfaces should be possible to cache window elements

What I ended up with is extremely straight-forward. There are only two interfaces (pure virtual classes): class Graphic represents the graphics device and manages loaded images and animations; class RenderTarget is kind of like an OpenGL context in that it can draw primitives into either the screen or an off-screen surface (depending on how it was created). There''s actually _no_ publicly visible image or animation class. Both are simply referenced by an ID number and a manual kind of "garbage collection" takes care of freeing all the memory.

Of course there is a Bitmap class behind the scenes, which also contains the blitting and map rendering code, but that''s only visible from the Graphic and RenderTarget code.

cu,
Prefect