that's because scalers don't work on tweaked modes such as 320x400 as seen in Normality. DOSBox uses a special 2x1 scaler for the tweaked VGA modex video modes.

Ah I see. I wasn't aware of this but am read up on it now that you pointed me in the right direction, thanks. At least I know now the scalers don't work and not that I configured incorrectly.

Also read up on how to use gulikoza's Direct3D patched DosBox. Played around with it and found the shader based scalers DO work - unfortunately however, the game does not appear to run at the correct aspect using Direct3D output. It should be 16:10 (as shown in the screens above) but it's displaying as 4:3 (and vertically stretched as a result) regardless of whether aspect correction is enabled or disabled.

For the moment I guess I'd rather play the game with big ugly pixels but at the correct aspect. If anyone knows how to use gulikoza's Direct3D and have the game run at the proper aspect, please let me know - haven't had any luck tracking down a solution for that myself.

Sweetz wrote:

It should be 16:10

No it shouldn't. 4:3 is the correct ratio.

CRTs are 4:3 and that's what pretty much all DOS-era video modes were designed for. E.g., 320x200 is a 16:10 pixel ratio, but on original hardware, a true 320x200 video mode would be shown as 4:3 with vertically stretched pixels. That was the expected ratio and most games were designed with that in mind.

and 320x400 is just the scanline-doubled version of that mode, so the aspect correction you're seeing is just the way it should be.

Yup, I know about CRTs and rectangular pixels when running 320x200 - but here's the thing, comparing to screenshots in the game's own manual the game appears to match them correctly at 16:10 instead of 4:3. Now of course that doesn't mean that the screenshots simply weren't printed at the incorrect aspect in the manual. However, when looking at circular objects, like circular fans and vents on walls, these appear perfectly circular at 16:10 and ovular at 4:3.

In fact, check out the speakers and anarchy symbol on the wall in my own 16:10 shots - they're correctly circular. If you clip off the black bars and resize the shot to 4:3, they end up looking vertically stretched. Also take a look the screenshots on GoG, which show the game at 16:10. Just informally, these do not appear deformed - they look aspect correct.

I know that's not hard evidence, but I think this is one 320x200/320x400 game that really is meant to display at 16:10.

Perhaps this is a case of all the game's art being internally designed at a resolution that used square pixels during its development, but then they switched to rendering at 320x400 late in the process for performance reasons and didn't account for needing to redo all of the game's art. So actually the game was always displaying at the "wrong" aspect back in the day. Whatever the case, the game just looks more correct to me at 16:10 than 4:3 and I can't seem to get it running at 16:10 with the Direct3D renderer.

when looking at circular objects

There are several games that have been designed with square pixels in mind but using a non square pixels mode in the end.

wd wrote:

when looking at circular objects

There are several games that have been designed with square pixels in mind but using a non square pixels mode in the end.

Yup I'm thinking that's what happened here.

Given the choice I'd rather play the game as the aspect that looks correct than go for the "historically accurate" experience - I wouldn't be looking to use quality improving scalers otherwise.

Sweetz wrote:

I know that's not hard evidence, but I think this is one 320x200/320x400 game that really is meant to display at 16:10.

Gremlin Interactive, the company that is listed as developer on GOG.com, was really heavy into developing games for the Amiga. Maybe that's the reason?

The reason why so many screen-shots and YouTube let's play playthroughs are 16:10 is because they are captured with DOSBox and DOSBox doesn't scale them (regardless of the aspect ratio setting). And most don't change the ratio when they publish their images or videos 😀

This is likely the same reason you find 16:10 shots in manuals. They didn't take a photo, but a digital screen-shot which is 320 x 200. Then they insert it into their DTP suite and voilà you have a 16:10 image.

Good thing is we have a choice these days 😀

BTW, while we're on the subject of Normality, the game creates a batch file (normal.bat) which is what is supposed to be used to start the game.

These are the contents of that batch file:

1@echo off
2copy normal.bat maps\silly.das >NUL
3del maps\*.das
4norm %1 %2 %3 %4 %5 %6 %7 %8 %9
5echo Stay Normal!

norm.exe is the actual game executable. Now I know syntax for every line there and what they do - at least their direct purpose - but I can not fathom what the intent is for creating that silly.das copy of the batch file itself and then immediately deleting it.

Is this a mysterious old Dos trick for doing something other than its apparent pointless purpose?

Given the somewhat odd sense of humor in Normality and the name of the file, do you think it's some sort meta joke - as though the developers were like: "let's be weird and run this useless command"?

Creating SILLY.DAS prevents a "File not found" message when there are no other files matching *.DAS to delete. In real DOS the message can't be hidden by redirecting output to the NUL device, so I'm thinking the intent is a more cosmetic appearance and/or to not cause concern that there might be a problem.

