General comments on v0.03

Messages are moved here (should anyone ever want to see them again) once they are no longer applicable to the current version (e.g. suggestions that have been implemented or bugs that have been fixed).

Moderator: George Gilbert

Forum rules
Please read the Forum rules and policies before posting.
Post Reply
User avatar
Gambit37
Should eat more pies
Posts: 13715
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

General comments on v0.03

Post by Gambit37 »

Here's some initial comments on v0.03 after a quick play test:

This version runs so much better on my system. Frame rate stays reasonably high, and the mouse hardly ever bounces or becomes difficult to control. On the whole performance seems better too, with startup time being shorter.

Save game format seems to work. Haven't noticed any glitches with that yet.

Stepped lighting is much improved, but still has some problems. DM used 6 levels of light, RTC seems to have 5. DM also never went completely black - on the lowest level you could still make out some details. It also takes a long time for light to diminish, much longer than in DM.

Sleeping still does not replenish stats as quickly as DM.

I have some other more specific comments but will either post these on existing relevant threads or start new ones.
User avatar
Gambit37
Should eat more pies
Posts: 13715
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: General comments on v0.03

Post by Gambit37 »

A few more general points:

DM has quick keys: Ctrl + Q to quit at any time (even on the title screen), and Ctrl + S to save. You can also press Return on the keyboard on dialog boxes with an OK button, and it acts as clicking the button. RTC doesn't have any of this.

Regarding save dialog: Change the message to read something other than 'Put the save game disk in drive C' - doesn't make sense.

Lord Chaos can kill you with a fireball when standing toe-to-toe, but you never see it. You do see it briefly in DM when he launches a fireball, or indeed any spell at close range - RTC doesn't do this.
User avatar
cowsmanaut
Moo Master
Posts: 4378
Joined: Fri Jun 30, 2000 12:53 am
Location: canada

light and dark

Post by cowsmanaut »

Uhmm the darkness depends on the brightness of your monitor.. If you raise your brightness you can play the entire game without lighting a torch.

Remember that in DM it used less colours and it wasn't a direct shift of the values into darkness but rather a shift to the darkest colours. And obviously the darkest grey was very visable.

In reality however one can not see anything when there is no light to see by.

One thought though would be to raise the light level when casting a fireball
level 4 when 1 square away
level 2 when two squares away
then nothing..

just a thought.

cheers
User avatar
Gambit37
Should eat more pies
Posts: 13715
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: light and dark

Post by Gambit37 »

I can't tell from your post if you are taking the mickey or not! :wink:

Of course you can raise the brightness of your monitor - it doesn't change the fact that DM used 6 levels of light.

You're wrong about what it was doing with the palette shifting. It didn't remap colours to the darkest colours - it actually changed the colour value of colours 17-32 to lower values. You can see this quite easily if you take screen grabs of each light level using something like Screen Thief.

Of course, in reality, you wouldn't see anything if there was no light. But perhaps in the Dungeon Master reality, the rock walls are phosporescent and give off a subtle glow. Perhaps all the monsters also have this attribute, Perhaps FTL wnated to give the player a fighting chance to vaguely see what was going on around them. Perhaps this, perhaps that.... it doesn't really matter. I'm simply pointing out that RTC does not do what DM does.

It's also worth noting that wearing the illumulet basically keeps the light level at 2, one higher than almost completely dark. That's why it's pointless having your party wear more than one as it makes no difference to the available light.

The Fireball idea is good - it's what was done in DM2. In fact, DM2 used a different light model as there were other light sources around such as torches and fires. Also, one extra bright level was left available for casting fireballs and for the lightning effect, to simulate areas being made temporarily brighter.
User avatar
cowsmanaut
Moo Master
Posts: 4378
Joined: Fri Jun 30, 2000 12:53 am
Location: canada

not quite right

Post by cowsmanaut »

think about it a moment. there were only 16 colours. Ok?
(actually there were 18 but two of the values were on a sort of time share arrangement with annother two the two purples from purple worms were not always there) ANYWAY.. :)

The colours you are using are needed in other things you have in your hand.. inventory.. character portraits etc. it would be really dumb for them to change the values of the whole pallet rather than just that of the images to the lowest colours in the *current* pallet. You can really see this in CSB on .. uhm the atrai I think it was.. at a further distance the colour dark brown was used here and there as an inbetween and resulted in the fountains eyes appearing red at a distance.

