qbismSuper8 builds

[leileilol]

Does your engine work properly? Tried the build from the sourceforge download, all I got rendering was a grey void and particles.

Also it really needs to honor -startwindowed

[qbism]

[qbism]

Yeah, -startwindowed should be killed as it's both vague and redundant. I tried to revive it but realized vid_win could use simplification. It's already commented-out in the original mh ddraw vid_win.c. Just set vid_mode explicitly at startup if needed. (Well, I guess I should verify that actually works.)

Many engines start up in a windowed mode by default but super8 will go fullscreen based on user feedback. Also it saves vid_mode cvar, I think other engines vary on that.

[mankrip]

[qbism]

The audience is not exactly huge, but of the few comments from players on this issue: Full screen, native res, don't like stretch-by-2 as a default. Windowed mode is often best for development so just set archive true for vid_mode is my thought.

Legibility of small text and icons is a problem on high-res. No easy way to stretch just the text and hud in the sense that so many hard-coded numbers have to change. Automatic 2x 3x or 4x selection with optional cvar override would be nice.

[leileilol]

There's no good reason why a game should start fullscreen first, especially if it goes fullscreen first and then sets the mode to the default mode set that could be a windowed mode. Some people play in windowed because they don't like it when a fullscreen low res game rearranges their desktop icons or resize all their open windows.

[qbism]

True, it should go to MODE_WINDOWED first in Vid_Init to have a safe fallback.

[Spike]

fte delays starting up video until after configs have been read.
but yeah, if you're going to set an unconfigured mode before reading the config, then that mode should be windowed, and the final configured mode should default to fullscreen.

[mankrip]

Starting in a maximized yet non-fullscreen windowed mode would be a nice middle ground... except that as soon as the demos starts running, the framerate would be very slow in not-so-powerful computers with high desktop resolutions. And extremely slow framerates makes it hard to navigate through the menus, so the user would be annoyed until he manages to navigate to the video modes menu and switch to a lower res mode when running the engine for the first time.

And no, I don't expect users to know how to use the console for that (and for anything else). I like to keep my engine newbie-friendly, which is why I've invested so much work on the menus. Except the Video modes menu... yet.

[leileilol]

[revelator]

idd

[mankrip]

[leileilol]

[mankrip]

I know, but setting the screen aspect ratio manually is still an awkward solution. 1280x1024 LCD monitors have a 5:4 screen aspect, which I bet most people think is 4:3, and I also bet most people can't tell whether a widescreen LCD monitor has a 16:9 or a 16:10 screen aspect, so calculating the screen aspect automatically is better.

Plus, calculating the screen aspect like Makaqu does ensures that the same setting will remain valid across different LCD monitors, so you can switch the monitor or play a copy of the game with the same config on different computers with different LCD displays without having to reconfigure the screen aspect settings again.

For CRT monitors there's really no way to calculate automatically, which is why I've implemented an option to set it manually.

[qbism]