Maes Posted November 28, 2011 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. 2 Share this post Link to post
Gez Posted November 28, 2011 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. 1 Share this post Link to post
Maes Posted November 28, 2011 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. 0 Share this post Link to post
Gez Posted November 28, 2011 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.) 0 Share this post Link to post
kb1 Posted November 28, 2011 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. 1 Share this post Link to post
tempun Posted November 28, 2011 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 FirefoxGez 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). 0 Share this post Link to post
Tormentor667 Posted December 7, 2011 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. 0 Share this post Link to post
tempun Posted December 7, 2011 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. 0 Share this post Link to post
CODOR Posted December 7, 2011 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...) 0 Share this post Link to post
Maes Posted December 7, 2011 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. 0 Share this post Link to post
tempun Posted December 7, 2011 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. 0 Share this post Link to post
Maes Posted December 7, 2011 So Doom should have used animated GIF for its HiColor mode? [/sarcasm] 2 Share this post Link to post
_bruce_ Posted December 7, 2011 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. 0 Share this post Link to post