qbismSuper8 builds

[Spike]

The fov aspect should be based upon the vrect rather than the total screen size, which keeps things working fine even if the hud takes a huge chunk out of the screen.
vanilla quake never compensated for non-square pixels (favouring 320*200 over 320*240 when both had the same physical display size on any monitor), so the only 'compatibility' thing is to keep the fov specify the major axis and have the other axis determined as a function of that. Whether you determine the major axis based upon 1:1, 4:3, or 16:10, or whatever the heck it is with the hud chopped out of it too, is up to you. Whichever you pick will mess up the viewmodel in some configuration.
For any ratio other than 1:1, you calculate the vertical fov as what it would be if your ratio were current, then calculate the horizontal fov as a function of that. Tall screens will then see much less, but also much less floor too.
Enabling dynamic window resizing first can really help with testing this stuff.
Make sure you properly recalculate fov aspect *after* everything else has been resized, and based only upon the view area's dimensions.

[qbism]

http://super8.qbism.com/2014/01/build-182-released/
Build 182 released. Minor stuff. A couple of Zendar hellknights mugging ogres:

[leileilol]

Any reason why it has to cap the framerate at 20 by default?

Any reason why the keyboard turning speed is ludicrously fast and is tied to the framerate?

[qbism]

Any reason why it has to cap the framerate at 20 by default?
Any reason why the keyboard turning speed is ludicrously fast and is tied to the framerate?

I accidentally included a super8.cfg in the zip. It has unusual settings. That one's easily corrected, but I don't know off-hand why keyboard turning is whack. I seldom use keyboard turning so that bug got by me.

[qbism]

...apparently I broke TIMESCALE (QIP modification) a while ago. Turning seems OK after removing it completely.
[EDIT] The build is fixed.

[revelator]

Is this one using the new open watcom yet ?

I think leilei would be mighty interrested if it is

[qbism]

My friend Levent created a Watcom build of R168 http://super8.qbism.com/wp-content/uploads/2014/01/168l-20130911-1842.7z
I may not have a chance to try it today, but I was able to compile a previous build from him with OW 2.0 Notes:

I'm sending last edited version. Seems like I have crashes in malloc. cl_demo.c PushFrameposEntry(): newf=malloc(framepos_t); I noted that I should debug it in linux or use VC. Notes are in doc/DONE.txt

exe included in build dir.

[revelator]

Thats quite a nice source setup he made there gonna see if the bugger runs

[revelator]

Yup runs fine but crashes if i try to turn down sound volume hmm ???.

[revelator]

Recompiled the bugger with the latest directx sdk runs fine but still crashes when trying to turn down sound volume, odly enough all other sliders work fine.
Looks like a bug in the sound code, but besides that it runs pretty well. Watcoms debugger unfortunatly does not work on win 7 64 yet :S so it will be quite a hunt unless someone has win 7 32 and got some time
to try and find out where it goes fubar.

P.S watcom uses dwarf debugging so no you cannot use msvc's debugger for it.

[qbism]

snd_mix.c throws pointer type warnings using mingw, but seemingly unrelated to changing of sound volume:

Code: Select all

C:\qbismSuper8\qbS8src\snd_mix.c: In function 'S_TransferStereo16':
C:\qbismSuper8\qbS8src\snd_mix.c:88:48: warning: passing argument 4 of 'pDSBuf->lpVtbl->Lock' from incompatible pointer type [enabled by default]
                                                &pbuf2, &dwSize2, 0)) != DS_OK)
                                                ^
C:\qbismSuper8\qbS8src\snd_mix.c:88:48: note: expected 'void **' but argument is of type 'DWORD **'
C:\qbismSuper8\qbS8src\snd_mix.c:88:48: warning: passing argument 6 of 'pDSBuf->lpVtbl->Lock' from incompatible pointer type [enabled by default]
C:\qbismSuper8\qbS8src\snd_mix.c:88:48: note: expected 'void **' but argument is of type 'DWORD **'

Have you tried changing sound volume from the console? It might be something in the menu itself, because changing sound volume doesn't trigger anything. 'snd_vol' is simply set equal to the cvar every pass in snd_mix.c functions. Yet, nothing special in menu code either.

[revelator]

Aye got those warnings myself with gcc, i fixed those in my old realm engine though they did not cause a crash.

Ill check out the console commands, hang on.

[revelator]

ok the actual var name is sfxvolume and changing it via the console works so seems theres a bugger in the menu slider code for it

[revelator]

happens in both of these if using the menu slider.

Code: Select all

    if (c == i++) ChangeCVar("snd_sfxvolume", sfxvolume.value, dir * 0.1, 0, 1, true);
    if (c == i++) ChangeCVar("snd_bgmvolume", bgmvolume.value, dir * 0.1, 0, 1, true);

i seem to remember a similar issue with another source with the 0, 1 increments being wrong.
ill have a look at my realm source cant remember if my engine also had this bug though.

[qbism]

Just ran a build, getting the same crash on both sfx and bgm sliders. Other sliders seem fine.