Chocolate Doom

For such small images you can render to the screen, grab the image to a texture and then render the actual scene as a fallback.

GZDoom still uses this method for small camera textures because it's faster than setting up the framebuffer to render to a texture.

Problem is that the grabbed, scaled up image will be 1600x1200.

I know I should probably post on bug tracker...but this is much easier than making an account and figuring out tracker.

1.5.0, WinXP. The window in windowed mode is positioned randomly on screen. Meaning the window is created in various locations on screen so I usually have to hit ESC and manually move the window to the middle of the screen. Most of the time the statbar is below Windows Taskbar.

I originally thought it was mouse cursor position related, but testing many times in a row without moving mouse and just hitting Enter key while my .bat was highlighted moved the window to many different locations on screen.

fraggle said:

Problem is that the grabbed, scaled up image will be 1600x1200.

Why that? You can set a much smaller viewport for that. I never had problems with it.

fraggle said:

Both of these look pretty ugly to me and to my eyes don't reproduce the look of the game as you see it on a CRT monitor.

Casually I've been playing around with the idea of recreating a perfect progressive-scan CRT look on LCD monitors.

One thing to keep in mind is that at 320x200, we're dealing with underscan, which results in a sort of "scanline" effect, and the bigger the monitor, the more visible. Personally, I think it looks nice since it helps pixelation a lil bit.

After analyzing my 19-inch CRT under a magnifying glass when playing vanilla Doom (real DOS, fullscreen) I figured out the exact scanline arrangement, and the rest consisted in calculating how the image would have to be upscaled for the fake overlay scanlines to look the same way real ones do on a CRT.

The image has to be proportionally upscaled to 1600x1000, 5 times it's original size, then 200 lines are duplicated from the 200 upscaled pixels of the vertical resolution, effectively changing the aspect ratio to 4:3 and leaving you with a 1600x1200 image. All this using nothing but nearest-neighbor.

At this point a simple overlay is added, placing a scanline every 2 real (not upscaled) pixels, and that's about it.

The test images below, when viewed at 1600x1200 (you may still need black bars on the sides) are literally indistinguishable from Doom running at it's native resolution on a regular progressive-scan CRT monitor, provided your monitor has vibrant colours and good contrast, which unfortunately rules out every LCD/Plasma screen on the market today, but worry not, oleds will be making it big in the years to come. In the meantime, however, this would give CRT users with newer video cards and inflexible drivers, a genuine taste of 320x200.

This way you get a proper 4:3 image without noticeable stretching plus the underscan look, all with pixel precision, no approximations. It couldn't be any simpler.

http://i54.tinypic.com/30aua05.png
http://i52.tinypic.com/1z1fhgo.png

Porsche Monty said:

Casually I've been playing around with the idea of recreating a perfect progressive-scan CRT look on LCD monitors.

One thing to keep in mind is that at 320x200, we're dealing with underscan, which results in a sort of "scanline" effect, and the bigger the monitor, the more visible. Personally, I think it looks nice since it helps pixelation a lil bit.

After analyzing my 19-inch CRT under a magnifying glass when playing vanilla Doom (real DOS, fullscreen) I figured out the exact scanline arrangement, and the rest consisted in calculating how the image would have to be upscaled for the fake overlay scanlines to look the same way real ones do on a CRT.

The image has to be proportionally upscaled to 1600x1000, 5 times it's original size, then 200 lines are duplicated from the 200 upscaled pixels of the vertical resolution, effectively changing the aspect ratio to 4:3 and leaving you with a 1600x1200 image. All this using nothing but nearest-neighbor.

At this point a simple overlay is added, placing a scanline every 2 real (not upscaled) pixels, and that's about it.

The test images below, when viewed at 1600x1200 (you may still need black bars on the sides) are literally indistinguishable from Doom running at it's native resolution on a regular progressive-scan CRT monitor, provided your monitor has vibrant colours and good contrast, which unfortunately rules out every LCD/Plasma screen on the market today, but worry not, oleds will be making it big in the years to come. In the meantime, however, this would give CRT users with newer video cards and inflexible drivers, a genuine taste of 320x200.

This way you get a proper 4:3 image without noticeable stretching plus the underscan look, all with pixel precision, no approximations. It couldn't be any simpler.

http://i54.tinypic.com/30aua05.png
http://i52.tinypic.com/1z1fhgo.png

Very nice!

Porsche Monty said:

Casually I've been playing around with the idea of recreating a perfect progressive-scan CRT look on LCD monitors.

Ok, interesting. As this takes all of 5 minutes to implement I've added a special option to the latest version in Subversion to do as you describe. To test it out, do this:

chocolate-doom -scanline -geometry 1600x1200 -fullscreen

That's about perfect! so very much appreciated :)

I still can't test it in fullscreen mode as briefly explained in the bug tracker (unrelated problem) but since it matches the test images 1:1, I think it's safe to assume fullscreen mode has no problems either.

Porsche Monty said:

Casually I've been playing around with the idea of recreating a perfect progressive-scan CRT look on LCD monitors.

