dungeonmaker-develop — Public list for developers and users of DungeonMaker

Re: [DM-dev] okay, just so I'm clear...

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

On Wednesday 06 June 2001 15:58, you wrote:
> I'm actually considering scrapping the dungeon-evolution stuff, due
> to some negative feedback I got on the idea: Basically it was that
> users would always (mis-)use their ability to rate dungeons to try to
> get the highest score, and rate dungeons higher not on the fun they
> had while playing them, but on the ease with which they could beat
> them. If that is done, it will IMO tend to lead towards extreme and
> possibly degenerate dungeons - either very open or very labyrinthine,
> whatever is better for the player to win. That's something I don't
=2E..

How about instead of a rating system, you use a numeric system where=20
high and low values don't correlate to "quality" of the data. I can't=20
imagine really clearly how this would work, but you're strong with=20
numbers so maybe you could fill that idea out. Maybe something which=20
uses percentages, like "75% must be taken up by rooms, 12% must be kept=20
empty." That sounds like a nightmare to code, though (enforcing the=20
numbers in the output). There may be something we can do, though.

Yes, random generation of dungeons (or "assistedly random," where the=20
user says, "I want N rooms, with cheese, hold the mayo...") would be=20
much more useful for me. The idea of evolving dungeons would certainly=20
be a cool testbed for your AI work, though. Maybe you can train a=20
crawler to spell out "We love you, Pete!" with dungeon walls ;)!

> If you come to finish the things you want to do on the DungeonMaker,
> and have switched it over to work with your objects and files, I
> would probably do the rooms-thing even over the warm season, just
> slowly. I can handle writing a bunch of code every week, just not
> keeping up with your furious pace of change;-)=20

