Dungeon Master Forum

It would be cool thing to be able to quit back to the entrance of the dungeon, where you can "enter", "resume", or use the new options (like the hint oracle) without restarting RTC and, as a consequence, preload all the bitmaps again. and again. and again. and again. and again etc.

I was about to post the same thing...

Definitely, if we have all spent the time loading the bitmaps, it's annoying not to be able to quit and use the hint oracle, or even be allowed to leasurely restart a game or enter again. I think the end screen should come up with two options - restart (meaning back to the entrance) and exit which leads to the credits..almost like the original game!

Actually, this is a must for later, when we need to playtest our own dungeons. Otherwsie to check out each change in a dugeon you are going to have to close and restart RTC to re-enter!

And how about a new option for the scroll screen - restart with new dungeon? This will close the curent RTC, but will then execute the rtc.exe file again (ok ok, that might sound like laziness, but it would still be nice).

I think there is currently one problem regarding the playtesting. The newest version seems to prescale ONLY those bitmaps used in the dungeon. That is an extremely good thing to do, but...

Of course, this option is an absolute must for all designers. As a result, would we need an option to prescale ALL the existing bitmaps, whether they're used or not? So that they need not to be re-prescaled after certain changes to a dungeon?

id say prescale ALL bitmaps and after dieing/quitting jump back to the entrance door.
when you hit the enter button, you choose a dungeon.
if you save a game, its called like the according dungeon (like the_zoo.sav), so you have also to choose the dungeon/savegame when you hit the resume button.
that would be the best comfort i can think of.
(oh, and link the hint oracle on the door )

It would see to me that prescaling all DM AND CSB images would fill up your memory pretty quick..

I think a better solution is to prescale only those needed that aren't already in memory. so if you added say, a fountain it would only load and prescale the two fountain images.

RTC is a Windows Application. It runs in a Virtual Memory.
A lot of precalculated stuff loaded in memory will not hog RAM space. Useless stuff will get swaped out on disk and sit there unused.
Do not worry about memory usage. It is virtual, very large, efficient.
As a general comment. Many programmers will waste time on speed and/or space issues, where there is no effort needed thanks to 1: Disk cache and 2: Virtual memory.
Cheers.

You have *way* more faith in M$ ability to handle virtual memory and memory. My hard drive thrashes so much when I play memory intensive games I swear windoze stores the important stuff on the hard drive and the crap in ram. Either way the less that gets carriesd over to virtual HD memory the faster and smoother a program will run. Virtual memory creates a <b> huge</b> performance hit.

the point is you DON'T want things in VM I have VM turned off I've got 256 megs of ram I have no use for VM.... Period!

VM is only as fast as you drive and for most people that isn't all that fast. it's also dependant on if you have a larg contiguos portion of free drive or else your VM is scattered through the drive.

As mentioned M$ can not make good decisions on VM and RM.. as I said, I have 256 megs of ram and I've run programs that have fairly low mem requirements yet it used VM!!??

So to close I would like to say that memory consumption is an issue, and a large one. You don't want to fill it with things you don't need. Gearge made a good call on this design already with loading just what is needed there would be nothing lost from only loading a few extra images each time you add a new dungeon graphic. the load time would be negligable and there would be only speed to be gained.

and one other thing to think about.. if VM was so efficient then why not just extract the graphics to a dir and just load them as needed.. thats more or less what you are suggesting..

ok, lets say the graphics are loaded the time they are needed.
but the different savegames (1 for each dungeon) should be implented, id say.

How do you shut of VM then?
It's annoying the crap out of me, windows keeps whining about opening other programmes cause RTC or DMute has trashed the .swp file : (

to shut down virtual memory you need to go to start menu/settings/controll panel.
then click on an Icon named 'system' from there there is an adavced tab that you can push and in there you can see performance options. In there is virtual memory. you can set it to 0 or off or whatever.. haven't done it for a while.

Chances are it will then whine that you may not be able to run stuff.. which is unlikley if you have 128M or more ram. so just ignore the stupidity and say yes.. you will now need to restart .. when you come back you may or may not notice a difference. Many people don't untill they play a game. My friend was stunned at how fast his army game (can't remember it's name you are more or less the average sniper/rambo who breaks into some base thingy.. sorta cool .. all 3d) ran afterwards. It's strange that windows will hand other things VM when there is a tonne of free REAL ram.. it's insane.

cheers, i'll try it!

Be ready to go back to having virtual memory on. I have 256 megs in my computer and some of the games I play will not run with it turned off. For example EverQuest and Diablo2 both stop and tell me to turn VM back on. The best advice I can give would be to set the min and max the same (generally for best performance twice your ram size if you can believe that) and get a program called Cacheman. Although the best version I think is version 3 but it doesn't support me or win2k. Version 5 I think tries to do way too much. If you have lots of ram you there is a conservative use flag you can set in a [vcache] section of system.ini. However its not set on my computer right now for some reason so I don't know the exact wording of it =/. Good luck. <p>Amaprotu
Mahkahl Darkwolfe "Avvisione"
Flezz Fuu
</p>

RTC is absolutely a great game and very realistic to the original one.

BUT I NEVER SAW SUCH A CRAP FOR THE MEMORY

My computer has got 128MB and when loading RTC
Windows takes all the free 120MB of my disk, which
makes 240MB !!!!!!! When you think of the original
game needing only 1MB, what's that joke ? Something
is really screwed up !

The game even CRASHED when I organized for a
monster to fall in a pit

