Home/ Questions/Q 146657
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T08:38:32+00:00

I’m working on a game and I’m currently working on the part that handles

  • 0

I’m working on a game and I’m currently working on the part that handles input. Three classes are involved here, there’s the ProjectInstance class which starts the level and stuff, there’s a GameController which will handle the input, and a PlayerEntity which will be influenced by the controls as determined by the GameController. Upon starting the level the ProjectInstance creates the GameController, and it will call its EvaluateControls method in the Step method, which is called inside the game loop. The EvaluateControls method looks a bit like this:

void CGameController::EvaluateControls(CInputBindings *pib) {     // if no player yet     if (gc_ppePlayer == NULL) {         // create it         Handle<CPlayerEntityProperties> hep = memNew(CPlayerEntityProperties);         gc_ppePlayer = (CPlayerEntity *)hep->SpawnEntity();         memDelete((CPlayerEntityProperties *)hep);         ASSERT(gc_ppePlayer != NULL);         return;     }      // handles controls here }

This function is called correctly and the assert never triggers. However, every time this function is called, gc_ppePlayer is set to NULL. As you can see it’s not a local variable going out of scope. The only place gc_ppePlayer can be set to NULL is in the constructor or possibly in the destructor, neither of which are being called in between the calls to EvaluateControls. When debugging, gc_ppePlayer receives a correct and expected value before the return. When I press F10 one more time and the cursor is at the closing brace, the value changes to 0xffffffff. I’m at a loss here, how can this happen? Anyone?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Are you debugging a Release or Debug configuration? In release build configuration, what you see in the debugger isn’t always true. Optimisations are made, and this can make the watch window show quirky values like you are seeing.

    Are you actually seeing the ASSERT triggering? ASSERTs are normally compiled out of Release builds, so I’m guessing you are debugging a release build which is why the ASSERT isn’t causing the application to terminate.

    I would recommend build a Debug version of the software, and then seeing if gc_ppePlayer is really NULL. If it really is, maybe you are seeing memory heap corruption of some sort where this pointer is being overridden. But if it was memory corruption, it would generally be much less deterministic than you are describing.

    As an aside, using global pointer values like this is generally considered bad practice. See if you can replace this with a singleton class if it is truly a single object and needs to be globally accessible.

    • 0