Ant_222 wrote:

Hello, all

What are the double-height and double-width modes? Are they part of the emulation of the video system or a mechanism implemented in DOSBox more effectively to use the available display area in case of non-scaling output surfaces? For example, when running Lure of the Temptress with svga_s3 RENDER_Reset() "sees" an array of 320x200 pixels, which is the true resolution of the game, but when I run it with vgaonly, the incoming array is 320x400 (double-height).

I am asking this with regard to my pixel-perfect patch, which this preliminary upscaling thwarts, taking away the necessary headroom for pixel-perfect manipulations. For example, with svga_s3 on my 1680x1050 display it upscales 320x200 to 1280x1000, while with vgaonly it can only upscale 320x400 to 960x800 (edit: and even this after I added a hack into RENDER_Reset(), which is not yet in the patch). Is there a reliable way always to get the original unscaled pixel array?

As far as I know it has consequences for capturing (see CAPTURE_AddImage), as when you capture 160x200 video it's captured at 320x200.

Go into int10_modes.cpp. You'll see _EGA_LINE_DOUBLE for 320x200 and _VGA_PIXEL_DOUBLE for 320x200 and 320x240.

Also look at vga_draw.cpp for vga.draw.double_scan.

The vgaonly machine type emulates certain details of real VGA cards that other VGA machine types do not. VGA has two basic scan types: 400 lines at ~70 Hz, and 480 lines at ~60 Hz; with most standard video modes based around these. In the case of 320x200, it is double-scanned to 400 lines, and the vgaonly machine type emulates this more faithfully so that line-wise effects (more often used in demoscene productions than games) are displayed as intended.

ripsaw8080 wrote:

The vgaonly machine type emulates certain details of real VGA cards that other VGA machine types do not. VGA has two basic scan types: 400 lines at ~70 Hz, and 480 lines at ~60 Hz; with most standard video modes based around these. In the case of 320x200, it is double-scanned to 400 lines, and the vgaonly machine type emulates this more faithfully so that line-wise effects (more often used in demoscene productions than games) are displayed as intended.

Thanks for the explanation. It poses a dilemma for me: whether to treat the image as a sparse 320x200 matrix or a normal 320x400 one. Whereas DOSBox is primarily intended for gaming, I incline toward the former choice, but of course I can make this optional via another parameter in the config file. What should you suggest?

Edit: In case vgaonly is only needed for non-gaming stuff, might I just leave the patch as it, for it already does the job for svga_s3?

There are features of the vgaonly machine type other than double-scanning that are useful for some games, such as video blanking. Don't take my point about demoscene productions too far; after all, the scene had a very definite crossover into games.

If adoption into official source is a goal then it is advisable to avoid, or at least be very frugal with, config file options. It is not mere happenstance that very few new options have been added in SVN since 0.74 was released.

ripsaw8080 wrote:

There are features of the vgaonly machine type other than double-scanning that are useful for some games, such as video blanking. Don't take my point about demoscene productions too far; after all, the scene had a very definite crossover into games.

Thanks. I should like to keep my scaler as hardware-independent as possible. In this case it must generally keep the full (400 or 480) resolution for vga_only, but optionally prefer the 200- or 240-line resolution for games that do not rely on the double-scan feature.

If adoption into official source is a goal then it is advisable to avoid, or at least be very frugal with, config file options. It is not mere happenstance that very few new options have been added in SVN since 0.74 was released.

It most certainly is, for the maintenance of the patch in parallel with the trunk is akin to Sisyphus's labour.

One way to decrease the number of options in my patch would be:

1output=surface
2suface_scaler=(none|pixel_perfect|nearest_neighbour|near_perfect)

I can make these scalers orthogonal to the output type, but that will require more work and (even more) serious rewrite of sdlmain.cpp.

I am all ready to discuss my patch with the authors and make changes that are necessary to include in into official source, but I fear I might need not only advice but help also...

ripsaw8080 wrote:

