Jazz Jackrabbit: Incorrect aspect ratio correction since commit 4c5cb55

[carlosefr]

Jazz Jackrabbit uses 320x200 in menus, but during gameplay switches to 320x199. This slight difference in resolution is not accidental and is meant to trigger a change in aspect ratio on real hardware (the game's assets assume square pixels), as can be seen in the CRT in this excerpt from an LGR video: https://www.youtube.com/clip/UgkxIpOb2sanGeuJBP6UNa5CtCt2LbUykJSd

DOSBox Pure (with the "Aspect Ratio Correction" core option set to ON) used to follow this behavior but, starting with commit 4c5cb55, it now forces an incorrect 4:3 aspect ratio.

[schellingb]

Can you write up your findings in #512 instead? There we are trying to figure out how real hardware behaves and how to best replicate it.

[alexb3d]

There is some confusion here.

CGA, EGA, VGA, etc. fill the entire screen, never leaving black bars (letterbox).

What you are seeing in the video is Windows Me, with a restricted MS-Dos, which is not capable of monitor synchronization. What it does is load the content and expand it proportionally to fit.

[schellingb]

This seems another video of Jazz Jack Rabbit on a CRT and there does not seem to be an aspect ratio change between menu and in-game: https://www.youtube.com/watch?v=KtFvkuv4FhE

[alexb3d]

That monitor is connected by composite at 480i. The image is stretched.

This monitor does support VGA 480p, and you can see that the image fills the screen.

I had that game and it didn't have a letter box, but I'm reading a lot of articles that say it did. My monitor had auto pan, maybe I am confused.

Some arguments say that the design is made at 16:10 (320x200), is that, 90% of DOS games have that design. Others say that the game hacks (?) the graphics mode, and switches from 70Hz (640x400) to 60Hz (640x480) and those remaining 80 lines are drawn as black lines. In addition, it appears to have a very thick rim.

In this post by vogon they talk about this and give a lot of technical data.

[carlosefr]

@alexb3d Here's another video showing a DVI capture (no black bars) and a VGA capture (with black bars): https://youtu.be/RsaDONIKBpc?si=BGnvfUPlRiVFcfIw&t=39

The specifics of how Jazz Jackrabbit sets up that video mode can be read here: https://forum.vcfed.org/index.php?threads/vga-320x200-60hz.1241527/#post-1294853 (there's more technical detail on that thread on why this and similar modes end up letterboxed).

The game's assets are designed for that aspect ratio. Now... it's true that many games have assets with wrong aspect ratios, even on systems where there is no aspect ratio change possible (e.g. consoles) but, in this case, it's reasonable to assume that they chose this video mode for some unknown reason, saw how VGA monitors reacted to it, and drew the assets accordingly.

It's also true that users with more "recent" VGA monitors could ajust the dimensions for that mode for the future. So it isn't inherently 16:10. But the developers probably assumed no one would do that just for a mode that no one else used.

@schellingb That video is showing an unknown source connected to a TV over composite video, not VGA.

[carlosefr]

Can you write up your findings in #512 instead? There we are trying to figure out how real hardware behaves and how to best replicate it.

@schellingb I will read that thread and figure out what I can add to it. But, the render.src struct already shows that it's 320x199 at ~59.7Hz. I'm not familiar with the code beyond what I explored to open PR #535, but it seems that with some extra information in there (number of scanlines, perhaps vertical/horizontal front/back porch sizes) it should be possible to calculate the proper aspect ratio for any mode.

But, as I mentioned above as well, if such a strange mode was actually commonly used (unlike this one used by Jazz Jackrabbit), people might end up adjusting their monitors for 4:3, making the concept of "proper aspect ratio" fuzzy.

[alexb3d]

DVI performance is correct, it is SXGA with 640x480x60Hz compatibility mode and will stretch everything to cover the screen. VGA supports dual sync.

This game on a Gateway 486 66Mhz did not produce black stripes, although the monitor was a beast and had auto panning. I'm not going to give too much Faith to my memory, and at this time I can't test on real hardware. So I'm going to stay out of it.

Just as a clarification, there were no defects in the development, 320x200 was the standard because it was what the technical limitations of that time allowed. Just as the Genesis is 3:2 and the Snes is 5:4.

[alexb3d]

One moment please!!!

DOSBox already does the letter box in this game, but RetroArch's interface doesn't seem to understand it.

This can be seen in windowed mode and by activating Aspect Ratio Correction, also if Overscan Border is activated, you can see the blue border it produced in VGA

It does not work in full screen and if, after starting the game, you activate full screen and return to the window, the game is placed in widescreen. The shaders don't work either, it seems that RetroArch only recognizes areas with drawn pixels.

With the border activated (VGA).

Without border (SVGA).

Other games do fill the entire screen.

PS: In this post by vogon they talk about this, but do not mention that it has been corrected.

[carlosefr]

That's interesting. Is that with DOSBox-pure 0.9.9 proper, or the latest code in this repository? Can you try with the #535 patch applied?

I haven't tested with windowed mode (my setup uses X11 with a frameless window manager). I'm testing with windowed fullscreen mode:

• Core Options > Aspect Ratio Correction = ON
• Settings > Video > Scaling > Aspect Ratio = Core provided
• Settings > Video > Fullscreen > Start in Fullscreen Mode = ON
• Settings > Video > Fullscreen > Windowed Fullscreen Mode = ON

That might be intended behavior, depending on how you look at it. Perhaps RetroArch doesn't care about buf.ratio for windowed mode (although I'm using a variation on windowed mode and it does care). If that's the case, I can understand wanting to maintain the windows' dimensions constant.

