think aspect correction might be a considered a scaler and those aren't applied to captured media

Maybe resize the result with virtual dub or so

Yeah, thats a possible reason indeed. Of course I could edit it afterwards but if you're doing hundreds of them it becomes somewhat annoying having to do that. Plus, it's just not an accurate capture.

Would this be hard to fix? I know releases are rare but maybe somone wants to do a custom build 😉

Plus, it's just not an accurate capture.

Yes, it is. If the game is 320x200, dosbox captures it as that. I don't think .AVI has a standard way of defining the aspect ratio.

ripa wrote:

Plus, it's just not an accurate capture.

Yes, it is. If the game is 320x200, dosbox captures it as that. I don't think .AVI has a standard way of defining the aspect ratio.

If you had properly read my post you would have noticed that that's exactly NOT what's happening. The video resolution (and thus aspect ratio) is not the one the game should and does run in.

The video resolution (and thus aspect ratio) is not the one the game should and does run in.

Yeah then instead of endless talks about it not being "correct" post some
facts like what resolution the game runs on, at what pixel aspect ratio,
and what the resulting screen/video captures look like, given that you did
not even try to mention the game's name, the dosbox version you're using,
or anything else of relevance.

Okay, I'm sorry, I somewhat messed up. I was right about the game displaying in a different resolution than the captured video was in. But, the error is the other way around.

The videos were correct, the actual gameplay wasn't. CGA games (which should be 320x200) were showing in a 640x480 (or 320x240 without normal2x). The reason for this? aspect=true. Once I set it to false again the gameplay was now also showing in 320x200.

I find this pretty confusing though. Isn't the whole purpose of aspect correction to ensure that the game is displayed in its native resolution?

The description from the .conf and Wiki does not explain why this happens either. Or I'm not understanding it correctly.

1  aspect = true | false
2
3Do aspect correction. It only affects non-square pixel modes (like for example Mode 13h, which has a resolution of 320x200 pixels and it's used by many DOS games), and it's needed to get correct aspect ratio on square-pixel screens in windowed mode.
4
5However, it may look weird in some situations due to line doubling. Also, many people don't notice it when the aspect ratio is distorted and may even prefer it without correction. It depends on the game.
6
7Default is false. 

ps: I'm using 0.73. I'd have mentioned if I was using something else.

I find this pretty confusing though. Isn't the whole purpose of aspect correction to ensure that the game is displayed in its native resolution?

Aspect correction is supposed to be used if your graphics card does not
stretch the 320x200 (non-square pixels) mode to fullscreen on a 3x2 monitor
thus translating it to a square-pixel equivalent sized mode is what it does.
Same goes for windowed mode on a square-pixel native resolution.

I don't know what you mean by 3x2 monitor.

But it doesn't matter because sspect correction is supposed to be used if your graphics card does not stretch the 320x200 mode (non-square pixels) to fullscreen on ANY monitor 😀

I don't know what you mean by 3x2 monitor.

True, should be 4x3.

Thanks, I see. So it's not an aspect ratio preservation per se as known from lets say, DVD playback software, but rather a special fix for a certain type of display. That didn't get clear from the manuals and wiki, at least not to me. Maybe reword it a bit for a future release to avoid similar confusion?

I know that scaler=normal2x was modified to be fast now. Does the same apply to aspect=true?

If so, maybe this message could be changed from:
# aspect: Do aspect correction, if your output method doesn't support scaling this can slow things down!.
to:
# aspect: Do aspect correction, if your monitor doesn't display it properly.

I know that scaler=normal2x was modified to be fast now.

?

in the past scaler=normal2x together with hardware output was automatically switched to hardware scaling. Later that was changed again and it still uses software scaling even if you use hardware output, but software scaling was somehow speeded up to compensate.

320x200 games are always 4:3 even though the video mode has pixels in a "16:10" ratio. CRT monitors don't see the horizontal pixel count, so they basically treat everything as 4:3. LCD monitors, on the other hand, see all the pixels (when using DVI) and might treat it as widescreen video instead, which is wrong. That's when you need aspect=true (IMO it should be default, along with output=opengl and fullresolution=0x0).

ripa: Qbix said sth about crappy opengl drivers on some video cards. That is why it is not.

ripa wrote:

320x200 games are always 4:3 even though the video mode has pixels in a "16:10" ratio.

Now you've got me confused again. Take a look at these screenshots taken from windowed mode with the Windows snipping tool (so the resolution matches what I actually see on the screen).

This is a 320x200 CGA game and as you can see the aspect=true screenshot looks vertically stretched. My display is a laptop with a native resolution of 1280x800.

aspect=false
scaler=normal2x
result: 640x400

aspect=true
scaler=normal2x
result: 640x480

To display 320x200 (8:5) on a 4:3 monitor using the full area it has to be stretched vertically. The pixels are not square in this mode. And that's what the hardware back then did.
640x480 is not stretched as it already is 4:3. The pixels are square.

Nowadays the pixels of a common LCD monitor are square. So in windowed mode (assuming your desktop resolution is the native resolution of the LCD), It can display 640x480 in a correct aspect ratio without scaling. But 320x200 has to be scaled to look as it did back then.

In fullscreen things are different as nobody can know what your video card together with the LCD monitor produce when they are switched to one of the old 8:5 modes - if they produce anything at all. If the effects are not what you desire you'd set fullresolition to a value which produces square pixels on your screen. Aspect=true then scales the 8:5 output to 4:3 as in windowed mode.

h-a-l-9000 wrote:

To display 320x200 (8:5) on a 4:3 monitor using the full area it has to be stretched vertically. The pixels are not square in this mode. And that's what the hardware back then did.

Well I'll be honest here and say I can't remember what the games looked like back then. PC-Man was one of the earliest I played on my Commodore PC-10 but it's been ages. I will not doubt your technical expertise when you say a full screen picture back then was stretched.

But, having said that, isn't it a bit curious the chosen resolution for CGA was 320x200 when this in fact could not be displayed correctly on a standard monitor (unless you had black bars that is). Does anyone know the reasoning behind this? And how it looked when hooked up to a TV instead?

Also, did any developers try to adjust for this kind of vertical stretching by reversing the processing? As in, storing a squished picture in 320x200 that would look right when stretched to 4:3? Somewhat like anamorphic DVDs.

But, having said that, isn't it a bit curious the chosen resolution for CGA was 320x200 when this in fact could not be displayed correctly on a standard monitor (unless you had black bars that is).

Read again what hal posted, that's exactly where the non-square pixels come
into play (320x200 cga DID fill the full 3:2 screen without black bars).
Some games were designed with square-pixel ratios in mind (like no correction
when drawing circles), which looked/looks not-fully-correct by times if it is
noticeable at all. Most games were simply written to "look nice" on the
standard 320x200 for a 3:2 screen.