Bug fix - Framerate-independent Damage and Bonus shifts

[mh]

[taniwha]

I've implemented this too in qf. Still can't push

I couldn't see any difference, but qf is still locked to 72fps and thus might not cause as much trouble. But then, not seeing any difference might be a good thing: I didn't break anything in the process

[Spike]

my concern with this is that stuffcmd(player, "bf\nbf\n") no longer results in brigher bfs. most noticable when picking up lots of items near each other.
personally I find just using a float instead of an int in the cshift_t struct works sufficiently well. Sure, there might be minor precision issues, but there are identical minor precision issues all over the quake engine that it doesn't really matter, so long as the value tends towards 0 instead of infinity.

[mh]

Hmmm - I don't see multiple subsequent bfs having that effect in ID Quake either.

In fact V_BonusFlash_f explicitly sets the colours and percent rather than accumulating them, so a new bf will just put them back to the starting values and won't make them brighter (otherwise they would be +=, not =).

Another silly bug with the original code is that the colours will still fade even if the client is paused. Even if nothing else they should use cl.time - cl.oldtime and not host_frametime.

[r00k]

Hmm, I can not replicate this bug. Ive set maxfps 72 -> 200 -> 500, with b bound to "bf" and spam it and it doesnt seem to fade slower/faster. I do notice vid_vsync 0 causes a screen tear but, thats normal.

[mh]

[revelator]

[Spike]

most compilers don't care if you leave trailing fields uninitialised inside structs.
some warn, because they're overly paranoid (gcc with -Wextra or -Wmissing-field-initializers), but C does not require it.

content-based colour shifts do not fade, so the added initial/time fields are not used in this case iiuc. the bugfix is really just for bonus+damage shifts as these are the only two that actually drop the flash percentages over time.

[mh]

[revelator]

All versions of gcc after 4.5 will throw this warning, can't say if correct or not but i doub't that if it was not that they would leave it in ?
since others before me have mentioned this behaviour.

Does make sense though gcc may becomming a bit to strict, atleast its not a compiler error yet

[revelator]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119

ancient bug it seems, still not fixed because the patch that was proposed needs further work.

also seems to be a problem because newer versions of gcc actually use the c++ compiler to do most C code, in fact after the first bootstrap of a gcc build g++ takes over building the remaining passes.

Gah

[revelator]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21033

second one i ran into was excess elements in scalar initializer, seems this one stems back from the gcc-3 days yikes.

So a good guess is that it will newer be fixed cause the gcc devs see the warnings as a feature to tell developers to check there code for possible errors.

Sadly this warning cannot be turned off.

[revelator]

Omg and it's totally random when this turns up, i just tried this tutorial on another engine and hello ? no warnings
but in another one -> joequake it also throws this. No adverse effects anyway so id flags this as a gcc fuckup of major dimensions but good luck getting them to fix it