It occurs to me as I look at the game some more that the image doesn't at all appear to be distorted due to an incorrect display ratio during the levels, objects that are supposed to be circular appear to be circular, rather than oblong, however, the planets on the world opening screens are oblong when aspect correction is not applied (but are properly circular when it is applied).

Also, looking at the in-level photo you have of Jazz Jackrabbit, it appears the game is leaving large blank bars above and below the game's output, in addition to having the monitor's resolution set to 640x480, rather than the 640x400 Keen has it set it to.

Considering many games in DOSBox typically run at 320x200 output, the output resolution must be being doubled before sent to the display, which means Jazz Jackrabbit might actually setting the display mode to 320x240 @ 60Hz during its levels and level loading screens, then centering its output vertically within that display area, something that DOSBox, unfortunately, does not emulate.

Now I'm curious, would it at all be possible to make DOSBox emulate this?

EDIT: Hey, since you've got a screenshot of the game during one of the levels, can you also get one of the game in the menu or on one of the world opening screens? I wanna see for sure whether or not I might have gotten this figured out now...

karashata wrote:

Also, looking at the in-level photo you have of Jazz Jackrabbit, it appears the game is leaving large blank bars above and below the game's output, in addition to having the monitor's resolution set to 640x480, rather than the 640x400 Keen has it set it to.

Considering many games in DOSBox typically run at 320x200 output, the output resolution must be being doubled before sent to the display, which means Jazz Jackrabbit might actually setting the display mode to 320x240 @ 60Hz, then centering its output vertically within that display area, something that DOSBox, unfortunately, does not emulate.

I noticed the same when capturing from the VGA card. It was recognized as 320x240 and had the black bars as mentioned. I can post the footage to Youtube in a bit with some of the menu included.

This really is getting interesting, and I would like to see that video once it's up.

I've altered my request on the request thread with the new explanation of what's actually occurring with this game and whether it would be possible to have DOSBox emulate this.

(I'm disappointed there doesn't seem to be strikethrough on this forum, I would have preferred to stroke out the old request blurb rather than just erasing it completely and replacing it with the new request...)

karashata wrote:

It occurs to me as I look at the game some more that the image doesn't at all appear to be distorted due to an incorrect display […]
Show full quote

It occurs to me as I look at the game some more that the image doesn't at all appear to be distorted due to an incorrect display ratio during the levels, objects that are supposed to be circular appear to be circular, rather than oblong, however, the planets on the world opening screens are oblong when aspect correction is not applied (but are properly circular when it is applied).

Also, looking at the in-level photo you have of Jazz Jackrabbit, it appears the game is leaving large blank bars above and below the game's output, in addition to having the monitor's resolution set to 640x480, rather than the 640x400 Keen has it set it to.

Considering many games in DOSBox typically run at 320x200 output, the output resolution must be being doubled before sent to the display, which means Jazz Jackrabbit might actually setting the display mode to 320x240 @ 60Hz during its levels and level loading screens, then centering its output vertically within that display area, something that DOSBox, unfortunately, does not emulate.

Now I'm curious, would it at all be possible to make DOSBox emulate this?

EDIT: Hey, since you've got a screenshot of the game during one of the levels, can you also get one of the game in the menu or on one of the world opening screens? I wanna see for sure whether or not I might have gotten this figured out now...

Here's the menu. If you're interested in what video modes games use, try the debugger-enabled Dosbox. It prints the video mode parameters (horizontal and vertical total, overscan, and blanked lines and derived height, width, and aspect ratio) into the Dosbox console.

I could try some other 480-line, 60 Hz game in real DOS using the CRT monitor, calibrate the picture width and height based on that, and then try Jazz to see if the picture is centered vertically or not. I think it's going to have a large black bar on the bottom, because that's how both the CRT after using size auto-adjust and the built-in LCD display Jazz.

Your monitor is wrong. That's 320x200 instead of 640x400, and the black borders on the sides shouldn't be there.

edit: most SVGA graphics cards doublescan 320x200, turning the effective resolution into 320x400. Your monitor probably just counts the 400 lines and assumes the horizontal resolution to be 640.

jwt27 wrote:

