The debugger contains a nice feature for viewing current surfaces, as well as indicating the creation/resizing/freeing of individual surfaces on the Graph.
However, if a project has a number of surfaces active at once, it can be hard to be sure which surface is which. This is especially a problem when looking through the surface viewer if multiple surfaces are blank currently:
Describe the solution you'd like
Add an optional argument to surface_create() called [debug_name] or something similar.
Alternatively a new function surface_set_debug_name( surface_id , debug_name ), though this would not allow game maker to print the name on the create event in the Graph.
Either way, this would allow game maker to assign an internal name to the surface, which could then be shown alongside its id number in the debug windows.
Describe alternatives you've considered
For creating/resizing/freeing of surfaces, you can print to the console a message describing the surface that the action takes place on. This is more clunky and is harder to read on the debug graph though, especially if you create/free multiple surfaces in a short time.
The only way to easily narrow down surfaces in the surface viewer is to remove surfaces from the game one by one, but that can often be difficult if major systems rely on those surfaces to function.
the same could also be requested of data structures and buffers. alternate solutions would be better, or more realistically a plug in with new ide would make this more reasonable.
Is your feature request related to a problem?
The debugger contains a nice feature for viewing current surfaces, as well as indicating the creation/resizing/freeing of individual surfaces on the Graph.
However, if a project has a number of surfaces active at once, it can be hard to be sure which surface is which. This is especially a problem when looking through the surface viewer if multiple surfaces are blank currently:
Describe the solution you'd like
Add an optional argument to
surface_create()
called[debug_name]
or something similar.Alternatively a new function
surface_set_debug_name( surface_id , debug_name )
, though this would not allow game maker to print the name on the create event in the Graph.Either way, this would allow game maker to assign an internal name to the surface, which could then be shown alongside its id number in the debug windows.
Describe alternatives you've considered
For creating/resizing/freeing of surfaces, you can print to the console a message describing the surface that the action takes place on. This is more clunky and is harder to read on the debug graph though, especially if you create/free multiple surfaces in a short time.
The only way to easily narrow down surfaces in the surface viewer is to remove surfaces from the game one by one, but that can often be difficult if major systems rely on those surfaces to function.
Additional context
No response