[DM-dev] rotation/orientation: found the solution

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

Okay, I've finally thought of the solution to the rotation/orientation 
problem, at that is to simply remove orientation. It would be useful for 
manipulating objects after their initial placement, but it's turning out to 
be more fuss than it's worth and is requiring more low-level changes than I'm 
up to dealing with. I'm going to abstract Wall and Door into BlockElement (or 
something like that) subclasses. BlockElements look like:

BlockElement( int x, int y, int w, int h, int square_type )

A Wall is just a BlockElement with a w OR h of 1, with the other dim set to 
n. square_type is from the enum DM:SquareTypes. I will propose that we add 
the Door types to this enum, instead of keeping them separate, with 
overlapping numbers. That will allow the Door class to simply be a 
BlockElement as well, with a square_type == to it's door type. That eases 
rendering as well, actually, as the Door won't have to translate. We simply 
add 300 to the current Door values and add them to SquareTypes enum. This
will mean a very simple migration change needs to be made to "legacy" DM 
code, but I think it's the "right thing" long-term.

With this model, walls and doors can also be of arbitrary sizes. The default 
constructors, however, will do the normal thing: 1xN or Nx1 for Walls, and 
1x1 for doors. If you want a 1x20 door, or a 13x2 door, though, go right 
ahead. The BlockElement could be used to make lakes, pits, or any other 
"filled-in" area. Columns, too, would fit will as a BlockElement subclass. I 
don't like the name BlockElement, though. Suggestions for a better name? 
Hell, a Room is just a BlockElement, isn't it, with Walls overlaid? This 
suggests moving this behaviour into DungeonElement, actually. Actually, now 
that I think about it, this is all a suggestions of things which 
DungeonElement can already do. Except for the Door enum still being separate, 
DungeonElement can do this stuff already. I'll experiment with the 
Door/SquareTypes merge, then.

Rotation, I've decided, I will handle at the render level - render it all, 
then rotate that rendered object. Much simpler to deal with, and 100% 
effective for dungeonmaker purposes.

I'm officially back on the PC starting tomorrow (tonight I'm just on to send 
a couple mails), so I should be able to code that by Tuesday night.

Another to-do of mine is to add command-line-style args parsing support to 
PropertyList. This will allow SIMPLE grabbing of command line options to 
libDM clients, like this:

PropertyList args;
int main( char **argv, int argc )
{
  args.parseArgs( argv, argc );
  int angle = args.getInt( "-rotate", 0 );
  string outfile = args.getInt( "-o", "Dungeon.txt" );
...
}

QUB's libs use this approach, and it works really well, allowing easy 
app-global access to arguments. It also allows the app to alter the 
arguments, which can be useful at times. Since a PropertyList object also 
allows saving and loading, it allows you to use config file and command line 
arguments in the same object, merging your configuration data into one object:

args.load( filename )
args.parseArgs( argv, argc )

In this case, command-line-passed args will override any loaded from the 
given file. Then the app can override it's own settings like this:

args.set( "-verbose", true );
args.set( "-dungeonwidth", 120 );
args.set( "-dungeonheight", 110 );
...
DungeonMaker dm = DungeonMaker();
dm.setProperties( args ); // this allows any data source to be used to 
configure the dungeon, as long as they use the same property names. Order of 
the options is not at all important, either.

Anyway...

Good night!


----- 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