Your monitor is wrong. That's 320x200 instead of 640x400, and the black borders on the sides shouldn't be there.

edit: most SVGA graphics cards doublescan 320x200, turning the effective resolution into 320x400. Your monitor probably just counts the 400 lines and assumes the horizontal resolution to be 640.

The black bars are there because I deliberately shrunk the picture so that the overscan areas are clearly visible. Horizontal pixel count is obviously not meaningful for analog monitors, so they probably pull the numbers out of some internal video mode database based on the frequencies and scanline count. Vanilla VGA uses scan doubling too.

The point is that Jazz's custom video mode looks the same to the monitor as 640x480 @ 60 Hz, resulting in letterboxing unless you manually adjust the height controls.

karashata wrote:

This really is getting interesting, and I would like to see that video once it's up.

Here you go:
http://youtu.be/RsaDONIKBpc

Please pause if needed to read the text I added. If you look closely on the diamonds in the DVI footage you'll see the stretching done by the graphics card is not correct compared to the VGA footage.

Actually, I found it easier to tell how badly stretched the DVI output was based on the oblong shape of the orbs and orblets in the game, since they're supposed to be circular in shape and not tallish ovals...

At any rate, that video helps confirm what's happening.

I did some thinking about it last night when I went to bed, before I actually went to sleep, and I realized what DOSBox is doing currently is only rendering the game's actual video output. It might be more desirable to render the output at the resolution determined by the display mode set by the game (and with aspect correction if enabled if the set mode requires it), then display the game's video output at the appropriate position within that rendered output.

If necessary, they could make such a thing a configurable option that's disabled by default (DOSBox would continue to act as it currently does in its default state), but can be enabled if the user so chooses, whether for a somewhat more accurate depiction of how the game performs on actual hardware (visually, at least), and possibly also in cases like mine where they just *really* want the program's output to remain at a consistent resolution for recording purposes (with the added benefit of providing a more accurate viewing experience as if watching it being played on real hardware).

ripa wrote:

If you're interested in what video modes games use, try the debugger-enabled Dosbox. It prints the video mode parameters (horizontal and vertical total, overscan, and blanked lines and derived height, width, and aspect ratio) into the Dosbox console.

karashata wrote:

...I realized what DOSBox is doing currently is only rendering the game's actual video output. It might be more desirable to render the output at the resolution determined by the display mode set by the game (and with aspect correction if enabled if the set mode requires it), then display the game's video output at the appropriate position within that rendered output.

Did you confirm your theory with actual results from the dosbox debugger?

I managed to figure the debugger out, at least as much as is relevant to this matter.

Here's the relevant output from the debugger when the game switches to gameplay mode:

1  65751987: VGA:h total 100 end 80 blank (80/98) retrace (84/96)
2  65751987: VGA:v total 527 end 398 blank (456/519) retrace (458/460)
3  65751987: VGA:h total 0.03178 (31.47kHz) blank(0.02542/0.03114) retrace(0.02669/0.03051)
4  65751987: VGA:v total 16.74677 (59.71Hz) blank(14.49057/16.49255) retrace(14.55412/14.61768)
5  65751987: VGA:Width 320, Height 199, fps 59.712998
6  65751987: VGA:double width, double height aspect 1.022391

For comparison, here's the output from the debugger for the world opening screen:

