Do rendering within actor classes?

I think i know what you''re talking about and i did somehting like this using Singleton classes. The only difference being that i had a render function in each class and i then had a render class calling all the render function. This worked fine for me.

regards,

ace

I know that letting the gameactors draw them self seem like a good OO design. But there can be problems with this approach. If you plan on implementing a multiplayer mode, you will probebly want to handle the AI and updates of you game actors on the server, which means alot of code has to be modified if they have references to your Display and input manager classes.

A better approach may be if you only have your game actors contain an id of a sprite or something, and some flags with info on wether it is visible or not. This leaves the problem of updating the sprites position, having the gameactor update it defeates the purpose completly since then it can just draw it aswell. But in your list of sprites that you render each frame, you could have each sprite have a reference to a gameactor, and update itself.

The way I do it is to have an adapter class which has common graphical functions and passes them through to a more specific class (or set of classes) that implement rendering with a specific API. This way, if I want to switch between, say, OpenGL and DirectX in the middle of program execution, I can just swap out the rendering implementation and none of the rest of the program cares.

What this means is that each of my "unit" objects has "components," which in turn have "output" classes. These output classes know how to draw themselves, but only in the generic terms of the rendering manager. They tell it: "I need a mesh drawn out of this vertex set." It gets the data set from a factory class which keeps a list of the meshes currently in use. In this way one can avoid data duplication.

As for input, I use a separate input manager which collects and handles user input. Objects have a general control class object, which specifies either an AI or an object which checks current user input information and then acts appropriately. In this way, it is easy to add multiple players by just latching a "user-specified" control class onto whatever object you want the player to control.

Of course, I have next to no professional experience, so... maybe this isn''t the way to go.

I've never seen my method mentioned anywhere else, so it might be totally off: bear with me

In my 2D game, I have (what I think is a called a singleton) CRender class that has a STL map with a bitmap and ID as its data. Every frame, my manager queries each object (missiles, characters, terrain, etc...) and generates a vector of int bitmapID's, which is then sent to my CRender class. My renderer searches it's map of bitmap/ID's, and then renders the appropriate bitmap to the screen (you can specify which "cell" of the bitmap for animation purposes as well)

Don't know if it's the best way, but I never liked the idea of providing some sort of surface to each object so that it could draw itself.

edit: it looks like null_void MIGHT use a similar method as I do, based off the second paragraph of his above post... not sure.

[edited by - Peon on April 1, 2004 6:48:29 AM]

Peon: A object doesn''t need to have a surface to draw itself, a more common approach is for an actor to only have a handle to a bitmap or whatever, which is managed the way you described, trough a list or map in a manager class. This is often refered to as a datamanager. Datamanagers work well with handle''s instead of pointers since you can serialize handles. It is also often singletons. There is a great article on this in Gpg 1.

There are two mainstream flavors:

1. let the actor draw itself

GameActor::draw()
{
   GlobalGraphicsManager()::getInstance()->draw(bitmaphandle, xpos, ypos);
}

2. Or draw a game actor:

//loop trough gameactorlist

GlobalGraphicsManager()::getInstance()->drawGameActor(*iterator);