The overscan border appears to be a different issue. It always has the same size regardless of aspect ratio and, if overscan means "areas of the screen where HBLANK/VBLANK is enabled", it should include any black bars as well. But that option has "Off/Small/Medium/Large" options, which implies it doesn't even try to be accurate. Also, does VGA even have visible overscan?

[alexb3d]

Is that with DOSBox-pure 0.9.9 proper, or the latest code in this repository? Can you try with the #535 patch applied?

The default configuration and core.

I make the comment about the border, so you are aware that it works, but honestly I don't know how. In the DOSBox forums they explain technically why it is that size.

[carlosefr]

So, we agree that DOSBox-pure should not force an aspect ratio of 4:3 and should instead calculate it based on what the emulated graphics card is reporting about the current video mode (as in PR #535)?

[alexb3d]

nope, we disagree. If you had carefully read the post you were reviewed, you would have seen that this was already discussed.

The aspect ratio reported by DOSBox is to convert the image to 4:3. It is just a gimmick to give the user the option.

The aspect ratio is not handled by the graphics adapter, it is a feature of the monitors. Ok, I'll explain it with pictures... An EGA Adapter does not care if it is an IBM 5154 monitor with an 8:5 ratio or a Mitsubishi XC-1410C Monitor with a 4:3 ratio. All the adapter expects is that the monitor supports horizontal and vertical frequency.

[carlosefr]

This is an interesting topic, but is drifting far away from the object of this issue, which is that DOSBox-pure is now universally forcing a 4:3 aspect ratio when the "Aspect Ratio Correction" core option is enabled.

Regardless of everything else in this discussion, @schellingb's assumption that 4:3 was by far the most common aspect ratio during the DOS days is a reasonable assumption to make. But it's the deflection area of the CRT that was almost always 4:3, not the picture within that area (the object of correction for that core option).

The displayed picture's dimensions can and do change within that area depending on the specific configuration of the graphics card's registers (blanking intervals, vsync rate) within the CRT's scanline rate/frequency(*), and that's why DOSBox reports the pixel dimensions in render.src.ratio (it's the result from those parameters).

(*) _This further complicates matters. For example, EGA output on a VGA card used VGA's 32KHz frequency not EGA's, and later even the frequency could be defined from software. But emulation needs some dose of pragmatism, otherwise there is no solution._

[alexb3d]

ot the picture within that area (the object of correction for that core option).

And this is where you are making a mistake, that's why I invite you to read the post, because it was also explained.

Absolutely everyone of all standards fills the entire screen. the only game that has these bars is this game, one of more than 20,000 that has DOS.

[carlosefr]

I've absolutely read the threads you've mentioned, and I've summarized the technical details of how this works. Can you specify which bits I missed from those threads?

Please consider that DOSBox's graphics layer is not emulating the monitor, it's emulating the visible picture output. That's why the aspect ratio correction option refers to the picture's aspect ratio, and not the full-frame (deflection area) ratio. If anything could emulate the monitor, it's the frontend (RetroArch) — which in ways it already does through shaders. It's only missing an option to set the monitor's dimensions separately from "Video > Scaling", which sets the picture's dimensions (it's essentially an override for the core provided aspect ratio, with similar semantics).

It's not only this game that uses a video mode that ends up on screen with a display ratio not 4:3 enclosed within a deflection area expected to be 4:3. Here's a (non-exhaustive) list [source]:

• Earthworm Jim 2: 320 x 224
• Gauntlet: 160 x 200, 256 x 200
• Incredible Machine / Even More Incredible Machine: 640 x 471, 640 x 448
• Jazz Jackrabbit: 320 x 199
• Jurassic Park: 320 x 184
• Lemmings / Oh No! More Lemmings: 640 x 350
• Linewars II: 320 x 480
• Pinball Dreams / Pinball Illusions: 360 x 350, 320 x 400
• Prehistorik 2: 312 x 200
• Quake: 320 x 350, 320 x 400, 320 x 480, 360 x 200, 360 x 240, 360 x 350, 360 x 400, 360 x 480
• Scorched Earth: 320 x 400, 320 x 480, 360 x 480
• System Shock (CD version): 320 x 400

All of these benefit from "Aspect Ratio Correction", and are all being forced into 4:3. It so happens that in many cases the mode's ratio is so close to 4:3 that we hardly notice (e.g. Prehistorik 2 between the menus and the levels, while it's displaying the level overview) or the game's assets don't have obvious geometrical distortions. Jazz Jackrabbit is just (possibly) the most jarring example.

This is why I updated PR #535 to use a generic formula (as suggested by @HitoriSensei in #512) instead of solving for Jazz specifically. It makes all these games more accurate as well. And with a single line of code.

In the end, it's @schellingb call.

[carlosefr]

Just a small clarification, in case it has become blurred by the long thread: I'm just trying to fix an issue that exists in the codebase now, even if just as a temporary solution. PR #535 doesn't prevent anything from being rethought in the future.