The best of the best...

[myk]

Super Jamie said:
Probably a limitation of the video chipset and drivers.

If it's the drivers (which I think is generally more likely) and the executable has a way to bypass what the stupid drivers think is available, as Chocolate Doom does, you can use 320x200. The 640x400 setting in other engines might need this, too.

The setting in chocolate-doom.cfg is autoadjust_video_settings, which must be 0.

I'm still waiting for Odamex to have a similar fix, periodically checking the corresponding bug report entry...

[chungy]

Chocolate Doom doesn't bypass anything, it only allows the modes that the driver reports having support for (or rather, SDL does this, but heh...)

[myk]

Isn't it that it bypasses that when you set the option to 0, thus allowing modes the driver thinks aren't available, but are supported by the hardware?

[Zilken989]

I'm quite sure that's exactly how it works, man... That's what makes the most sense, and I've had that happen in previous expierences :P :S

[chungy]

myk said:

Isn't it that it bypasses that when you set the option to 0, thus allowing modes the driver thinks aren't available, but are supported by the hardware?

This doesn't really make sense. The driver should dictate exactly what modes are allowed, how exactly do you bypass that? I know for certain that I wasn't able to use 640x400 for a long time until a driver update added the mode back.

[Zilken989]

Hmm... I've never heard of, or even had that issue... that's shitty

[myk]

MikeRS said:
This doesn't really make sense. The driver should dictate exactly what modes are allowed, how exactly do you bypass that?

No idea, personally; I'm not a programmer or drivers expert. That's just what I had understood from when fraggle was working on the issue.

What makes me think this is the impression that some card and driver combinations require autoadjust_video_settings 0 to obtain 320x200 and 640x400. Something is telling the engine that those aren't available, yet they are possible. Maybe it's not the driver, as you say, although I have a Windows 98 system, where hardware can be accessed directly, so perhaps in that case Chocolate Doom can bypass the Windows driver? Otherwise, I'm guessing SDL is somehow asking Windows what resolutions are available, by default, and Windows doesn't normally let you go under 640x480.

What I know for certain is that on some systems the "16x10" 4/3 resolutions work without any help, so something must be normally telling Chocolate Doom and Odamex that they aren't an option, on my system.

[fraggle]

myk said:

Otherwise, I'm guessing SDL is somehow asking Windows what resolutions are available, by default, and Windows doesn't normally let you go under 640x480.

Yes, that's basically it, as far as I can tell.

Chocolate Doom uses SDL's API to get a list of supported video modes. It will only use one of these modes and if you try to specify something different, it will switch to a valid mode. Setting autoadjust_video_settings to zero turns this off; if you do this, the screen width/height values will just get passed straight through to SDL when it sets the screen mode.

It seems on some machines, some modes don't appear in the list that SDL returns even though they're valid and you can set them. I assume this is probably due to the driver being used not listing them.

I'm not planning on trying to develop fixes for this because it very much depends on the make and model of video card that you're using, and in any case I don't think it's that big a deal. My main priority is getting something that works on as many machines as possible. Sticking with autoadjust and the SDL mode list seems to me like the best option because at least it's using modes that should definitely work. Plus, the option's always there in the configuration file if you want to go under the hood and tweak it :-)

[myk]

Yeah, no problem here, I consider the no autoadjust option to be a fix. The one that needs a fix of some sort is Odamex.

[Quasar]

Eternity just cuts to the chase and tries to set whatever mode is requested. If SDL fails to set the mode, we try to switch back to a safe resolution. If the safe resolution fails, we bomb out.