Ah makes sense. So I guess the game must create some .das files for whatever purpose while it's running (there aren't any such files in the directory after install) that they want to clean up each time the game runs.

Mau1wurf1977 wrote:

Sweetz wrote:

I know that's not hard evidence, but I think this is one 320x200/320x400 game that really is meant to display at 16:10.

Gremlin Interactive, the company that is listed as developer on GOG.com, was really heavy into developing games for the Amiga. Maybe that's the reason?

No. 320x400 is the usual double-line 320x200 that's a VGA mode. They were aiming for a high resolution 4:3 mode without turning to VESA. (They were able to do that later with the same 3d engine in Realms of the Haunting) It has nothing to do with an AMIGA legacy, especially since you can see some DOS Deluxe Paint colors and tones around here, and since Deluxe Paint usually works in 320x200...

If it were made for 16:10, all the sprites and the world would be vertically taller.

Capcom CPS1/2 games often faced this problem. Their native resolution is 384x224. It's a 4:3 resolution, but people tend to play it widescreen anyway because the square pixel judgment of 384x224 makes it look 16:9 (leading to fat/wide characters)

Those GOG.com screenshots (uglyscaled to 710x443, way to go guys!) definitely have some squashed-looking stuff - especially those elliptic spark-like sprites in the first and last shots, those would be circular in 4:3.

no idea why d3d shaders do aspect correction even if you set it to off. Maybe it's a matter of hacking the .fx files a bit.

It's not the shaders, it's the D3D output itself. aspect=true will always scale to 4:3 exactly and aspect=false will try to come as close as possible to 4:3 using only integer factors. This is only for fullscreen modes, window modes work the same as other outputs.

VileRancour wrote:

Those GOG.com screenshots (uglyscaled to 710x443, way to go guys!) definitely have some squashed-looking stuff - especially those elliptic spark-like sprites in the first and last shots, those would be circular in 4:3.

I agree those sparks do look squashed, but there are plenty of other circular things in the game that look correct at 16:10 - and notably the pre-rendered cutscenes definitely look like they were made with square pixels in mind.

-----

Here's the behavior I'm observing with Direct3D output vs DirectDraw:

In all cases fullscreen=true is set and the resolution used is 1920x1080. For Direct3D the pixel shader being used is HQ2X.fx

When using Ddraw:
•With aspect=false: The game's image is scaled to fit the screen vertically and displays at 16:10 (as shown in the screenshots in my first post).

•With aspect=true, the game's image is scaled to first the screen vertically and displays at 4:3 - no surprises there.

Regardless of the aspect setting, using a scaler setting with Ddraw does nothing (as has been discussed).

When using Direct3D:
•With aspect=false and no scaler option set: The game displays in a 16:10 window in the middle of the screen. I haven't actually checked the res, but I'm presuming it's 640x400. Tthe game is not scaled to fit the screen vertically as when using Ddraw. Additionally the pixel shader does not seem correctly applied to the whole image. So while this shows the game in the aspect I prefer, I don't want to use this due to the game displaying in a small area.

•With aspect=false and scaler=hardware2x: The game displays in a 4:3 window in the middle of the screen (I'm presuming 640x480), but now the pixel shader is applied to the complete image.

•With aspect=true and scaler=hardware2x: The game is scaled to fit the whole screen vertically and displays at 4:3.

I'm writing this from the office right now. Once I get home, I'll upload some screenshots of each of the above if they'll be of use to anyone.

I was waaay off on my guesses at the the displayed resolutions before. Nevertheless, the behavior is still generally as described above - except there's some oddness with the Direct3D output when aspect correction is disabled, but the scaler is set to "hardware2x". It actually displays the game in a 6:5 aspect window (and not 4:3 as stated) in that case.

I'm not sure if this is all already known caveats of the Direct3D output - but maybe it's of use to someone.

I will say though, as you can see in the last shot the Direct3D HQ2X scaler does look pretty darn amazing.

.

Seems to me it works as designed. In case #3 (direct3d_aspect-false_scaler-none) dosbox will internally double the width from 320 to 640 using nearest neighbor resize so the shader can't smooth it as much as working with the original 320x400. That's why hardwareXx scalers were introduced...
Aspect=false is precisely that - aspect=false. You can't argue AR is wrong when setting it that way 😀. It is intended for cases when using integer factors will result in (nearly) correct AR (such as stretching 320x200 to 1600x1200 using 5x and 6x). Your 1080 vertical resolution unfortunately does not play well with 400 of the games original lines that's why aspect=false looks weird. A 320x200 game however would be nicely stretched to 1280x1000 (4x:5x; as opposed to 1440x1080 (4.5x:5.4x) if aspect=true would be used).
D3D is output is not official and is experimental. That's why it does some things differently.