qbismSuper8 builds

[revelator]

If i remember correctly it turned out that it needed negative increments in those two, sadly realm was not the one with this particular problem :S and the harddisk with my old projects died some time ago so ill have
dig out those sources from somewhere else now.

[qbism]

Yeesh, when I change cvar console names from 'snd_sfxvolume' and 'snd_bgmvolume' to 'sfxvolume' and 'bgmvolume' the bug is fixed! (Or at least disabled.) I changed those at one point to be consistent with other 'snd_' commands and never had a problem compiling it with mingw. Maybe I missed something.

[revelator]

strange indeed ??? are those cvars also called snd_bgmvolume etc internally ? as in cvar_registervarable("snd_bgmvolume") or does it still use the old string.

[qbism]

No, just console for consistency. Always had trouble finding them

[dreadlorde]

Could you link to what is needed to build qbism on windows (7 if that matters)? I've tried installing the direct x sdk but code blocks complains about missing headers iirc.

[qbism]

I use Codeblocks Advanced. It has all the necessary SDKs included IIRC. Many add-ons for Codeblocks are included and tools for msys posix dev. http://sourceforge.net/projects/cbadvan ... 20Minimal/ If XP support is desired, mingw version will need to be 4.7 and not 4.8.

[revelator]

Next version of cb advanced will use Msys2 and pacman .
This means that it will be pretty easy to downgrade the gcc version if needed instead of having to do it by hand every time.
It will also be less cluttered. Current version has a lot of workarounds for the Old Msys shortcommings both in regards to its toollset and support for the mingw64 compiler so its a bit bloated.

[qbism]

New release, mostly due to the save vulnerability mentioned by Spirit. Now using COM_ForceExtension for .sav and .dem. This also fixes the multiplayer scoreboard. Release 185 at

[ceriux]

would be cool to see a port of qbism on android. would also be neat if there was enough csqc to draw a custom hud.

[qbism]

Android would be interesting to see. I don't know of any 3D software-rendered games ported.

[cubanraul]

Hey Mr Qbism,

This is a follow up to a message I posted on your blog about getting crashes while underwater on any map. I can get them with portals as well.

vid_ddraw 1 reduces crash frequency but does not eliminate it.

Changing water opacity to anything other than default fixes it completely.

Tests were done on a fresh install on each system.

CRASHES:

AMD Phenom II X4 965 3.4GHz
8GB RAM
Windows 8 64-bit

AMD Phenom II X6 1055T 2.8GHz
16GB RAM
Windows 7 64-bit

Intel Core 2 Duo E8500 3.17GHz
4GB RAM
Windows 7 32-bit

NO CRASH:

AMD A4 3400 2.7GHz
4GB RAM
Windows Thin PC (Windows Embedded Standard 7) 32-bit

Intel Core i3 530 3.61GHz
4GB RAM
Windows 8 64-bit

[qbism]

Welcome to I3D!
The default wateralpha value may be the key. Originally there was only 0.33 alpha and 0.66 alpha. 0.50 (the default) is a fairly recent addition. Transparency required lookup tables, which is why values are fixed. The cvar can take other values, but 0.3 for example will map to 0.33.

Perhaps this bug does not affect icores. I develop on an icore 5 and don't crash at 0.5.

There's also a problem with recent xp builds not actually running on xp machines. Perhaps the issues are related. Another coder found various mis-matched typecasts and corrected them. These may not be part of the problem but it won't hurt to fix. Another possibility is newer gcc builds which have dropped support for xp (and what else??)

Thanks for reporting results on various machines. I can try out a Phenom laptop (not sure which version but it's a triple core).

[cubanraul]

Thanks, been following this forum for a while and finally had reason to post. 0.66 does the trick and I'll stick with that for now.

With the Intel Core 2 Duo E8500 3.17GHz system I was able to eliminate the crash by using the previous version of the threading DLL. This only delays the crash by a second or two on AMD Phenom II systems though.

That is too bad about XP support. I'd like to run qbismSuper8 on my AMD Geode LX and DM&P Vortex86MX+ systems that can't handle anything more recent. Both manage about 60fps in TyrQuake and it'd be interesting to see what I get with qbismSuper8.

Now back to playing with the various colored lighting and fog settings

[revelator]

Qbism you could try setting -mtune=generic for the CFLAGS that should make the executable work on all types of processors.
untick the processor optimizations in the build settings first though

[leileilol]

Part of the motivation behind Engoo was to get DP105-standard features in Windows 95 and DOS for Pentium processors (Somewhat defying expectations). Ditching the older platforms even as recent as XP seems rather anachronistic with a software renderer still relying on on 1995-era code... but this might jsut be beyond qbism's choice from the use of the recent compiler's gratuitous vendor-lockin. Just because XP SP3's support dropped a couple months back doesn't make it suddenly "prehistoric obsolete", even if it came out Fall 2001. It's a very good dontfixwhataintbroke OS that continues to stand the test of time, only crippled by modern driver and API support by choice of the executives, since the only ways to get people off XP would be to introduce something exclusive in Vista/7, etc. much less like the case of XP v. 98 when kernel architecture was a genuine limitation.

An ideal solution would just port all of these to work in Gcc working in Mingw/Msys, and that requires a lot of patience... and I kind of want to see what Clang does to the software renderer too, regarding optimizations