GMS 2 Debugger Producing Different Results to Running Game Normally

Spilt_Inc

Member
Hi,

I'm hoping I'm posting in the right place but it's my first time posting here, so any guidance at all will be appreciated.

I've been coding a quiz game in several answer boxes (each eventually to represent a player) are present to enter text (answers to a given questions) into. Should the majority of the players type in the correct answer to these boxes, a line of text should appear as a reward (the text being a clue relating to the overarching game). Should all players be correct, the game should reward them with 3 lines of text, each drawn in a list formation.

When I run the game normally and simulate 3 players answering correctly, the build draws 11 lines of text and I can't yet tell why.

The bug itself is one thing. However, my true issue is, when trying to debug, I am met with completely different results to when running normally. A breakpoint in one place in the code leads to a single line of text being drawn. But simply moving that break point to another line of code results in no lines of text being drawn at all. At no point do I alter the code to produce these different outcomes.

My question is: are there cases which cause the debugger to behave differently to running normally? If so, how can I get the two to synchronise?

I'm probably missing something staggeringly obvious, but I've got no idea what it would be. I've tried looking for other similar issues in the forum, but found nothing as yet. If something exists, please point me there!

Any help would be great.

Thanks
 

Nidoking

Member
The bug itself is one thing. However, my true issue is, when trying to debug, I am met with completely different results to when running normally. A breakpoint in one place in the code leads to a single line of text being drawn. But simply moving that break point to another line of code results in no lines of text being drawn at all. At no point do I alter the code to produce these different outcomes.
Is the breakpoint in the Draw event, perchance? Resulting in a different number of lines having been drawn when the game breaks, depending on how much of the Draw event has run up to that point?
 

Spilt_Inc

Member
Is the breakpoint in the Draw event, perchance? Resulting in a different number of lines having been drawn when the game breaks, depending on how much of the Draw event has run up to that point?
One of the breakpoints is in the draw event, yes. However, when I run the debugger until it hits the breakpoint then press the dubug's play button again, the build continues to run (as I have the answer-check set to trigger only when I click the left mouse button) and, again, it will draw a different number of lines of text than running normally.

Am I interpreting your response right?

Thanks for your reply, btw.
 

chamaeleon

Member
I would recommend starting to add a bunch show_debug_message() statements that tell what code paths executes (inside if code blocks or else code blocks, inside iterative statements like for or while, messages before and after such things to make sure I know the program is executing code surrounding these statements in the first place, etc.) and why (what variables and expressions contributed to the code path being taken, and how are they different from what I expected). What I like about this approach is that I get the same output over and over for the same debug messages every run, and I simply add more until I have a sufficiently clear picture why the program does what it does.
 

Nidoking

Member
One of the breakpoints is in the draw event, yes. However, when I run the debugger until it hits the breakpoint then press the dubug's play button again, the build continues to run (as I have the answer-check set to trigger only when I click the left mouse button) and, again, it will draw a different number of lines of text than running normally.
If the breakpoint is in a Draw event, then some things will have drawn and some things will not have drawn. Some things might be in the middle of drawing. Suppose that there are supposed to be three draw_text calls, and you put a breakpoint between the first and second lines. All three lines may well be drawing each frame, but because you have stopped execution after one draw_text, you will only see one drawn line of text on the screen while the program is stopped. The other two lines will draw after you resume execution, then be erased when the next Draw event starts, to be drawn again as the Draw event executes.

Don't expect breakpoints in Draw events to give you meaningful results, because they won't.
 

Spilt_Inc

Member
I would recommend starting to add a bunch show_debug_message() statements that tell what code paths executes (inside if code blocks or else code blocks, inside iterative statements like for or while, messages before and after such things to make sure I know the program is executing code surrounding these statements in the first place, etc.) and why (what variables and expressions contributed to the code path being taken, and how are they different from what I expected). What I like about this approach is that I get the same output over and over for the same debug messages every run, and I simply add more until I have a sufficiently clear picture why the program does what it does.
I haven't had a chance to work on anything for a week, but if this approach gives the same debug results then I am very glad for the guidance. Thank you very much!
 

Spilt_Inc

Member
If the breakpoint is in a Draw event, then some things will have drawn and some things will not have drawn. Some things might be in the middle of drawing. Suppose that there are supposed to be three draw_text calls, and you put a breakpoint between the first and second lines. All three lines may well be drawing each frame, but because you have stopped execution after one draw_text, you will only see one drawn line of text on the screen while the program is stopped. The other two lines will draw after you resume execution, then be erased when the next Draw event starts, to be drawn again as the Draw event executes.

Don't expect breakpoints in Draw events to give you meaningful results, because they won't.
Ah, well that would explain it. Thank you for walking me through that, I really appreciate it.
 

rwkay

YoYo Games Staff
YYG Staff
Also you have to bear in mind that when rendering is happening the GMS2 runtime is preparing the instructions for the GPU to render on the next frame and the rendering has not started yet, it will also be rendered to an offscreen surface (even when application_surface is disabled, it will be rendered to the backbuffer) this will not be shown until the GPU has finished rendering when the frame of instructions has been sent (the whole frame is submitted at once, at the end)

Russell
 
Top