This method doesn't really work. Scanlines tend to be acceptable on CRTs due to the very high contrast ratio and high brightness at levels that LCDs cannot obtain. When you try to emulate scanlines on an LCD they just end up making the picture look dark and muddy since the scanlines are too bright.

EDIT: Oh wait you covered that durrrr.

After modifying my monitor driver I can finally go fullscreen with 1600x1200 and the scanlines look as just as intended.

I'll no longer be needing tedious trickery to get powerstrip to use my custom timings for the unsupported 320x200 mode since 1600x1200 works at an exact 70.000000000000000Hz by driver default, and despite the output resolution being over 5 times larger than vanilla's, Chocolate Doom is blazingly fast so I get no slowdowns whatsoever.

All this may seem ridiculously trivial, but I could die a happy man today.

Are you using Windows? Just wondering since it seems that Windows drivers are hiding or disabling low-resolution modes such as 320x200 these days...

Yes, XP.

Several 320x200 modes are installed with the driver and I never had problems using any of them, it's the custom timings created with powerstrip (needed for the perfect 70Hz) what are tricky to apply to underscan resolutions as they're not officially supported by this application.

chungy said:

Are you using Windows? Just wondering since it seems that Windows drivers are hiding or disabling low-resolution modes such as 320x200 these days...

For Windows machines RivaTuner can be used to add those resolutions back safely.

Graf Zahl said:

Why that? You can set a much smaller viewport for that.

For accurate blockiness.

Nine times out of ten I can't even understand what Porche Monty is asking for.

Creaphis said:

Nine times out of ten I can't even understand what Porche Monty is asking for.

Then you can assume it's a CRT and a SoundBlaster. ;)

Creaphis said:

Nine times out of ten I can't even understand what Porche Monty is asking for.

the 90s.

Just got a segmentation fault a little while ago, while playing njdoom2.wad on level 15. I was walking around the outside area (where the red doors are located), and the game crashed all of a sudden for no obvious reason.

It generated a core file, so I poked around a little...

