Is there a way to make show_debug_overlay() larger?

[CruelBus]

I can read it just fine in a Windows VM environment, but when I compile to Android YYC, it's so small, I can't read the page flips and batches.

Is there some way to scale the output of that feature or is there a way to access the number of page flips and batches to be desplayed?

Thanks for your time.

 

[FoxyOfJungle]

Unfortunately, no. I would also like it to be possible to move this... On phones with rounded edges, it's hard to see the FPS..

 

[Nocturne]

Tbh, this seems like something that could be added... simply place a scalar optional argument in the function, like "show_debug_overlay(true, 2)" to show it scaled up twice (and auto-adapting to the width of the display to match). I'd file a bug report suggesting this and explaining in as much detail possible why this is important and useful to devs.

 

[HalRiyami]

Tbh, show_debug_overlay is such an odd function. It feels like it should've been supplemented with functions to better visualize the frame time breakdown. I wish we had a get_cpu/gpu_time functions so we can draw them ourselves (it would be much more informative to know that 80% of my frame is taken by the draw event, and 15% by the step event, than to look at the bar and attempt to infer from it). What I'm saying is that every single single element shown can have its own dedicated function.

 

[Nocturne]

Suggest it too! Nothing stopping you filing suggestions for functions like this, especially if they are of general benefit to all developers. Just make sure to supply as much information as possible about how you want the function to work and the justification for adding it. YYG are very receptive to this kind of thing, especially if it's a "small" feature (relatively) that can have a benefit to a large portion of users.

 

[JeffJ]

I would add to that suggestion the option of changing the position of where to display the values. Maybe even what values to display / not display.

 

[Roldy]

Tbh, show_debug_overlay is such an odd function. It feels like it should've been supplemented with functions to better visualize the frame time breakdown. I wish we had a get_cpu/gpu_time functions so we can draw them ourselves (it would be much more informative to know that 80% of my frame is taken by the draw event, and 15% by the step event, than to look at the bar and attempt to infer from it). What I'm saying is that every single single element shown can have its own dedicated function.

This. No need to modify show_debug_overlay if they would just expose the data and let people draw/analyze the stats directly.

 

[HalRiyami]

I have made the suggestion to YYG already and I urge everyone here to do the same. The more people suggest a feature, the more likely it gets implemented.
I tried to make my case for the suggestion and if you want, you can read it in the spoilers below:

Spoiler: Description

I would like to propose a small set of debug functions. "show_debug_overlay" has been the go to function when testing and is irreplaceable as even the debugger does not show the information this function does. As per the manual, the debug overlay shows the following information among others:
- Number of texture swaps
- Number of vertex batches
- The update speed of the step event
- The time required for the draw event

While I believe every single piece of information presented by the debug overlay is uniquely useful and deserves its own function, I would like to propose the following complementary functions as they seem like the most useful:
get_cpu_time - Returns (real) the time in microseconds spent by the CPU in the last frame (This could either be time taken by the step event or the entire time spent by the CPU including garbage collection and others, though singling out the step event is more useful).
get_gpu_time - Returns (real) the time in microseconds spent by the GPU in the last frame (I believe this should include all draw related events such as GUI and pre and post draw).
gpu_get_texture_swaps - Returns (real) the number of texture swaps
gpu_get_vertex_batches - Returns (real) the number of vertex batches

I believe these are fairly simple to implement as the data is already being collected by GMS2 and the functions would only be providing methods to return the individual data.

Spoiler: Benefit

I sincerely believe that these functions would greatly improve the everyone's ability to debug their game or system. One of my major gripes with the debug overlay is that I often find myself wondering how much time is the GPU really taking as opposed to inferring from the bar (it is really easy to confuse the colors).

The proposed functions provide several benefits:
1. The bar colors are not color blind friendly. With these functions, we can circumvent the need for the bar entirely.
2. The overlay being fixed means we have to live with missing info when debugging on mobile due to rounded screens. Displaying the data wherever we want, however we want, circumvents this issue.
3. Since the info is displayed using the default font, it is too small to be legible on mobile. Similar to point 2.
4. Being able to tell that 80% of the frame time is taken by the GPU (dividing get_gpu_time() by delta_time) and 15% by the CPU informs us better on how the load is split and as such, load balancing becomes easier since we have tangible data to back it up.
5. As it stands right now, the overlay is an all or nothing feature, but when debugging we often want to debug individual elements in our projects. If I want to work on improving draw calls, I only need texture swaps and vertex batches.
6. Some specific features require knowing both CPU and GPU times such as Dynamic Resolution and a Particle optimizer.

Overall, I can't think of any reason why giving us control on what, where, and how we display debug info would be harmful in any way. I would highly appreciate if you take this suggestion into consideration and give us those functions.

If you want to make the suggestion and don't want to write the whole thing, just copy mine.

 

[sp202]

I wish we had a get_cpu/gpu_time functions so we can draw them ourselves

Theoretically 1/fps_real should give you CPU time and 1/fps-1/fps_real should give you GPU time.

 

[HalRiyami]

Theoretically 1/fps_real should give you CPU time and 1/fps-1/fps_real should give you GPU time.

I don't think this is true. From the manual pages of fps and fps_real, the only difference between them is that fps is capped at room speed while fps_real isn't. In fact, I wouldn't be surprised if neither really returns the CPU time but returns the total fps (CPU + GPU).

 

[sp202]

I don't think this is true. From the manual pages of fps and fps_real, the only difference between them is that fps is capped at room speed while fps_real isn't. In fact, I wouldn't be surprised if neither really returns the CPU time but returns the total fps (CPU + GPU).

fps_real only measures CPU usage. You can see this for yourself by uncapping your framerate by using a large room_speed and using a heavy shader or making the game GPU-limited in some way, fps will be far below fps_real. If however you make your game CPU-limited, fps_real and fps will report essentially the same value.

 

[HalRiyami]

fps_real only measures CPU usage. You can see this for yourself by uncapping your framerate by using a large room_speed and using a heavy shader or making the game GPU-limited in some way, fps will be far below fps_real. If however you make your game CPU-limited, fps_real and fps will report essentially the same value.

Oh I didn't know that. I still prefer a descriptive function or built-in variable for each.