Re: [DM-dev] Dungeon Rendering :)

[Stephan B. <ste...@ei...>]

On Wednesday 02 May 2001 14:32, Henningsen wrote:
> 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

That my major flaw in coding:
I set out to do one task, come across a bug, chase the bug, and always=20
end up 4 features away from what I set out to do. I end up with 3 times=20
as many features, but not because I set out to do it ;).

> what you were thinking when you wrote that code. (I hope you put
> lotsa comments in your code too;-)

You'll see some comments like, "too innebriated to deal with this. Fix=20
it later." ;)  I comment to myself only because I have, so many times,=20
gone back even just a week later and said, "what the FU<< was I=20
DOING?!?!"

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

Basically. It's length stays at 5, but it's "relative" length is set to=20
1, and it's height it then set to 5. It's visually the same as rotating=20
it, without actually rotating it. This only works on simple objects,=20
though (the same square type throughout the whole object). Objects=20
which have children can't do this - they would need to actually rotate=20
to make the visuals show up correctly.

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

As it stands, we can hold more data than the original objects, but are=20
still 100% backwards compatible with those as well, at least from the=20
point of view of functionality (as opposed to programmatic usage).

> >Actually, that function is completely untested, but "should work"
> > ;).
>
> Uh-oh. You're not committing without testing your code first, I hope.

That part, yes, because I have no code which can test it yet. Once I=20
get the hierarchy building all tested then it's a simple matter to call=20
room->removeAllWalls() and watch what happens. The code looks like=20
it'll work, though. It uses the typeid() functions to compare data=20
types, which I used a lot in earlier versions of QUB.

> >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
=2E..
> > 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;-)

Still enjoying it! It's a nice challenge, certainly.

Have a great day!

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"...and 'do as you will' shall be the whole of the law." -- ??