[DM-dev] idea!

[Stephan B. <st...@wa...>]

I just started working on the Rooms/Walls combos and came up with some ideas 
I'd like to throw by you and see if they sound as useful to you as they do to 
me:

Current DM holds it's own array of ints for the map. I'd like to split that 
into a DMGrid object, which does the same thing but in it's own object. The 
reason is simple:

bool Room::render( DMGrid & );

lets the room "draw" it's contents onto the target grid. Returns false if 
there is some error (out of bounds, etc., though the item would still be 
rendered as much as it could.

Even better would be to make a Renderable interface and have Room and Wall 
subclass that, then we have:

DMGrid::render( Renderable * );

But I'm not sure what the Renderable API would have to look like (it would 
have to be generic enough to allow the DMGrid to handle drawing for all types 
of objects, and this seems a bit complex). I'd appreciate any ideas on a 
Renderable API which would allow DMGrid to handle all the rendering. That 
would allow a single point of operations for all drawing activity - we could 
add any number of Renderable objects without changing the drawing code. But 
we do have to make a flexible and not-too-much-work-for-the-coder way of 
representing the render data to the DMGrid. I can only think of providing a 
list of coordinates. Something like this:

DMGrid::render( Renderable *rendit )
{

// Point == pair<int,int>
// CoordsList == list<Point>;
...
CoordsList cl = rendit->GetRenderCoords();

// now iterate through cl, take out the x/y coors, and call
// this on each iteration:
{
    DungeonMaker::SquareTypes sq = rendit->GetSquareType( x,y );
    SetSquare( x, y, sq );
}
...
} // end render()

The problem, though, is that rendit->GetSquareType() has to have a way of 
returning that data which does not overburden the maintainer of the 
Renderable class which we are working with. If it's too much work for the 
coder for each new class, I don't wanna do it. If we can, though, then any 
item which is Renderable can be drawn onto the map easily and painlessly with 
very little coding.

For now I'll go with the first option (much simpler, though not as 
watertight).

Either way, it abstracts our data representation and allows non-DungeonMaker 
objects access using a simple interface.

Does this sound okay? It would also mean simplification of the DungeonMaker 
class internals and API (plus adding Set/GetGrid() methods).



----- Stephan Beal - st...@wa...
http://qub.sourceforge.net  -  http://stephan.rootonfire.org
http://dungeonmaker.sourceforge.net
"Now I'm not normally the kind of person who likes to trespass, but
sometimes you just find yourself over the line." -- Bob Dylan