I don't have a guaranteed solution for you, but Jazz changes video refresh rate between menu and gameplay (70 Hz --> 60 Hz), which may be why Fraps creates a new file. I made a custom version of Dosbox which lets you force a specific refresh rate (say, 60 Hz all the time). It might help (although probably not if the game really also changes the number of pixels), but you'll have to build the custom Dosbox version yourself from the source code, because the prebuilt binaries I made don't include video recording. It's available in this thread:
DOSBox over S-Video TV-Out stuttering/jerkiness

Unfortunately the game does also change it's resolution when it changes the refresh rate, I know as much because it breaks the aspect ratio correction feature DOSBox has (which *only* corrects 320x200 and 640x400 to 320x240 and 640x480 respectively), because the resolution during the actual gameplay isn't exactly 320x200. It loses one vertical pixel and becomes 320x199, determined by carefully watching the bottom of the DOSBox window frame at 3x scaling and noting how far up it moved when transitioning from the world loading screen to the game proper. This is *much* more dramatic when aspect correction is enabled, due to the aspect correction not being applied to the 320x199 resolution the game switches to.

For what it's worth, I am able to record one contiguous file if I run the game in full-screen mode, however, when playing in full-screen mode, the game (or possibly DOSBox itself) briefly freezes when it has to switch from the 70 Hz @ 320x200 of the menu and world loading screens to the 60 Hz @ 320x199 of the level loading screens and the levels themselves. This is less than ideal for my intentions, as I would prefer to be able to record a smooth gameplay experience such as what running in windowed mode provides me.

This is why I was hoping there might be some way to get DOSBox to pad out the video output to 320x200, to correct for the game's losing a vertical pixel when transitioning from one mode to the other, so things like aspect correction would still be usable and so the output would remain at a consistent resolution so Fraps wouldn't be forced to restart recording all the time.

I do appreciate your attempt to help, though, however, it appears the refresh rate isn't actually important to Fraps (though it is recommended to record at 70 FPS to prevent Fraps recording from possibly slowing down some games). (I am curious, though, if the game's refresh rate *does* matter to DOSBox's internal recorder, 'cause that would mean Jazz Jackrabbit would cause recording of multiple files with the internal recorder regardless of whether or not the output resolution could be padded to maintain a consistent 320x200.)

Resolution padding won't fix it alone. The AVI gets captured at a different rate too and you just can't cross the streams

What about running DOSBOX in Windowed mode and use FRAPS (or VLC) to capture the whole desktop? Then you just crop away the un-necessary parts of the footage.

Does the built-in capture not work with this game?

Unless you want to capture MIDI music, the built-in capture is rock solid.

@leileilol - I'm fairly certain if the output resolution could be padded, Fraps would be able to record a single contiguous file, as it does not seem to care what the refresh rate of the game is and whether or not it switches from one refresh rate to another, this proven by the fact I can record a single contiguous file if I run DOSBox in full-screen mode. The built-in recorder might care, if it's capture frame rate is determined by the game's refresh rate, but Fraps' capture frame rate isn't dependent on the game's frame rate, and as long as it's set to capture at 70 FPS, it records DOSBox smoothly without slowing down the games.

@vetz - I suppose I could do that, but then I'm not really getting any benefit from using Fraps over any other screen capturing software. I ultimately chose to use Fraps because I *don't* have to crop anything, it only records the video output from the game itself (along with the system audio and microphone).

@Mau1wurf1977 - The built-in recording works, but it also gets cut each time the game switches resolutions (and, apparently, could possibly end up being cut each time the game's refresh rate is changed, which happens along with the resolution change), so it's no better than Fraps is as far as that's concerned. It would also require recording any audio commentary I might wish to include in a separate application, which would then require extra editing, and could potentially de-sync from the video if DOSBox ended up slowing down any time during the recording (since DOSBox slowdowns don't affect the final video recording).

At any rate, I appreciate the advice, even if it may not actually be that helpful to the situation I find myself in.

If there's a feature request section to these forums, perhaps I should request a way to pad the video output to maintain a consistent 320x200 resolution (before scaling and aspect correction, of course), just in case there are other games along with Jazz Jackrabbit that end up with resolutions slightly less than the usual 320x200 most DOS games run at.

Along these lines, if Jazz is truly using a 320x199 resolution, and this is not some emulation quirk, I wonder if it is also changing the monitor refresh rate on real hardware from 70Hz to 60Hz.

