VIDEO - Overscan border (SDL1)

[DosFreak]

Why does it have to be a internal border? Mabye change the window border if possible? or throw up a box with the color. heh.

[h-a-l-9000]

Change the icon color

[HunterZ]

For fullscreen it has to be an internal border or else people will complain that they can't run a game fullscreen in its native resolution and still see the border (since on real hardware it would appear only in the CRT overscan area).

For windowed mode you could simply increase the size of the window enough to draw actual borders around all 4 sides of the emulated screen, which would more accurately emulate the behavior of the real hardware. For example, a 320x200 game scaled up to a 1280x800 window could instead be presented at, say, 1296x816, leaving enough space around the edges for an 8-pixel-thick border to be shown all the way around.

[robertmo]

It doesn't have to be internal.

1. It is only for a few games.
2. Black boarder should be ignored - so it is only for moments when a boarder different from black is being used.
3. Window mode can accept any resolution.
4. Fullscreen mode with overlay/ddraw/opengl/openglnb can accept any resolution if it is set to something else than original, actually original is accepted too - it will be just displayed in a bit smaller "window" surrounded by black area.
5. Fullscreen mode with surface will be just displayed in a bit smaller "window" surrounded by black are.
6. If someone for some reason cannot use overlay/ddraw/opengl with other than original resolution or cannot use overlay/ddraw/opengl at all and doesn't want to have a game in a bit smaler window may have an option in dosbox.conf for turning off boarder (the way it is right now in dosbox). And maybe an additional option for very simple internal (without transparency and only one/two (maybe adjustable) pixel thick)
7. Maybe an option in dosbox.confl: boarder=3/2/1/0/-1/-2/-3 with 3 (external) as default, 0 for none, "-#" for internal. Or boarder=external3/external2/.../none/internal1/.../internal3.

[robertmo]

(since on real hardware it would appear only in the CRT overscan area).

