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]

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

On my laptop it works... I also experienced the grey void in a previous build (due to an overrun error in mips function) but not 134. Try deleting old super8.cfg.

I didn't realize -startwindowed was broken, but digging into it there's an old FIXME note in VID_InitModes. May or may not be related to the breakage. I've been setting windows mode from the menu which may not be affected.

Code: Select all

...
    // automatically stretch the default mode up if > 640x480 desktop resolution
    hdc = GetDC (NULL);

    for (i = VID_WINDOWED_MODES; i<nummodes; i++) //qb: FIXME - this gets stomped on.
    {
        if ((modelist[i].width == GetDeviceCaps (hdc, HORZRES)) && (modelist[i].height == GetDeviceCaps (hdc, VERTRES)) && !startwindowed)  //qb: do fullscreen as default.
        {
            vid_default = i;
            continue;
        }
    }
...

[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]

super8 will go fullscreen based on user feedback.

What did they say, exactly?

I also used to prefer my engine to start in fullscreen, but after years of little annoyances I made it always start in windowed mode. At least I doubled the startup windowed resolution to 640x400, to make the text easier to read.

[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]

For Engoo i'm wanting to follow Zdoom's arrangement of the video modes menu, which is a short list of options (Fullscreen, Depth, Modes by aspect ratio, Force aspect ratio) and then all the available resolutions from that.

except that as soon as the demos starts running, the framerate would be very slow in not-so-powerful computers with high desktop resolutions.

What's in your mind for "not-so-powerful"? Is 40fps on Pentium IV 2.6GHz at 1920x1080 that bad? A well armed Pentium II can achieve 20fps in 800x600 too...

[revelator]

idd

[mankrip]

Modes by aspect ratio

Most games seems to do it this way, but this is actually wrong. All video modes (including supposedly-widescreen ones like 1920x1080) have a 4:3 screen aspect in my CRT monitor, but in LCD/LED/Plasma/etc., they doesn't.

In short, video modes doesn't belong to screen aspects. Which is why I've implemented multiple screen aspect support in Makaqu the way I did: Set wether the screen has a variable (CRT) or square (LCD) pixel aspect, and if the screen is a CRT one, set the screen aspect manually. In square pixel aspect mode, the screen aspect can be calculated automatically, so the user doesn't need to set it. All these options are in Makaqu's Screen adjustment menu.

I have also added an option to define whether fullscreen square-pixel video modes are being stretched up to the native resolution. This takes care of any screen aspect distortions that would happen if, for example, a 640x480 video mode is running in a 1280x800 LCD screen. If there was any reliable way to check whether the video card/monitor is stretching the image, I would also make the engine set that automatically.

By the way, I've also made it so the borders of the screen can only be adjusted on CRT monitors.

And Makaqu also adjusts the video aspect correctly when running in a windowed mode. So, for example, a 640x480 (4:3) windowed mode will be displayed correctly in a 1280x1024 (5:4) desktop video mode stretched up to a 1920x1080 (16:9) native resolution of a LCD screen. And no matter which video modes the user changes the game and/or the desktop to, the game's video aspect will still be corrected automatically.

I haven't seen any other game or engine with better support for multiple video aspects than this.

What's in your mind for "not-so-powerful"? Is 40fps on Pentium IV 2.6GHz at 1920x1080 that bad? A well armed Pentium II can achieve 20fps in 800x600 too...

My laptop is a cheap 1.8 GHz Celeron with 1.75 GB of RAM and Windows Vista with tons of stuff installed. This is why the framerates are so low in the screenshots I post at Makaqu's blog. I usually get around 12 fps in 1280x800 (in scenes without any water or dynamic lights), and this would be even slower if I was playing music and running other programs in the background.

[leileilol]

Modes by aspect ratio

Most games seems to do it this way, but this is actually wrong. All video modes (including supposedly-widescreen ones like 1920x1080) have a 4:3 screen aspect in my CRT monitor, but in LCD/LED/Plasma/etc., they doesn't.

That's what "force aspect" is for (for the 1% still using 4:3 CRTs), and listing modes by aspect ratio would be just a filtering option.

[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]

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

Drat, I'm getting the gray void again on debug builds of the current SVN (136) but not release builds. This is difficult to debug because it doesn't crash or issue a message. Seems like an overrun.

On release builds it crashes after dying in lava and then loading saved games from certain maps. I can't use the debug build because that build doesn't crash. Of course not, the one time a crash is wanted! (Since it's just a gray void, I feel my way around the start map into the lava.) It seems like the "cshift hangover" crash but that code hasn't changed since it was fixed many builds back.

Best guess is that it's still related to recent mips optimization. Next step is to try swapping out with the previous mips code.