Re: [DM-dev] Dungeon Rendering :)

[Henningsen <al...@gl...>]

>xxxDxxx (D == Door)

You should also make a check that the door opening is at least minCorrWidth.
Right now, with a minCorrWidth of 2, if an entity had a radius of 1.5, it
could not pass through this door. Major annoyance!

>If you call setOrientation( Vertical ), the wall will look like:
...
>and won't be rendered (or rendered incorrectly). I want to fix this 
>before I commit the Door stuff.

Yeah. Squash bugs as soon as you notice them, or the code will go all to
hell over time. Whenever I notice a bug, I make it my number 1 priority to
fix it. I mean, there's no one coming after us who *will* fix it if we
don't... and when you fix it soon, you still remember what you were thinking
when you wrote that code. (I hope you put lotsa comments in your code too;-)

>The current implementation of setting a wall's orientation is kind of 
>lame, but it works for our simple case: it simply resizes the wall. 
>Each wall has a Length field. If orientation == Horiz, then it's 
>resized to length,1. If it's vertical, then it's resized to 1,length. 

I don't get that. You mean when the wall was length 5, when you flip it from
vertical to horizontal, it gets length 1 in the process? Or do you mean all
walls currently have width one?

>get/setSquareSubType(): by default this returns -1. Subclasses may use 
>this to set a "sub type" for their square. A Wall square could specify, 
>for example, if it's a corner wall, a "high wall", etc. A door could be 
>open, closed, gold-inlaid, etc. This function is used by Door to hold 
>it's type. The subtype can be collected for the object as a whole (the 
>case with most objects, plus the default implementation) or objects may 
>supply a subtype for a square at at a given x/y coordinate. Currently 
>only Door uses these at all, but it's there for future use if we want 
>it.

We will definitely want lots of wall types in the dungeon, but whether they
will be set here or later (by a program that uses our library) i don't know.
We definitely want to preserve the generation information of walls, to be
able to render different graphics for different wall generations.

>Actually, that function is completely untested, but "should work" ;).

Uh-oh. You're not committing without testing your code first, I hope.

>Load/save is still on the back burner. I spent about 4 hours yesterday 
>completely rewiring the class hierarchy and moving functions around 
>into a hierarchy which made more sense to my brain. We should now have 
>forward-compatible save support so we can drop in binary, XML, 
>GridSlammer, etc. save support with very little pain later on (the pain 
>is only in the parser). We'll simply have to implement new Serializer 
>objects for the new file types. I've still got plenty of work to do on 
>the text-saving version, I think a few more days.

Ahh... I hope you're still having fun;-) 

Peter