just out of general curiosity.. I'm wondering about graphics.dat and it's versitility. I know now that monsters can be altered and even increased in size.. I also notice that the implimentation of new sounds into the engine over all etc etc.
So, my question is then how far can all of this go? can it be brought up in colours? 32? 256? can more frames be added? can additional elements be added at all? ie different wall sets? or more wall and floor adornments? more monster types?
For sounds how many new sounds can be put in and worked with? how far can it all really go?
I don't expect any major additions to be added obviously since such things can already be done in DMJ and RTC. so it's more just the idea of how versitile these formats are and how far you could really push them? After all you've reverse engineered the whole thing and so it's interesting to see how far they could have gone back in the day had they developed for a more powerfull system with the code they already had.
moo
general questions about graphics.dat
Moderator: Zyx
Forum rules
Please read the Forum rules and policies before posting. You may
to help finance the hosting costs of this forum.
Please read the Forum rules and policies before posting. You may
to help finance the hosting costs of this forum.
-
cowsmanaut
- Moo Master
- Posts: 4380
- Joined: Fri Jun 30, 2000 12:53 am
- Location: canada
-
cowsmanaut
- Moo Master
- Posts: 4380
- Joined: Fri Jun 30, 2000 12:53 am
- Location: canada
-
Paul Stevens
- CSBwin Guru
- Posts: 4322
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Who are you asking? Not me, I hope. I avoid investigating
the graphics file. People like Zyx know a lot about it, as is
evident from works like Conflux.
The 16-color limit is absolute unless you rewrite the
entire thing as George has done.
If someone can demonstrate how the file can be modified
for some of your other ideas then I am willing to see if
adjustmenst to the runtime engine might be possible.
the graphics file. People like Zyx know a lot about it, as is
evident from works like Conflux.
The 16-color limit is absolute unless you rewrite the
entire thing as George has done.
If someone can demonstrate how the file can be modified
for some of your other ideas then I am willing to see if
adjustmenst to the runtime engine might be possible.
-
cowsmanaut
- Moo Master
- Posts: 4380
- Joined: Fri Jun 30, 2000 12:53 am
- Location: canada
yeah it was just a general question.. I guess about dungeon.dat too..
Really just a curiousity about how expanded it can all be. If the limits imposed were dead locked in the main code or if a gentle nudge in any direction could be achieved. I've noted, as mentioned above, that new images of different size and make can be supplimented in.. you've allowed for larger number of items and such in the dungeon etc etc.
So really just got me thinking about how far it could all go.. just in fun
moo
Really just a curiousity about how expanded it can all be. If the limits imposed were dead locked in the main code or if a gentle nudge in any direction could be achieved. I've noted, as mentioned above, that new images of different size and make can be supplimented in.. you've allowed for larger number of items and such in the dungeon etc etc.
So really just got me thinking about how far it could all go.. just in fun
moo
-
PicturesInTheDark
- Arch Master
- Posts: 1154
- Joined: Mon Aug 26, 2002 4:47 pm
- Location: Vienna, Austria
>can it be brought up in colours?
The graphics.dat is structured for 16 colors. Can't be changed without restructuring.
Note: adding graphics is not the same as replacing, because you have to change the total number of graphics, add the dimensions of the new graphics in a list at the beginning of the file, change the memory allocated for each kind of graphics... These numbers are certainly inside the graphics.dat but we still don't know where exactly. But someone researching them could find them in a few days probably.
>can more frames be added?
Frames: frames by tick: it has nothing to do with the graphics.dat. Paul could answer that.
Monster frames: (I mean different positions of monsters)
1) Each monster could be quite easily associated with the 4 normal positions (Attacking, front, side, back). Currently some monsters have only 3 or 2 views. This would mean adding pictures into the graphics.dat but I think it's possible. I would require a little research, though.
2) Adding more than 4 pictures: for the graphics.dat this would be a little more complex than 1). For the engine I don't know.
>can additional elements be added at all?
> ie different wall sets? or more wall and floor adornments? more monster >types?
Wall decorations, floor decorations, door decorations: probably yes. It's just about adding the pictures and saying how much graphics there are. It would need a little research and coding a program (because the calculations should be made each time you modify it)
Wall sets: very, very complex to change the graphics.dat for that. It would be simplier for Paul to load them from an external file like for the portraits.
Monster types: I guess it is possible. We just need to find where the number of monsters is stored.
>For sounds how many new sounds can be put in and worked with? how far can it >all really go?
How many: the two limitations I can think of are:
the allocated memory (?)
the index number: probably 256 (?)
Just guessing, though.
The graphics.dat is structured for 16 colors. Can't be changed without restructuring.
Note: adding graphics is not the same as replacing, because you have to change the total number of graphics, add the dimensions of the new graphics in a list at the beginning of the file, change the memory allocated for each kind of graphics... These numbers are certainly inside the graphics.dat but we still don't know where exactly. But someone researching them could find them in a few days probably.
>can more frames be added?
Frames: frames by tick: it has nothing to do with the graphics.dat. Paul could answer that.
Monster frames: (I mean different positions of monsters)
1) Each monster could be quite easily associated with the 4 normal positions (Attacking, front, side, back). Currently some monsters have only 3 or 2 views. This would mean adding pictures into the graphics.dat but I think it's possible. I would require a little research, though.
2) Adding more than 4 pictures: for the graphics.dat this would be a little more complex than 1). For the engine I don't know.
>can additional elements be added at all?
> ie different wall sets? or more wall and floor adornments? more monster >types?
Wall decorations, floor decorations, door decorations: probably yes. It's just about adding the pictures and saying how much graphics there are. It would need a little research and coding a program (because the calculations should be made each time you modify it)
Wall sets: very, very complex to change the graphics.dat for that. It would be simplier for Paul to load them from an external file like for the portraits.
Monster types: I guess it is possible. We just need to find where the number of monsters is stored.
>For sounds how many new sounds can be put in and worked with? how far can it >all really go?
How many: the two limitations I can think of are:
the allocated memory (?)
the index number: probably 256 (?)
Just guessing, though.
-
Paul Stevens
- CSBwin Guru
- Posts: 4322
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
I get the impression that you are not all
familiar with Christophe's work. See:
http://dmweb.free.fr/FFData.htm
familiar with Christophe's work. See:
http://dmweb.free.fr/FFData.htm
-
cowsmanaut
- Moo Master
- Posts: 4380
- Joined: Fri Jun 30, 2000 12:53 am
- Location: canada
I find it odd that DM PC brings up a 256 colour mode and yet only uses a 16 colour pallete.
as for frames.. I'm just remembering that in DM2 while it was rather cartoony.. it had a little animation for moving from block to block. making the transition more smooth rather than a blink and thud. I suppose what could be done in that sence (and it probably could have been done back then too now that I think about it.) Is use of scaling and colour look up tables. (as I suspect you and Geaorge are both doing) Taking the original full size images and removing the multiple levels (thus providing more space for more images related to those monsters) and then doing the size and brightness shift in code. With this a smoother transition could be done by making inbetweens for each jump. So from tile A to tile B you could have an inbetween size that pops on for a moment. if then that inbetween were a new frame.. then all the better.
I had also been thinking of animated torches on the wall... just something as simple as being able to assign a "flip me" tag to wall graphics so that the flame would appear to be animating as it does for the monsters. Or adding in a 3-4 image cycle.
Hmm this reading from an external file. Could it be possible then to have more than one graphics.dat? hae some kind of flag at the beginning of a level that says not only which graphics to load (As far as I could tell it reloads into memory the required images while going up or down a level since my disc drive would go nuts) but which graphics.dat to load them from. so you could have graophics.dat, graphics2.dat, etc etc.. perhaps setting a max might be good but... it's an idea. yes no?
can sounds be pulled from an outside file too? That would probably work for adding in those sounds not found in the Atari version.
anyway.. thanks for amusing a curious mind.
oh and BTW . DAMN you guys!! the depth to which you have collectively seperated and catelogued the every byte of DM is just amazing.. patience I do not have! Good job!
moo
as for frames.. I'm just remembering that in DM2 while it was rather cartoony.. it had a little animation for moving from block to block. making the transition more smooth rather than a blink and thud. I suppose what could be done in that sence (and it probably could have been done back then too now that I think about it.) Is use of scaling and colour look up tables. (as I suspect you and Geaorge are both doing) Taking the original full size images and removing the multiple levels (thus providing more space for more images related to those monsters) and then doing the size and brightness shift in code. With this a smoother transition could be done by making inbetweens for each jump. So from tile A to tile B you could have an inbetween size that pops on for a moment. if then that inbetween were a new frame.. then all the better.
I had also been thinking of animated torches on the wall... just something as simple as being able to assign a "flip me" tag to wall graphics so that the flame would appear to be animating as it does for the monsters. Or adding in a 3-4 image cycle.
Hmm this reading from an external file. Could it be possible then to have more than one graphics.dat? hae some kind of flag at the beginning of a level that says not only which graphics to load (As far as I could tell it reloads into memory the required images while going up or down a level since my disc drive would go nuts) but which graphics.dat to load them from. so you could have graophics.dat, graphics2.dat, etc etc.. perhaps setting a max might be good but... it's an idea. yes no?
can sounds be pulled from an outside file too? That would probably work for adding in those sounds not found in the Atari version.
anyway.. thanks for amusing a curious mind.
oh and BTW . DAMN you guys!! the depth to which you have collectively seperated and catelogued the every byte of DM is just amazing.. patience I do not have! Good job!
moo
-
ChristopheF
- Encyclopedist
- Posts: 1603
- Joined: Sun Oct 24, 1999 2:36 pm
- Location: France
- Contact:
The original DM/CSB engine already did the size and brightness changes in code. Images of creatures and items are only stored in full size in the graphics.dat file.
What you are asking for (smoother transitions) was done in DM2.
And about the disk activity when you change level, this is not related to graphics loading. As far as I know, all the graphics file is put in memory when the game loads. then, when you change go from one level to another, the disk activity you notice is about checking the copy protection of DM, no data is loaded at all.
I am working on a web page with detailed information about the DM copy protection scheme, which was very clever.
What you are asking for (smoother transitions) was done in DM2.
And about the disk activity when you change level, this is not related to graphics loading. As far as I know, all the graphics file is put in memory when the game loads. then, when you change go from one level to another, the disk activity you notice is about checking the copy protection of DM, no data is loaded at all.
I am working on a web page with detailed information about the DM copy protection scheme, which was very clever.
Christophe - Dungeon Master Encyclopaedia
-
cowsmanaut
- Moo Master
- Posts: 4380
- Joined: Fri Jun 30, 2000 12:53 am
- Location: canada
so it was just the wall sets that were done in multiple brightness/size then.. not monsters and objects?
So if it was only checking copy protection then it took it's sweet time. It would grind away when ever I went up or down stairs and then I would be in that new section.. but it took a little while to do it seems.
Anyway, if it wasn't loading any graphics then I guess the idea of multiple .dat files would be pointless or it would require a much more indepth rewrite of some code.. though again.. this is still only hypothetical. I don't expect any of this to come to pass.
moo
So if it was only checking copy protection then it took it's sweet time. It would grind away when ever I went up or down stairs and then I would be in that new section.. but it took a little while to do it seems.
Anyway, if it wasn't loading any graphics then I guess the idea of multiple .dat files would be pointless or it would require a much more indepth rewrite of some code.. though again.. this is still only hypothetical. I don't expect any of this to come to pass.
moo