1  65736530: INT10:Set Video Mode 13
2(skipped a few non-video related lines)
3  65743802: VGA:h total 100 end 80 blank (80/98) retrace (84/96)
4  65743802: VGA:v total 449 end 400 blank (407/442) retrace (412/414)
5  65743802: VGA:h total 0.03178 (31.47kHz) blank(0.02542/0.03114) retrace(0.02669/0.03051)
6  65743802: VGA:v total 14.26812 (70.09hz) blank(12.93347/14.0456810 retrace(13.09235/13.15591)
7  65743802: VGA:Width 320, Height 200, fps 70.086303
8  65743802: VGA:double width, double height aspect 1.200000

So, basically, it seems that the VGA resolution set by Jazz Jackrabbit during gameplay and level loading screens is only 320x199, which is the resolution that DOSBox displays it at. The rest must be related to overscan and padding, or some such, which apparently DOSBox isn't concerned with.

At any rate, this was quite an interesting exercise, and it seems unlikely I'll be able to get as ideal circumstances for recording the game as I'd like (though modifying the game's executable to set a 320x200 resolution instead of the 320x199 resolution it normally sets is a possibility, and would at least provide a consistent resolution when playing the game without aspect correction enabled).

Quick intro to the debugger:
- alt-pause to break into the debugger (pauses emulation)
- home/end in the debug console to scroll the debug prints
- F5 in the debug console to resume emulation

There's a pretty good article about VGA video signal here: http://wiki.osdev.org/Video_Signals_And_Timing

Here's the relevant prints in the debugger console (Jazz gameplay, Dosbox .conf machine=vgaonly):

1VGA:h total 100 end 80 blank (80/98) retrace (84/96)
2VGA:v total 527 end 398 blank (456/519) retrace (458/460)
3VGA:h total 0.03178 (31.47kHz) blank(0.02542/0.03114) retrace(0.02669/0.03051)
4VGA:v total 16.74677 (59.71Hz) blank(14.49057/16.49255) retrace(14.55412/14.61768)
5VGA:Width 320, Height 398, fps 59.712998
6VGA:double width, normal height aspect 1.022391

H refers to horizontal and V to vertical. First and second lines:
- "h total" is the total number of horizontal pixels divided by some integer (depends on VGA details, 4 in this case)
- "v total" is the total number of scanlines (vertical pixels)
- "end" is the number of active pixels/scanlines. 80x4 = 320 horizontally, 398 vertically.
- "blank" are the first and last blanked pixels/scanlines. In the previous photos, they are visible as the dark gray border around the picture. They're dark grey instead of black because I adjusted the brightness to maximum and the CRT hadn't warmed up yet.
- "retrace" are first and last invisible retrace lines during which the CRT beam is returned from right to left and/or bottom to top. They should be within the blank pixels/lines.
- Overscan pixels/lines can be calculated like: total - end - (blank end - blank start). In this case 2 pixels of horizontal overscan and 66 lines of vertical overscan, most of which is below the active picture instead of above.

Third and fourth lines:
- Horizontal and vertical duration in milliseconds and frequency in (kilo-)Herz. Both of these are displayed by the CRT monitor in the photos. By the way, number of scanlines ("v total") is horizontal frequency / vertical frequency.
- The vertical frequency is the refresh rate i.e., the FPS.

Fifth and sixth lines:
- Width, height, fps, aspect ratio of Dosbox video output based on the above.

Wouldn't it be 8 pixels of horizontal overscan, due to the division by 4 in this case..?

At any rate... that's quite a lot of information to process.

EDIT: So based on the debugger output, can anyone explain how the final output resolution during gameplay ends up being 640x480, or is the monitor just switching to a standard mode that best fits the game's output?

EDIT #2: Of course, I'm referring to the game running on actual hardware, in this case...

karashata wrote:

Wouldn't it be 8 pixels of horizontal overscan, due to the division by 4 in this case..?

Yes, I forgot to multiply. In fact, the multiplier is 8 instead of 4 (so the total H pixels is 800, of which 640 are active). The "doublewidth" print means that two adjacent pixels are the same, so the effective horizontal resolution of half of that.

karashata wrote:

EDIT: So based on the debugger output, can anyone explain how the final output resolution during gameplay ends up being 640x480, or is the monitor just switching to a standard mode that best fits the game's output?

EDIT #2: Of course, I'm referring to the game running on actual hardware, in this case...

The CRT monitor probably makes a guess based on the H and V frequencies and scanline count. Based on those, Jazz's gameplay video mode looks the same as 640x480 @ 60 Hz.

Ah, I guess that makes sense.

It is somewhat unfortunate that emulating something like this probably isn't something the DOSBox developers would be too interested in doing, especially since the game already works quite well, even if it's not presented quite the same as it would on real hardware. Plus, I would have to guess that emulating something like this might be somewhat difficult anyway, and their time and resources are probably better spent trying to make sure other games work and implementing other features that actually improve the performance of the program or improve the gaming experience.

I did learn a lot from this, though, it really is quite interesting.