There is now an option in the Init.txt file to switch off the pre-scaling of the graphics and scale them all on the fly. There are two major benifits from this
1) Faster loading time (cut from about 30s to 5s for me).
2) Significantly lower memory usage (about 70% lower!).
However it slows the drawing speed down substantially. I choose my words carefully here. Although the time it takes to draw each graphic is longer (about 3 times longer actually) this *may* mean that the frame rate increases as the original (non-scaled) graphics fit into a machines memory.
Obviously the degree to which this impacts on you will be a direct function of the ammount of memory you have and the speed of your processor (the more of each you have, the less difference there will be between the two). For my PII-450;128MB I get a stable 105fps for pre-scaled graphics either with or without anti-aliasing. For scaling on the fly this drops to 85fps for ordinary scaling and 50fps with anti-aliasing. Each of these figures are quoted for a simple scene (standing one square back from the torch holder by the stairs so that the torch holder, stairs, scroll and waterskin are in view) - for a more complex scene then the differences between the two methods will be greater.
Graphics (V0.05)
Moderator: George Gilbert
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.
-
George Gilbert
- Dungeon Master
- Posts: 3022
- Joined: Mon Sep 25, 2000 11:04 am
- Location: London, England
- Contact:
Resolution and scaling switch
First thing I wonder, is if RTC will support higher-res dungeon and monster graphics that users might create? Also how many colors will be supported?
Second is whether a switch can be implemented to turn off scaling entirely, and instead use the pre-made distant gfx frames from the original DM. There are a few reasons for this:
1) It doesen't gel right when the distance-scaled objects appear at a higher resolution then the surrounding dungeon.
2) Some monsters use the distant GFX to give the illusion of walking by alternating sides: A worm points his head to the right at the farthest view, to the left at intermediate, and to right again at the closest.
3) It's better than pre-aliased (in the case of a consisten resolution), as it's been cleaned up by hand.
4) I prefer the built-in shading "effect" on the farther monsters, reminds you more that its a torch your carrying, not a flashlight. I also prefer the older DM's 8-bit color scaling of various torchlight amounts, but I imagine that would be a pain to implement and it is of little consequence when you can cast FUL all the time
Maybe someone could make a dungeon where FUL doesen't work and you must rely on torches or +light items though...
5) Its faster than either scaling method, if running low-res, it takes up less memory, and it gives more control to the dungeon modder. It does increase download sizes a bit though...
Great work so far, I hope to see the new dungeons soon
Second is whether a switch can be implemented to turn off scaling entirely, and instead use the pre-made distant gfx frames from the original DM. There are a few reasons for this:
1) It doesen't gel right when the distance-scaled objects appear at a higher resolution then the surrounding dungeon.
2) Some monsters use the distant GFX to give the illusion of walking by alternating sides: A worm points his head to the right at the farthest view, to the left at intermediate, and to right again at the closest.
3) It's better than pre-aliased (in the case of a consisten resolution), as it's been cleaned up by hand.
4) I prefer the built-in shading "effect" on the farther monsters, reminds you more that its a torch your carrying, not a flashlight. I also prefer the older DM's 8-bit color scaling of various torchlight amounts, but I imagine that would be a pain to implement and it is of little consequence when you can cast FUL all the time
Maybe someone could make a dungeon where FUL doesen't work and you must rely on torches or +light items though...5) Its faster than either scaling method, if running low-res, it takes up less memory, and it gives more control to the dungeon modder. It does increase download sizes a bit though...
Great work so far, I hope to see the new dungeons soon
-
George Gilbert
- Dungeon Master
- Posts: 3022
- Joined: Mon Sep 25, 2000 11:04 am
- Location: London, England
- Contact:
Re: Resolution and scaling switch
> First thing I wonder, is if RTC will support higher-res
> dungeon and monster graphics that users might create?
> Also how many colors will be supported?
RTC already supports any resolution over 640x400 and either 24 or 32bpp graphics - it's just that in the graphics currently used only about 16 of the grillion possible ones are used! The final release will be driven off a simple script text files which will point to *.bmp files which can be of any type you like - actually, it already does this, but only in the debug build
Also there is support for hand-scaled objects (all the pits,
stairs, walls etc are provided as seperate graphics and not scaled at run-time; precisely for all the reasons you say). In fact, thinking about it, all the objects that DM pre-scales are also pre-scaled by RTC - which "pre-made distant gfx frames from the original DM" are you refering to?
As you say to do it for all objects would kill the download size (one of the first versions of the code I wrote only used pre-drawn-scaled 24bpp bitmaps and takes up about 50MB).
The current versions of RTC are released to test the integrity (or otherwise) of the engine, but it is designed to cope with much more than the standard DM can throw at it. The reason why I havn't released all the dev.kit to do all the extra stuff yourselves is that the specifications are constantly refined on each build which would mean that each time I release a new exe anything you'd designed may become obsolete...
> dungeon and monster graphics that users might create?
> Also how many colors will be supported?
RTC already supports any resolution over 640x400 and either 24 or 32bpp graphics - it's just that in the graphics currently used only about 16 of the grillion possible ones are used! The final release will be driven off a simple script text files which will point to *.bmp files which can be of any type you like - actually, it already does this, but only in the debug build
Also there is support for hand-scaled objects (all the pits,
stairs, walls etc are provided as seperate graphics and not scaled at run-time; precisely for all the reasons you say). In fact, thinking about it, all the objects that DM pre-scales are also pre-scaled by RTC - which "pre-made distant gfx frames from the original DM" are you refering to?
As you say to do it for all objects would kill the download size (one of the first versions of the code I wrote only used pre-drawn-scaled 24bpp bitmaps and takes up about 50MB).
The current versions of RTC are released to test the integrity (or otherwise) of the engine, but it is designed to cope with much more than the standard DM can throw at it. The reason why I havn't released all the dev.kit to do all the extra stuff yourselves is that the specifications are constantly refined on each build which would mean that each time I release a new exe anything you'd designed may become obsolete...
Silly me
I was under the impression that the graphics for monsters appearing a square and two squares away from the player were pre-done and then recorded to the DM disk itself. But to fit the game on 1 low-density floppy, FTL probably did have the graphics scaling be done by the software for these farther images. I guess that's what my Atari ST was doing when it took 10 years to load the game.
For the 16-color graphics, I prefer the 16 color light scaling, and also for the scaling to maintain a consistent resolution. But for custom 16 million color user graphics this would be very different.
I still think it's best that objects should not scale to a higher resolution than they appear when up close. Keep the resolution consistent. In some situations this will save on memory and computer time.
You've probably already done it, but an option for some monsters to "wobble", flipping the image horizontally as they approach. Some monsters also use this in their attack.
In the final implementation, consider a 3rd option: pre-scaling and aliasing once, and then storing on the hard drive. No need to do this every time before you start gaming.
Also, allowing users to supply actual 256 color and 16-color bitmaps at any resolution they choose (rather then stuffing 256 colors into a 16-million bitmap) would save considerably on download time.
Another Q, would it be possible for the dungeon creator to specify a bit depth that would be used for shading? Currently its 16 or 24 bit, but allowing also an 8-bit color shading option can save on computer speed and space. Having several 256 color bitmaps that are first shaded in 256 colors, and then pasted together into a 16 bit final image saves on memory and speed issues considerably, while a limit of a unique 256 color pallete for each bitmap wouldn't be much of a limitation on graphical quality.
Also, wouldn't it make sense that walls perpendicular to the player should have scaling? This can save a lot of space for dungeons that use many different wall types.
For the 16-color graphics, I prefer the 16 color light scaling, and also for the scaling to maintain a consistent resolution. But for custom 16 million color user graphics this would be very different.
I still think it's best that objects should not scale to a higher resolution than they appear when up close. Keep the resolution consistent. In some situations this will save on memory and computer time.
You've probably already done it, but an option for some monsters to "wobble", flipping the image horizontally as they approach. Some monsters also use this in their attack.
In the final implementation, consider a 3rd option: pre-scaling and aliasing once, and then storing on the hard drive. No need to do this every time before you start gaming.
Also, allowing users to supply actual 256 color and 16-color bitmaps at any resolution they choose (rather then stuffing 256 colors into a 16-million bitmap) would save considerably on download time.
Another Q, would it be possible for the dungeon creator to specify a bit depth that would be used for shading? Currently its 16 or 24 bit, but allowing also an 8-bit color shading option can save on computer speed and space. Having several 256 color bitmaps that are first shaded in 256 colors, and then pasted together into a 16 bit final image saves on memory and speed issues considerably, while a limit of a unique 256 color pallete for each bitmap wouldn't be much of a limitation on graphical quality.
Also, wouldn't it make sense that walls perpendicular to the player should have scaling? This can save a lot of space for dungeons that use many different wall types.
-
George Gilbert
- Dungeon Master
- Posts: 3022
- Joined: Mon Sep 25, 2000 11:04 am
- Location: London, England
- Contact:
Re: Silly me
Hmm - I think some of this is a step backwards and so am not keen to implement it. In particular regressing to 8-bit colour would be a real pain to code in terms of the shading and blitting routines - it's so much easier (although maybe not quicker) just to splat out a colour onto the screen than to try and deal with different palletes, merging, picking the right one and whatnot. Similarly with only using 16 colours in the DM-shading model doesn't seem as if there's much point other than to try and copy DM *exactly* - I think there comes a point when RTC and DM diverge and this is one of them; copying just for the sake of it when a "better" version is available isn't the way forward. Of course that leaves it widely open to interpretation as to what "better" is and it has to all be considered within the context of being DM-like. Given that it's not necessary (as it was for the ST/Amiga) it doesn't seem worth-while to implement it now (although I grant it would speed the frame rate up considerably).
On another point RTC does actually maintain a consistent resolution - it just doesn't look like it does. Everything is done on a pixel basis but for each pixel in DM the resulting bitmap in RTC contains 4 (DM runs in 320x200, RTC in 640x400); the bitmaps are stored internally at the higher resolution and scaled as such - I recommend having a look at a old version of the program (NewDM) which exposes the graphics core a bit more:
<a href="http://www.mrao.cam.ac.uk/~gg215/dm/New ... wDM.zip</a>
Although many (many!) features aren't implemented properly (in particular the pressure pad) it'll give you an idea of how the graphics bit works (although again it's changed a bit in RTC, the principle is very similar). Again I think this is the right way to do it as it allows for the flexibility for initially higher resolution graphics.
Final point (!) is that the graphics are already stored in RTC as 256 colour bitmaps (and converted to 24bpp internally on boot-up); hence why the download is still quite small!
On another point RTC does actually maintain a consistent resolution - it just doesn't look like it does. Everything is done on a pixel basis but for each pixel in DM the resulting bitmap in RTC contains 4 (DM runs in 320x200, RTC in 640x400); the bitmaps are stored internally at the higher resolution and scaled as such - I recommend having a look at a old version of the program (NewDM) which exposes the graphics core a bit more:
<a href="http://www.mrao.cam.ac.uk/~gg215/dm/New ... wDM.zip</a>
Although many (many!) features aren't implemented properly (in particular the pressure pad) it'll give you an idea of how the graphics bit works (although again it's changed a bit in RTC, the principle is very similar). Again I think this is the right way to do it as it allows for the flexibility for initially higher resolution graphics.
Final point (!) is that the graphics are already stored in RTC as 256 colour bitmaps (and converted to 24bpp internally on boot-up); hence why the download is still quite small!
Yeah basically
"It's so much easier (although maybe not quicker) just to splat out a colour onto the screen than to try and deal with different palletes, merging, picking the right one and whatnot."
Absolutely correct, bigger pain to code but some performance gain. I'm just worried about all these 16-bit graphics taking up lots of processor and/or memory. The loading time may be 30 seconds now, but what happens when *all* monsters and objects are implemented? And if you enable realtime aliasing, can you handle 20+ mummies, with a pile of 20 objects on the ground? (Things like this do happen in CSB)
I just realised that scaling perpendicular walls would probably cause seaming problems, so Ill retract that suggestion.
On a similar issue, I believe you mentioned that you could have different wall tilesets within the same dungeon level? If so, must a full celing/floor/wall be implemented for this seperate tileset, or can aspects of the two merge? For example, say I wanted to keep the same celing and walls in an area, but I wanted to turn the floor red or something. Would I have to include a second copy of the original wall and celeing graphics that go with my new red floor?
Good to hear that resolution and 256 color downloads are already implemented - what haven't you thought of? ;p
Absolutely correct, bigger pain to code but some performance gain. I'm just worried about all these 16-bit graphics taking up lots of processor and/or memory. The loading time may be 30 seconds now, but what happens when *all* monsters and objects are implemented? And if you enable realtime aliasing, can you handle 20+ mummies, with a pile of 20 objects on the ground? (Things like this do happen in CSB)
I just realised that scaling perpendicular walls would probably cause seaming problems, so Ill retract that suggestion.
On a similar issue, I believe you mentioned that you could have different wall tilesets within the same dungeon level? If so, must a full celing/floor/wall be implemented for this seperate tileset, or can aspects of the two merge? For example, say I wanted to keep the same celing and walls in an area, but I wanted to turn the floor red or something. Would I have to include a second copy of the original wall and celeing graphics that go with my new red floor?
Good to hear that resolution and 256 color downloads are already implemented - what haven't you thought of? ;p
-
George Gilbert
- Dungeon Master
- Posts: 3022
- Joined: Mon Sep 25, 2000 11:04 am
- Location: London, England
- Contact:
Re: Yeah basically
> but what happens when *all* monsters and objects are
> implemented?
They already are; all the CSB monsters and objects as well as all the DM ones are already included and loaded on boot-up. There won't be any further extension in the load time...I've programmed it for the worst case (a mega dungeon with absolutely everything on one level) - if anything then it'll get shorter if I implement a "partial loading" of only the required objects (although, again, this is a pain to code, so I'm quite happy with sticking with everything).
The issue of having many many objects on the screen is unrelated to this, but a serious point. Although I havn't tried it, I think it will slow down terribly for more than about 10 real-time aliased objects on screen for anything less than about a 500MHz processor. The non aliased blitting is done in hardware though calling your graphics card to take the load off the processor so I think the best deal is just to turn aliasing off if the frame rate drops too low.
> must a full celing/floor/wall be
> implemented for this seperate tileset
Sort of. It must be implemented but it can be specified to be the same as another one. For example a (representative) data file might look like:
[Graphics]
WALLS_GREY = walls_grey.bmp
FLOOR_GREY = floor_grey.bmp
ROOF_GREY = roof_grey.bmp
WALLS_RED = walls_red.bmp
[Wall set 1]
WALLS = WALLS_GREY
FLOOR = FLOOR_GREY
ROOF = ROOF_GREY
[Wall set 2]
WALLS = WALLS_RED
FLOOR = FLOOR_GREY
ROOF = ROOF_GREY
i.e. you have to fully specify everything, but the grey floor and roof isn't loaded twice, just referred to twice. Again, look at the NewDM graphics loading data files (in the /Data folder) to see how it works.
> what haven't you thought of?
Plenty, I'm sure!
> implemented?
They already are; all the CSB monsters and objects as well as all the DM ones are already included and loaded on boot-up. There won't be any further extension in the load time...I've programmed it for the worst case (a mega dungeon with absolutely everything on one level) - if anything then it'll get shorter if I implement a "partial loading" of only the required objects (although, again, this is a pain to code, so I'm quite happy with sticking with everything).
The issue of having many many objects on the screen is unrelated to this, but a serious point. Although I havn't tried it, I think it will slow down terribly for more than about 10 real-time aliased objects on screen for anything less than about a 500MHz processor. The non aliased blitting is done in hardware though calling your graphics card to take the load off the processor so I think the best deal is just to turn aliasing off if the frame rate drops too low.
> must a full celing/floor/wall be
> implemented for this seperate tileset
Sort of. It must be implemented but it can be specified to be the same as another one. For example a (representative) data file might look like:
[Graphics]
WALLS_GREY = walls_grey.bmp
FLOOR_GREY = floor_grey.bmp
ROOF_GREY = roof_grey.bmp
WALLS_RED = walls_red.bmp
[Wall set 1]
WALLS = WALLS_GREY
FLOOR = FLOOR_GREY
ROOF = ROOF_GREY
[Wall set 2]
WALLS = WALLS_RED
FLOOR = FLOOR_GREY
ROOF = ROOF_GREY
i.e. you have to fully specify everything, but the grey floor and roof isn't loaded twice, just referred to twice. Again, look at the NewDM graphics loading data files (in the /Data folder) to see how it works.
> what haven't you thought of?
Plenty, I'm sure!
Re: Yeah basically
I just noticed that with anti-aliasing on and preloading off my frame rate and mouse responce drops in about half if I stand right in front of a wall object that can perform an action (levers, fountains etc). If I turn preloading back on, there is no drop in frame rate whatsoever when I stand in front of these objects. I'm only mentioning it because it sounds strange, maybe its accidentally (on purpose?) rescaling/drawing/something the wall object?
- Amaprotu
- Amaprotu
- Amaprotu
That sounds about right
Loading only what's needed for a level sounds best
And good to hear about the wall options...
Heres a Q though, say I wanted to make a "table" that you can set stuff down on, and can throw stuff over, and see the other side, but you can't walk through it. Is this doable with RTC?
And amapromptu, that is how it works... if you pre-load, then it does all the aliasing/scaling only once and stores it in memory. With preloading enabled, aliasing will slow down your boot up, but will have no effect on in-game.
If you don't preload, then I imagine it has to scale and alias for each frame, so that can really kill your framerate...
And good to hear about the wall options...
Heres a Q though, say I wanted to make a "table" that you can set stuff down on, and can throw stuff over, and see the other side, but you can't walk through it. Is this doable with RTC?
And amapromptu, that is how it works... if you pre-load, then it does all the aliasing/scaling only once and stores it in memory. With preloading enabled, aliasing will slow down your boot up, but will have no effect on in-game.
If you don't preload, then I imagine it has to scale and alias for each frame, so that can really kill your framerate...
Re: That sounds about right
I understand that foxbat, I think what I forgot to mention is that when I stand directly in front of any other wall object (grate, hook etc) there is no drop in frame rate. And if I look at the wall object down the hall, or one square away or to the side there is no drop in frame rate from when no wall objects are in sight. I only get a drop in frame rate (significat 50% at least) when standing directly in front of wall objects that can have an effect. I did not test keyholes but water fountains and levers had this effect. What this seems like to me (someone who has never seen the code and doesn't know how the program is working) is that the object is being redrawn on each check to see if you are doing something to the object. Rather, I believe, the object should be drawn once when you first move there, and again when/if you do someting with it. Again I am not sure exactly what is happening, only George knows that. Is that clearer?
Aside from this effect my computer gets the same frame rates (low 40s) no matter which settings I choose in the config file. <p> <a href="http://www.icq.com/icqtour/webcomm.html"><img alt border="0"src="http://online.mirabilis.com/scripts/onl ... e.gif"></a> AMAPROTU
<p><a href="http://msg.mirabilis.com/scripts/contac ... 7004"><img altborder="0" height="23" src="http://www.jps.net/amaprotu/wot/icqme.gif" width="88"></a><ahref="mailto:2667004@pager.mirabilis.com,amaprotu@jps.net"><img alt border="0" height="23"src="http://www.jps.net/amaprotu/wot/email.gif" width="87"></a><ahref="http://web.mirabilis.com/scripts/srch.d ... 7004"><img alt border="0"height="23" src="http://www.jps.net/amaprotu/wot/zoom.gif" width="87"></a></p></p>
Aside from this effect my computer gets the same frame rates (low 40s) no matter which settings I choose in the config file. <p> <a href="http://www.icq.com/icqtour/webcomm.html"><img alt border="0"src="http://online.mirabilis.com/scripts/onl ... e.gif"></a> AMAPROTU
<p><a href="http://msg.mirabilis.com/scripts/contac ... 7004"><img altborder="0" height="23" src="http://www.jps.net/amaprotu/wot/icqme.gif" width="88"></a><ahref="mailto:2667004@pager.mirabilis.com,amaprotu@jps.net"><img alt border="0" height="23"src="http://www.jps.net/amaprotu/wot/email.gif" width="87"></a><ahref="http://web.mirabilis.com/scripts/srch.d ... 7004"><img alt border="0"height="23" src="http://www.jps.net/amaprotu/wot/zoom.gif" width="87"></a></p></p>
- Amaprotu
-
George Gilbert
- Dungeon Master
- Posts: 3022
- Joined: Mon Sep 25, 2000 11:04 am
- Location: London, England
- Contact:
Re: That sounds about right
Well, it won't be anything to do with whether or not an object has an action or not; for a start it's dealt with somewhere else in the code totally seperate to the drawing, and secondly water fountains don't have actions.
My guess, from what you describe, is that if you stood in front of the manacles then you'd get a similar effect too; i.e. the frame rate slows down when you're standing infront of a large graphic, which kinda makes sense really...
My guess, from what you describe, is that if you stood in front of the manacles then you'd get a similar effect too; i.e. the frame rate slows down when you're standing infront of a large graphic, which kinda makes sense really...
Re: That sounds about right
All right I went in and did some research, these are with out preloading and with anti aliasing. I have a Celeron 500, 256MB ram, a TNT2 32meg vid car (not M64) running win98 if anyone is interested.
Isolated items (nothing else on the screen in frames per second)
key hole : 40-42
Rock on floor in front of wall: 40-42
Closed door with hole in it and screamer moving behind: 13-25
door (grate type, not solid) open and closed: 40-42
hook: 40-42
lever: 20-23
waterfountain: 20-23
manacles: 40-42
solid door with button (open & closed): 40-42
ring on wall: 40-42
empty hero mirror: 40-42
hero mirror w/ hero: 40-42
stairs: 40-42
vi alter with scroll: 40-42
blank wall: 40-42
moss on wall: 40-42
text on wall (where you can read the text): 40-42
These items I could not get alone on the screen durring my test (there are walls in the distance or something, corner etc.):
empty hall (looking down the hall): 40-42
grate: 38
puddle: 38
text one square back: 30-32
By perform an action I meant that you can right click on the water fountain to have the leader drink, I didn't mean the fountain actually did anything. My first conclusion was obviously wrong, otherwise buttons, mirrors and torch holders would all have the same effect on frame rate, which they don't.
I dunno what the case is, it just seems weird to me. I tested with multiple items in each cast to make sure it wasn't the location (something behind it being scaled or something).
Also I only get this effect with preloading off and anti-aliasing on. If I turn off anti-aliasing effect is gone, if I turn on preloading the effect is gone.
Severity: Minor
Priotity: very low
- Amaprotu
Isolated items (nothing else on the screen in frames per second)
key hole : 40-42
Rock on floor in front of wall: 40-42
Closed door with hole in it and screamer moving behind: 13-25
door (grate type, not solid) open and closed: 40-42
hook: 40-42
lever: 20-23
waterfountain: 20-23
manacles: 40-42
solid door with button (open & closed): 40-42
ring on wall: 40-42
empty hero mirror: 40-42
hero mirror w/ hero: 40-42
stairs: 40-42
vi alter with scroll: 40-42
blank wall: 40-42
moss on wall: 40-42
text on wall (where you can read the text): 40-42
These items I could not get alone on the screen durring my test (there are walls in the distance or something, corner etc.):
empty hall (looking down the hall): 40-42
grate: 38
puddle: 38
text one square back: 30-32
By perform an action I meant that you can right click on the water fountain to have the leader drink, I didn't mean the fountain actually did anything. My first conclusion was obviously wrong, otherwise buttons, mirrors and torch holders would all have the same effect on frame rate, which they don't.
I dunno what the case is, it just seems weird to me. I tested with multiple items in each cast to make sure it wasn't the location (something behind it being scaled or something).
Also I only get this effect with preloading off and anti-aliasing on. If I turn off anti-aliasing effect is gone, if I turn on preloading the effect is gone.
Severity: Minor
Priotity: very low
- Amaprotu
- Amaprotu