Menu

#16 First run problems - openGL crash when firing

v1.0_(example)
open-accepted
Stefano
5
2013-04-06
2013-04-03
Anonymous
No

-Crash caused by bullet texture, ogre.log lines below:

21:48:03: Mesh: Loading Bullet.mesh.
21:48:03: WARNING: Bullet.mesh is an older format ([MeshSerializer_v1.40]); you should upgrade it as soon as possible using the OgreMeshUpgrade tool.

-Elabling DS pirates logging on dsConfig.cfg doesn't work

No other problems, commands (except fire) and sounds run smoothly

Discussion

  • Stefano

    Stefano - 2013-04-03

    The crash seems to happen when shooting - should not be related to the texture, but it would be worth to try what happens with the openGL renderer.

    The warning should not be relevant: all the meshes give it.

    The absence of log may depend on the lack of log statements in the shooting code path.

     
  • Stefano

    Stefano - 2013-04-04

    Confirmd: swithched the test copy to the openGL renderer from the ogre config window and reporoduced the crash.

    Action plan: attempt to workaround using the settings. It may be far too complex to understand what is going wrong "inside" openGL.

    It may be worth to try a more modern version of ogre (but I am not sure if this affects the openGL libraries.

     
  • Stefano

    Stefano - 2013-04-04

    Tweaking the settings did not help.
    Changing the bullet material, the same.

    Running from visual studio (debug/release, with F5) we have a crash (memory exception) at startup!
    (I admit I did not test the openGL rendering since a while...).

     
  • Stefano

    Stefano - 2013-04-04
    • summary: First run problems --> First run problems - openGL crash when firing
    • labels: --> Interface (example)
    • status: open --> open-accepted
     
  • Stefano

    Stefano - 2013-04-06

    Noticed that enabling the IO redirection to a console, normally used only in debug build, solves the crash.

    Debugged after the exception, noticed the "uncatched exception handler" in the stack.
    Added a try-catch with logs.
    The crash is caused by the double deletion of the bullet.
    When the goManager is asked to remove a object and can not find it, it throws.
    E0406 13:35:42.617710 4176 Main.cpp:217] Programming error! Deleting a object not in the goManager!

    This does not occur when using DirectX. Some more logging in the goManager:
    I0406 14:01:41.353865 3780 goManager.cpp:53] Removal of go playerBullets0
    I0406 14:01:41.353865 3780 goManager.cpp:24] Query for go playerBullets0
    E0406 14:01:41.353865 3780 CreatorsUtilities.h:31] Null pointer: go could not return the object called [playerBullets0].

    Only the 1st line is printed when using DirectX or when the output redirection is enabled. Go figure...

     
  • Stefano

    Stefano - 2013-04-06

    Here is one of the problem: the bullet is created inside the ship.

    I0406 14:39:54.687036 3224 Bullet.cpp:50] Bullet end of life by impact playerBullets0
    I0406 14:39:54.687036 3224 Bullet.cpp:61] Colliding: playerBullets0 PlayerSpaceship
    I0406 14:39:54.687036 3224 SpaceShip.cpp:80] Spaceship impact
    I0406 14:39:54.687036 3224 Bullet.cpp:50] Bullet end of life by impact playerBullets0
    I0406 14:39:54.687036 3224 Bullet.cpp:61] Colliding: playerBullets0 PlayerSpaceship
    I0406 14:39:54.687036 3224 SpaceShip.cpp:80] Spaceship impact

    The second problem is that the collision is flagged twice!

    It is a bit absurd to have the issue only on OpenGL, let alone to have it dependant on the debug console. I suspect that those features influences the timing of the operations: the simulation becomes less accurate and we have bogus collisions. But I can not confirm this.

    Worked around by increasing the "safety distance" that separates the spaceship and the bullets. A better way of defining the bullet starting point would help.

     

Log in to post a comment.