Not only. My LCD (Samsung 204B 20" 1600x1200) has it too when i connect my old 386 and even my modern Geforce 280GTX with a DVI cable


Btw - is there actually any use for the boarder? I noticed that Crystal Caves displays a text box after you have picked up the last crystal. And you cannot close the box by accident, cause you have to press "esc" key for that. So boarder colour notification is not needed in this game.

[Kippesoep]

Btw - is there actually any use for the boarder? I noticed that Crystal Caves displays a text box after you have picked up the last crystal. And you cannot close the box by accident, cause you have to press "esc" key for that. So boarder colour notification is not needed in this game.

It does that only the first time. After that, the border is the only notification.

[Great Hierophant]

In order to have a full border, you will have to put up with a bit of windowboxing.

In CGA and EGA, the border size seems to be the same to my visual observations. In CGA 80 column mode the borders are 112, 80, 22 and 24 pixels wide (left, right, top, bottom). The time for a scanline is 912 pixels, but 80 of those are the horizontal sync pulse. Similarly, there are 262 scan lines, 16 of which are for the vertical sync pulse. In the 40-column and 320x200 graphics modes, the vertical information is the same but the horizontal pixels are double clocked (since they cover the same screen area).

With a VGA card, the borders are much smaller, more strips than bars.

In the gif below I show the "ideal" border display, where you see every color being generated by the raster. It is deliberately off-center.

[HunterZ]

That's got me thinking: Many people use widescreen monitors these days, while DOS games were made for 4:3. The dead area on the sides of widescreen monitors could be used to show the overscan border. It's not quite ideal, though, since it would only be on 2 sides.

[robertmo]

On the other hand many people use 17" and 19" lcd monitors with dead areas at top and bottom This makes it a bit more complicated

[robertmo]

I was afraid of something like that. It means that the game sets non-zero border color but it still black and carries no useful load. Two possible solutions: detect complete (or nearly complete) black and ignore it as well OR set no border as DOSBox default because it is only needed by a handful of games. In ideal case, shortcut key -- I just did not want to touch that part of the code until the feature gets debugged and proven.

That black boarder is usefull because without it on some levels (for example first one) boarder is blue, while it should be black on all levels (you can see that with output=surface). So right now dosbox doesn't display this game properly.

So no need for detecting black or shortcut key.

[tsm]

Hello and forgive me for revamping this old thread. I am a FastTracker II enthusiast and this program finally runs smoothly in DOSBox at full speed.
There's only one problem: when you toggle the "edit mode" on and off by pressing <space>, FastTracker II changes the border's color and there's no other way to tell whether you are in "edit mode" or not. I took vasyl's patch and applied it manually to version 0.74. I recompiled and now I can set the border size through the config file, actually getting a border around the FT2 screen. But this border is always black! I also tried some of the games mentioned in this thread and the border is always black too.
Any suggestions? Vasyl, are you there?

[NY00123]

Guess what?

Although the dimensions may be far from accurate and it is not fully tested, I have uploaded a new overscan border patch which adds *additional* borders around the image, for all supported outputs.

Games can you can check for testing (which I've tried today): Alley Cat, Commander Keen 1/4, Wolfenstein 3D, Doom, Duke Nukem 3D. Of course there are more, like ones mentioned under this topic beforehand.

Same caveats (and chances are that there are more):
- Although I've implemented the changes so the given feature works with all outputs, this is totally untested with output=ddraw. Furthermore, it may fail to work in certain cases even with outputs for which I've tested this with. For instance, output=surface with fulldouble=true (when working as expected) is a totally untested case.
- I can't seem to find a way to specify the precise dimensions of the overscan borders, given the emulated video mode. While there's a lot that can be told (hsync/vsync pulse time, hsync/vsync retrace time...) I haven't figured out how to take advantage of these, if it's even possible.
- With this patch, the overscan border is *added* to the image. This is the case with output=surface and similarly with windowresolution=original for all outputs.
- The way the aspect correction is done (if applied) may differ from one output to another and even be quite inconsistent, especially if the overscan borders are relatively large (which is not the case as of this patch).

A new setting is added with the patch, named... yep, "overscan". It does *not* have the same meaning as in any previous overscan patch, though.
The given setting can accept three values: "off", "auto", "forced". And you surely don't want to set overscan=forced, combined with fullresolution=original and a full screen, since... well, chances are that your setup doesn't support a quite unusual screen resolution (which contains the borders).

On the contrary, for that exact reason, with overscan=auto (the default with this patch), the overscan borders are *disabled* if fullscreen=original and while full screen is toggled on.

Hope someone has fun with this!

[NY00123]

A small update to the patch is attached to this post. The changes are:
- The overscan borders color is now properly queried (or so I assume) for Tandy/PCjr.
- Accesses to VGA-specific structures done for obtaining the overscan borders color are not done from sdlmain.cpp directly, anymore.

I should mention an additional game that you can try for the purpose of testing: Prince of Persia. Basically, you can wait until the screen flashes for any reason. There are certain combinations of video mode + hardware (machine setting) for which it does not occur, though.

As in the preceding post, I can't say this is a complete patch.
- All issues mentioned earlier apply, including the incorrect dimensions of the overscan borders (which depend on the current (emulated) hardware and video mode).
- More generally than the dimensions, it's true that I don't have lots of kinds of genuine hardware to test this against, in order to ensure all behaviors are proper.
- I really don't have any idea when it comes to composite output. If the border should be shown with this (again, don't know), then the way I've done it with the current patch may easily fail to work here.

[NY00123]

I have just attached an SVN build of DOSBox r3842 with the patch applied, for the ones interested. As usual you may find that this EXE has its limits (like the inability to take a screenshot - which wouldn't contain the overscan borders even if it were compiled in, anyway).

[Great Hierophant]

On a real VGA CRT monitor, the borders are usually pretty small, generally 4-5 pixels wide on each side. On a CGA CRT, the borders are very large, they fill the screen between the active image and the monitor bezel.

Composite color borders work the same way as RGB color borders, but there are few games you would want to play that use a border that is not black on a composite color monitor. Blue typically was the most common background/border color after black.

[NY00123]

So it seems like the composite borders color may be non-black. Even if they are black, though, due to the way composite output artifacts look like, the given patch may not do it the right way.
To solve this, a different patch, modifying the emulator side of things in vga_draw.cpp (and possibly more), rather than the host side in sdlmain.cpp (and minor changes to a couple of more source files), may be the right way.

As for the correct border sizes, it seems like DOSBox does not currently store the data required for these, at least when it comes to the the video modes. So it seems like some data from the CRTC registers, for the supported video modes, should be extracted on real hardware in some way. Manual measurement (in pixels) of overscan borders with real hardware, as done by you for a couple of CGA modes (as shown in your post here from 2009), is helpful as well.

EDIT: Alternatively, if there are manuasl with CRTC data for the various supported video modes, these can be useful as well, although whatever is actually reported by the (real) hardware should be more reliable in terms of emulation.

[VileRancour]

About CGA borders (and by extension, PCjr, Tandy, and 200-line EGA modes. VGA is different as noted):

I don't have my sources handy right now, but the total visible area - including borders - should be 240 pixels tall, and 720 hi-res pixels wide (=360 low-res pixels); this agrees with NTSC timings which CGA is based on. If we assume that the image is perfectly centered, it's easy to calculate the size of the border on each side. However,

- At least a small part of this overscan area is normally obscured by the monitor or TV bezel, though you could probably conveniently ignore that.
- The active image area isn't necessarily centered within the total visible area; the exact position should be determined according to the relevant MC6845 register values (the attached PDF may help). Emulating this in DOSBox would enable some "screen shaking" effects that don't currently work, as well as H-position adjustment in games like Atarisoft's Gremlins or Moon Patrol.

Some relevant info: http://www.reenigne.org/blog/cga-why-th ... to-be-set/

Motorola MC6845 CRTC datasheet:

[NY00123]

Thanks for all info so far!

I should probably add the fact I've hoped it should be possible to let a simple app written in ASM extract data from the CRTC registers, right after setting a video mode with "int 10h".

Unfortunately, it seems like at least some of the useful registers are write-only, although they may still be readable in practice (as it seems to be with DOSBox, at least for one emulated video card). The other alternatives, I guess, are manual measurements of the borders (as done above by Hierophant) and extractions of ROM data (which have their...problems).

About CGA borders (and by extension, PCjr, Tandy, and 200-line EGA modes. VGA is different as noted):

I don't have my sources handy right now, but the total visible area - including borders - should be 240 pixels tall, and 720 hi-res pixels wide (=360 low-res pixels); this agrees with NTSC timings which CGA is based on.

So the composite case is different from what you get with non-composite CGA monitors? At least, based on Hierophant's reply from 2009, the visible area, including the borders, has the width of 912-80=832 high-res (or 416 low-res) pixels and the height of 262-16=246 pixels.

At least a small part of this overscan area is normally obscured by the monitor or TV bezel, though you could probably conveniently ignore that.

Yeah, that's another issue, for which I'd give a low priority.

- The active image area isn't necessarily centered within the total visible area; the exact position should be determined according to the relevant MC6845 register values (the attached PDF may help). Emulating this in DOSBox would enable some "screen shaking" effects that don't currently work, as well as H-position adjustment in games like Atarisoft's Gremlins or Moon Patrol.

Back to Hierophant's example, I think it is an example where the image is not centered. Furthermore, there are chances I saw this "screen shaking" effect at some point, long ago. Can't tell for sure now, though.

[NY00123]

EDIT: I suspect this may still require some edits (although I'm not fully familiar with the topic anyway), so we should not assume this is a reliable source. Nevertheless, I've found this file hosted on a repository of reenigne (a nickname that may sound familiar for obvious reasons...): https://github.com/reenigne/reenigne/bl ... values.txt

A couple of more notes that I can add:

- It is admittedly the case that there may still be some more which I don't know at this point. In particular, the desired data from the CRTC registers should be fetch correctly, and their roles depend on the hardware. (EGA and VGA compatible seem to be different from the rest in that sense, although it's still much better to be careful.)
- Running DOSEMU, the too-modern GTX 460 I've gotten here may display wrong colors for CGA and EGA modes (see viewtopic.php?t=28916 for more details). However, it seems to be quite good at displaying overscan borders (using a DVI connector), at least in terms of VGA (or compatible) behaviors. The borders in Doom (apparently in tweaked mode 13h) are smaller than in Keen (say mode 0Dh), which I understand to be the expected behaviors. There are even chances that the borders' dimensions are accurate here, but I can't tell for sure. I'd add that, at least for modes 0Dh and 13h, the kind of ASM app I've talked about seems to show that the values of the registers are common among DOSBox (with VGA/SVGA emulated card) and DOSEMU with the GTX.

[VileRancour]

I should probably add the fact I've hoped it should be possible to let a simple app written in ASM extract data from the CRTC registers, right after setting a video mode with "int 10h".

Unfortunately, it seems like at least some of the useful registers are write-only, although they may still be readable in practice (as it seems to be with DOSBox, at least for one emulated video card). The other alternatives, I guess, are manual measurements of the borders (as done above by Hierophant) and extractions of ROM data (which have their...problems).

So what you want is to grab the actual results from real hardware? You may be able to debug or disassemble int 10h to get the exact CRTC register values, though you could probably find most of them in relevant tech refs (e.g. the IBM PC/XT Technical Reference v2.02 pages 1-125 and 1-148 for MDA and CGA respectively).

I don't have my sources handy right now, but the total visible area - including borders - should be 240 pixels tall, and 720 hi-res pixels wide (=360 low-res pixels); this agrees with NTSC timings which CGA is based on.

So the composite case is different from what you get with non-composite CGA monitors? At least, based on Hierophant's reply from 2009, the visible area, including the borders, has the width of 912-80=832 high-res (or 416 low-res) pixels and the height of 262-16=246 pixels.

The signal timings are the same, so there should be no difference between composite and RGB as far as border size is concerned.
The horizontal sync pulse is 160 hi-res pixels wide, not 80 (well, it *is* 80 in the peculiar case of 80x25 color text mode, since that mode's data bandwidth requires the clock rate to be doubled, and not compensating for that was probably an oversight). But the width itself doesn't seem to be very relevant, since in all CGA modes the h-sync is always positioned 720 hi-res pixels after scanline start (see MC6845 register R2, or line 14 in reenigne's register_values.txt above - the units are in char widths), and only the part before that is displayed.

For the height, I also subtracted the 6 pixels that comprise Vertical Total Adjust (MC6845 register R5); as per the specs, these extra scanlines are only there to bring the refresh rate as close as possible to 60Hz. I can't find any concrete ruling on whether or not they should be considered within the displayed area, but since the difference will almost certainly be 'hidden' past the display's edges, it may be convenient to discard them (FWIW, most capture equipment typically grabs 240 scanlines for all CGA modes).

It's entirely possible that I'm missing something here, but if I find anything to clear it up further I'll be sure to follow up.