I'm beginning to wonder if I should do a quick capture of the game using DOSBox's internal capture tool and check the dimensions (and frame rates) of the resulting videos... That could settle once and for all whether the game is actually losing a pixel vertically when switching from menu to in-level game play... Of course, that depends on DOSBox being able to capture video at any arbitrary resolution rather than being forced to a multiple of 4 like most codecs are...

I have no idea whether the game on actual hardware changes the monitor's refresh rate when switching from menu to in-level game play. I do recall that Windows briefly blanks the monitor when switching modes, so I can't imagine a DOS game being able to switch the monitor's refresh rate on-the-fly without any blanking being necessary.. (Then again, it could be that Windows does it only as a precaution, so I really can't say...)

EDIT: I went ahead and did a quick capture with DOSBox's internal capture tool just because I wanted to make absolutely sure I was right, and thankfully the ZMBV codec can capture video at any arbitrary resolution (rather than being forced to a multiple of 4 like so many other codecs). The game is indeed switching to a 320x199 resolution @ ~60Hz during the actual game play, while the menus and a few other screens run at the proper 320x200 resolution @ ~70Hz. (This also confirms that DOSBox internal capture tool would still be forced to record multiple files due to the frame rate change even if the video output could be padded to maintain 320x200 resolution.)

So, yeah, we can definitively say that's the issue here.

karashata wrote:

@Mau1wurf1977 - The built-in recording works, but it also gets cut each time the game switches resolutions (and, apparently, could possibly end up being cut each time the game's refresh rate is changed, which happens along with the resolution change), so it's no better than Fraps is as far as that's concerned. It would also require recording any audio commentary I might wish to include in a separate application, which would then require extra editing, and could potentially de-sync from the video if DOSBox ended up slowing down any time during the recording (since DOSBox slowdowns don't affect the final video recording)

Yea the syncing issue is a problem and one of the reasons I started doing videos on real computers.

The split up videos however is no big deal as you just drop them into your timeline in your video editing software.

But this might not suit your situation.

The issue I have with the recording being split into multiple files is that each time recording has to be restarted to a new file, a brief moment of the game footage gets missed while the old file is being closed and the new file started. This wouldn't be so bad if the transitions where this resolution change happens were blank video and silent audio (for just long enough for the new video to be started), however for this game this is not the case. In particular, the transition from the world opening screen to that world's first level is accompanied by an audio and visual effect (unless hitting Esc, which skips it) that ends up partially cropped due to recording being restarted. This would probably go unnoticed by most of the people watching the video, but I would know that small segments of the video and audio are missing. (It would also mean I would have to consciously *not* make any commentary during those moments, to avoid having any of my speech be cut out. These moments may be fairly brief but they are quite noticeable with commentary over them.)

I suppose I might be making a bigger deal of this than it really warrants, but I do think it's an issue that can be corrected for. Beyond just making capturing this game easier (not having to deal with multiple files), it would also allow aspect correction to work on the whole game (not just the main menu and other screens that correctly use 320x200 output), and it would also allow full-screen play without the application briefly freezing when having to re-scale the output every time the resolution changes.

I've added a request to the feature request thread detailing this issue and asking if they could possibly implement some way to pad the video output to maintain a consistent resolution in cases like this, hopefully they think it's something that is beneficial to the program and look into it.

You can force Dosbox to round up Jazz's weird video mode by adding this line to vga_draw.cpp in function VGA_SetupDrawing:

1vdend += 1; // existing code
2vdend = (vdend + 3) - ((vdend + 3) % 4); // new line to round up to multiple of 4

Along these lines, if Jazz is truly using a 320x199 resolution, and this is not some emulation quirk, I wonder if it is also changing the monitor refresh rate on real hardware from 70Hz to 60Hz.

Yes it is. I tested it in real MS-DOS using a CRT monitor. The monitor reported 70 Hz / 31.5 kHz in the menu, and 60 Hz / 31.4 kHz ingame. When the game switches video modes, the monitor goes blank or flashes briefly.

The fun part is that my Avermedia VGA HD capture card had no issues with sync'ing with this special resolution on a real DOS computer... 🤣
If I had to take a guess, I would've thought this game would fail.

With VLC I got the transition with a continuous clipfile as well.

I know this doesnt help the OP though, but incase anyone was wondering 😉

Hehe I'm sure S-Video captures it fine. But some games trigger that "rainbow" test image of the VGA converter 😀

ripa wrote:

You can force Dosbox to round up Jazz's weird video mode by adding this line to vga_draw.cpp in function VGA_SetupDrawing: […]
Show full quote