Yes, I do change things quickly and without notice often (it's a=20
side-effect of having coded alone for so long). As I wrote last week,=20
my software tends to "grow" instead of being a product of a=20
well-thought-out API. I "learn" the API I need as I work with it, and=20
change it accordingly, from a user's perspective. I find that that=20
leads to a pretty usable API in the end, with something for both me=20
(the developer of the library) and me (the user of the library) ;).=20
That's 100% how QUB has evolved as well, with very little forethought=20
other than the vague "vision" or concept of the software.=20
The DungeonElement API is almost done "growing," though. I'm pretty=20
happy with the API in it so far, but want to make some minor tweaks as=20
I remove the extra classes (Door, etc.). Actually probably 1/3rd of=20
libdm/*.cpp will go away tonight as I flatten out the model.

> Remember though, it
> must compile on MinGW:-( or I'll not work on that branch. The Windows
> market is still quite a bit larger than Linux<sniff>.

That should be even easier after these changes. Once I'm done I will=20
check out the latest MinGW and try it out under VMWare. I'm only using=20
std c++, so the only problems I anticipate are minor build problems=20
(which I'll work to resolve, of course). I don't _expect_ any problems,=20
but if there are any I anticipate they will be in the shell code I've=20
got embedded in the makefiles. We'll see.

You'll see lots of CVS changes tonight. In fact, I may start on the=20
right now. I'm so sick of apache, PHP, Oracle, tomcat, jserv, setting=20
up user accounts and re-orging our server dir structures that I could=20
puke. We got a new woman (sysadmin) in the office yesterday, and she'll=20
take over some of the more mundane stuff soon. I'm looking forward to=20
that. I was online working until 2:30 this morning, and I'm wiped out=20
(in the sense of sick of THIS stuff for a while). I've got 5 days off=20
starting next Thursday, and I plan on doing nothing but Coding. I can't=20
WAIT. Me, the machine, and my bottle of Sprite. And a periodic call to=20
Tony's Pizza, of course (since they bring the Sprite and Spezi)...

----- Stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

Re: [DM-dev] okay, just so I'm clear...

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

>> I had a Wall class like that designed earlier, just the .h file, with
>> WallStartX ,Y , DoorOffset, DoorWidth, ... forget what else...
>
>This is very similar to what I've been thinking, but I didn't know for 
>sure if you were okay with doors bigger than 1 square.

Actually, you should ensure that all doors are larger then minCorrWidth.
Currently I have minCorrWidth = 2, and I expect to have agents in those
dungeons with radius 1.2 or so, definitely over 1. Imagine the fristration
if they could not move through the doors in some dungeons. That's what
minCorrWidth is for, insure that all passages are wide enough for the
agents, so it must be enforced on doors too.

>Easier and harder, actually. The base design is easier, fundamentally, 
>but harder for my brain because I've got what I like to call "The Peter 
>Syndrom," named after my friend and computer mentor Pete Angerani, in 
>Houston. He designs so much flexibility into everything that it never 
>gets finished. You want a text editor which can do your laundry if you 
>write extension LISP code? Pete could do it. He used to "program" 
>pacemakers (it's all done via circuitry, though - no software). He 
>wanted to make them coin-operated, but his mgt didn't like that. 
>I have to back away from that far-too-flexible approach sometimes, 
>because it's not always needed. It's certainly an exercise in 
>self-restraint ;). I agree completely that it's the best approach for 
>this app, though, it's just difficult for me to K.I.S.S. sometimes.

Yes, KISS!! - we all have to remind ourselves of that from time to time.

>Okay, let me finish up and "flatten out" the object moswl and write up 
>a sample app and then we can begin to mix that in with the existing 
>system, or start writing towards the new genetic stuff you want. I 
>suspect that you will want to wait until colder weather hits before 
>doing that, which (of course) is fine. I can start by porting these 
>objects into the existing DM 0.9x/1.0 architecture, and making an 
>intermediary prototype so we can see where we need to go from there.

I'm actually considering scrapping the dungeon-evolution stuff, due to some
negative feedback I got on the idea: Basically it was that users would
always (mis-)use their ability to rate dungeons to try to get the highest
score, and rate dungeons higher not on the fun they had while playing them,
but on the ease with which they could beat them. If that is done, it will
IMO tend to lead towards extreme and possibly degenerate dungeons - either
very open or very labyrinthine, whatever is better for the player to win.
That's something I don't want. So i consider scrapping the evolution thing.
Anyway, I'll do the "random room" thing first, that definitely has higher
priority with me ( and with you, right?). I think next cold season I will
want to do the rooms-thing, the "focal point - precomputed paths"-thing, and
then write a sample game in SDL or Nebula Device. 

If you come to finish the things you want to do on the DungeonMaker, and
have switched it over to work with your objects and files, I would probably
do the rooms-thing even over the warm season, just slowly. I can handle
writing a bunch of code every week, just not keeping up with your furious
pace of change;-) Remember though, it must compile on MinGW:-( or I'll not
work on that branch. The Windows market is still quite a bit larger than
Linux<sniff>.

Peter
http://alifegames.com      website re-launched with new content
read    "Complicity and the Brain: Dynamics in Attractor Space"
at           http://alifegames.com/project/ComplicityBrain.html

Re: [DM-dev] okay, just so I'm clear...

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

On Tuesday 05 June 2001 23:38, you wrote:
> Generations should potentially go up to 100, for large dungeons/small
> maxAge's - I haven't explored that yet but it should remain possible.

That's no problem. The enum can be extended. Also, for all functions=20
which use the enum, I've made them take "int" instead of "SquareType"=20
just for this reason: so people can extend the square types and pass=20
them to "core" functions without having to modify the SquareType enum.

> > be recreated from the grid, is my point. This is the environment
> > the crawlers want, if I remember correctly, so we can get a nice
> > separation of the "dungeon basics" and the "fleshing out" of the
> > dungeon by the crawlers.
>
> Very good, this is indeed what the Crawlers want, every cell one
> value designating its content.

Excellent. This allows us to keep the user-side design completely=20
separate from anything the crawlers need.

=2E..

> I had a Wall class like that designed earlier, just the .h file, with
> WallStartX ,Y , DoorOffset, DoorWidth, ... forget what else...

This is very similar to what I've been thinking, but I didn't know for=20
sure if you were okay with doors bigger than 1 square.

> > data is easily user-editable, so they could mix/match if they want
> > by using emacs (though editing with vi must be righteously
> > unsupported ;).
>
> I guess. If I do the "dungeon evolution" thing, i would also need the
> ability to store data in two files, one "rooms"-file, and one
> "Evolving"-file. I laid those out in an earlier posting.

Yup, I've been thinking about how to handle that. I'm thinking one=20
central object, which is a proxy for several input/output files. That=20
would allow a user to set DungeonElements and genetic data into one=20
place, and that object could then (if needed) split it into separate=20
files. I don't know if that's terribly useful, though.

> Hit things beautifully, i'd say.=20

Oh, good.

> Isn't it much nicer and easier,
> flat-hierarchy style?=20

Easier and harder, actually. The base design is easier, fundamentally,=20
but harder for my brain because I've got what I like to call "The Peter=20
Syndrom," named after my friend and computer mentor Pete Angerani, in=20
Houston. He designs so much flexibility into everything that it never=20
gets finished. You want a text editor which can do your laundry if you=20
write extension LISP code? Pete could do it. He used to "program"=20
pacemakers (it's all done via circuitry, though - no software). He=20
wanted to make them coin-operated, but his mgt didn't like that.=20
I have to back away from that far-too-flexible approach sometimes,=20
because it's not always needed. It's certainly an exercise in=20
self-restraint ;). I agree completely that it's the best approach for=20
this app, though, it's just difficult for me to K.I.S.S. sometimes.

> One thing in case that's not clear: There is no
> need for myself to be able to save dungeons in flat style - all
> saving can be done as higher level objects (in rooms-file). The

I'm trying to take the approach of the higher-level user (i.e., QUB),=20
but you're right in your statement below, I think:

> Dungeonmaker then reads those in, generates flat dungeon, and
> delivers pointer to that dungeon map to library users. Generally,
> users will put more data on the map, and save the map in their own
> format and style.

That's what I'm thinking, as well.

Okay, let me finish up and "flatten out" the object moswl and write up=20
a sample app and then we can begin to mix that in with the existing=20
system, or start writing towards the new genetic stuff you want. I=20
suspect that you will want to wait until colder weather hits before=20
doing that, which (of course) is fine. I can start by porting these=20
objects into the existing DM 0.9x/1.0 architecture, and making an=20
intermediary prototype so we can see where we need to go from there.

See ya!

----- Stephan
Generic Universal Computer Guy
st...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

Re: [DM-dev] okay, just so I'm clear...

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

Stephan Beal wrote:

>In the end, logically, we will have a grid with N objects on it. These 
>objects can be doors, walls, open spaces - anything defined in the 
>DM::SquareType enum: (DM.h)
>    enum SquareType { sq_None = -1, sq_Floor=0, sq_X=1, sq_Wall=sq_X, 
>sq_Hash=2, sq_Open=3, 
>                       sq_C=4, sq_Reserved=5, sq_Y=6, sq_Door=7,
>                       sq_Gen0=10, sq_Gen1=11, sq_Gen2=12, sq_Gen3=13, 
>sq_Gen4=14,
>                       sq_Gen5=15, sq_Gen6=16, sq_Gen7=17, sq_Gen8=18, 
>sq_Gen9=19,
>                       sq_Gen10=20, sq_Gen11=21, sq_Gen12=22, sq_Gen13=23, 
>sq_Gen14=24,
>                       sq_Gen15=25, sq_Gen16=26, sq_Gen17=27, sq_Gen18=28, 
>sq_Gen19=29,

Generations should potentially go up to 100, for large dungeons/small
maxAge's - I haven't explored that yet but it should remain possible.

>Each cell is completely independent of any other cell. For ease of writing 
>new dungeons, we abstract some of that into higher-level objects like walls 
>and rooms (which are only a wrapper around 4 wall objects). These objects are 
>not hierarchical in any way, and not related to one-another. For flexibility, 
>the high-level objects can be "moved around" in the grid while "in memory", 
>and are then rendered to an integer-based grid (the top-level container 
>object, the "Dungeon"). This means, for example, that a coder could do this:
>room->move( 5,7 );
>Once it is rendered to the grid:
>dungeon.renderTo( mygrid )
>the data "in the grid" is immutable as an object - each cell must then be 
>dealt with independently. The higher-level objects cannot be recreated from 
>the grid, is my point. This is the environment the crawlers want, if I 
>remember correctly, so we can get a nice separation of the "dungeon basics" 
>and the "fleshing out" of the dungeon by the crawlers.

Very good, this is indeed what the Crawlers want, every cell one value
designating its content.

<snip> ...
>This would assume that all walls get a door near the center, or we could use 
>a slightly stricter format:
>wall=x,y,w,h  // no walls
>dooredwall=x,y,w,h[,doorx=(x+w/2),doory=(y+h/2),doorwidth=1]

I suggest we use a format for the higher level (design-program) objects
where every wall contains data fields for doors, such that doors can be
anywhere in the wall and any size. That for every wall, then they are easier
to parse. You could have a different name for "WallWithNoDoor" which would
be mostly for user convenience, and which would have fewer data fields.

I had a Wall class like that designed earlier, just the .h file, with
WallStartX ,Y , DoorOffset, DoorWidth, ... forget what else... 

>Using an altered version of the config file object we can use hopefully use 
>that object for the storage of DungeonElement and other dungeon data, like 
>the stats data, etc., using ini-style settings for those as we've discussed 
>before. Then rooms data can be stored in the same file with the stats, etc., 
>but each type of data is easily user-editable, so they could mix/match if 
>they want by using emacs (though editing with vi must be righteously 
>unsupported ;). 

I guess. If I do the "dungeon evolution" thing, i would also need the
ability to store data in two files, one "rooms"-file, and one
"Evolving"-file. I laid those out in an earlier posting.

>Have I hit everything, or just beat around it all?

Hit things beautifully, i'd say. Isn't it much nicer and easier,
flat-hierarchy style? One thing in case that's not clear: There is no need
for myself to be able to save dungeons in flat style - all saving can be
done as higher level objects (in rooms-file). The Dungeonmaker then reads
those in, generates flat dungeon, and delivers pointer to that dungeon map
to library users. Generally, users will put more data on the map, and save
the map in their own format and style.

Peter Henningsen
http://alifegames.com      website re-launched with new content
read    "Complicity and the Brain: Dynamics in Attractor Space"
at           http://alifegames.com/project/ComplicityBrain.html

[DM-dev] okay, just so I'm clear...

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

Okay, before I redo this, I want to be sure that I'm imagining the right 
thing. If not, please feel free to adjust me in the right direction. This is 
as much a thinking session as it is a question. So... I may answer it myself 
by the end ;).


In the end, logically, we will have a grid with N objects on it. These 
objects can be doors, walls, open spaces - anything defined in the 
DM::SquareType enum: (DM.h)
    enum SquareType { sq_None = -1, sq_Floor=0, sq_X=1, sq_Wall=sq_X, 
sq_Hash=2, sq_Open=3, 
                       sq_C=4, sq_Reserved=5, sq_Y=6, sq_Door=7,
                       sq_Gen0=10, sq_Gen1=11, sq_Gen2=12, sq_Gen3=13, 
sq_Gen4=14,
                       sq_Gen5=15, sq_Gen6=16, sq_Gen7=17, sq_Gen8=18, 
sq_Gen9=19,
                       sq_Gen10=20, sq_Gen11=21, sq_Gen12=22, sq_Gen13=23, 
sq_Gen14=24,
                       sq_Gen15=25, sq_Gen16=26, sq_Gen17=27, sq_Gen18=28, 
sq_Gen19=29,
                       sq_X_EW,  sq_X_NS, sq_X_10,
                       sq_Last // just a placeholder, to control looping
                    };


Each cell is completely independent of any other cell. For ease of writing 
new dungeons, we abstract some of that into higher-level objects like walls 
and rooms (which are only a wrapper around 4 wall objects). These objects are 
not hierarchical in any way, and not related to one-another. For flexibility, 
the high-level objects can be "moved around" in the grid while "in memory", 
and are then rendered to an integer-based grid (the top-level container 
object, the "Dungeon"). This means, for example, that a coder could do this:
room->move( 5,7 );
Once it is rendered to the grid:
dungeon.renderTo( mygrid )
the data "in the grid" is immutable as an object - each cell must then be 
dealt with independently. The higher-level objects cannot be recreated from 
the grid, is my point. This is the environment the crawlers want, if I 
remember correctly, so we can get a nice separation of the "dungeon basics" 
and the "fleshing out" of the dungeon by the crawlers.

The utility in functions like move() and resize() and such are that they make 
GUI-based dungeon editors possible. Users can drag the room around, and it's 
position changed. When it's saved, though, it's "rendered". The down-side of 
saving in this format, though, is that you can't reconstruct it later on. 
Thus these high-level objects need to be able to write themselves out (and 
read from) a higher-level format, like:
room=x,y,w,h
wall=x,y,w,h
door=x,y[,w,h]


In actuality, room and wall will be of the same object type, except that it's 
SquareType will be different. This means that the words "room", "wall", and 
"door" will translate directly to some SquareType value. Hmmm. That means 
that the C++ classes Room, Wall, and Door are overkill, as they are all 
DungeonElements with different SquareTypes (under this slight change in 
thinking, anyway). So all I have to do is remove the add() methods, or 
restrict their access to protected (so higher-level subclasses can be 
created, but client apps can't do it), and then do away with Room, Wall, and 
Door, or make them one-line subclasses for convenience and ease-of-reading. 
Then I've gotta add:

	string toString();
Returns "<sq_type_name>=x,y,w,h"
	static DungeonElement * 
	DungeonElement::fromString( const string & );
Parses a dungeonelement from [something=x,y,w,h].

Then there's the file load/save, but most of that code is already done. It's 
mainly re-org of the existing stuff, I think.

So, we would have a file format which looks (for DungeonElements, anyway) 
like:
room=x,y,w,h
room=x,y,w,h
room=x,y,w,h

Or how about simply:
object=x,y,w,h,square_type
this is less human-readable, however.

This format we can read and write and use to restore a 
programatically-generated dungeon to it's original, object-based state. That 
may not be useful for DungeonMaker, but it'll be very useful for other apps, 
where users can edit their dungeons.

The down-side of this, though, is that if you want a door on your wall, 
you've got to keep track of 2 objects:
wall=x,y,w,h
door=x,y,w,h

If you move wall, you've gotta move door. That's the down-side of a flat data 
format. Of course, we could write code to parse things like:

wall=x,y,w,h[,doorx=(x+w/2),doory=(y+h/2),doorwidth=1]

This would assume that all walls get a door near the center, or we could use 
a slightly stricter format:
wall=x,y,w,h  // no walls
dooredwall=x,y,w,h[,doorx=(x+w/2),doory=(y+h/2),doorwidth=1]

Using an altered version of the config file object we can use hopefully use 
that object for the storage of DungeonElement and other dungeon data, like 
the stats data, etc., using ini-style settings for those as we've discussed 
before. Then rooms data can be stored in the same file with the stats, etc., 
but each type of data is easily user-editable, so they could mix/match if 
they want by using emacs (though editing with vi must be righteously 
unsupported ;). 

Have I hit everything, or just beat around it all?


----- Stephan Beal - st...@wa...
http://qub.sourceforge.net - http://gwm.rootonfire.org
http://byoo.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

[DM-dev] useful C++ macros

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

Okay, maybe this is elementary, but...

Use something like this to easily check for null pointers:

#define CERR cerr << "debug: " << __FILE__ << ": " << dec << __LINE__ << ": "
#define G_ASSERT(ptr, msg, ret) if(!ptr) { CERR << msg << endl; return ret; }


void 
foo( obj * )
{
	G_ASSERT( obj, "no, no, no: obj may ! == (!something)", );
// note the ending: ', )' because this is a void function.
...
}

I'm not a fan of assert(), since it exit()s, but these fit the bill nicely 
as long as you're in the habit of doing error checking on return values 
(and you are, aren't you?). If you're writing with a UI toolkit, change 
G_ASSERT to launch a dialog instead.

I particularly like the CERR macro, because it's a drop-in replacement 
for cerr/cout/clog, with the benefit of additional debug info:
CERR << "use it just like cin or cerr. " << dec << 42 << "." << endl;


----- Stephan Beal - st...@wa...
http://qub.sourceforge.net - http://gwm.rootonfire.org
http://byoo.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

Re: [DM-dev] Door parse error

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

>This has GOT to be a compiler error. I'm going to try renaming the class 
>entirely, but I don't foresee that as being helpful.

Or it could be a Makefile error, right? What is you renamed Door.h to Wall.h
and vice-versa? Wonder what happens then...

Peter

[DM-dev] Door parse error

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

I just do not get it. If I #include Door.h directly above the line where I 
first use it, it compiles, but doesn't link. If I include it anywhere else, 
it gets included (or does not give an error about not being included) but 
does not compile.

I took the #ifdef... out of Door.h to prove it is being included. Yes, it is.

GGGGRRRR!!!!!! I don't understand!!!!

ASF80[y245780[4`7809-@#!1`2!$!$@!$@#@#

This has GOT to be a compiler error. I'm going to try renaming the class 
entirely, but I don't foresee that as being helpful.

----- Stephan Beal - st...@wa...
http://qub.sourceforge.net - http://gwm.rootonfire.org
http://byoo.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

[DM-dev] Fwd: WG: GCC 3.0's giant step forward

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

GCC 3.0 coming out soon :)

----------  Forwarded Message  ----------
Subject: WG: GCC 3.0's giant step forward
Date: Fri, 25 May 2001 14:01:15 +0100
From: "michael oberhuber" <mic...@ei...>
To: "stephan" <ste...@ei...>, "Amir@Einsurance. De"=20
<am...@ei...>


> -----Urspr=FCngliche Nachricht-----
> Von: Lin...@it...
> [mailto:Lin...@it...]
> Gesendet: Freitag, 25. Mai 2001 13:04
> An: mic...@ei...
> Betreff: GCC 3.0's giant step forward
>
>
>
>
> LINUX TIPS AND TRICKS --- May 25, 2001
> Published by ITworld.com -- changing the way you view IT
> http://www.itworld.com/newsletters
> __________________________________________________________________
> ______________
>
> HIGHLIGHTS
>
> * GCC 3.0's imminent release has developers salivating over improved
>   compiler technology, language support, portability, and
> performance.
>
> SERVICES
>
> * Career Corner: Earn your Linux certification!
> __________________________________________________________________
> ______________
>
> SPONSORED LINK
>
> ** FREE APACHE SSL GUIDE FROM THAWTE **
>
> Planning Web Server Security? Find out how to implement SSL! Get the
> free Thawte Apache SSL Guide and find the answers to all your Apache
> SSL security issues and more at:
> http://ad.doubleclick.net/clk;2858499;4609756;h
> __________________________________________________________________
> ____________
>
> Get Ready for GCC 3.0!
> By Danny Kalev
>
> As we all know, Open Source products don't have rigid deadlines.
> However, the tentative release of the new GCC 3.0 compiler scheduled
> for June 15th is a significant leap in terms of compiler technology,
> language support, portability, and performance. This week, I will
> present the novelties and enhancements of the imminent GCC 3.0
> compiler.
>
> GCC 3.0 New Features
> While GCC supports several languages, including Fortran, Objective C,
> and Java, its first and foremost usage is as a C/C++ compiler. In
> this regard, the development team has invested a great deal of work
> designing, implementing, testing, and bug fixing. The new version
> will support the C++ Standard Library properly. Up until now,
> essential components of the Standard Library were missing, such as
> the <locale> and <sstream> libraries, while other components of the
> C++ Standard Library have been supported only partially. This is
> going to change soon, as GCC 3.0 includes a brand new implementation
> of the Standard Library.
>
> Another major change is a new Abstract Binary Interface (ABI). For
> this reason, no binary compatibility exists between GCC 3.0 and older
> versions of compiled code. However, unlike previous releases, the ABI
> is stable and expects to remain unchanged in the following releases.
>
> In terms of core-language features, the 3.0 release fixes some minor
> bugs and includes a newly written preprocessor. Tighter support of
> C99 is also expected, although the new release doesn't fully support
> the new C standard yet.
>
> Regarding compilation technology, GCC 3.0 is expected to compile code
> faster; some tests showed it 40% faster than its predecessor.
> Compiling large amounts of code and applications that make extensive
> use of templates make this improvement much more noticeable -- an
> area that has been pretty neglected thus far.
>
> Additional changes you'll find in GCC 3.0 include:
>
>     * GCC 3.0 will offer better Java support. Unlike previous
> releases, the Java standard library should be included in the new
> release. Thus, users won't have to download it separately;
>     * Apparently, GCC 3.0 will not support the Chill language anymore
>       due to a lack of interest (and volunteers);
>     * The creators of GCC 3.0 ensure that the generated code's
> quality is at least as good as its predecessor. In fact, it seems
> that the new release will be better in this regard.
>
> For more information on GCC 3.0, visit the official GCC Web site at
> http://gcc.gnu.org.
>
> About the author(s)
> -------------------
> Danny Kalev is a system analyst and software engineer with more than
> 10 years of experience, specializing in C++ and object-oriented
> analysis and design on various platforms including VMS, DOS, Windows,
> Unix, and Linux. His technical interests involve code optimization,
> networking, and distributed computing. He is also a member of the
> ANSI C++ standardization committee and the author of ANSI/ISO C++
> Professional Programmer's Handbook (Que, 1999). Contact him at
> li...@ex....
> __________________________________________________________________
> ______________
>
> ADDITIONAL RESOURCES
>
> GCC Development Tools
> http://www.itworld.com/jump/lintps_nl/www.palmos.com/dev/tech/tools/g
>cc
>
> GNU Compilers on Win32
> http://www.itworld.com/jump/lintps_nl/www.geocities.com/Tokyo/Towe
> rs/6162/gcc.html
>
> The Linux GCC HOWTO
> http://www.itworld.com/jump/lintps_nl/www.linuxdoc.org/HOWTO/GCC-HOWT
>O/ __________________________________________________________________
> ______________
>
> CAREER CORNER
>
> EARN YOUR LINUX CERTIFICATION WITH WAVE TECHNOLOGIES
>
> Show 'em you've got the skills when you earn your Linux certification
> with Wave. You'll cover not just one Linux distribution but the most
> common distributions in use. Wave trains thousands of IT
> professionals a year and we know what it takes to succeed?expert
> courseware, great instructors and top-notch mentoring. Get certified
> GUARANTEED or your money back! Register to win a FREE BOOT CAMP OF
> YOUR CHOICE! http://ad.doubleclick.net/clk;2856806;5495913;w
> __________________________________________________________________
> ______________
>
> CUSTOMER SERVICE
>
> SUBSCRIBE/UNSUBSCRIBE:
> - Go to: http://reg.itworld.com/cgi-bin/subcontent12.cgi
> - Enter your email address under "Current subscriber" to log in
> - Uncheck the box next to the newsletter you want to unsubscribe from
> - Or check the box next to the newsletter you want to subscribe to
> - Submit
>
> If you have questions, please send email to customer service at:
> mailto:su...@it...
> __________________________________________________________________
> ______________
>
> CONTACTS
>
> * For editorial comments, write Andrew Santosusso, Associate Editor,
>   Newsletters at: and...@it...
> * For advertising information, write Dan Chupka, Account Executive
> at: dan...@it...
> * For recruitment advertising information, write Jamie Swartz,
> Eastern Regional Sales Manager at: jam...@it... or Paul
> Duthie, Western Regional Sales Manager at: pau...@it... *
> For all other inquiries, write Jodie Naze, Product Manager,
> Newsletters at: jod...@it...
> __________________________________________________________________
> ______________
>
> PRIVACY POLICY
>
> http://www.itworld.com/Privacy/
>
> Copyright 2001 ITworld.com, Inc., All Rights Reserved.
> http://www.itworld.com
>
>
>
>
> **SEND TO A FRIEND**
> Share this email with a friend! Click here!
> http://itw.itworld.com/GoForward/a14724a35445aSa75969426a18
>
> SUBSCRIBE/UNSUBSCRIBE
> Please click on the link below to modify your subscription,
> unsubscribe, or change your email address:
>
> http://itw.itworld.com/Change-Remove/a14724a75969426a18

-------------------------------------------------------

--=20
----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
It's a thankless job, but I've got a lot of Karma to burn off.

Re: [DM-dev] reward: what the Hell is wrong with this code?

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

>I don't particularly want a structure with all headers in one common .h 
>file, mainly because it requires a rebuild on all cpp files for minor 
>changes to one header. While I've programmed as a hobby since I was a 
>kid, I didn't learn OO concepts, nor do anything "big" (more than a few 
>thousand lines) until I learned Java (started 5 years ago). Java has 
>very strict rules about classes and their files:
>* 1 public class per file
>* That class must have the same name as the file which contains the 
>sources (in c++, this is translated to mean one .h and one .cpp per 
>class).

Yeah, that is a widespread style in C++ too, but I don't like it much. It is
OK when one works in Kdevelop with a class browser, but in XEmacs it is much
easier to work when the number of files is smaller. For my next project (the
Big Project, as I call it on my soon to be relaunched site;-), I'll make
rules about programming style, and one of the rules will be to keep all the
classes from one module (like rendering or simulation) in one cpp/h file
combination. As long as compile time is under 1 minute, I'm not worried at
all by having larger files. Even compile time of 3 minutes is nice - like a
commercial break, giving me a reason to get up and move my body or get a
drink or do whatever one otherwise easily forgets in the rush of
coding/debugging.

If you put the contents of Door.h in Wall.h you'd at least know for sure
whether the problem is a missing .h file.

Anyway, good luck,
Peter

Re: [DM-dev] reward: what the Hell is wrong with this code?

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

On Thursday 24 May 2001 00:47, you wrote:
> Ok I did, and it did compile alright. But the thing in main_hierarchy
> baffles me as much as you. I simplified the line in question, and the
> same mistake occurs, if you just declare in the first line of the
=2E..
> mistake. Forgot to do that while I was still in Linux, but then you'd
> not want your code to have that structure, right? Some Makefile where
> Room is last or treated in some special way that might result in
> this?

Damn. I was hoping a second pair of eyes would see something stupid I'd=20
forgotten. I first thought it was a problem with my:
#ifndef FOO_H
#define....

thought perhaps I had a duplicate of DOOR_H. That wasn't the case,=20
though. I renamed all of those to DM_CLASSNAME_H because I thought=20
perhaps "DOOR_H" may be defined in some other system header (couldn't=20
imagine why, though). Didn't fix it. I'm completely baffled. I'll keep=20
looking, though.

I don't particularly want a structure with all headers in one common .h=20
file, mainly because it requires a rebuild on all cpp files for minor=20
changes to one header. While I've programmed as a hobby since I was a=20
kid, I didn't learn OO concepts, nor do anything "big" (more than a few=20
thousand lines) until I learned Java (started 5 years ago). Java has=20
very strict rules about classes and their files:
* 1 public class per file
* That class must have the same name as the file which contains the=20
sources (in c++, this is translated to mean one .h and one .cpp per=20
class).

There are other rules regarding packages (namespaces) and the directory=20
structure to hold the files, but they don't apply at all to a c++=20
environment, so I won't go into them.

The most common Java conventions dictate that classes are named like=20
ClassName, not classname, nor class_name nor Class_Name, and that=20
functions are named like functionName(), not function_name(), nor=20
FunctionName(). Of course, these are just conventions, but I stick to=20
them for consistency's sake, and because I find them quite readable.=20
It's easy to see I "come from Java" when one looks at my c++ code=20
(assuming one knows Java).

I've found that to be soooo much simpler to maneauver through than=20
c-style code, so I try to stick with it in c++ as well (though I=20
occasionally step out of that).

Anyway... back to work. It's a holiday (dunno which one), but today is=20
perfect for me to work. I get distracted very easily when people keep=20
coming to me with requests and questions and such, and get frazzled=20
because I forget what I was in the middle of. Quiet days like this one=20
are great. I just wish the weather wasn't so nice so I wouldn't feel so=20
guilty about being inside ;).

See ya!

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Feel the fever coming. You're shaking and twitching.
You can scratch all over but that won't stop you itching.
Can you feel a little love?" -- Depeche Mode

Re: [DM-dev] reward: what the Hell is wrong with this code?

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

>1) NEVER use -k. That kills some of the variables which the makefiles 
>needs.
>2) You must ALWAYS run 'make' one time (more neither hurts nor 
>helps) from the top-most level, and any time you add a .h 
>file to libdm/*. That recreates the .h files in include/dm (symlinks on 
>a Unix machine, copies under Windows).
>
>Give that a try...

Ok I did, and it did compile alright. But the thing in main_hierarchy
baffles me as much as you. I simplified the line in question, and the same
mistake occurs, if you just declare in the first line of the function in
question:
Room* pRoom;
It complains that pRoom is undeclared. I also moved the #include for the
Room-file around to the very start of the list of includes, but to no avail.
But I think it's pretty certain that for one reason or another, Room.h is
not really included. Next thing I'd try is to put everything from Room.h
into Wall.h and see whether that removes the mistake. Forgot to do that
while I was still in Linux, but then you'd not want your code to have that
structure, right? Some Makefile where Room is last or treated in some
special way that might result in this?

Peter

Re: [DM-dev] reward: what the Hell is wrong with this code?

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

On Wednesday 23 May 2001 14:59, you wrote:
> I tried to compile the latest CVS, and got this error log, even with
> line 70 commented out:
>
> cd /home/peter/DungeonMaker/sf2new/dungeonmaker/dungeonmaker/
> make -k

1) NEVER use -k. That kills some of the variables which the makefiles=20
needs.
2) You must ALWAYS run 'make' one time (more neither hurts nor=20
helps) from the top-most level, and any time you add a .h=20
file to libdm/*. That recreates the .h files in include/dm (symlinks on=20
a Unix machine, copies under Windows).

Give that a try...

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"Feel the fever coming. You're shaking and twitching.
You can scratch all over but that won't stop you itching.
Can you feel a little love?" -- Depeche Mode

Re: [DM-dev] reward: what the Hell is wrong with this code?

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

I tried to compile the latest CVS, and got this error log, even with line 70
commented out:

cd /home/peter/DungeonMaker/sf2new/dungeonmaker/dungeonmaker/
make -k 
/home/peter/DungeonMaker/sf2new/dungeonmaker/shared.make:51:
main_hierarchy.d: No such file or directory
main_test.cpp:21: warning: No include path in which to find dm/PropertyList.h
main_hierarchy.cpp:22: warning: No include path in which to find
dm/PropertyList.h
main_hierarchy.cpp:25: warning: No include path in which to find
dm/DungeonElement.h
main_hierarchy.cpp:26: warning: No include path in which to find dm/Room.h
main_hierarchy.cpp:27: warning: No include path in which to find dm/Wall.h
main_hierarchy.cpp:28: warning: No include path in which to find dm/DMGrid.h
main_hierarchy.cpp:29: warning: No include path in which to find dm/Door.h
make[1]: Entering directory
`/home/peter/DungeonMaker/sf2new/dungeonmaker/dungeonmaker'
g++  -Wall -g  -I. -I/home/peter/DungeonMaker/sf2new/dungeonmaker/include
-c main_random.cpp -o main_random.o
g++ -Wall -g  -I. -I/home/peter/DungeonMaker/sf2new/dungeonmaker/include
-L-L/usr/lib -L/usr/local/lib -L.  -lstdc++  -o dungeonmaker main.o
/home/peter/DungeonMaker/sf2new/dungeonmaker/libdm/libDungeonMaker.a
g++ -Wall -g  -I. -I/home/peter/DungeonMaker/sf2new/dungeonmaker/include
-L-L/usr/lib -L/usr/local/lib -L.  -lstdc++  -o randomdungeon main_random.o
/home/peter/DungeonMaker/sf2new/dungeonmaker/libdm/libDungeonMaker.a
g++  -Wall -g  -I. -I/home/peter/DungeonMaker/sf2new/dungeonmaker/include
-c main_hierarchy.cpp -o main_hierarchy.o
main_hierarchy.cpp:22: dm/PropertyList.h: No such file or directory
main_hierarchy.cpp:25: dm/DungeonElement.h: No such file or directory
main_hierarchy.cpp:26: dm/Room.h: No such file or directory
main_hierarchy.cpp:27: dm/Wall.h: No such file or directory
main_hierarchy.cpp:28: dm/DMGrid.h: No such file or directory
main_hierarchy.cpp:29: dm/Door.h: No such file or directory
make[1]: *** [main_hierarchy.o] Error 1
make[1]: Target `all-local' not remade because of errors.
make[1]: Leaving directory
`/home/peter/DungeonMaker/sf2new/dungeonmaker/dungeonmaker'
make: *** [.] Error 2
make: Target `default' not remade because of errors.

Compilation exited abnormally with code 2 at Wed May 23 09:01:47

Obviously my environment failed to find many files, not just Door.h. One
mistake I see is that you include your own files in brackets, like in
#include <dm/Door.h>
This is the way to include library files. The proper way to include files
you wrote yourself is
#include "dm/Door.h"
But what baffles me is that this hasn't produced a mistake earlier. Other
than that, I really can't help. This type of mistake is the reason I like to
keep with simple make-files and not too many files in the project, 'cause i
don't understand what's going on;-( The shared.make error at the start is
particularly weird: What the dickens is main_hierarchy.d? Not mentioned on
that line, but substituted from somewheres... the other mistakes could all
be due to <> instead of "".

Good luck,
Peter

At 08:33 PM 5/21/01 +0200, you wrote:
>Just checked in: 
>drastically altered/simplified Door/Wall objects. But for some reason I can't 
>get the main() function to compile: parse error. It's telling me that Door 
>isn't defined. But Door.h is included, and everything matches up, as far as I 
>can see.
>
>Can you PLEASE take a look at dungeonmaker/main_hierarchy.cpp, line 69 and 
>tell me why the hell it doesn't compile if I uncomment line 70? I'm at a 
>complete loss.

[DM-dev] reward: what the Hell is wrong with this code?

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

Just checked in: 
drastically altered/simplified Door/Wall objects. But for some reason I can't 
get the main() function to compile: parse error. It's telling me that Door 
isn't defined. But Door.h is included, and everything matches up, as far as I 
can see.

Can you PLEASE take a look at dungeonmaker/main_hierarchy.cpp, line 69 and 
tell me why the hell it doesn't compile if I uncomment line 70? I'm at a 
complete loss.




----- Stephan Beal - st...@wa...
http://qub.sourceforge.net - http://gwm.rootonfire.org
http://byoo.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

[DM-dev] commited to CVS

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

I've just commited a missing file into CVS, which should fix
any build problem caused by the code checked in the other
night. I've also added lots of API docs into
DungeonElement.h. That's really the core object of this
hierarchy, so that's where to look if you want to get an
idea of what I'm doing.

[DM-dev] working code in CVS

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

Howdy, howdy,

Okay, a building, working DM is in CVS. note that the old dungeonmaker app 
still works as it used to, and does not use any new API or anything. There 
are other apps in the dungeonmaker/ dir which play with the new API.

Note that the API which is in CVS will undergo some restructuring soon, as I 
get rid of this orientation/rotation stuff I started. It's more complex than 
it needs to be. 

Note that Doors don't currently work, and won't until I fix the orientation 
stuff, hopefully tomorrow (but I've been called back in to work tomorrow, and 
don't know how long that will take :( ).

Building, then running dungeonmaker/dtest will dump a rendered dungeon to the 
console. Look at main_hierarchy.cpp for the code.

The libdm folder has lots of objects in it, but don't let that scare you. 
Some of that will go away, or merged, and that kind of thing. It's a big 
playground right now, as I try out different things. The sudden 
multiple-server migration at work has taken up all of my spare time this past 
week, but that's over now (well, the important parts) so I will hopefully 
have every evening this week to work on it. Stepping back from it for a 
couple of weeks has given me some new insights, too, which I'll be applying.

If you look at any objects in the libdm dir, look at DungeonElement. That's 
the root for all renderable Dungeon objects (rooms, walls, pits, chests, 
doors, pits-o-lava, wandering elves, etc...).

Take care, all,

----- Stephan Beal - st...@wa...
http://qub.sourceforge.net - http://gwm.rootonfire.org
http://byoo.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

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

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

On Monday 14 May 2001 14:46, you wrote:
> >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 thought you wanted rotation of dungeon elements for interactive
> design. Once a design is set, i don't see where we would need to
> rotate anything.

I do, actually, but I don't want to implement it just yet ;). I'm being=20
lazy, so that feature can wait. :) I'll probably not do anything at all=20
with rotation until I get ready to do that part of the dungeon designer.

> >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:
>
> Hmm, yeah, I don't see the usefulness of that, but if you do... just
> remember not to add any functionality that you have no use for
> yourself;-)

Wouldn't think of it ;).

I know it doesn't sound very useful at first, but it allows us to have=20
a static, global config object where any number of clients can read and=20
share config data. Actually, in this context it's not as useful as a=20
long-running app (where DM is a "run to quickly generate output" app).

I'll be back on the home PC tonight and will try to finish up the=20
BlockElement stuff. I'll keep you posted, of course.

----- Stephan Beal
Generic Universal Computer Guy
ste...@ei... - http://www.einsurance.de
Office: +49 (89) 552 92 862   Handy: +49 (179) 211 97 67
"What the flesh requires keeps the heart imprisoned." -- Depeche Mode

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

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

>Okay, I've finally thought of the solution to the rotation/orientation 
>problem, at that is to simply remove orientation....
> 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 )

Ahh, that's inspired... very cool

>Hell, a Room is just a BlockElement, isn't it, with Walls overlaid?

Right now, the insides of rooms arenothing special, just open space. If you
use large doors, Crawlers can (and will often) actually go inside rooms and
build walls there if there's enough room. This can be avoided if desired by
making the door space into "must remain open" squares.

>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 thought you wanted rotation of dungeon elements for interactive design.
Once a design is set, i don't see where we would need to rotate anything.

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

As they say here in the Maritimes (by way of parting salute): "Don't work
too hard".

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

Hmm, yeah, I don't see the usefulness of that, but if you do... just
remember not to add any functionality that you have no use for yourself;-)

C'ya,
Peter

[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

[DM-dev] STL reference online

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

http://www.dinkumware.com/htm_cpl/

It's a 3rd-party implementation of the STL, but it's
supposedly "compliant". I haven't dug through it, aber es
sieht gut aus. Cross-referenced and all, with samples. It
looks a bit like the Qt API docs, as far as the layout..

See y'all!

----- Stephan

Re: [DM-dev] Dungeon Rendering :)

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

On Thursday 03 May 2001 16:01, you wrote:
> >That my major flaw in coding:
> >I set out to do one task, come across a bug, chase the bug, and
> > always end up 4 features away from what I set out to do. I end up
> > with 3 times as many features, but not because I set out to do it
> > ;).
>
> Ahh - feature-creep - where will it get us?

If I was any good an planning past the next 4 hours I'd tell you ;)

> And me, with my philosophy of the sparse interface...

Mine is more a philosophy of simple-to-use interface. I build a very=20
high-level interface, and then build the low-level API which can=20
provide that functionality using more lines, in the case that the user=20
really wants to screw around with it.

> I should let you know that my monitor is acting up, and I suspect it
> will go "kaputt" some time soon, and then I'll be offline for a
> while. Might be a long while, since the outdoors is very enticing,
> and not having a monitor is a very reliable way to keep me off the
> computer;-) In emergencies, my phone is 902-528-2467.

Good to know. I may just call to speak to the man who started it all. I=20
haven't been on the PC so much at home because my arms are acting up=20
(I've had RSI for about 8 years now, because I just can't break myself=20
away from computers). My willpower is about 4cm long, though, so I=20
never stay off for too long ;).

See ya!

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

Re: [DM-dev] Dungeon Rendering :)

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

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

Ahh - feature-creep - where will it get us?

And me, with my philosophy of the sparse interface... 

I should let you know that my monitor is acting up, and I suspect it will go
"kaputt" some time soon, and then I'll be offline for a while. Might be a
long while, since the outdoors is very enticing, and not having a monitor is
a very reliable way to keep me off the computer;-) In emergencies, my phone
is 902-528-2467.

Peter

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

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