The vgaonly machine type emulates certain details of real VGA cards that other VGA machine types do not. VGA has two basic scan types: 400 lines at ~70 Hz, and 480 lines at ~60 Hz; with most standard video modes based around these. In the case of 320x200, it is double-scanned to 400 lines, and the vgaonly machine type emulates this more faithfully so that line-wise effects (more often used in demoscene productions than games) are displayed as intended.

Am I right that double-scan is reported to render.cpp as

1render.src.dblh == 1,
2render.src.dblw == 0

Is it ever possible that dblh should be false and dblw true? When?

Ant_222 wrote:

Is it ever possible that dblh should be false and dblw true? When?

Absolutely. I wouldn't say it's super common, but some games use mode 13h tweaked to 320x400. Blood & Magic, Threat, and DreamForge/Event Horizon games (Ravenloft series, Veil of Darkness, The Summoning, et al.) are examples that come to mind.

ripsaw8080 wrote:

Absolutely. I wouldn't say it's super common, but some games use mode 13h tweaked to 320x400. Blood & Magic, Threat, and DreamForge/Event Horizon games (Ravenloft series, Veil of Darkness, The Summoning, et al.) are examples that come to mind.

Thank you. I noticed strange behavior with Veil of Darkness. The game's "actual" resolution is 320x200, but with vgaonly it runs at 320x400, and even then some update rectangles (sdl.updateRects) have an odd height. How is it possible? A double height should have caused all update rectangles to have an even height, should not it have?

Veil of Darkness, like other Event Horizon games, uses 320x400 for the intro and cut-scenes, but "normal" 320x200 for gameplay. Not entirely normal because a VGA hardware split-line is used so the lower window of the UI can be dragged up and down with the mouse, but dunno if that's responsible for anything you're seeing as odd.

ripsaw8080 wrote:

Veil of Darkness, like other Event Horizon games, uses 320x400 for the intro and cut-scenes, but "normal" 320x200 for gameplay.

Yes. I meant the gameplay (not the intro) resolution that is reported in

1render.src.width
2render.src.height

With the machine type vgaonly it is 320x400, whereas with svga_s3 it is 320x200.

Not entirely normal because a VGA hardware split-line is used so the lower window of the UI can be dragged up and down with the mouse, but dunno if that's responsible for anything you're seeing as odd.

I meant odd as not divisible by two (not even). Since vgaonly sees 320x200 as 320x400 one should expect that all update rectangles (sdl.updateRects) will have an even height (divisible by two), which is not the case for some reason:

1if( rect->h % 2 != 0 )
2{  LOG_MSG( "Odd height: %i ", rect->h );  }

Ant_222 wrote:

With the machine type vgaonly it is 320x400, whereas with svga_s3 it is 320x200.

Yes, vgaonly double-scans 200 lines to 400 lines, as I earlier explained.

Ant_222 wrote:

Since vgaonly sees 320x200 as 320x400 one should expect that all update rectangles (sdl.updateRects) will have an even height (divisible by two)

It's rather the point that it's rendered as 400 individual lines, otherwise the desired line-wise behavior wouldn't work.

ripsaw8080 wrote:

Veil of Darkness, like other Event Horizon games, uses 320x400 for the intro and cut-scenes, but "normal" 320x200 for gameplay.

With the machine type vgaonly these modes seem indistinguishable, because DOSBox does not even call RENDER_Reset() at the transition from intro to gameplay. Is that correct behavior? In these conditions my scaler routine cannot adjust its parameters.

Ant_222 wrote:

With the machine type vgaonly these modes seem indistinguishable

