Dungeon Master Forum

With the recent release of ADGE, I've come upon quite a few unused bits in the graphics.dat file which could prove useful. Just a few little things. The problem is that we aren't using them!

Every bit we can use should be a bit we use! (hahaha)

The first example is every single combo (A combo struct in the graphics.dat file contains 8 bytes). Each combo is of the structure:

first attack
difficulty of first attack + 1 bit for whether or not it uses up charges
second attack
difficulty of second attack + 1 bit for whether or not it uses up charges
third attack
difficulty of third attack + 1 bit for whether or not it uses up charges
unused byte
unused byte

Now there are 44 of these combo's, and each combo has 2 unused bytes. Would it not be unwise to think up something useful for such occasion and implement them?

I don't know really, there are hundreds of unused bits/bytes all over the place, and it seems that there are quite few things that could be thought up for new dungeons. I guess it's really up to the dungeon makers.

But here is just an example that some people might actually think as useful:

Each MONSTERDESC (monster data) has at least two entire unused bytes (byte 13 and byte 25, or if referring to CSB source, uByte8[5] and uByte22[3]). These bytes are all set to 0 for each monster, and I've tried my hardest to see whether or not they are ever even accessed, and I have found they are not. With two entire unused bytes, we could store some sort of "spells" in there that the monster can shoot, and/or a power level.

in a general layout, it might look something like this... I'm not asking for this to be implemented, I'm just wondering if the dungeoneers could make use of something like that. There are countless unused bits in the graphics.dat file, all over the place that could be used. It would require additions to the CSBWin source though.

One thing that might not be a bad idea is to try and get some of the static elements of certain things (such as knights having a double attack) dynamic. A single bit test in an unused bit has alot of power there.

What do you think?

-rain`

An idea I think I have mentioned before is to use multiples of graphics.dat. That is, with CSBuild, each level points to a separate graphics.dat, say graphics1, graphics2 etc. This I think would be a nice solution for the designer who justs wants to use say 3 or 4 wall sets, on a level by level basis, and opens up the ability to have different monsters too, level by level. I am not PaulS, but my thinking is that would not be too difficult to implement, and if used carefully by the designer would work better than using DSAs/masks/skins and associated confusion.

I appreciate that the downsides are the apparent 'wastage of space' here as only a small portion of the graphics.dat will be changing (walls/wallobjects/monsters/doors) but so what?! 3 dats will be maybe 1mb, and as dungeon files are getting bigger and bigger with csbgraphics files for overlays and sounds, I cant see that an extra mb is much to worry about.

I stress again, I think it is a simple solution for those who have a few spare graphics sets. That is, if it is simple to implement. I like simple effectiveness. Any comments?

Before using any 'unused bits' in the graphics.dat you need to ensure that this data is never used in any way by the program. It may prove to be a very difficult task.

The data added to the graphics.dat that would not be used by the original games and only by CSBwin, so what is the benefit of including this data inside graphics.dat? I would prefer keeping 'standard' graphics.dat files on one side, and extended data files on another side, containing all the advanced features.

I think that before this is over there will be a simple way
to declare an entire level as using a different Skin. And
a simple way of importing the necessary pieces into
CSBgraphics. Right now it is being developed and so
no finished utilities exist.

We might reload graphics for a level but even they are
cached and some precomputations are done. I have never
figured out the entire caching scheme. Switching the
Graphics.dat file was the first thing I thought about when
the question of different wallsets first arose. But I gave up.
It was not simple for me.

But the other parts of the 'graphics' that describe monsters and
their abilities, etc. would be quite impossible. Suppose that
on level 1 monster type 3 is a Screamer and on level 2 monster
type 3 is a Demon. But they are both running around at the
same time in the code. When the party was on level 1, the
Demons on level 2 would be acting like Screamers. And when
the party was on level 2 the Screamers would be acting like
Demons.

I see the complications. But I had thought about the monster paradox (if that is the right word) and would probably use the exact sames stats. I would not alter the dm.gil file or the game parameters via adge. Just the graphics. Again, not really a new monster, but the illusion of many types would be there, like say both DM and CSB monsters. And of course, new walls.

Yes, I agree, the good work of many people especially yourself and Zyx will see that the skins/csbgraphics will come good.

I won't say it is impossible. Replacing monster graphics
for a level might be quite reasonable. I think they have
numbers in a limited range. Someone said that he
successfully added graphics to the file. Perhaps we
could put multiple monster graphics in the Graphics.dat
and use alternate ones based on the level.

Not this week, though.

Yes, rain` continues his great work on the graphics file, but Christophe has commented on a possible problem about completely identifying the workings of the file. However, if it is possible to add new graphics, I can't see how this would affect the original game as it wouldn't be used here; just in custom dungeons. I suppose this overlaps with Zyx's earlier post about monster graphics.

A double millenium of posts! Worrying...

Congratulations - try not to let the power go to your head and start yelling at people ; )