anyhow.. if they shifted the wholes set of greys down then your swords and armour and rock/boulder etc etc would all darken too. (please remember when you pick up one of these objects it goes to it's orriginal colours still on the same screen) So I'm pretty sure I'm right no matter what your Screen theif tells you. There is no other way for them to do it.

On the other note.. It's not good that one can simply turn up the birghtness and walk around with no need of a tourch .. also the fact that you say it was completely black just shows how dificult it is to match everyones taste since everyone sets brighness and contrast to their own taste. I think that the last light level should be nealry black and anything else is fine as is.
User avatar
Gambit37
Should eat more pies
Posts: 13715
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

OK, let's try again...

Post by Gambit37 »

Uhuh... DM uses 32 colours, two (more or less equal palettes) of sixteen colours, split over two rows. The top row of sixteen colours is used to draw the inventory, objects, interface, mouse pointer etc. The bottom row is used to draw the dungeon display. The second row of colours are lowered to darker values to simulate the light diminishing effect without affecting elements of the display that have been drawn using the top row of colours. The lighting effect would not be possible using 16 colours and the technique you describe without the dungeon looking REALLY weird.

Palettes change slightly per level to account for the two colour change for things like the worms (two pinks), trolin and water elementals (two blues), coutal and swamp slime (green and orange), etc. etc. In these cases, two colours on the second row are replaced on certain levels.

It's possible that 32 colours were used on the PC version, which is where I'm getting the information from, and that 16 colours were used on Amiga and ST displays. But seeing as a normal Amiga/ST lo-res display was 320 x 240 x 32 colours, I don't see why FTL would have limited themselves to half the amount of colours they needed to create the lighting effect. Also, colour depths are defined on a bit level basis, which means that the amount of colours available in each step effectively doubles: 1,2,4,8,16,32 etc. If your argument was correct and there are 18 colours used in DM, then at minimum a 32 colour screen depth would need to be set up to allow 18 colours on screen at once. If that's the case, then why on earth would FTL not bother to use the 14 spare colours, and why would they go to all the trouble of building palette lookup tables for the colour shifting?

Palette shifting using lookup tables DOES exist in DM2, but they have a much larger palette of 256 colours to play with, so it's more efficient than the technique used in DM and CSB.

Screen Thief is an excellent program, and I do trust it to tell the truth. Unless I've pissed it off or something, I don't know why it would give me false information. I think you need to rethink this! :)
User avatar
cowsmanaut
Moo Master
Posts: 4378
Joined: Fri Jun 30, 2000 12:53 am
Location: canada

hmmm

Post by cowsmanaut »

I'm not very good at verbal communication of ideas visual is much better.

At any rate, I pointed out that there were 18 colours yes. I also stated that the 2 colours were switched depending on the level they were on. these 2 colours change from level to level. I say it's a 16 colour mode since the orriginal was done for an Apple IIe .. I do not think they wrote the game from scratch on each platform. They probably needed to make minor changes to screen drawing and sound etc. The Amiga version possibly loaded in a 32 colour mode yes but it allowed for hardware sprites which would use those extra colours perhaps..it could be done with 16 still though so I doubt it.. the ST however if you noticed had a little blue hand (not sure why but..) and when you picked up things they turned to the same blue (cyan but whatever).

So anyway, 320x200x16 is completely possible on the Amiga.

Anyhow, everyone noticed that when you move a a monster to a 'wrong' level it would change to some weird colour. Why would this happen in a 32 colour pallete? There is no reason as they would have more than enough colours to go around. And this is on the pc where in a vga mode you can have 320x200x256. Also if they used 32 colours why would they not 'tidy' up the graphics? Instead of using odd colours for shading etc?