You can force Dosbox to round up Jazz's weird video mode by adding this line to vga_draw.cpp in function VGA_SetupDrawing:

Copy code to clipboard

1vdend += 1; // existing code
2vdend = (vdend + 3) - ((vdend + 3) % 4); // new line to round up to multiple of 4

I'll have to look into setting up a build environment to compile DOSBox in, but I can definitely give that a try if I can get one set up without much trouble,

Thanks for the suggestion.

(Just curious, the fact you've come up with this as a work-around/fix for this particular issue, does this mean you tested this already, and if so, does it cause any problems for games that don't need to be fixed..?)

I was able to get Jazz running in 200 (double-height) lines and 4:3 aspect ratio at all times, but the frame rate still switches between 70 Hz and 60 Hz due to the change in total vertical lines. Dunno why Epic wanted 60 Hz in-game... maybe they had cross-platform plans that never materialized.

First, I modifed JAZZ.EXE to use the more common value for the display end register in mode 0x13, changing instances of B8 12 8D to B8 12 8F. This leaves an extra line at the bottom of the display that appears to remain black, but there's no guarantee it won't start displaying junk at some point.

Then I used Hal's MB6 (or ykhwong's build which uses MB6's aspect correction) to run the game. These unofficial builds also apply aspect correction to text modes, which may prove useful for the purpose here.

Having text mode's aspect corrected wouldn't be as important for this game, since it never switches to text mode during gameplay. However, it would be useful for recording a game like X-Com 2 (which briefly switches to text mode between its Geoscape and Tactical gameplay modes), since it would allow for one contiguous file. (That said, with X-Com 2, that brief mode switch isn't actually a problem, since it's a very clear transition point, and it would be easy enough to avoid making any commentary during the switch from Geoscape mode to Tactical mode and back.)

I'm going to try out ripa's code fix and see if that provides a workable solution, though modifying the EXE could also be a solution I could look into (and, if the blank line at the bottom were to remain blank, that would actually be ideal, as ripa's solution sounds like it will stretch the video output to keep it at 320x200, whereas I want it padded so the game graphics aren't warped in any way, even if quite mildly since it's only 1 pixel difference...).

Well, "fixing" the display end in DOSBox source or in the game executable will probably have the same result. However, with the DOSBox source approach, you'll need a bit more code than ripa's suggestion in order to override the (mis)calculated aspect ratio. Alternatively, you could fix up the display end in MB6 or ykhwong's build source, but they are more challenging to self-compile than official DOSBox source.

Edit: I guess you could also disable aspect correction for recording and then apply the correction in post-processing.

Hm, so apparently DOSBox's aspect correction isn't *only* linked to the game's output resolution, as editing the game executable to force 320x200 output at all times does not allow DOSBox to aspect correct the whole game. (However, it would allow me to record it as one contiguous file without aspect correction enabled, and honestly the game doesn't look terrible without the aspect correction... It also means playing in full-screen wouldn't briefly freeze the program as it re-scales for the resolution change, since the resolution remains constant, also without aspect correction enabled.)

This probably means I was mistaken in believing that padding the video output to maintain a consistent resolution would allow for aspect correction to be used at all times either, since it doesn't appear to be linked only to the output resolution... Now I understand why you suggested using a build that also applies aspect correction to text mode.

At any rate, this is turning out to be somewhat more interesting than frustrating at this point...

(Just curious, the fact you've come up with this as a work-around/fix for this particular issue, does this mean you tested this already, and if so, does it cause any problems for games that don't need to be fixed..?)

I only tested it in Jazz. Like ripsaw suggested, my solution also pads the video output with extra lines at the bottom. If you want to fix the aspect ratio for Jazz, you can again hack VGA_SetupDrawing:

1//if ( width >= 640 && height >= 480 ) { // existing code commented out
2    aspect_ratio = ((float)width / (float)height) * ( 3.0 / 4.0); // existing code
3    if (doublewidth) aspect_ratio *= 2; // new code
4    if (doubleheight) aspect_ratio /= 2; // new code
5//} // existing code commented out

I'm not convinced the current aspect ratio calculation is wrong, however. Notice the much larger black bars around the picture in Jazz compared to Keen. The overscan area, which is not emulated in vanilla Dosbox, is the turquoise border around the picture in Keen and the slightly brighter border around the picture in Jazz. The slightly darker area around both is the blanking area. I deliberately set the brightness to maximum and set the width and height of the picture to minimum so that you can see those areas around the active picture. Of course it's possible my old laptop is not 100% VGA compatible.