Closed Yamagi closed 5 years ago
@Yamagi Could you reproduce this bug?
I have tried with v7.30 and v7.31pre without success. Maybe be need to do some pre requirements? I have to checked with:
map hangar1
noclip 1
<go to place>
noclip 0
<jump to hole>
Hi, sorry for the delay. I was AFK over the holidays. I'm unable to reproduce the problem. But the reporter send me this patch that fixes the issue for him:
--- sw_surf.c.prev 2018-12-22 20:33:44.956516534 +0300
+++ sw_surf.c 2018-12-22 20:32:18.844521717 +0300
@@ -57,6 +57,9 @@
if (!tex->next)
return tex->image;
+ if (!currententity)
+ return tex->image;
+
c = currententity->frame % tex->numframes;
while (c)
{
And another one:
Again, happens only in the software rendering mode:
FYI: I have checked with all versions from initial c43e944a commit. And I can reproduce bug with fan. So its not regression.
I was told in IRC that the fan bug was even in the original client. So I think we should just ignore it if it's not trivial to fix.
Not only the fan glitches out in that room but also part of a wall in certain camera positions. If you switch to the GL renderer you see some z-fighting going on. I haven't looked into how the software renderer works yet but maybe that's part of what's happening with the fan as well? Like the wrong vertices being clipped and the resulting face extended with a vertex to the far right or something.. wall glitch z-fighting
Both GL renderer have gl_zfix
to work around the z-fighting. Just set it to 1 and you're done. It shouldn't be too hard to implement it for the softrenderer.
I tried it and first just did vid_restart
then restart the game but the artifacts are still there. Either gl_zfix doesn't do what it is supposed to or it isn't caused by z-fighting.
I actually found the same artifacts on the fan.
Just to clarify, the picture 'wall glitch' is in sw renderer and 'z-fighting' in gl. It's just curious that those faces where the z-fighting artifacts occur in gl glitch out in sw.
I can't reproduce the crash with 7.41. If someone is still seeing it feel free to reopen the issue.
This was reported by email, I'm just the messenger:
Hello. I would like to report a bug.
yquake2 7.30 crashes in soft rendering mode on maps/hangar1.bsp
How to reproduce a crash:
Attachments: jump.png: location of the hole error.txt: output log yquake2: executable binary save.tgz: save file of the actual playthrough when the crash was observed
Yamagi Quake II crashed! This should not happen...
Make sure that you're using the last version. It can be found at http://www.yamagi.org/quake2. If you do, send a bug report to quake2@yamagi.org and include:
This output
The conditions that triggered the crash
How to reproduce the crash (if known)
The following files. None of them contains private data. They're necessary to analyze the backtrace:
quake2 (the executable / binary)
game.so (the game.so of the mod you were playing when the game crashed. baseq2/game.so for the main game)
Any other data which you think might be useful
Thank you very much for your help, making Yamagi Quake II an even better source port. It's much appreciated.
=======================================================
Product: Yamagi Quake II Version: 7.30 Platform: Linux Architecture: x86_64 Compiler: 7.3.0 Signal: 11
Backtrace: yquake2(+0x724e0) [0x55ad3e6ca4e0] yquake2(+0x726d2) [0x55ad3e6ca6d2] /lib64/libc.so.6(+0x368d0) [0x7fee3c4db8d0] /usr/lib64/yamagi-quake2/ref_soft.so(+0x155dc) [0x7fee244925dc] /usr/lib64/yamagi-quake2/ref_soft.so(+0x1119a) [0x7fee2448e19a] /usr/lib64/yamagi-quake2/ref_soft.so(+0x9858) [0x7fee24486858] yquake2(+0x27a53) [0x55ad3e67fa53] yquake2(+0x22b3c) [0x55ad3e67ab3c] yquake2(+0x1a921) [0x55ad3e672921] yquake2(+0x4efc5) [0x55ad3e6a6fc5] yquake2(+0x4f36e) [0x55ad3e6a736e] yquake2(+0x4f9b6) [0x55ad3e6a79b6] yquake2(+0x9f42) [0x55ad3e661f42] /lib64/libc.so.6(__libc_start_main+0xe7) [0x7fee3c4c6ae7] yquake2(_start+0x2a) [0x55ad3e661fda]
Segmentation fault
error.txt