qbismSuper8 builds

[revelator]

Clang uses a syntax similar to gcc so should not be to hard the codelite editor supports clang so maybe a good choice if you want to experiment.
My somewhat dated codeblocks editor does not but i heard that it was added to later versions, well should give me an excuse to update my version.
Only downside is that i probably have to hack the current versions sources to support cb::advanced (again erf) cause last time the support for the MinGW64 compiler was kinda shoddy.
Can atleast get by most things with gcc if you take the time to learn the compiler switches -mtune=generic will optimize for old 386 processor instructions which should work on all architectures even AMD.
But it can probably be felt on the speed.

[qbism]

The easiest fix to try for Super8 would be going back to gcc 4.5 or 4.6. But it's not a good long-term solution. I'm also working on a Watcom project based on Levent's port of an earlier version. Watcom output will definitely run on XP.

Ironically VS2013 produces great XP output, and the IDE is enjoyable to use.

I don't know much about Clang... Does it support old Windows versions?

[revelator]

Think so but not 100 on it it has a rather good static source scanner though which could help track mistakes.
Msvc 2013 is quite good aye its just a bit bloated by all the win 8 support tools but works beautifully.
Watcom has full support of XP if you need directx support its better to get the directx sdk though, watcoms built in replacements are pretty limited,
it does link fine with msvc libraries though so thats a plus. SDL also works with watcom.

[leileilol]

[qbism]

[mankrip]

[qbism]

[cubanraul]

With a stock install vid_ddraw 1 is still required to eliminate the crash while in the water/portals on AMD Phenom II systems. I'll give a Core 2 Duo system a test later on today. As before changing r_wateralpha to anything other than the default eliminates it. Something is for sure improved since vid_ddraw 1 still crashed on Phenom II systems on the last build if r_wateralpha wasn't also adjusted.

On my AMD Geode (500 MHz of raw power) system the regular build crashes immediately but the watcom one runs as intended.

[qbism]

[cubanraul]

On Core 2 Duo and Core 2 Quad systems the crash is now fixed. Can anyone else replicate this crash on anything and if so, on anything other than a Phenom II?

[revelator]

Not home atm but ill run it through a corei7 and an old AMD x2 when i get back can also try it out on a really old P4 machine i use for retro gaming.
edit: debugging threaded functions can be a real pain in the ... especially when one thread zombies out and takes the whole shebang down with it before the debugger can attach itself :S.

[qbism]

I appreciate additional machine type tests
Current status- GDI video.rowbytes mix-up seems to be solved. Threaded warp code is removed. Not sure if it was part of the problem, but there was no speed benefit on test systems up to an icore5. Icore7 could be tested by setting thread cvar between 1 and 8. Hopefully will get a new build up this weekend.

[revelator]

Ok tested on the machines i have and no problem this side (though i use a newer build of open watcom for compiling).

Open Watcom 2.0 still in beta but there are daily changes on github so bugs might be fixed that could have caused crashes before.

[cubanraul]

[qbism]

Build 193 is up. It should be an improvement. I can still replicate this crash... but only at one resolution setting! It occurs in both TDM-GCC and Watcom builds so it's not a compiler quirk. I've found that it happens even at a different initial r_wateralpha setting. The key is to change it before jumping in the water.

Of course this all goes away by setting vid_ddraw cvar to 1. Fascinating.

Threads are gone, asm is back, and fog is faster. It's still the same post-process fog with some clean-up, not drawspan fog.