[Ninety-Six]

I've had a DOSBox emulator set up in a special directory on this machine to tinker and experiment on older games (or to even play some of them at all if they lack a source port). I decided to load up Duke 3D for a nostalgic laugh, and after spending far too many days arguing with the sound setup (ah, the memories), I was in.

And it struck me immediately that Duke didn't look all that different from eduke32. At least, as far as resolution goes. Coming fresh off the heels of Doom in DOS, it's quite a jump. I tried to look into it and apparently both games run at 320x200, which I found even stranger. I see a lot more obvious artifacting from the lower resolution in Doom than I do in Duke. Not that I don't see any because I obviously do. It just seems like Duke's sunglasses double as corrective lenses vs. Doomguy's blurry helmet.


Keep in mind, I'm running them from the exact same instance with the exact same config files. And sure, maybe over twenty years of playing Duke 3D has desensitized me to some of its aging aspects, but at the same time I don't think that's the entire explanation. I swear I can see a lot further ahead with clarity in DOS Duke than I can DOS Doom.

Is anyone able to explain this discrepancy? Am I really just blind here, or is there something I'm missing? Were the resolutions I found incorrect? Does Doom purposefully cut down its visiblity even in high detail mode? Is this a weird quirk of DOSBox? Or is this one of those Build black magic jank things that totally shouldn't work but does anyway?

[MrFlibble]

Well, the monster sprites in Duke3D are larger than those in Doom, so they will look more detailed and crisp at a distance compared to Doom's; and the levels are more detailed. This might create an impression that there is more low-res "artifacting" in the latter than in the former. There is also likely a huge difference between how each game handles palette colour remapping to simulate varied light levels, including diminishing lighting at a distance..

[Ninety-Six]

MrFlibble, on 26 March 2021 - 01:18 PM, said:

Well, the monster sprites in Duke3D are larger than those in Doom, so they will look more detailed and crisp at a distance compared to Doom's; and the levels are more detailed. This might create an impression that there is more low-res "artifacting" in the latter than in the former. There is also likely a huge difference between how each game handles palette colour remapping to simulate varied light levels, including diminishing lighting at a distance..

I'm sure that's part of it, but compare these screenshots:





I took these shots at about the same angle relative to a lower floor. In the duke picture the edge is clearly less artifacted.

Again, these are both taken from the exact same DOSBox executable, so the configs are identical. I checked the setups as well to see that there wasn't any display setting I was missing. Doom apparently doesn't have anything for display in its setting, and Duke 3D is set to the Normal 320x200. Now it's true I have dosbox set up to use the normal2x scaler to avoid the default (which tends to be glitchy on Dosbox), but again this is the case for the entire application so it should be applied to both. Especially since it's only the normal scaler and not the weird and chunky hq filter.

EDIT: I just noticed the image resolutions are weird. I took both of these through the Ctrl+PrntScrn command but the Duke image is significantly larger than the Doom image. Doom is exactly what you'd expect for a doubled 320 image. Duke's is not?


I have no idea what's going on here.

[Phredreeke]

Are you sure Duke is actually set up to run at 320x200?

[Ninety-Six]

Phredreeke, on 27 March 2021 - 07:15 AM, said:

Are you sure Duke is actually set up to run at 320x200?

Now that you've asked I guess I'm not sure anymore. What does it default to? I was under the impression the other video option was a compatibility thing.

Given the battles against the sound options and how even trying to change back to a setting that kinda worked but now didn't at all, I'm understandably hesitant to test both.

[Phredreeke]

I mean, easiest way would be to open up DUKE3D.CFG and see what it says

[Perro Seco]

Ninety-Six, on 27 March 2021 - 08:05 AM, said:

Now that you've asked I guess I'm not sure anymore. What does it default to? I was under the impression the other video option was a compatibility thing.

Given the battles against the sound options and how even trying to change back to a setting that kinda worked but now didn't at all, I'm understandably hesitant to test both.

Damn, it's not that difficult, try with my configuration file. Sound and music work, and it's already set to 320x200, which is my favourite resolution to play these old games. You might want to change the controls though.

Attached File(s)

•  D3DCFG.zip (1.95K)
  Number of downloads: 223

[Aristotle Gumball]

That isn't 320x200 in the Duke screenshot for sure.

[Ninety-Six]

Phredreeke, on 27 March 2021 - 09:20 AM, said:

I mean, easiest way would be to open up DUKE3D.CFG and see what it says

