Game Crashes on Level 9

Crash Log - https://gitlab.com/snippets/1720475

Tested on latest git build. There is a chance that this is due to my system configuration, I will run some more games with this exact same system configuration and find out if it is crashing in only AstroMenace.

The game crashes on level 9, at semi-random times?

Crash log was saved by running "astromenace >out 2>&1"

AMDGPU - Radeonsi Mesa 18 - ARCH

(As an aside, enabling GLSL with shadows off brings my FPS down from 750 to 15. Then enabling 8x8 increases it to 50. Very strange. Every other graphics setting I can run at max. RX480, Ryzen at 4 ghtz.)

Another thing, level 9 is almost impossible at %143 difficulty, Maybe enemy missiles need nerfing and enemy lasers need to be buffed?

The game crashes on level 9, at semi-random times?

I don't have such info, and can't reproduce this crashes. But clang-static-analyzer tell me about 3 memory-related issues in collision detection code, so...

Unfortunately, log is useless in this case.
Is it possible for you launch game with debugger? It show you exactly point of issue in code.
You can do it easy with QtCreator with GUI, for example.

Btw, in 2007 I had a lot of issues with opensource ATI drivers... for example, drivers could crashes on glDrawArrays() call, but work fine with glDrawElements() with same data. Have no idea why.

As an aside, enabling GLSL with shadows off brings my FPS down from 750 to 15. Then enabling 8x8 increases it to 50. Very strange.

Hmm... strange. Same shaders are used in both cases, but in case of shadow used another "if-else" block with more calculations.

Another thing, level 9 is almost impossible at %143 difficulty, Maybe enemy missiles need nerfing and enemy lasers need to be buffed?

As I know, with proper ship you can do it in easy way. At least my brother told me, that only 14 and 15 levels are hard on 150%. Weapons will be revised, and missiles too, but in next game version (I hope so).

I have installed QtCreator and I used that to compile the debug build. I managed to reproduce the problem twice, but I still must research how to find the data, it seems to just show me the same things that were in the console.

I recorded a video and checked it, and the game freezes exactly when a missle hits the ship, just before it explodes. Though, another time I think it happened when a pulse weapon hit. Maybe just collision detection problem?

The fix for the cursor has an unintended side-effect, the game holds onto the cursor when it freezes, so I can't check all the qtcreator info, only the last screen that was active. (Edit: Other full screen programs cannot alt-tab either, this whole problem might be only on my system.) After a freeze I can ctrl-alt-f1 and then restart normally. The system doesn't freeze, only the game.

I have installed QtCreator and I used that to compile the debug build. I managed to reproduce the problem twice, but I still must research how to find the data, it seems to just show me the same things that were in the console.

https://www.youtube.com/watch?v=B7UsWtyhXh4
In your case, you need start the game with "Start Debugging" button and wait for crash.
The debugger info with Level/Function/File/Line are most interested here (after crash), not "Application Output" itself.

I recorded a video and checked it, and the game freezes exactly when a missle hits the ship, just before it explodes. Though, another time I think it happened when a pulse weapon hit. Maybe just collision detection problem?

This could be one of them, since we know for sure 3 still are not fixed, and will be fixed only after object management code will be refactored. I will refactore all code, but I need time.

The fix for the cursor has an unintended side-effect, the game holds onto the cursor when it freezes, so I can't check all the qtcreator info, only the last screen that was active. (Edit: Other full screen programs cannot alt-tab either, this whole problem might be only on my system.) After a freeze I can ctrl-alt-f1 and then restart normally. The system doesn't freeze, only the game.

You could comment this lines with "//" in order to prevent cursor grab:

astromenace/src/game/game.cpp

Line 626 in 8bc056c

SDL_SetWindowGrab(vw_GetSDLWindow(), SDL_TRUE);

astromenace/src/game/game.cpp

Line 1489 in 8bc056c

SDL_SetWindowGrab(vw_GetSDLWindow(), SDL_TRUE);

Debug info: https://gitlab.com/snippets/1721822

I still can't understand, what is wrong with line "x = x * one_over_L;", and why no one reported me a bug during 11 years.

Is it possible on this screen https://gitlab.com/uploads/-/system/personal_snippet/1721822/55a3b305c2540c23b368c2ea91b374ee/data-1.png
show me what values have sVECTOR3D in right top window:
> this 0x7fffffffde4c sVECTOR3D
I am interesting, what x, y, z values are.

Thanks to this issue, I found wrong particle system's emission logic. Fixed now. :-D

Could you please check commit 4bdc477
I think, this issue could be connected to infinity loop in particle system emission code, in GenerateLocationCubeType() (probably, this issue connected to 'Destroyable weapon' option).
I am still worry, why static analyzers say me nothing about this infinity loop...

Nice work! There is no more freezing problem! 👍

But, now there is a different problem. Similar to the other problem, but now Astromenace will close instead of freeze. It happens less often though.

A memory analysis showed me many times "radeonsi", maybe you don't see the problem because the radeon code isn't getting called in your tests, only nvidia? I will run again and look more closely, when I ran the analysis it was an accident. I will try with valgrind + GDB and then try clang.

I wasn't running the debugger when the close occurred, I will try to reproduce the problem and return with more info.

If I see sVECTOR3D again, I will check the values.

A memory analysis showed me many times "radeonsi", maybe you don't see the problem because the radeon code isn't getting called in your tests, only nvidia?

Yes, I have only nvidia now.

I will try with valgrind + GDB and then try clang.

Yes, please. I need more info about this. I will recheck particle systems code one more time, but, this could be another issue, not connected to previous at all.

The game no longer crashes, I do not know what caused it to crash the other time.

I ran as many other tests as I could to try and find anything, maybe some of this information will be useful.

AstroMenace Function Call Analysis: https://gitlab.com/snippets/1722836

AstroMenace Memory Analysis: https://gitlab.com/snippets/1722837

AstroMenace Compilation Warnings: https://gitlab.com/snippets/1722838

I ran as many other tests as I could to try and find anything, maybe some of this information will be useful.

Thanks!