qbismSuper8 builds

[mankrip]

Best guess is that it's still related to recent mips optimization.

See if r_drawflat 1 still works.

[Baker]

issue on release build but not debug build ...

The one time I was unfortunate enough to have a "only release build has problem" issue, I felt like going outside and yelling "NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!"

"D O _ N O T _ W A N T ! "

[qbism]

Thanks, r_drawflat 1 check was the ticket. It didn't affect the gray void, which ruled out a lot of things. So with some testing I found the exact build where the debug is broken and am looking at the diff.

Hopefully the "release-only" side of the issue will clear itself up when the boo-boo is found! Otherwise will try the screaming thingy.

[qbism]

squashing bugs!

BUG #1 -"Grey Void"
After many hours of searching, it turned out to be a silly typo. But when chasing these things down, other little needed tweaks appear, so it's not total aggravation. The outcome of the error was that native video aspect was set to 0 in debug build. It was correctly set 1.0 in release builds, which obscured the problem for several builds until debug build was actually played.

Code: Select all

void VID_GetDisplayModes (void)
{
DEVMODE   devmode;
int   i, j, modenum, cmodes, existingmode, originalnummodes, lowestres;
int highestres; //qb: use this as basis for video aspect ratio
int   numlowresmodes, bpp, done;
int   cstretch, istretch, mstretch;
BOOL   stat;
// enumerate > 8 bpp modes
originalnummodes = nummodes;
modenum = 0;
lowestres = 99999;
>>>>typo location >>>SHOULD BE 'highestres', ARGGH!  lowestres = 0;

BUG #2 - crash on savegame load after lava death
This crash only occurred on release build, not debug. Yiikes. Stepping down optimization from -O3 to -O2 in release build makes the bug go away. So the aggressive optimization setting could be the problem, or the setting change just obscures the bug further. I'll probably try setting some fake sys_errors to discover which line it's crashing on, brute force, before releasing a fixed build.

[mankrip]

Quake's video mode changing is a mess anyway. And not everything is recalculated on the correct order, so I'm getting video aspect problems in my engine when switching between some resolutions. Updating the video aspect from the menu fixes that, but is not a true solution.

There's a lot of work to be done on that.

[revelator]

Gcc has a known history of goofing up with agressive optimization
some versions Work some dont so as a rule of thumb i allways use O2 and specific optimization options to rule out the optimization switches that fail.
4.8.0 has a bug with O3 optimization producing bad results i hope 4.8.1 will have it fixed when it comes.

[qbism]

With -O3 I tracked the crash to this loop in D_WarpScreen

Code: Select all

    for (v=0 ; v<scr_vrect.height+AMP2*2 ; v++)
    {
        rowptr[v] = d_viewbuffer + (r_refdef.vrect.y * screenwidth) +
                    (screenwidth * (int)((float)v * hratio * h / (h + AMP2 * 2)));
    }


It doesn't make sense, but along the way I noticed other glitches like missing polys when compiling with -O3 flag, so I'm assigning blame to that unless other issues arrive. BTW, occurs with mingw 4.7 and 4.8.

Quake's video mode changing is a mess anyway. And not everything is recalculated on the correct order, so I'm getting video aspect problems in my engine when switching between some resolutions. Updating the video aspect from the menu fixes that, but is not a true solution.

Agreed... I came up with an effective but hacky automatic solution. Use of "vid.aspect" was confusing me, so I replaced it with "vid_nativeaspect" (yay another global). It's set based on the assumption that the highest detected resolution is the native one. I guess I could switch it back to vid.aspect now. I guess the only point of that would be imaginary multi-display support.

When VID_SetMode is called literally 16 times in vid_win.c, you know it's going to be fun!

[mankrip]

With -O3 I tracked the crash to this loop in D_WarpScreen

Code: Select all

    for (v=0 ; v<scr_vrect.height+AMP2*2 ; v++)
    {
        rowptr[v] = d_viewbuffer + (r_refdef.vrect.y * screenwidth) +
                    (screenwidth * (int)((float)v * hratio * h / (h + AMP2 * 2)));
    }

Well, I've just rewritten the whole screen warping code anyway; the original produced incorrect results in all cases except when running in a 320x240 resolution with "viewsize 120" (in vanilla Quake) or with "viewsize 100; scr_top 0; scr_bottom 0; scr_left 0; scr_right 0; sbar_show_bg 0" (in Makaqu).

It took me weeks to untangle all of the original screen warping code, understand it well enough, rewrite it, fix the bugs and add proper support to multiple resolutions and video aspects. I've still got to test it a little more to be sure that it's perfect.

[szo]

Gcc has a known history of goofing up with agressive optimization
some versions Work some dont so as a rule of thumb i allways use O2 and specific optimization options to rule out the optimization switches that fail.

Many (but surely not all) failures are actually due to bugs in user code. Gcc is as much buggy as are all other compilers out there, but one must be sure of his code's correctness at first.

4.8.0 has a bug with O3 optimization producing bad results i hope 4.8.1 will have it fixed when it comes.

What is the issue you are encountering? (Gcc bugzilla entry?) I compiled quakespasm and uhexen2 with gcc4.8 at O3 and haven't hit an issue yet.

[revelator]

It was very specific ill see if i can dig up the bugzilla id but it was also causing some trouble for me with some code that other compilers handled well.
Btw i hear rumors that lto broke with 4.8.0 on Windows gonna check it tomorrow as its quite late here now

[revelator]

I think it was this one http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56145 i remember i couldnt get the code to run unless i added -fwrapv to the -O3 optimizations, it seems to be caused by the switch from ppl to isl optimization libraries. There was also a bug in current release binutils (cant remember bug id) that caused nm to fail generating symbols for dll builds so the compiler i provide comes with the latest
cvs version which has that fixed (does not affect exe builds so should be fine for quake but better safe than sorry). 4.8.0 still has a rather large list of serious regressions which will hopefully be fixed with 4.8.1.

4.8.0 is neither worse nor better than many compilers in fact gcc mostly does a better job than msvc but this release features a slew of new additions like SSE (64 bit only) so its predictable that there might be some bumps in the road.

[qbism]

I think it was this one http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56145 i remember i couldnt get the code to run unless i added -fwrapv to the -O3 optimizations

-fwrapv didn't get rid of the crash in this case. But removing -march=core2 did work, and produced 1%+ framerate increase in timedemo. Strange! Switching to -O2 works as well but 10% decrease. -O2 without setting -march was only 3% slower. So the -march settings (at least icore2) actually produce slower and sometimes buggier output in 4.80 !? I'm going to try a few other -march options as well.

[szo]

I think it was this one http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56145 i remember i couldnt get the code to run unless i added -fwrapv to the -O3 optimizations, it seems to be caused by the switch from ppl to isl optimization libraries. There was also a bug in current release binutils (cant remember bug id) that caused nm to fail generating symbols for dll builds so the compiler i provide comes with the latest
cvs version which has that fixed (does not affect exe builds so should be fine for quake but better safe than sorry). 4.8.0 still has a rather large list of serious regressions which will hopefully be fixed with 4.8.1.

So it is target-specific (windows)?

... a slew of new additions like SSE (64 bit only)

You mean SEH, right?

... so its predictable that there might be some bumps in the road.

Definitely, yes

[revelator]

target specific aye and aye its SEH was a bit tired when i wrote it.

[qbism]

Bug-fixes. [EDIT]: Just realized runes overlap hud numbers in "sbar 4" mode. Will fix next time.
Automatic hud and centerprint text scaling, from Makaqu 1.6.
sv_cullentities cvar - Reduces network traffic and cheat potential by culling entities that player can't see. On by default. From r00k post.
Built with gcc 4.80 via reckless' cbadvanced + mingw
https://sourceforge.net/projects/qbism/files/latest/download?source=files