Oh. I forgot that even existed.

Okay yeah it wasn't 320 for sure.



So here's an interesting thing I found after testing with that. Duke doesn't cock his gun anywhere near as much on the results screen in the actual 320 mode, while he does that all the time in both the higher resolution version and eduke32.

[oasiz]

Easy way to tell pixel densities in duke3d is that the status is 320 pixels wide and 34 pixels high
This means that at 320x200 the status bar will be mapped 1:1 to the screen resolution and 3D itself would be the remaining 320x166 pixels.

Back in VGA days the most compatible and used mode was 320x200 or with tweaks you could get 320x240 and a correct aspect ratio, but these were generally all optional.

This puts 320x200 stretched to 4:3 (by the CRT) as the "intended look", not necessarily the best look, but something that HAD to give you the best general experience, maybe you could say "calibrated look"

Something like 640x400 would in turn double the status bar pixels and render the 3D portions at high resolution.
Of course how the drawing routine works, if screen elements are not not perfectly pixel aligned and scaled, you will get doubled/dropped pixels on the bitmaps that get put on screen.
This is usually evident source ports/mods that generally aim for more compact and better HUDs at the expense of scaling artifacts in lower resolutions.

Based on your screenshot, you can tell that that the status bar looks much lower resolution than the 3D portions, unlike doom example where the statusbar matches.

[MrFlibble]

BTW, here's something that I was wondering about. Would it be technically correct to say that 320x200 is the "original"/"native" resolution of Duke3D, if from the start it officially supports at least four resolutions: 320x200, 320x400, 640x480 and 800x600 - those are selectable from the setup utility, but even more are available by manually editing the CFG? This is in stark contrast to Doom which only supported VGA at the time of release, and no other resolutions were ever added to the official DOS version.

There is little doubt that during development of Duke3D, 320x200x256 was given priority (we know that 640x480 is buggy in LameDuke) and was indeed the default resolution - I don't think there are any pre-Atomic edition high-res official preview screenshots of Duke3D (unlike Shadow Warrior). But the renderer itself was designed so that you'd basically get the same view of the game world in any available resolution on a 4:3 display, the limits depending on whether the user's video card and CPU could handle the high-res modes. Here's a sliding comparison shot I made a while ago showing DOS Duke3D in 320x200 (aspect-corrected to 640x480) and 640x480 modes:
https://imgsli.com/Mzc0NTM

This is unlike Doom which notoriously screwed up the aspect correction issue when the Doom95 port was created.

[MusicallyInspired]

Doom at least was finally fixed when the Unity-wrapped ports were made last year. Duke3D supporting high-res modes was likely what kept the aspect ratio issues at bay that plagued Doom for so long. And still plagues Wolf3D too in a way.

[MrFlibble]

MusicallyInspired, on 28 March 2021 - 03:27 PM, said:

Duke3D supporting high-res modes was likely what kept the aspect ratio issues at bay that plagued Doom for so long.

I believe that comminuty-made Doom ports were fairly quick to fix the aspect ratio issue. It's exactly the point of my question that Duke3D, starting from the first official release (shareware v1.0), even if you don't count the leaked/unreleased stuff, comes with an array of screen resolutions that are all intended to render the game in a uniform way. 320x200 simply corresponds to the lowest system specifications supported, and there is no evidence that the game was intended to be played in 320x200 as the "true" resolution or something. For example, all official screenshots from the Atomic Edition that are available from Apogee/3D Realms website show the game in 640x480.

[Ninety-Six]

There might be additional evidence that the higher resolution was sort of a "soft patch" given how some small things change behavior, such as Duke cocking the gun on the level results far more frequently vs. how rare it is in 320. It almost seems like a bug with how hard the cut to the next level is.


That said though, could you clarify what you meant by the game being rendered in a uniform way? I mean the sliding picture is what it is, but I don't understand how Doom doesn't do that. I'm not doubting; I'm just clearly in the dark about something.

[oasiz]

320x200 is not the best look but it's the "calibrated look", just like how audio mastering is done to sound good on common equipment. Not necessarily intended but it's what has to look as good as possible as it would have been the most used one.
During duke3d's release, 640x480 required a beast of a machine to be playable. During doom's development such a thing would have not been realistic.

Build itself supported higher resolutions for some time, it's likely that they played around with these since the beginning but all things like scaling HUD items on the screen to things like screen effects (tilting, quake, etc..) would require code to actually handle other cases besides 320x200.
During development they likely knowingly ignored things like these as it's pointless to create robust routines for experiments.

As for the bonus screen timing, you'd be surprised how many timing related things get eyeballed based on ticks and dependant on system speed.
Remember that 320x200 doesn't require VESA modes so even that might make a difference with code paths. 640x480 requires 4x times the pixels.
I recall that the original DOS version had more fade to black transitions on some screens as well..

[Ninety-Six]

oasiz, on 29 March 2021 - 08:57 AM, said:

you'd be surprised how many timing related things get eyeballed based on ticks and dependant on system speed.

Consider this a failing on my part to understand how dosbox functions, then, since given that it can run both modes, should that not mean the system speed is roughly the same independent of the resolution?

Though that being said, I remember this happening back when I still had an Atomic CD running on Windows' then-native DOS support, so clearly I'm still suffering a critical misunderstanding somewhere along the line.

[MrFlibble]

Ninety-Six, on 29 March 2021 - 08:17 AM, said:

That said though, could you clarify what you meant by the game being rendered in a uniform way? I mean the sliding picture is what it is, but I don't understand how Doom doesn't do that.

DOS Doom doesn't do that, simply because there is no option to set any resolution above 320x200. And, as mentioned above, once it was ported to systems that support higher resolutions or don't use 320x200 at all (like Macintosh), it took some time and community enthusiasts to establish proper rendering at higher resolutions. Neither Doom95 nor Mac Doom do any aspect ratio correction.

DOS Duke3D on the other hand is already built with these resolutions implemented. "Uniform" is probably not the best choice of words, I meant to say that whichever resolution you select for the game, it's designed in such a way that you always see the same thing, only the resolution differs. E.g. you don't see more of the level on the screen if you go to higher 4:3 resolutions at any time, you only get a "crisper" image due to more pixels on the screen.

Ninety-Six, on 29 March 2021 - 09:15 AM, said:

Consider this a failing on my part to understand how dosbox functions, then, since given that it can run both modes, should that not mean the system speed is roughly the same independent of the resolution?

DOS Duke3D runs in software mode, meaning that it's the CPU that does the renderer math. Higher resolutions require more CPU power. The fact that it runs inside an emulator makes no difference.

You can check this yourself. Start the game in 320x200 and use the DNRATE code to display the frame ticker. You can then exit back to the looping demos so that you have the same things happening on the screen for the ticker to count. Repeat in 640x480 mode. The ticker will go down. Absolute values will depend on your DOSBox configuration and host PC power, but relatively, the ticker will be lower at 640x480 than at 320x200. Oh, and different ticker values are observed for the different 320x200 modes, that the game supports, as I described here.

[Ninety-Six]

MrFlibble, on 30 March 2021 - 01:25 AM, said:

DOS Doom doesn't do that, simply because there is no option to set any resolution above 320x200. And, as mentioned above, once it was ported to systems that support higher resolutions or don't use 320x200 at all (like Macintosh), it took some time and community enthusiasts to establish proper rendering at higher resolutions. Neither Doom95 nor Mac Doom do any aspect ratio correction.

DOS Duke3D on the other hand is already built with these resolutions implemented. "Uniform" is probably not the best choice of words, I meant to say that whichever resolution you select for the game, it's designed in such a way that you always see the same thing, only the resolution differs. E.g. you don't see more of the level on the screen if you go to higher 4:3 resolutions at any time, you only get a "crisper" image due to more pixels on the screen.

Okay I think I'm starting to understand. I didn't realize, though, that higher 4:3 resolutions changed the aspect ratio (since that would still be 4:3, wouldn't it?). I mean I'm already aware of the tall pixels on older CRTs, but does that change in higher resolutions? Or is it a different aspect ratio correction we're talking about?

EDIT: Immediately after posting this reply it might have clicked for me. Do you mean aspect ratio in the same way that Y-shearing works? That is, higher resolutions would end up looking more like this?



Mind, this taller image in general and not the illustrative view boxes. This is the only image I know of that visually demonstrates Y-shearing so bear with me.

MrFlibble, on 30 March 2021 - 01:25 AM, said:

DOS Duke3D runs in software mode, meaning that it's the CPU that does the renderer math. Higher resolutions require more CPU power. The fact that it runs inside an emulator makes no difference.

You can check this yourself. Start the game in 320x200 and use the DNRATE code to display the frame ticker. You can then exit back to the looping demos so that you have the same things happening on the screen for the ticker to count. Repeat in 640x480 mode. The ticker will go down. Absolute values will depend on your DOSBox configuration and host PC power, but relatively, the ticker will be lower at 640x480 than at 320x200. Oh, and different ticker values are observed for the different 320x200 modes, that the game supports, as I described here.

Interesting. Yet the gun cock seems to function properly with the slower frame rate vs. the 320 mode. I wonder if I were to take the 640 resolution and shrink the view size down (to increase frame rate) if that would re-break the end screen or if the 640 resolution on that screen would ensure it functions as it's supposed to.


This thread has taken on a new life from where it started but that is totally okay since I am learning some fascinating stuff about the DOS-era Build engine.

[oasiz]

Bit offtopic but you can see watch video to see stuff about Y-shearing in one easy clip


As for aspect ratios, VESA modes were a wild west with stuff like 360x360 as an option.
320x200 is 16:10 but the idea is that a CRT would stretch this to 4:3, matching something like 640x480 in terms of end result.
Not sure how duke handles it but it might be that the 3D portions have some aspect ratio stuff to them, making things match 4:3 and rest is just pixel density.
With 3D it's easier since it's just samples of a pre-defined geometry and you can easily just have more horizontal sampling accuracy compared to vertical and so on.

You can boot up eduke32 (like in the video) with a crazy high vertical resolution compared to horizontal and get a fuller frame.

[MrFlibble]

Ninety-Six, on 30 March 2021 - 03:44 AM, said:

I didn't realize, though, that higher 4:3 resolutions changed the aspect ratio (since that would still be 4:3, wouldn't it?). I mean I'm already aware of the tall pixels on older CRTs, but does that change in higher resolutions?

That's the catch. SuperVGA/VESA modes from 640x480 and above use square pixels. So the Build engine internally adjusts output in these modes to correct the image to the right vertical proportions -- so well that you wouldn't notice on that 320x200 vs. 640x480 comparison shot I posted. (For the avoidance of doubt, I corrected the 320x200 screenshot to 640x480 manually using the method described here).

Interestingly, you can also configure Duke3D to run in the 640x400 resolution if you edit the CFG file manually, which will automatically disable aspect ratio correction so that
the 640x400 image would be stretched to 640x480 on the CRT screen. In fact, Powerslave uses exactly this mode but misleadingly calls is 640x480 in the setup menu.

No, I did not mean Y-shearing.

Ninety-Six, on 30 March 2021 - 03:44 AM, said:

Yet the gun cock seems to function properly with the slower frame rate vs. the 320 mode. I wonder if I were to take the 640 resolution and shrink the view size down (to increase frame rate) if that would re-break the end screen or if the 640 resolution on that screen would ensure it functions as it's supposed to.

I do not know your DOSBox configuration and the host system specs, but it generally makes sense to run games at fixed or capped CPU cycles, instead of relying on the auto/max cycles function.

For example, earlier you asked if the game could be running at the same speed regardless of the resolution in DOSBox. It is possible to do by adjusting the CPU cycle values for each resolution. You could run the game in 640x480 with DNRATE and take note of the ticker values, then switch to 320x200 and manually adjust cycle count (F11-F12; preferably edit the conf file to go up and down a fixed amount of cycles like 100 cycles at one step) to get similar r maybe even identical values on the ticker. That would mean slowing down DOSBox for 320x200 compared to 640x480.

Usually I run 320x200 FPS 2.5D games with cycles capped at 26800, as described here.

cycles=auto 7800 100% limit 26800

[Ninety-Six]

MrFlibble, on 30 March 2021 - 05:26 AM, said:

That's the catch. SuperVGA/VESA modes from 640x480 and above use square pixels. So the Build engine internally adjusts output in these modes to correct the image to the right vertical proportions -- so well that you wouldn't notice on that 320x200 vs. 640x480 comparison shot I posted.

Fascinating. From my more amateur tinkerings I always thought that Duke 3D/Build had been better future-proofed than other engines at the time. I know Duke 3D came out in 1996 (even if the engine had a few earlier iterations), which was a huge leap forward in technology across the board so higher resolutions and stuff is to be expected. But even past this sort of corrective measure I'm kind of shocked at how adjustable to modern standards the game could be customized through the setup program, both in terms of control and now this advanced pixel ratio stuff. I don't think even Quake had this much going for it (at least not in an options menu. There was the console though, but that's by default less user-friendly than a settings menu).

Of course this isn't entirely without precedent; there was a lot of customizable depth to Rise of the Triad as well. Not to the same extent, but again I can't find many games around the same time that reached for any similar level of adjustability.

Duke 3D and the Build Trinity are games I would argue that, were it not for the DOS requirement, would be some of the easiest games to get set up and running to semi-modern standards without a source port. The higher resolution options (even if still tiny by today's standards, are significantly less chunky than other games), and the versatility of the control setups that can easily adjust to WASD or whatever key bindings you prefer, go a long way for Build to age much more gracefully. It might be a buggier engine compared to some of its contemporaries, but despite that it seemed designed to handle the changing landscape a lot better.


That's at least the opinion I've been forming by exploring the old DOS executables and comparing them to both themselves and other games of the time.

MrFlibble, on 30 March 2021 - 05:26 AM, said:

No, I did not mean Y-shearing.

I know you didn't mean actual Y-shearing, but I meant in the same way as that. In other words if the aspect ratio was not corrected when going to a higher resolution if it would look like the vertically extended image I posted. I brought up Y-shearing because as I understand it, games that use Y-shearing render the image much higher vertically so the player can emulate looking up and down.

I was asking if the uncorrected higher scale Doom engine looked like a Y-sheared rendering but all on one screen.


Or I guess in simple terms I'm asking what Doom looked like before proper aspect ratio correction was brought in to the fold. I can only truly appreciate the way Duke 3D handles it if I saw what it looked like when handled wrong.

I never had Doom95 as a point of reference.

[MrFlibble]

Ninety-Six, on 30 March 2021 - 05:53 AM, said:

Or I guess in simple terms I'm asking what Doom looked like before proper aspect ratio correction was brought in to the fold. I can only truly appreciate the way Duke 3D handles it if I saw what it looked like when handled wrong.

I never had Doom95 as a point of reference.

I just found out that Doom95 does not want to run properly on Win8.1; but Doomwiki.org has a nice comparison shot:
https://doomwiki.org...5Comparison.png

[Ninety-Six]

MrFlibble, on 30 March 2021 - 09:14 AM, said:

I just found out that Doom95 does not want to run properly on Win8.1; but Doomwiki.org has a nice comparison shot:
https://doomwiki.org...5Comparison.png

Okay so I was right; it does render more of the screen vertically like if it had Y-Shearing (but obviously isn't).

Though it also looks to me it renders less horizontally?

[oasiz]

One thing to add here is that duke3d's screen drawing functions assume a virtual viewport of 320x200, this means that even at 1600x1200 you can only place items at 320x200 precision.
This applies to 2D bitmaps drawn on top of the 3D stuff (weapons, HUD, crosshair, etc..)
Source ports like Eduke32 introduce improvements that allow toggling optional precision at subpixel accuracy and the ability to ignore AR correction (forced stretching).

[Ninety-Six]

oasiz, on 30 March 2021 - 11:01 AM, said:

One thing to add here is that duke3d's screen drawing functions assume a virtual viewport of 320x200, this means that even at 1600x1200 you can only place items at 320x200 precision.
This applies to 2D bitmaps drawn on top of the 3D stuff (weapons, HUD, crosshair, etc..)
Source ports like Eduke32 introduce improvements that allow toggling optional precision at subpixel accuracy and the ability to ignore AR correction (forced stretching).

Lowest Common Denominator, I would guess.

Incidentally how does this apply to widescreen weapon patches such as the ones in World Tour or Megaton?

[MusicallyInspired]

MrFlibble, on 29 March 2021 - 06:21 AM, said:

I believe that comminuty-made Doom ports were fairly quick to fix the aspect ratio issue.

Yeah, I was referring to all the official releases before the newest Unity-wrapped ones.

[Phredreeke]

oasiz, on 30 March 2021 - 11:01 AM, said:

One thing to add here is that duke3d's screen drawing functions assume a virtual viewport of 320x200, this means that even at 1600x1200 you can only place items at 320x200 precision.
This applies to 2D bitmaps drawn on top of the 3D stuff (weapons, HUD, crosshair, etc..)
Source ports like Eduke32 introduce improvements that allow toggling optional precision at subpixel accuracy and the ability to ignore AR correction (forced stretching).

Does this still apply to Redneck Rampage or was the size for the virtual viewport increased along with the resolution of the HUD?

[oasiz]

I think RR uses the exact same draw routines. It works just fine with higher resolutions, your virtual grid on placement is just limited.