Probably because there wasn't a need to distinguish at the render level, and I wonder if that isn't just as true for your purpose. In any case, it should be distinguishable at the draw level, and perhaps you can pass an indication from draw to render; just be careful to keep them separate (e.g. don't use vga. struct in render.)

ripsaw8080 wrote:

Ant_222 wrote:

With the machine type vgaonly these modes seem indistinguishable

Probably because there wasn't a need to distinguish at the render level, and I wonder if that isn't just as true for your purpose.

I think not, because the 320x400 intro and the 320x200 gameplay allow different pixel-perfect scaling factors, e.g. for my 1680x1050 display:

1   Intro: 320 x 400 --[4.0 x 2.0]--> 1280 x 800  PAR: 0.50 (actual: 0.60)
2Gameplay: 320 x 400 --[4.0 x 2.5]--> 1280 x 1000 PAR: 1.25 (actual: 1.20)

because the we cannot collapse adjacent pixel rows in the intro, which has an actual vertical resolution of 400 pixels, but can in the gameplay and thus have a better PAR approximation.

ripsaw8080 wrote:

In any case, it should be distinguishable at the draw level, and perhaps you can pass an indication from draw to render; just be careful to keep them separate (e.g. don't use vga. struct in render.)

The initialization of my scaler is currently tied to RENDER_Reset(), so passing the information about double-scan via another route will require a serious rewrite which I would rather postpone till after the patch has been accepted into the official source. I will soon upload the latest version of the patch and ask you to review my changes and tell me what I should fix and change to make it acceptable. Shall I also upload the patch to the "Patches" section at SourceForge?

ripsaw8080 wrote:

Yes, vgaonly double-scans 200 lines to 400 lines, as I earlier explained.

Understood.

ripsaw8080 wrote:

Ant_222 wrote:

Since vgaonly sees 320x200 as 320x400 one should expect that all update rectangles (sdl.updateRects) will have an even height (divisible by two)

It's rather the point that it's rendered as 400 individual lines, otherwise the desired line-wise behavior wouldn't work.

YesЧI understand it as well, but whereas Veil of Darkness doesn't seem to rely on double-scan—for it works correctly at 320x200 with svga_s3—the rows in the source pixel array should come in pairs, i.e.:

1row[    0] == row[  1]
2row[    2] == row[  3]
3...
4row[2*h-1] == row[2*h]

where h is the source heght (200). That said, I do not understand why the update rectangles in Veil of Darkness gameplay with vgaonly sometimes have an odd height or an odd ordinate, e.g.:

1x: 0, y: 0,   w: 320, h: 1
2x: 0, y: 107, w: 320, h: 47

—How can a single-pixel horizontal line be updated in double-scan mode? Should it not be at least two pixels thick? Likewise, how can a horizontal band 47 pixels high be updated? Should it not be 48 pixels high, so as to correspond to a 24-pixel-high band in the original 320x200 resolution?

I don't think the rendering cares if the 400 lines come from a 400 line source or a doubled 200 line source, so odd-line update regions can occur for either source. I suppose it's not convenient for your purpose, so the usual choices apply: work with it, work around it, or change it.

My advice to you is to just work on perfecting your patch, and don't bother with "campaigning" to get it accepted into official source because it's not productive. As with all patches, if yours is sufficiently in line with project goals then it may be incorporated into official source, but if not then it will be relegated to the sphere of unofficial builds.

ripsaw8080 wrote:

I don't think the rendering cares if the 400 lines come from a 400 line source or a doubled 200 line source, so odd-line update regions can occur for either source.

Even though it doesn't care about it, I don't see how odd-sized update regions can arise.

ripsaw8080 wrote:

I suppose it's not convenient for your purpose, so the usual choices apply: work with it, work around it, or change it.

Yes—I have already written a workaround. Inconvenience is all right, but I should like to understand why it is there. If each source line is doubled then I fail to understand why the height and vertical offset of the update rectangles must not be even.

ripsaw8080 wrote:

My advice to you is to just work on perfecting your patch, and don't bother with "campaigning" to get it accepted into official source because it's not productive. As with all patches, if yours is sufficiently in line with project goals then it may be incorporated into official source, but if not then it will be relegated to the sphere of unofficial builds.

This makes me afraid of introducing any serious changes because they will be increasingly difficult to merge with new official revisions. I constantly fear that my work will be lost. But I will try to do as you say.

Ant_222 wrote:

This makes me afraid of introducing any serious changes because they will be increasingly difficult to merge with new official revisions.

It's a good idea to consider the maintenance aspect in the approach to any patch. Refactoring/rewriting large sections of existing code tends to make maintenance a headache; some inserted/deleted lines in existing code, with sections of additional code elsewhere, is relatively painless.