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]

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]

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

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

[qbism]

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