• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Legacy GM [solved] - (possibly dumb) drawing to the GUI Layer question

JackTurbo

Member
Hi All,

New to the forum and I'm pretty new to GMS too (having only gotten it in the humble bundle).

I am already making good progress and am working pretty much 100% in GML. I think I'm getting a good handle on most things (in large due to the wealth of resources available), however despite having read yoyo's documentation on draw gui many times, I've some questions about drawing to the GUI Layer.

Is it only possible to draw to the Gui layer in an objects GUI Draw event?

And if (as I suspect) the answer is yes, am I doing the correct thing by having objects without sprites directly defined that instead draw the relevant sprite in drawgui event? - Because if I define the sprite directly in the object it gets drawn to the game layer.

Also this presumably means I cannot directly draw to the Gui layer from within scripts? - so if I were to want to do something like this, I guess I'd want to create a variable in an object's gui event and instead manipulate that variable from the script?

Thanks for any help and sorry if the questions are bit stupid.
 
R

renex

Guest
You do need in fact to use a draw gui event to draw to the gui layer, but nothing's stopping you from calling a script on a draw gui event.
 
It's really nice to have a GUI layer, but it's also a bit tricky to work with it. Just mind that the GUI layer has its own coordinate system.

If you add a sprite to an object and that object has no (non-GUI) draw event, the object will draw itself to its x and y position inside the room. Same behaviour if you have a draw event and write draw_self(); somewhere in that events code.

The GUI layer however won't move with the room. That's the whole deal about a GUI layer after all. So draw_sprite([sprite], [subimage], x, y); will not work as intended when the game window (=view) is larger than the room.
Upper-left corner of the GUI Layer is obviously 0,0 and
lower-right corner would be display_get_gui_width(), display_get_gui_height();

Also as far as I remember the gui layer is by default as large as the application surface and the application surface is by default as large as the first room (or view?) for the rest of the game. You can manually change the application surface size with
surface_resize(application_surface, [width], [height]); (i.e. if you want to change resolution)
and the gui size with
display_set_gui_size([width], [height]);
 

JackTurbo

Member
Thanks for the responses guys, although I'm not sure I explained my issues too well.

I've already been using an object called oCameraControl which handles all my view, viewport, window and resolution stuff. By default this sets the game to full screen and then uses display_get to set the view, viewport and gui layer to the display's dimensions. This seems like a logical approach to me and thankfully is working predictably so far.

I've also created a basic debug panel that toggles display of important values like gui resolution, mouse x/y position relative to the room, mouse x/y position relative to the gui layer etc, which has already proved itself invaluable.

I'm working on a turn based strategy prototype, and my most recent undertaking has been moving all of the UI/hud stuff up to the GUI layer. This is largely because I want to use big rooms that the player explores using edge pan and/or drag panning, so need the hud to be static.

I've got 95% of it done and working as intended, however I was more questioning if my approach was the best way?

A lot of my ui elements are spawned by the various objects and scripts in play. On a character's turn for example the character object runs a script that looks up their abilities and spawns the relevant buttons with instance_create.

If these buttons have a sprite defined however these get drawn to the game layer, even if the button object only has a gui draw event. To get around this issue I've removed the sprite from the object itself and instead in the button's drawgui event, used the draw_sprite function to draw the sprite. - now, I know this works, but does this approach make sense? is this an efficient approach, or is there a better way?


Thanks again for the responses and sorry for the long post. :)
 
afaik that's the way to do it.

As mentioned the sprite of an object gets drawn to the room if you don't have a normal draw event. If you want to draw a sprite in the Draw GUI event you don't assign a spite to the object and you use draw_sprite in the Draww GUI event. If I understand you correctly that is what you did.

In case you want to assign a sprite to an object for whatever reason (i.e. if you place the object in the room editor and want to see it better for layout purposes) but you only draw it to the GUI instead of to the room:
You can add a draw event and put a comment with no code in it. That will prevent the sprite from being drawn to the room.
And then get the objects sprite id in the draw GUI event: draw_sprite(sprite_index, [subimage], [gui x], gui y]);
 

JackTurbo

Member
Thanks Reverand.

While I am very new to GML and GMS, I am starting to get pretty confident.

However I guess I am just very aware that there is lots that I do not know, and to a degree that is undermining that confidence. Good to hear that I'm on the right track in this instance though!
 
Top