Now that you have run your game with the debugger attached, you may have noticed that not much has changed. Memory, FPS and Colored Circle: Displays the current memory usage, current frames-per-second (FPS), and the circle will be green when the debugger is attached and the application is running, or red otherwise.Discard Collected Data: While debugging, the debugger will keep the data it collected on its last run, so you can reference it after you've closed the application.Real-Time Debugging: This is a toggle to control whether we want variables to be updated in the debugger while the application is running, or only when it is paused.Step Into, Step Over, and Step Out: These buttons advance our code line by line when the application is paused.Close the Game: This one acts similarly to the one above to stop the execution of the game.Continue, Break, and Restart Game: These buttons let us pause (break) the program, continue to the next breakpoint (or continue execution if no other breakpoints are set), and restart the program.This is what the toolbar looks like:įrom left to right, we have these sections: Let's go over each one of these, and we will go into more detail as we go along in the article. Once you are in the Debugger tab, you will see a set of buttons at the top. If a window isn't showing up, or you closed it by accident, go to Debugger > Windows and there will be a full list of available windows that can be displayed. You can customize the layout of every one of these windows, but here's what mine looks like Once the game launches, you will see a new tab show up at the top of your code editor, and a multitude of other windows opening. However, to launch the game with the debugger attached, you will need to press the Bug icon instead, or you can also use F6. You may be used to launching your game by pressing the Play symbol at the top bar, or by pressing F5. Once you pinpoint the function/section that is running slowly, then you can optimize it. This is where the profiler comes in handy, giving you detailed information about what functions are being called at every stage of the game run-time and compiling the data in a way easy to analyze. Programmers are decent at spotting obvious bottlenecks, but on any application that isn't trivial, it's hard to find them. Profiling is often more useful in the second half of the project when you experience slowdowns in your game due to the amount of objects interacting with each other. It can also show you more advanced information, such as the state of your textures and surfaces, current graphics options, values of buffers, etc. GameMaker's debugger allows you to run your code line by line, checking the values of every variable and their changes along the way. This is fine for quickly debugging a small feature, but when you have many moving parts working together, generating these messages can quickly get out of hand. The first solution that comes to mind is to check the values of variables, or the results of conditional statements, by using debug messages or drawing text to the screen. Then we go back to the code and look at it for 20 minutes thinking it should work. We've all been in that situation where we write code, run the game, and nothing works like expected.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |