[Plataea]

I started Duke Nukem 3D in Eduke32 and have a problem. I've noticed that the graphics seem to be stretched vertically a bit, as if the aspect ratio is wrong or something. I carefully compared the graphics I'm getting in Eduke32 with DOSBox and Eduke32 seems to have a higher height-to-width ratio than it should. I've tried everything I could think of and nothing seems to fix it. It's not a big difference, but it really bugs me personally. I would really appreciate it it there is some way to fix this.

I'm using plain Eduke32. I'm not using the HRP, nor any other additions. I used the Duke Nukem 3D files from GOG.com. The problem is the same regardless of resolution. The problem persists both in fullscreen and windowed mode and with or without polymer. Changing the aspect ratio from auto to something else didn't seem to help, either. Changing the renderer actually seems to make the problem worse.

I have attached the log files. The picture I attached is from the beginning of level E2M1, although I'm not sure how well it shows the stretching.

My PC is running Windows 7 Home Premium, 32bit. Intel Core i3 CPU. 530 @ 2.93Ghz. 4Gb Ram (2.99 usable). My video card is Nvidia GeForce GT330. I'm using "EDuke32 2.0.0devel r2835", which I downloaded a few days ago.

Attached thumbnail(s)

• 

Attached File(s)

•  eduke32.log (1.37K)
  Number of downloads: 202
•  mapster32.log (723bytes)
  Number of downloads: 215

[TerminX]

EDuke32 has code to correct for differences in pixel aspect ratio. With the DOS version, the game normally ran in 320x200 (a 16:10 resolution) stretched to 4:3, giving you rectangular pixels. With modern operating systems you usually run the game in a resolution native to the LCD panel you're displaying it on, so the aspect ratio of the output has to be adjusted to match the intended aspect ratio of the game. I think you can disable it with "r_usenewaspect 0" in the console if the correct display bothers you too much.

[Plataea]

Sorry, if I'm a bit of a noob, but are you saying that the original/DOSBox version is actually stretched, and Eduke32 has corrected this and is meant to be different? Is the way it's currently showing for me in Eduke32 correct and as the designers intended? If I changed it, would it then be stretched and not as the designers intended?

[Hendricks266]

I don't think "intended" is exactly the right word in this situation. A decision was made somewhere along the line to base the renderer on a 320x200 (16:10) resolution, most likely because it was a VGA resolution, with rather low-level DOS support. A further decision was made that when the game was played on any of its higher resolutions, it would take the same aspect ratio and stretch/squeeze it, giving you non-square pixels. Whether the lack of generation of proper square pixels in aspect ratios other than 16:10 was simply not known, not cared about, or omitted due to technical, performance, experience, or laziness reasons, we would have to really get into the developers' heads to understand why this was not implemented, and I highly doubt anyone would remember after 16 years.

With the above in mind, the non-rectification of screen-stretching (pun!) hinges on one thing: whether or at what times the Duke 3D game developers had access to Ken and/or the BUILD engine source code to make modifications to the engine.

Personally, I think non-square pixels suck, if and only if it is possible to have perfectly square pixels with equal or greater detail. (A circumstance where I am OK with non-square pixels is the technique the motion picture industry uses to produce widescreen video on DVDs, locked by design to 4:3.)

Furthermore, given the increasing variety of screen resolutions available, I would have to say that the developers would not have preferred the first image below over the second.

Original: r_usenewaspect 0


Modern: r_usenewaspect 1

[NY00123]

A few examples found online show that there may be no general rule for the "intended" way, if there is any.
As for personal experience, back when 4:3 CRT monitors were used, I would often stretch the pic to fill the whole screen (more or less), using the monitors' controls. So, no matter what is the resolution, you would get a picture with an aspect ratio of 4:3.

As for the DOSBox output being stretched or not, that actually depends on one minor setting. If you have "aspect=false" in the DOSBox configuration, I suggest you to change it to "aspect=true" and then make another comparison. The latter should be used to gain a ratio of 4:3 (even for supposedly non-4:3 resolutions); Well, at least in most cases. The "Normal Mode" of 320x200 in Duke Nukem 3D (as it is called in the SETUP application) is one of them.

[Hendricks266]

Ah, thank you for adding the point about the monitors. I forgot that in 1996, windowed mode did not exist, and there was no visible difference in terms of stretching no matter which resolution the game used; only clarity/detail changed. As for the correctness of r_usenewaspect, it depends on whether your paradigm implies stretching a resolution to your monitor's size, or employing a windowed viewpoint on your screen.

[Helixhorned]

Hendricks' two pics completely reflect my opinion, too. Just another minor note: if playing in full-screen mode, EDuke32 must know the screen's physical aspect ratio to potentially correct for non-square pixels with a non-native resolution. In Windows, this is attempted automatically at startup time, but if you're running on a different OS, or the auto-detection fails for some reason, you can set it manually with r_screenaspect.

[Plataea]

Thanks for your help and information, everyone. The thing is, I have tried running the game in DOSBox in 800x600 resolution and also 320x200 with "aspect=true" (so that it's in 4:3). Either way, Eduke32 still looks a bit taller and thinner. You have been helpful, but I still don't quite understand why there's a difference.

[Jan Satcitananda]

I've just tested the image aspect ratio ingame on a simple wall in 1024x768 8-bit mode... and 128x128 texels stretch into 512x492 screen pixels with old aspect ratio setting, whereas it measures 512x510 with the 'auto' setting. So, the original look is about 4% flattened, but I can't give a rational explanation of that. Maybe their screens were slightly different from the standard 4:3 ratio, more square perhaps (still not enough for 5:4 like in modern 1280x1024 screens).

[Fox]

Plataea, on 23 July 2012 - 05:04 PM, said:

Thanks for your help and information, everyone. The thing is, I have tried running the game in DOSBox in 800x600 resolution and also 320x200 with "aspect=true" (so that it's in 4:3). Either way, Eduke32 still looks a bit taller and thinner. You have been helpful, but I still don't quite understand why there's a difference.

Games like Duke Nukem 3D or Doom have been created at a time which monitors had rectangular pixels, thus Eduke32 is correct in "stretching" the screen.

"Streched" graphics - reference picture - graphics with perfectly square pixels





To check the aspect ratio, create a map with the player standing at exactly 2048 units away from a way with default size. It should show 256 pixels horizontally and 200 pixels vertically.





Now here is the same view with Polymost/Polymer with aspect ratio set to "Auto".



So yes, Eduke32 does not display the aspect ratio exactly like it should (should it?). It seems to be strecthing the image 1.25x instead of 1.2x.

[Helixhorned]

CraigFatman, on 04 August 2012 - 02:06 AM, said:

I've just tested the image aspect ratio ingame on a simple wall in 1024x768 8-bit mode... and 128x128 texels stretch into 512x492 screen pixels with old aspect ratio setting, whereas it measures 512x510 with the 'auto' setting. So, the original look is about 4% flattened, but I can't give a rational explanation of that. Maybe their screens were slightly different from the standard 4:3 ratio, more square perhaps (still not enough for 5:4 like in modern 1280x1024 screens).

Yes, these are my findings too, though I measured a factor of 1.07, which EDuke32 corrects for. That value is far too small to be a ratio of any of the common screen ratios, so I'm just as stumped as you as to why this happens.

Fox, on 04 August 2012 - 03:32 AM, said:

Games like Duke Nukem 3D or Doom have been created at a time which monitors had rectangular pixels, thus Eduke32 is correct in "stretching" the screen.

(...)

So yes, Eduke32 does not display the aspect ratio exactly like it should (should it?). It seems to be strecthing the image 1.25x instead of 1.2x.

Well, that's the question. IMO the "correct" way is to have squares in the world be square on the screen. Btw, there's samples/aspect.map which I use as reference.

[NY00123]

I have just got two relevant questions to ask, regarding the following info:

Helixhorned, on 23 July 2012 - 11:16 AM, said:

Just another minor note: if playing in full-screen mode, EDuke32 must know the screen's physical aspect ratio to potentially correct for non-square pixels with a non-native resolution. In Windows, this is attempted automatically at startup time, but if you're running on a different OS, or the auto-detection fails for some reason, you can set it manually with r_screenaspect.

So, here they are:

1. Assuming SDL 1.2.10+ is used, can SDL_GetVideoInfo be used to obtain the physical aspect ratio on platforms other than Windows? At least it seems to do the job here, if called before SDL_SetVideoMode. For reference: http://www.libsdl.or...i/SDL_VideoInfo

2. Now I see that sometimes, the aspect correction is done under the assumption that the game contents fill the whole screen. On other times, the aspect ratio is rather based
on the video mode, which makes sense when windowed mode is in effect - but also in fullscreen mode, if the drivers let you preserve the aspect ratio. So far (at least on Linux) it seems to me the behavior is determined on a specific set of conditions, as long as "Aspect Ratio" is set to "Auto" in the relevant menu:

* All renderers in a windowed mode, as well as Polymer in a fullscreen - Assume the game's screen resolution should be used for the ratio.
* Polymost in a fullscreen - Assume the game contents fill the whole screen.
(And before you're asking, software renderer in a fullscreen is not currently supported on Linux, at least not natively by EDuke32.)

On a possibly irrelevant note, I've also noticed that Polymer seems to zoom things out a bit, in comparison to the rest. Maybe it was rather Polymost zooming in before, but I'm not sure now.

Anyway, I've thought that maybe we could have two aspect ratio settings that don't depend on the renderer, nor the videomode. One is "Filled" which assumes the contents fill the screen, and the other is... well, "Not Filled"?

I think that's it for now. The zooming thing does hint that things may be more complicated than what could one thing.

Cya later,
NY

[Helixhorned]

NY00123, on 24 August 2012 - 12:50 AM, said:

1. Assuming SDL 1.2.10+ is used, can SDL_GetVideoInfo be used to obtain the physical aspect ratio on platforms other than Windows? At least it seems to do the job here, if called before SDL_SetVideoMode. For reference: http://www.libsdl.or...i/SDL_VideoInfo

I think that could be done, assuming it would give us the dimensions of the physical screen's native resolution.

Quote

2. Now I see that sometimes, the aspect correction is done under the assumption that the game contents fill the whole screen. On other times, the aspect ratio is rather based
on the video mode, which makes sense when windowed mode is in effect - but also in fullscreen mode, if the drivers let you preserve the aspect ratio. So far (at least on Linux) it seems to me the behavior is determined on a specific set of conditions, as long as "Aspect Ratio" is set to "Auto" in the relevant menu:

I hadn't thought about drivers preserving the aspect with resolutions that don't match the native x/y ratio before. Since r2959, when r_screenaspect is 0, square pixel aspect is assumed (and the value 0 is made default, but note that the config may contain a saved value).

Quote

(And before you're asking, software renderer in a fullscreen is not currently supported on Linux, at least not natively by EDuke32.)

Asking the window manager to disable window decorations and setting SDL_VIDEO_WINDOW_POS to "center" has practically the same effect.

Quote

On a possibly irrelevant note, I've also noticed that Polymer seems to zoom things out a bit, in comparison to the rest. Maybe it was rather Polymost zooming in before, but I'm not sure now.

The classic renderer and Polymost share many principles, so they tend to draw things similarly. Polymer on the other hand is designed entirely from scratch, so there are both minor and major disagreements to the old way of drawing things. I agree that the FOV should be the same across all of them, but it's not top priority.

Quote

Anyway, I've thought that maybe we could have two aspect ratio settings that don't depend on the renderer, nor the videomode. One is "Filled" which assumes the contents fill the screen, and the other is... well, "Not Filled"?

If I understood you right, that's not relevant anymore with the change mentioned above?

[NY00123]

Helixhorned, on 27 August 2012 - 12:28 PM, said:

I think that could be done, assuming it would give us the dimensions of the physical screen's native resolution.

I have some feeling that a false positive is possible - when a non-native screen resolution is set as the desktop one, though.

Helixhorned said:

I hadn't thought about drivers preserving the aspect with resolutions that don't match the native x/y ratio before. Since r2959, when r_screenaspect is 0, square pixel aspect is assumed (and the value 0 is made default, but note that the config may contain a saved value).

Now about this, looks like it is a bit of my fault that... I don't often update EDuke32 SVN revisions recently .
So, I have updated it about a hour ago and can see the change. The default value set for r_screenaspect is now 0, so the determined aspect ratio == video mode aspect ratio. At least I *think* the default wasn't 0 before... (using some revision "28xy" beforehand.)

Helixhorned said:

Asking the window manager to disable window decorations and setting SDL_VIDEO_WINDOW_POS to "center" has practically the same effect.

Guess that should be one way that works at the moment, then.

Helixhorned said:

The classic renderer and Polymost share many principles, so they tend to draw things similarly. Polymer on the other hand is designed entirely from scratch, so there are both minor and major disagreements to the old way of drawing things. I agree that the FOV should be the same across all of them, but it's not top priority.

ok, I see.

Helixhorned said:

If I understood you right, that's not relevant anymore with the change mentioned above?

Well, now that the default stretching behavior depends only on the video mode, it seems more appropriate to me. At least, whenever a resolution with the ratio of 4:3 is selected, everything is rendered to 4:3 by default, which is what you'd expect from many other games. Truly, the older behavior of EDuke32 (for Polymost on fullscreen) is useful if the graphics card drivers don't support aspect-preserving of any fullscreen video mode. But, it has its own limitations, like a stretched UI. It is natural to expect that, though, considering that the UI is somewhat "more sensitive" to the screen's shape in terms of pixels.