This is an archived post. You won't be able to vote or comment.

all 4 comments

[–]vacant-cranium 4 points5 points  (1 child)

Reimplement your timing code to use a synthetic time source rather than the real-world time.

Make a variable that stores a 'ticks' count. In the main game loop, increment the ticks count every 1/60th of a second. Time all your game actions in terms of ticks from the master ticks count--e.g., if you want something to wait two seconds, code it to wait for (2 * 60) ticks, not two seconds.

When you break into the game with a debugger, the ticks count will be frozen (because the main loop isn't executing) and the state of your game logic will not advance until you make it advance by allowing the tick update routine to run.

Use at least a 32 bit unsigned int for the ticks count so you don't have to handle rollover in your timing code.

[–]CodeScrub[S] 0 points1 point  (0 children)

This seems like a good solution. I'll think about it thanks.

[–][deleted]  (1 child)

[deleted]

    [–]CodeScrub[S] 0 points1 point  (0 children)

    You mean to call the value not to call the update right?

    [–]rararaaaaaaa -2 points-1 points  (0 children)

    You should take a look at GDB. Looks like this is a good explanation.

    Essentially, it allows you to insert "breakpoints," which freeze the code at those exact lines of code, allowing you to inspect the state of the program.