Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Maes

Alpha v0.4 HiColor mode screenshots

Recommended Posts

As you may know, the v0.4 Doom Alpha was suspected for a long time to have a HiColor mode, which however none was ever able to get to work to the best of my knowledge.

Among the various detail modes available in the Alpha, pressing "R" would turn the screen from normal (left) into something like this (right):



Many thought this was a broken screen mode, but upon closer analysis, this turned out to be, indeed, the "lost" HiColor mode. In this mode, the Alpha does indeed write 16-bit 555 RGB pixels to the screen, only that the VGA screen mode is never changed to a proper 320x200 HiColor mode. The bands you see are actually the high and lower bytes of the 16-bit color blits interpreted as 8-bit indexes.

Luckily, there's a way to recomposite them into proper (well, almost) HiColor images: by saving the DOSBOX screenshots as BMP without any other change, the raw indexes (and thus the actual data in the VGA buffer) is preserved. Without any other changes, I tweaked the BMP file a bit so the bit depth was set to 16-bit, and the horizontal resolution to 160 pixels, while preserving the same data.

This is the result:



As with my Mocha Doom HiColor experiment, the difference in color depth is hard to see with the naked eye, but The Gimp's ColorCube analysis doesn't lie:

  • Normal mode screenshot: 130 unique colors;
  • HiColor interpretation of garbled screenshot: 224 unique colors
More screenies:





Apparently, Doom only rendered to a 160x200 window in this mode, or there is data which is ending up in non-visible addresses of the VGA (perhaps only even columns are written in the first 64K of the VGA? Only a debugger could reveal whether this is the case). I have no idea if anyone has ever seen this mode working in practice, but under DOSBOX at least no graphics card emulation mode causes a switch to a proper mode: all give garbled stripes.

In any case, this is more proof that this mode wasn't worth the effort: it would double the video bandwidth for little or no gains in visuals, at least not in id levels and not at vanilla resolution, let alone that they'd probably have to bundle doom.exe with a host of different video drivers to support all kinds of different SVGAs at the time.

Share this post


Link to post

Yeah, if the trade-off for hi-color was low-resolution, it was mostly useless.

Here's the first picture stretched to 640x400. If you're still using Firefox as your browser, you'll even get to see it as animation. I chose APNG rather than GIF because amongst the two layers there are 347 unique colors.


Note how pretty much everything (except the leg of the marine turning his back to you) looks a lot worse in low resolution despite the high color. The benefit of increased color depth is entirely negated.

Share this post


Link to post

I'm not entirely sure they actually rendered this mode in in low detail.

The status bar is also rendered at a lower resolution but with proper colors, and this could be interpreted in two ways:

  • Everything is indeed rendered in low detail, and the status bar was rendered with an entirely different mechanism compared to the beta version (e.g. as a patch together with other sprites, and so affected by the low detail mode).
  • Stuff is actually rendered in high detail, and there is stuff written at other parts of the VRAM which can only be made visible by hacking the VGA or forcing a SVGA mode switch during runtime.
Now I'm not aware how exactly the "HiColor" mode's memory layout was supposed to work . However it's possible to induce a HOM-like flickering by setting DOSBOX to emulate "vgaonly", switching to "HiColor" mode and then going back to a normal mode. At least this sort of proves that they never switched to an actual SVGA mode, and that probably they only attempted 16-bit writes without leaving VGA Mode X.

Share this post


Link to post

Judging from the output, if it was at normal resolution then it was in a weird interleaved column formats. And you'd need to have DOSBox work in a weird 640x200 mode to capture all the columns, then put them back in the right order. This doesn't seem very credible to me.

It makes sense to me that, given the extremely limited amount of video memory available*, if each pixel takes twice as much memory, then there would be half as many pixels to compensate.

(* I remember being astonished by the game Rise of the Robots because what it did was, according to my "PC Hackers' Bible", totally impossible. Heh.)

Share this post


Link to post

My guess would be that, in fact, the alpha *is* writing 320x200, in two banks of video memory. Used to be that you had to switch banks by writing to an I/O port, IIRC, to write an entire screen, on any video mode that required > 64K (even in 32-bit mode). Anyway, interesting work, indeed.

Share this post


Link to post
Gez said:

If you're still using Firefox as your browser, you'll even get to see it as animation.

It's not that there's a browser which sucks less than Firefox

Gez said:

I chose APNG rather than GIF because amongst the two layers there are 347 unique colors.

TRUE COLOR GIFS EXIST!!1 (Each GIF frame can has its own palette).

Share this post


Link to post
tempun said:

TRUE COLOR GIFS EXIST!!1 (Each GIF frame can has its own palette).

That doesn't make GIFs true color, you are still limited to 8-bit per frame.

Share this post


Link to post
Tormentor667 said:

That doesn't make GIFs true color, you are still limited to 8-bit per frame.

Aaaand you can make frames zero-delay. Which allows to create an illusion of true color.

Share this post


Link to post

tempun said:
Aaaand you can make frames zero-delay. Which allows to create an illusion of true color.

Yup. (You can see the 16x16 blocks being drawn, but I think that's because it's uncompressed...)

Share this post


Link to post
tempun said:

Aaaand you can make frames zero-delay. Which allows to create an illusion of true color.



That would technically make it a HAM mode, but without the guarantee that it would be displayed correctly.


Actually, that's more like the "2 colors per block" limitation of the ZX Spectrum display, or the 4-color per block limitation of the NES. Essentially you can split an image into 16x16 blocks each with its own palette. Needless to say, this adds considerable overhead (every block of 256 pixels has its own 256-color palette. Ugh.)

I recall there was a similar trick to display "true color" on standard VGA cards (actually, give the illusion of 18-bit color) by alternating all-red, all-green and all-blue components of a picture coupled with a palette change (all red, green or blue hues), thus giving a (very flickery) illusion of RGB666 color.

Share this post


Link to post
CODOR said:

Yup. (You can see the 16x16 blocks being drawn, but I think that's because it's uncompressed...)

I think the delay is for illustrative purposes.

Share this post


Link to post

So Doom should have used animated GIF for its HiColor mode? [/sarcasm]

Share this post


Link to post

Awesome stuff.
Always wondered about that mode. On the machine I tried it, P60 with Super7 video card, the result was an immediate crash. The picture was only visible for a moment then it was back to DOS.
Vertical dimension of it seemed 100 pixels only.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×