qbismSuper8 builds

[leileilol]

Hmm. This is why I suggested the Quakespasm code. It only looks really bad for that one 640x480 unscaled hud case that's most definitely a bug, but the rest seems to line up with Quake's 320x240 metrics. I assumed qbism were to implement hud scaling as well. (also mh it's been a while!!!)

Sorry for the downsized pictures - it's a GIF. and ignore the differently lit model and flares, that's not the point (But it does help tell the engines apart- also viewscale scales the SB_LINES which also affect the refdef's size)

my computer was an AMD Cyrix 233 computer that ran it at 12 fps in 512x384.

Cyrix was piss-poor for Quake in general. An AMD K6 233 would be fine with it though, and there's no such thing as an AMD Cyrix...so i'm leaning towards Cyrix MII from the poor framerate here and the fact there's no AMD K5 that ever clocked that high. A PII 233 w/ Fastvid would make 512x384 fly and make using the 640 modes much more feasible.

[mankrip]

there's no such thing as an AMD Cyrix...so i'm leaning towards Cyrix MII from the poor framerate here

Whoops, you're right. It was a Cyrix MII 233. It's been a long time.

[leileilol]

I should mention that 320x200 scaling is less fortunate...

[mankrip]

I should mention that 320x200 scaling is less fortunate...

I don't have a WinQuake executable here to compare, so I've used ToChriS.

[edit] Looks like Engoo's FOV is wrong.

[mh]

I'm actually quite satisfied that the calculations I've got are correct. If for example you plug some values into the widescreen FOV calculator I linked, going from 800x600 with fov 90 to something weird like 800x480, it gives an equivalent FOV of 102.68038349182, which my code calculates 102.68038 for, and maintains the same vertical FOV (68.038696) in both cases.

This isn't a theory - I've cross-checked it with multiple different sources, going from widescreen to non-widescreen, and with variable sbar heights, and it's consistent in all cases. Using 640x432 as a baseline maintains the same vertical FOV for all different values of sbar height too, which is also important to get right.

My code is also consistent for "tallscreen" modes like 300x676, making horizontal FOV constant but allowing vertical FOV to stretch the height, and again it maintains the same FOV for all values of sbar height. I haven't yet checked how the QuakeSpasm code behaves in that scenario, but even though nobody will ever actually use such a mode, it is important for verifying correctness.

[mankrip]

going from 800x600 with fov 90 to something weird like 800x480, it gives an equivalent FOV of 102.68038349182, which my code calculates 102.68038 for, and maintains the same vertical FOV (68.038696) in both cases.

This isn't a theory - [...] it's consistent in all cases. Using 640x432 as a baseline maintains the same vertical FOV for all different values of sbar height too, which is also important to get right.

Consistency and correctness are different things.

Open the vanilla WinQuake 1.09 code, and add this:

Code: Select all

void V_BonusFlash_f (void) // When you run over an item, the server sends this command
{
   cshift_bonus.percent = 50;
   cl.cshifts[CSHIFT_BONUS] = cshift_bonus; // TO DO: should be set at initialization

   Con_Printf ("fov x %f\n", r_refdef.fov_x);
   Con_Printf ("fov y %f\n", r_refdef.fov_y);
}


These are the results in Makaqu:



Also, this is a comparison I've made while rewriting the underwater screen warp. In a couple of them (4:3/5:3 video on a 4:3 desktop stretched to a 16:10 screen) the warping is wrong (I've already fixed it later, though), but the aspect is still correct:

[qbism]

What makes it go wrong is the zoom. If you zoom in and then zoom out, the viewmodel doesn't return to its normal position.

I was unable to duplicate this.

Which FOV are you basing the reposition on? If you use the horizontal FOV (r_refdef.fov_x, which is the one that's initially set to 90 from the cvar), it will have different results on different video aspects. A widescreen video has a bigger horizontal FOV than a 4:3 video (which is the one I've tested it on), so if your repositioning algorithm is expecting a widescreen FOV, it will think that the view is still zoomed in when the fov is 90.

To get proper results, the repositioning must be based on the value of the vertical FOV, or on the value of the "fov" cvar itself (if it hasn't been changed by the engine).

It's based on scr_fov. This is also the only function where scr_ofsx, scr_ofsy, and scr_fov are modified by the engine.

Alias zoom attempts to zoom all the way into fov 5, original quake limits fov 10 to 170, super8 is 30 to 140 for some forgotten reason. If there's not a glitch I'll change it back. That should not affect the view model reposition because the range check happens first.

Code: Select all

void SCR_AdjustFOV (void)
{
// bound field of view //qb: change to 30 - 140
    if (r_fisheye.value) //qb:  set it yourself, for now
        return;
    if (scr_fov.value < 30)
        Cvar_Set ("fov","30");
    if (scr_fov.value > 140)
        Cvar_Set ("fov","140");
    scr_ofsx.value = (pow(scr_fov.value, 2)-scr_fov.value*70)/2000 -3; //qb: compensate view model position
    scr_ofsz.value = (pow(scr_fov.value, 2)-scr_fov.value*70)/2000 -1;//qb: compensate view model position
    if (oldfov != scr_fov.value)
    {
        oldfov = scr_fov.value;
        vid.recalc_refdef = true;
    }
}

[qbism]

... I was able to duplicate the 4:3 scaling error. Looks like attempting to scale to 16:9 on a native 4:3.

Regarding FOV, the expectation is that fov_x would be the same at all video aspects, with or without sbar. In other words the view is cropped vertically rather than horizontally in all cases. This is seen in the animations.

[mankrip]

It's based on scr_fov. This is also the only function where scr_ofsx, scr_ofsy, and scr_fov are modified by the engine.

Wait; I know what's happening.

For some reason (which I can't remember exactly), the FOV value isn't always updated correctly in the engine. So, most likely what's happening is that your code is actually using the FOV value from the previous time the FOV was changed, and not the current value.

I had a lot of trouble dealing with that when implementing the support for multiple video aspects.

[qbism]

Fortunately the Mobility died on my switchable graphics HP, and when the Intel took over I realized it had a 1366x768 mode for testing.
http://super8.qbism.com/wp-content/uploads/2013/10/qbism-Super8-v175-setup.exe
aspect ratio correction and GDI non-power-of-two really fixed this time. Probably.

Screenshot: Drake mod - arcanum1

[leileilol]

Why does it need to be a setup program?

[qbism]

A zip is also available http://super8.qbism.com. Installer is easier for most users.

[Spirit]

Any chance that you could add the (zipped) source to the zip? Or provide a accompanying standalone source zip for each release?

[qbism]

For a source code zip, click on "download snapshot".http://sourceforge.net/p/qbism/super8/HEAD/tree/
The "history" link will allow browsing and snapshot download at any previous release.

[r00k]

sorry to dig up an old thread but
mh's method pertains IF the sbar is NOt an overlay?
so the quakespasm code should work only if the sbar is an overlay
.