So, I'm sorry but I can not accept the theory. Besides I've been doing lo-res low colour graphics for games for a VERY long time and Have learned the tricks used to get more colours out of specified screen mode. One of those is that you leave free spots in your pallete for changing colours. There is a game for Amiga that does this called Karate Masters (I think that's the name) It uses 32 colour mode and only uses 16 for the background and leaves the remaing at a value of zero. then it has the characters which uses the last 16 and leaves the first 16 at value zero then in game combines the two palletes. This allows for more depth to their backdrops. It's a very old trick and I'm fairly sure it's what they did.

At any rate it is not possible to know without asking one of the orriginal crew.. or by breaking down the whole of the code and looking through it.

You know I've forgotten why we are debating this at such length anyway.. :)
User avatar
cowsmanaut
Moo Master
Posts: 4378
Joined: Fri Jun 30, 2000 12:53 am
Location: canada

screen grabs

Post by cowsmanaut »

Also on a side note. I did the screen grab thing and counted the number of greys only one is added after the first light level. value of 36. however to support my theory.. annother colour ends up vanishing. still leaving only 16 on screen *max* at one time.
Pharaoh
Neophyte
Posts: 5
Joined: Sat Feb 10, 2001 6:56 am

DM colors and stuff

Post by Pharaoh »

Actually, Gambit37, I'll have to go with Drake on this one in saying DM wasn't more than 16 colors.

When he said he'd counted 18 colors total, he also said that no more than 16 were displayed simultaneously, which is the issue here, not how many are in the game itself. This is similar to how a plain-vanilla VGA adapter has a maximum palette size of 256 colors, but since each color is specified by an RGB triple, there are actually 262144 colors available.

I originally played DM on the Atari ST, and your statement about the default "low res" on that machine being 320x240x32 is wrong. The ST's low res was 320x200x16, organized in a planar fashion, with 8k per plane, for a total of 32k. This 32k video size was fixed in hardware, though its location in the ST's memory could be changed, and is why the ST medium and high res modes are four colors and monochrome, respectively. Higher resolutions could be achieved by using the "porch" area- the border area that's usually black, or whatever color 0 was set to, but I only saw this done once. Likewise, more colors could be achieved, but only by changing the palette registers as the screen was drawn, but such an approach requires very tight synchronization between the video display and the software. It's fine for still images or paint programs (like Spectrum 512), but far too CPU-intensive for a realtime game on an 8mHz machine.

As far as the Amiga goes, I'm well aware it could handle 320x240x32, but the only graphical change I'm aware of between the ST and Amiga versions had to do with the mouse cursor, as in the ST, it was cyan when an empty hand or arrow, as it was when holding an item over the view screen. On the Amiga, I believe it was flesh colored when an empty hand, and items always had their full color (as they did on the ST when _not_ over the dungeon view area, so don't try telling me they increased the color depth). I'm not sure what color the Amiga arrow was, though. Likewise, the PC version has a white hand and arrow, and held items maintain their color over the view area.

As far as the PC version goes, I get options for both EGA and VGA when I run it. Yes, the EGA one looks like shit, even though it can handle 16 colors, but this is more due to the fact that the primary colors are only two bits wide for the EGA, rather than 6 bits for the VGA. In other words, there are only 4 shades of true grey available. So, I run it under VGA, natch.

Then I do a few screen grabs. I'm running Win95, and since I don't have any decent DOS screen grabbers, I just use the printscreen/paste-from-clipboard technique. The VGA version _is_ running in a 256-color mode according to this, but that doesn't mean it's using all of them. For some reason, it gets scaled to 640x400 from 320x200, but I'm pretty confident this is Windows, since plain-vanilla VGA couldn't handle that resolution in 256 colors. Even in 16 colors, it'd require hardware tweaking, since the nearest BIOS modes are 640x350 and 640x480.

Anyways, after saving the first image and looking through the palette, it looks like more than 16 of the colors are used. However, many of them are colors that are never used within the game. I'll grant that more than 16 (about the first 20 or 22) are used in the game, but never all at the same time. Paint Shop Pro's "count colors" option of my numerous screen grabs never turned up more than 16 colors. I mean, if you're going to claim they used 32 colors simultaneously, you'd have to concede that they used a 256 color mode (VGA offers only 1, 4, or 8 bits per pixel- not 5). To use your own argument, then ("why on earth would FTL not bother to use the 14 spare colours"), why wouldn't they use the spare 224 colors? Maybe because they didn't want to totally redo graphics which were originally designed to run on machines with 16 color graphics hardware, such as the ST.
User avatar
Gambit37
Should eat more pies
Posts: 13715
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: DM colors and stuff

Post by Gambit37 »

I accept that what you say about the ST version is probably true, having never seen the ST version running. The statement about lores screens on the ST was pure speculation on my part, assuming as I did that the ST version was the same as the Amiga version.

I've only played the Amiga and VGA PC versions of the game, and I'm 100% certain that my description of the 32 colour palette and the light diminishing effect is true for these two platforms. I fully accept that there will be differences in versions with fewer available colours on screen. Perhaps I should have made it clearer in my original post that this was the case.

ScreenThief will rightly perform a 256 colour grab of the PC VGA screens from DM. But it's quite clear that when you view this palette, only the top 32 colours are being used by the program, and the rest of the palette is being ignored. I can only assume that rest of the palette is using default colours specified either by ScreenThief or the VGA hardware itself.

For the sake of a quick port to the PC, it's pretty obvious why FTL didn't extend the palette to use all 256 colours under VGA. They waited for DM2 to do that. The ST and Apple II versions were coded at the same time, and then the Amiga version came later, with the PC version following the Amiga version. I think the PC code is based on the Amiga port, using 32 colours, which would explain this. Obviously they had to code two different models, one for EGA and one for VGA.

I'm afraid you can't rely on the Count Colours option in Paint Shop Pro to give reliable results in this case. It looks at <b> actual</b> colour values, so if you have two greys the same that are in different parts of the palette, it won't have a clue if different indexes of the same colour value are used to draw a particular pixel, and will report it as one colour. Try getting a grab of level 5 with a swamp-slime or couatl on screen, then do count colours. That palette's two unique colours are orange and green and should be clearly seen in the second row of colours. Note that this will only work if you get a grab with the light level less than maximum (otherwise colours on the second row match exactly the colours on the first row, with the exception of the two unique colours)

I guess the truth of the palette issue is a mixture of mine, your's and Drake's info, and is platform dependent. I'm sure no-one else really cares, but I found the discussion interesting!
Pharaoh
Neophyte
Posts: 5
Joined: Sat Feb 10, 2001 6:56 am

DM colors and stuff

Post by Pharaoh »

Regarding using PSP's "count colors" option, I'm well aware it looks at actual color values, not palette indices. However, my theory is that this is done as a simple convenience.

See, the only time the palette is changed, the only time one or more colors get "pushed out" by new colors, is when a large rectangle of the screen gets redrawn. This is the dungeon view/character inventory section. I submit that when you get a slime or couatl on the screen, there are as many unused colors from the "top" palette as there are used ones in the "bottom" palette. Since they had to store all the pictures in memory (for that level, at least) in memory _anyways_, and the palette shift only happens when this section is redrawn, and they had a 256-color palette available (16 times what they needed for the DM graphics), they opted to have the images use different pieces of the palette, rather than share indices from 0-15. This way, they only redraw the screen, rather than redraw the screen _and_ reprogram the palette registers. It's simply a convenience, nothing more.

One way to test my theory (I haven't yet) would be to save the screens in question, load 'em up in your paint program of choice, one that has an "eyedropper" tool of sorts (ie, gets the color you click on in the image). Then, change that palette value to 0 0 0. If you have to change more than 16 (well, 15, since one palette entry already is black), then you've got more than 16 colors displayed at once. Otherwise, while you may have a pixel value in excess of 15, your image will be entirely absent of one of the values from 0-15.

Why they wouldn't have just stuck with a planar 16-color mode, and just mapped the first 16 of the 256 VGA color registers (what we've been referring to as the "palette") into the EGA palette is a mystery to me. I mean, since it supports EGA display, they evidently had to write the planar rendering code anyways. Perhaps they don't do any palette changes in the EGA mode, though, what with EGA's color mixing capabilities sucking as horribly as they do.
Pharaoh
Neophyte
Posts: 5
Joined: Sat Feb 10, 2001 6:56 am

DM colors and stuff

Post by Pharaoh »

Ack. I might not have been too clear at the beginning of my last message. What I meant by "as a convenience" wasn't in reference to the counting colors, as my wording implied, but rather to the reasoning behind why the PC version of DM might have used 32 colors of the palette.

Anyways, I spent a few minutes and cobbled together a quick and dirty program to examine a Windows bitmap file, and report the number of colors from the palette that are actually used. It totally ignores what the RGB values for the palette indices _are_, and merely flags whether a specific index has or has not been used in the image. Needless to say, it only works on 16 color and 256 color images. I don't know if the bitmap format allows for other color depths with palette-based images, but I don't think so.

I'll email a copy of the source to you; it should compile fine under any ANSI compliant C compiler. You might find it useful for something else as well (though who knows what).
User avatar
Gambit37
Should eat more pies
Posts: 13715
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Screengrabs available if anyone's interested...

Post by Gambit37 »

I finally put up some screengrabs of the PC VGA version of the Dungeon Master light diminishing effect. Download these and open them in Paint Shop Pro or similar, and you'll see exactly what I'm talking about. Ignore the palette below the first two rows of 16 colours as they're not used. I'm having trouble getting the same from the Amiga version, due to my emulation being a bit up the creek, but I'm fairly certain it uses the same effect.

<a href="http://www.resonant.freeuk.com/dm1palet ... sPC.zip</a>

Cheers! :)
User avatar
George Gilbert
Dungeon Master
Posts: 3022
Joined: Mon Sep 25, 2000 11:04 am
Location: London, England
Contact:

Re: Screengrabs available if anyone's interested...

Post by George Gilbert »

Fixed the original points (whatever they were!) for V0.04
Post Reply