(gdb) bt
#0 R_DrawMaskedColumn (column=0x8cfa1fff) at r_things.c:364
#1 0x1c02376a in R_RenderMaskedSegRange (ds=0x3c056300, x1=306, x2=306)
at r_segs.c:185
#2 0x1c025659 in R_DrawMasked () at r_things.c:981
#3 0x1c022ed9 in R_RenderPlayerView (player=0x3c053a80) at r_main.c:906
#4 0x1c005283 in D_Display () at d_main.c:300
#5 0x1c00544b in D_DoomLoop () at d_main.c:440
#6 0x1c006421 in D_DoomMain () at d_main.c:1519
#7 0x1c00b6cf in main (argc=0, argv=0x0) at i_main.c:152
(gdb) l
359 for ( ; column->topdelta != 0xff ; )
360 {
361 // calculate unclipped screen coordinates
362 // for post
363 topscreen = sprtopscreen + spryscale*column->topdelta;
364 bottomscreen = topscreen + spryscale*column->length;
365
366 dc_yl = (topscreen+FRACUNIT-1)>>FRACBITS;
367 dc_yh = (bottomscreen-1)>>FRACBITS;
368
(gdb) print topscreen
$6 = 0
(gdb) print column->length
Cannot access memory at address 0x8cfa2000
(gdb) print column->topdelta
$9 = 0 '\0'
(gdb) info args
column = (column_t *) 0x8cfa1fff

So maybe the column struct got corrupted or something...

I went back to the game, but it didn't crash again. This is the first hard crash like this I've experienced during a game (I mean as the result of a bug rather than something like visplane overflow).

Creaphis said:

Nine times out of ten I can't even understand what Porche Monty is asking for.

In this case, something that looks worse than interlacing.

Can we have a "Be annoyingly vanilla" option already? Stuff like the IDMUS bug in doom and many other ridiculous things that I can't remember off the top of my head seem to only serve to annoy and should be optional. Just throwing that out there.

That's a dangerous slippery slope. I'd rather deal with strange, annoying little bugs than having someone just picking and choosing and deleting which engine quirks are "just annoying" and ending up destroying the entire premise of making the most authentic-to-the-original port ever made.

Megamur said:

That's a dangerous slippery slope. I'd rather deal with strange, annoying little bugs than having someone just picking and choosing and deleting which engine quirks are "just annoying" and ending up destroying the entire premise of making the most authentic-to-the-original port ever made.

What? no, it's not. There's certain parts of vanilla doom that serve no purpose of gameplay or demos or even netplay but cause crashes when there should be none. Most of these were fixed by emulating different executables, but when it comes to some "bugs" that crash the game because of 1.9-itis, I have problem with it.

IDMUS and Z_Malloc errors are a big issue. Chocolate-doom already supports long demos and larger savefiles, which is actually the two most annoying things about vanilla doom, conveniently toggle-able.

NOT-BUGS has a list of these annoyances. visplanes errors I can understand, but crashes in the menu just causes problems.

Csonicgo said:

Can we have a "Be annoyingly vanilla" option already? Stuff like the IDMUS bug in doom and many other ridiculous things that I can't remember off the top of my head seem to only serve to annoy and should be optional. Just throwing that out there.

What part of "Chocolate Doom is a Doom source port that accurately reproduces the experience of Doom as it was played in the 1990s" don't you get?

If you want a reasonably genuine vanilla experience minus the "annoyances", use prBoom+, that's what it's there for.

I see Chocolate Doom as more of an "archaeological restoration" project where improvements beyond increasing compatibility and usability on newer OS', should not be considered, but then again, not my project, not my rules.

Porsche Monty said:

What part of "Chocolate Doom is a Doom source port that accurately reproduces the experience of Doom as it was played in the 1990s" don't you get?

If you want a reasonably genuine vanilla experience minus the "annoyances", use prBoom+, that's what it's there for.

I see Chocolate Doom as more of an "archaeological restoration" project where improvements beyond increasing compatibility and usability on newer OS', should not be considered, but then again, not my project, not my rules.

Your argument is flawed because Chocolate Doom already has several optional bugfixes and extensions, which don't in any way conflict with its ability to fulfill its mission statement.

Also, since when does PrBoom+ in any way resemble playing vanilla?

Porsche Monty said:

What part of "Chocolate Doom is a Doom source port that accurately reproduces the experience of Doom as it was played in the 1990s" don't you get?

How is any of the stuff I mentioned essential to its usability as an accurate testing platform?

And how accurate are we talkin' here? Down to the nice feature of vanilla sending garbage to the printer when it has a venetian blinds crash? Maybe there's a WAD out there that exploits this to print out an ascii Doom logo.

Chocolate Doom, therefore, should be accurate down to the number of hairs pulled out of my head back in the day.

(Why stop there? Why, if we could somehow create a program that simulates a DOS PC and run Doom in that, it would be the most authentic experience ever!)

In all seriousness, there are no wads that use Z_malloc errors. There are no wads that exploit the patch drawer in the options menu. There are NO wads that exploit the IDMUS bug. There's only ONE WAD EVER MADE that uses a dirty trick to crash the game, and I think everyone knows which one. Yes, that one.

esselfortium said:

Your argument is flawed because Chocolate Doom already has several optional bugfixes and extensions, which don't in any way conflict with its ability to fulfill its mission statement

I don't quite remember any vanilla-exclusive bug that has been fixed in Chocolate. In fact, one of the goals was to reproduce vanilla bugs so it screwed up just like vanilla did.

You could even argue that these few extensions aren't much of a deal given that at least one of them is also available in it's original form as a patch for vanilla; the longtics fix. That's the real slippery slope here, you got to know where to stop. Maybe the remaining Doom+ features (actually all of'em, as the vanilla demo limit option in Chocolate uncaps rather than extends) could be implemented when everything vanilla is already working as intended, then call it a day for good. But you need to be very careful and understand how and when they can be done as you could end up introducing even more problems and forgetting the "vanilla essence". Personally I'd favor something that looks and behaves exactly like vanilla without absolutely anything extraneous to it, something so you couldn't tell apart from the real DOS thing, but I'm pretty happy with what's been done so far and it only keeps getting better.

esselfortium said:

Also, since when does PrBoom+ in any way resemble playing vanilla?

Since always?

Csonicgo said:

In all seriousness, there are no wads that use Z_malloc errors. There are no wads that exploit the patch drawer in the options menu. There are NO wads that exploit the IDMUS bug. There's only ONE WAD EVER MADE that uses a dirty trick to crash the game, and I think everyone knows which one. Yes, that one.

All those fancy stability fixes mean nothing to a true vanilla enthusiast ;)

Porsche Monty said:

I don't quite remember any vanilla-exclusive bug that has been fixed in Chocolate. In fact, one of the goals was to reproduce vanilla bugs so it screwed up just like vanilla did.

There's an option to extend vanilla's limited savegame size, for one. In addition, Chocodoom is compatible with longtics demo recording.

You could even argue that these few extensions aren't much of a deal given that at least one of them is also available in it's original form as a patch for vanilla; the longtics fix. That's the real slippery slope here, you got to know where to stop.

And why is it up to you to determine when enough is enough, enough so for your own opinion to be worth talking down to others for voicing their thoughts? (Serious question.)

esselfortium said:

There's an option to extend vanilla's limited savegame size, for one. In addition, Chocodoom is compatible with longtics demo recording.

How's that a bug fix? well, maybe it is, but I can't read code.

esselfortium said:

And why is it up to you to determine when enough is enough, enough so for your own opinion to be worth talking down to others for voicing their thoughts? (Serious question.)

And who said it was up to me?

Xeros612 said:

In this case, something that looks worse than interlacing.

Actually I think it looks excellent, just like ye olde CRT I used to have. I've actually had this idea before myself but I never bothered to to come up with an implementation... but I thought 1600x1200 would be the only reasonable resolution it would work in. (I played with chocolate-doom -scanline on a 1920x1200 monitor btw, looks fantastic!)