Linking doors to their tiles
Forum rules
Please read the Forum rules and policies before posting.
Please read the Forum rules and policies before posting.
Linking doors to their tiles
Hi,
I'm currently planning on making a new DM clone on portable consoles, and I'm still studying how the DM data are organized.
By looking at the DM encyclopedia, I see that there is a separate list of doors, with several properties (like for example the "bashable" or the "destroyable" attributes). Later in the dungeon.dat file, there are the maps definitions themselves, specifying the type of every tile.
If a tile is a door, some local informations are also available here (like orientation), but I don't see how you can link this tile to the corresponding door in the doors list. Is it done via the list of objects on this tile?
Thank you for your help!
Michoko
I'm currently planning on making a new DM clone on portable consoles, and I'm still studying how the DM data are organized.
By looking at the DM encyclopedia, I see that there is a separate list of doors, with several properties (like for example the "bashable" or the "destroyable" attributes). Later in the dungeon.dat file, there are the maps definitions themselves, specifying the type of every tile.
If a tile is a door, some local informations are also available here (like orientation), but I don't see how you can link this tile to the corresponding door in the doors list. Is it done via the list of objects on this tile?
Thank you for your help!
Michoko
- Paul Stevens
- CSBwin Guru
- Posts: 4321
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Are you on any LW sites like TotS or PA?
Note that teleporters are also like that - a tile is designated 'door' or 'teleporter' and it therefore uses the first object to get all it's operational information from. The tile type simply says the state of the door object - open, closed, bashed, north-south facing or left-right.
This is different to pits, stairs and false/illusionary walls, where every single state is a different tile type ad there is no additional object required
Note that teleporters are also like that - a tile is designated 'door' or 'teleporter' and it therefore uses the first object to get all it's operational information from. The tile type simply says the state of the door object - open, closed, bashed, north-south facing or left-right.
This is different to pits, stairs and false/illusionary walls, where every single state is a different tile type ad there is no additional object required
Re: Linking doors to their tiles
A map is an array of tiles. Each tile contains a pointer to its first object. Okay. But I don't understand why tiles are also holding information on the first object. Is there a reason why this information (e.g. "door state", "door orientation"...) isn't stored in the object as well? Wouldn't that be more... intuitive?
It's impossible for a tile to hold more than one field type objects at the same time - e.g. a "door" AND a "pit", or a "pit" AND a "teleporter" - , isn't it?
It's impossible for a tile to hold more than one field type objects at the same time - e.g. a "door" AND a "pit", or a "pit" AND a "teleporter" - , isn't it?
- Paul Stevens
- CSBwin Guru
- Posts: 4321
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Re: Linking doors to their tiles
Yes. And the reason is that DM had to fitIs there a reason why this information (e.g. "door state", "door orientation"...) isn't stored in the object as well?
into 512K of memory and a floppy disk.
Remember that the display memory
came out of that 512k, too. Try it!
The designers put bits wherever they
could be found. They could not afford
to add another word to the object
representing a door but there were
unused bits in the byte representing
the tile. This lack of space explains
a LOT of what made Dungeon Master
what it was.
Re: Linking doors to their tiles
So can you say or can#t you say that this lack of space and the resulting restructuring of the code would make a difference in overall speed of the game? (compared to a straight forward code I mean)
After all, an interpreter (computer) just reads the bits and has to do loops anyway, it is not like a harddisk or CD that gets slower if it has to collect the information(bits and pieces no pun intended) all over the place I guess...
surely for understanding of the code for humans it would have greater (negative?) impact than for machines.
maybe the loading itself does not matter that much but the actual live program(in memory that is) that waits and does its thing is the critical part where the speed loss or speed gain (overall performance) is determined!
After all, an interpreter (computer) just reads the bits and has to do loops anyway, it is not like a harddisk or CD that gets slower if it has to collect the information(bits and pieces no pun intended) all over the place I guess...
surely for understanding of the code for humans it would have greater (negative?) impact than for machines.
maybe the loading itself does not matter that much but the actual live program(in memory that is) that waits and does its thing is the critical part where the speed loss or speed gain (overall performance) is determined!
Re: Linking doors to their tiles
Yes, just as I thought.And the reason is that DM had to fit
into 512K of memory and a floppy disk.
Could you tell me how much memory is needed to store all the graphics at the same time? How much memory would I have to provide if I wanted to load only the graphics into memory needed on a specific level of the dungeon? Is there a significant difference at all? (Sorry for asking. I haven't read the entire technical documentation yet.)Remember that the display memory
came out of that 512k, too.
In my humble opinion, it doesn't have any impact on the speed. It seems to be only a trick for saving some of the valuable memory.So can you say or can#t you say that this lack of space and the resulting restructuring of the code would make a difference in overall speed of the game? (compared to a straight forward code I mean)
After all, an interpreter (computer) just reads the bits and has to do loops anyway, it is not like a harddisk or CD that gets slower if it has to collect the information(bits and pieces no pun intended) all over the place I guess...
surely for understanding of the code for humans it would have greater (negative?) impact than for machines.
maybe the loading itself does not matter that much but the actual live program(in memory that is) that waits and does its thing is the critical part where the speed loss or speed gain (overall performance) is determined!
- Paul Stevens
- CSBwin Guru
- Posts: 4321
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Re: Linking doors to their tiles
Speed.....on the Atari the CPU was
definitely pushed to its limits on
many occasions. But the extra
few dozen instructions to decode
a door's properties once every several
seconds was insignificant. It was
the graphics and the monsters moving
about all the time that consumed CPU.
But.....remember how slow those
floppy disks were? Anything that
reduced the number of bytes transferred
between the floppy disk and memory
made a big difference in your playing
experience. The designers did a
whopper of a wonderful job balancing
all these pro/con, give/take, plus/minus
trade-offs in every part of the program.
There is evidence of compromise in
every corner of the program.
definitely pushed to its limits on
many occasions. But the extra
few dozen instructions to decode
a door's properties once every several
seconds was insignificant. It was
the graphics and the monsters moving
about all the time that consumed CPU.
But.....remember how slow those
floppy disks were? Anything that
reduced the number of bytes transferred
between the floppy disk and memory
made a big difference in your playing
experience. The designers did a
whopper of a wonderful job balancing
all these pro/con, give/take, plus/minus
trade-offs in every part of the program.
There is evidence of compromise in
every corner of the program.