The idea is that I can write a game, reference a graphical device, and simply write adapter classes to interact with the commands given.
For instance, I'm currently using a node-based system to represent graphics. Initially, we have a sprite. We know that this sprite is going to draw somehow but we're not using a library to truly determine anything.
Instead, classes using this graphics will use Nodes that contain manipulative data that can be interpreted later:
Sprite *ghost; // Graphical representation of a ghost
Graphics_Device->insert(ghost); // Add it to the rendering list
....
class Ghost_Simple : public Ghost
{
Graphics::Drawable::Node *my_sprite = ghost->makeNode<PositionData>();
...
void update()
{
(PositionData*)my_sprite->getData()->setImgPos( getX(), getY() );
}
}
...
Logically, graphics are represented and the appropriate data (can be defined easily by users!) will define how these graphics will be used later:
// Visitor pattern
class GraphicsAdapterDevice : public GraphicsDevice
{
private:
SomeAPI::APIGraphics::device *device;
void onDraw(Sprite *spr, DrawData* data)
{
TransformableData* d = dynamic_cast<TransformableData*>(data);
if(d!=0)
{
device->drawImage(d->getImg(), d->getX(), d->getY()); // drawImage is part of some API
}
ColorData* c = dynamic_cast<ColorData*>(data);
if(c != 0)
{
device->drawImageColored(c->getColorRGB() ); // drawImageColored is part of some API...
}
}
void onDraw(Polygon *poly, DrawData* data)
....
}
Quickly you should be able to spot the smell. For one, a lot of dynamic casting to figure out what new data is being sent for these graphics to be interpreted. Secondly, every new image type needs to have a new function to draw it.
Another idea I had was to allow the class itself to handle how it was drawn, but it needed to be visited by the GraphicsDevice to know how to handle it. Then that would violate the ability for these classes to be logically represented and completely unusable in case the user decides to switch APIs.
In summary, I love the idea of representing graphics in such a manner that it exists almost as logic, yet separated from game logic, but it can be easily tied to a Graphics API. This code would be virtually portable anywhere and the only portions the coder would need to worry about is writing the adapter graphics device to render graphics correctly based on some API. (but have all the information they'll need to do so!)
I would appreciate the help getting this model represented correctly. Or perhaps I'm looking at it the wrong way.
Thanks in advanced.