We need to do something... Dear author I can help
you if you want I am sure you wanted to make
RTC a working version and that optimization was left
for later which is absolutely good, but I would be happy to help you program it

Denis

ACK! George got rid of the "(not so) frequently asked questions" section! No wonder your having difficulty here... ok this is my recap of the pertinant section:

DM: 4 bit color (16 colors) 320*200
RTC: 24 bit color (16.7million colors) (640*400

This alone means each screen has either 12 times as much data to sent to the screen or 6million times as much data (I can't decide which if either). Aside from this, a limited color base allows for some tricks. When you have a palette of colors you can adjust all those colors to do shading (basically colors 0-15 all have a value you set, you can change those to change things very efficiently). However if full color mode you can not do this, you have to redefine all the objects colors and resend it to the screen. RTC also has transparency and partial tranparency, this take a lot of processing power as well.

All this amounts to a much slower program that takes a lot more memory. Why do it then? Because the *main* point to RTC is to create a platform where it is easy to create dungeons of more variety than is possible with DMute. Once the format is released it will be able to create dungeons with your own graphics for items, walls, characters, monsters and even the interface. More types of puzzles should be at least easier to implement etc. A large part of this forum has been the discussion of ideas we want george to implement in the dungeon creating code to make puzzles not possible in DM with DMute.

<p>Amaprotu
Mahkahl Darkwolfe "Avvisione" (48th level Enchanter [EQ])
Flezz Fuu (27th Level Rogue [EQ])


Deja Moo - The distinct feeling you have heard this bullshit before.</p>

The screen is 4 times the size, so it's actually 24 times as much info, not 12 : )

heh ya thats right. =p

<p>Amaprotu
Mahkahl Darkwolfe "Avvisione" (48th level Enchanter [EQ])
Flezz Fuu (27th Level Rogue [EQ])


Deja Moo - The distinct feeling you have heard this bullshit before.</p>

Ok I understand the problem, but really, the game is far too slow, so we should be able to find a way to solve it :

1. Isn't there (I don't know directX at all) some kind of method/procedure/driver to display with a palette and this method would convert it for us ? Or even, why not open a screen with less colors ? Wouldn't it be possible ?

2. Ok future dungeons, but then, each dungeon should have a config to specify the colors

Anyway, I'm *sure* some solution must exist, because in the actual situation it's really crazy : So much memory used AND so slow ! It could be one or the other but both... Compared to 1MB on Amiga and the speed )

BTW thanks for your replies

The palette thing would be much harder to implement, especially as RTC uses alpha transparency which requires a 16 or 14 bit colour depth. You can 'fake' transparency using a paletted 8-bit display, but it requires massive lookup tables to be generated for palette shifting, and it's much harder than simply splatting out stuff direct to a true-colour display.

Don't forget that the main reason for RTC was for the author, George, to learn about games programming (and not, as Amaprotu said to make a flexible dungeon creation tool - that was a secondary aim). George is learning all the time, so perhaps in time the methods RTC uses for memory management will improve.

While it's true that RTC *could* be more memory efficient, faster, and have more options. It would require George to learn them. He has mentioned he isn't very experienced at this sort of thing.(game programming)

The best way that those in the "Know" about programming can help is simply by offering suggestions on ways to optimise. The worst that could happen is that he has already tried and dismissed it or done it already. You'll have to understand though that he will not show his sources since they do contain proprietary code that (from what he's told me) is not solely his alone. While he has written it all, some of it I think has been written for his job.

any examples should be DX3 compatable since he's made a lot of effort to get it to work on NT.

Is he still planning to upgrade it for DX8 once the final version is finished? So there will be the final NT version, and the final win98 version.

>You can 'fake' transparency using a paletted 8-bit display,
>but it requires massive lookup tables to be generated for
>palette shifting, and it's much harder than simply splatting
>out stuff direct to a true-colour display.

256*256 per alpha level. (*1 byte, since we only need 256 values)

So, a full 256 level alpha blending lookup table for 8-bit mode would be 256*256*128 (128 levels, you can do the rest 128 levels by swapping the colors around ) = 8388608 bytes.

So, with only few alpha levels, it wouldn't be bad, and the advantage of 8-bit modes is that they are insanely fast compared to true color blending (generally, but there are ways around that too)... The biggest problem is the limited 256 color palette.

- X-Viila, aka. Toni Y.
Creator of Return of Chaos, Grave of King Millius and DM2 dungeons.

Um, that's not what I meant. I wasn't referring to true alpha blending using the method you describe, but something more like Doom or Duke Nukem where there are fixed number of light levels per colour.

The lookup tables are then only as large as the number of light levels multipled by the number of colours - each number in the lookup table is just a pointer to a location in the palette to use a darker colour. So if you have 16 light levels and build the mapping yourself, it's only 16* 256 colours = 4096 bytes or 4Kb.

This approach works for light levels only, not for transparency, unless you want to sit there for months working out which colours in the palette to use to simulate transparency, when overlaying one colour over another. Of course, your method would work fine if there are only a few transparency levels to use, such as 25%, 50%, 75%.

ABout transparency...at the moment, the transparency is only 50% or 100%, to give fast bit checking for each oone

Would it be easier, for having the 25, 50 and 75, to have two sets of numbers...

the first is a transparency check as before...if 0, then it ignores the next two, and moves on to the next picture, while if it's 1, then it checks the next two bits, whic has 00 - 11 for 0 (invisible) to 75%

Would this be an efficient way of making sure that the speed of start up was affected to greatly by more transparency?