• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 Feature Suggestion: Editor Draw Event

matharoo

manualman
GameMaker Dev.
So, I already submitted this feature request to YYG, but I wanted to make a thread to share the idea with y'all (and Yal, and YAL).

Basically, objects could have an Editor Draw event. Anything you draw in that event gets drawn in the Room Editor, not in the game.

Here are some possible uses:

1) You could have an object that acts like some sort of a grid, which you could visualize in the Room Editor using this event.

2) (From @Cloaked Games) You could have switches linked to locked doors, and you could show that connection in the Room Editor by drawing a line from the switch to its door instance.

3) You could have variables for the direction and magnitude of an instance's initial movement, which could be represented by an arrow.
(Then you could possibly have an Editor Step/Input event where you could take mouse input directly from the Room Editor and modify the direction and magnitude variables, by modifying the visible arrow.)
 
Last edited:

rIKmAN

Member
These all sound like things that could be implemented ourselves if YYG ever release / document the editor extension API that's been talked about for years.
 

Mike

nobody important
GMC Elder
This is a massive thing to implement. Remember the IDE is written in C#, so not only would you need on the fly script compilation, you'd also have to run the game. You can't get away with just running those events, because there could be variables setup and controlled from other scripts - so you'd need more. You'd also have to handle crashes/exceptions very gracefully, and display "something" if the 💩💩💩💩 hits the fan. Also, if the event gets stuck in a loop, you'd have to be able to stop it without killing the whole thing, meaning you'd need to use the virtual machine, and not just compile it.

All this could slow down the IDE considerably depending on the skill of the end users code. Chances are, you'd need to run this on a thread and take the results over now and then, so that if the code sucked and was really slow - or if they were doing tens of thousands of these in a big room - remember you can zoom out and see everything, it won't kill the IDE.

On top of all that, you'd also need to be able to on the fly texture page creation, as any event will draw sprites, and while it could be simple page creation, you'd still need something like that.

This isn't something anyone could throw in, this is something you'd have to design into a major version release. It's one of those things that sounds nice and simple, but as soon as you think about it for a moment, you realise what a massive task it is....
 

matharoo

manualman
GameMaker Dev.
This is a massive thing to implement. Remember the IDE is written in C#, so not only would you need on the fly script compilation, you'd also have to run the game. You can't get away with just running those events, because there could be variables setup and controlled from other scripts - so you'd need more. You'd also have to handle crashes/exceptions very gracefully, and display "something" if the **** hits the fan. Also, if the event gets stuck in a loop, you'd have to be able to stop it without killing the whole thing, meaning you'd need to use the virtual machine, and not just compile it.

All this could slow down the IDE considerably depending on the skill of the end users code. Chances are, you'd need to run this on a thread and take the results over now and then, so that if the code sucked and was really slow - or if they were doing tens of thousands of these in a big room - remember you can zoom out and see everything, it won't kill the IDE.

On top of all that, you'd also need to be able to on the fly texture page creation, as any event will draw sprites, and while it could be simple page creation, you'd still need something like that.

This isn't something anyone could throw in, this is something you'd have to design into a major version release. It's one of those things that sounds nice and simple, but as soon as you think about it for a moment, you realise what a massive task it is....
I agree, it's not simple at all.
 

Hyomoto

Member
While the "total" idea is a bit rough, I think it does highlight some basic desirability for ways to visualize things in the room editor. For example, perhaps two objects could be "linked" or share some "linked" variable(s) that is visualized in the editor with a line. Or support some basic shapes that, again, are either entirely cosmetic or can perhaps be linked to a variable. I know there's already been some talk over giving more control over how things display in the room editor such as starting sprite index etc... These types of suggestions are really just about enhancing how we visualize certain things in the room editor, and while there are always going to be hail Mary suggestions, there are pieces that still make sense and are desirable.
 

GMWolf

aka fel666
On top of all that, you'd also need to be able to on the fly texture page creation, as any event will draw sprites, and while it could be simple page creation, you'd still need something like that.
Nah, texture pages are kinda obsolete these days, at least if you target newer API levels.
You could have array textures and just fill each layer.
You could use sparse textures.
Bindless is also an option.
So there, of the top of my head, three simple ways to get around texture pages.

Oh and of course, you could just break the batch for every texture, or use the existing texture pages from previous builds.

Remember the IDE is written in C#, so not only would you need on the fly script compilation, you'd also have to run the game. You can't get away with just running those events, because there could be variables setup and controlled from other scripts - so you'd need more.
You could run GML just from the AST. So just parsing and interpreting. Not that bad.
And as for the other thing. You could have editor events. Like, editor create, editor draw, editor step, editor mouse and keyboard events.
Take a page out of unity's editor scripting book ;)

All this could slow down the IDE considerably depending on the skill of the end users code. Chances are, you'd need to run this on a thread and take the results over now and then, so that if the code sucked and was really slow - or if they were doing tens of thousands of these in a big room - remember you can zoom out and see everything, it won't kill the IDE.
Yep.

This isn't something anyone could throw in, this is something you'd have to design into a major version release. It's one of those things that sounds nice and simple, but as soon as you think about it for a moment, you realise what a massive task it is....
It's a big task but it would add far more functionality than YYG ever could add themselves.
I mean, timelines could be implemented that way.
Tilemaps could have been implemented that way too.
Really all sorts of features could be worked in to the editor by users once we get editor scripting support.

These all sound like things that could be implemented ourselves if YYG ever release / document the editor extension API that's been talked about for years.
This!
One of the reasons I got GMS2 was for the promised editor extension support.
That and the teased other language that never made it either.
I do feel a little cheated but that is my fault I guess.
 

Mike

nobody important
GMC Elder
Nah, you still want some form of texture page, but as I said, it could be much simpler - even a simple POW2 fitting would be fine. I was just emphasising that you'd need to have some kind of dynamic page generation. You defiantly don't want to break on every quad you submit.

No, tilemaps had to be done natively to get the speed. When dealing with large rooms, and "many" layers of tilemaps, you need that speed. If you only use a single layer or so, you might get away with it. But tilemaps were designed to be very quick so you could abuse them a little.

I expect timelines to go away once sequences appear..... they're horrible.

Yes, you could add more events and that would help and stop you having to run "the game", but you still have to deal with bad code, stuck loops, crashes and the like.

I suspect you'd be better doing a c# plugin than this - yes, once the API is released, whenever that is....


I'd do shader support in the IDE long before any of this. They are self contained, and you could more easily do them - though it's still a large task.
But in the end.... there's a load of other things I'd do before making the contents of the room editor look prettier. :)
 

GMWolf

aka fel666
But in the end.... there's a load of other things I'd do before making the contents of the room editor look prettier. :)
It's not about making it pretty.
It's about adding new editing functionality.
For instance, you could add new path systems (to use whatever curve you like).
Or define arbitrary shapes.
You could add text to the room.
You could do sequences too.
UI! We could implement UI editors!!!
Yeah, the list goes on.

Agreed though, a c# API would be much nicer.
In fact forget GML, c# as scripting would be ace! Probably would be less work longer term. Ghaa who am I kidding, I don't really care....
 

Mike

nobody important
GMC Elder
It's not about making it pretty.
It's about adding new editing functionality.
For instance, you could add new path systems (to use whatever curve you like).
Or define arbitrary shapes.
You could add text to the room.
You could do sequences too.
UI! We could implement UI editors!!!
Yeah, the list goes on.

Agreed though, a c# API would be much nicer.
In fact forget GML, c# as scripting would be ace! Probably would be less work longer term. Ghaa who am I kidding, I don't really care....
Sure.... but this is why we created the "plugin" architecture in the first place. Nothing to do with adding these events etc to objects, but letting you add core features to the IDE.

The room editor from memory allows it's own plugins, as does the image editor. Outside that, you have the basic plugin system to add whole new editors. But as I've said before, it's all about documentation - and being able to safeguard peoples work if they use a plugin.

But this was more than a year ago now.... A lot will have changed, so who knows if it's still even on the cards.
 

JeffJ

Member
A much simpler and more limited way to get similar results would be to allow each object to have an "editor sprite" - a sprite that would only show up in the room editor. If no such sprite was defined (only regular sprite), then that would be shown in the editor (and if neither were defined, then it would show up as the usual "no sprite" default).

Granted, you couldn't do any animated or coded stuff, but it would get you some of the way, and without all the headaches Mike pointed out.

This way, you could even do a completely separate texture group for editor sprites only. A really nice feature on top of this would be an option to disable/remove such a group from compiled builds if they were not needed for actual gameplay.
 

TsukaYuriko

☄️
Forum Staff
Moderator
You can do a lot of this already.


Create a sprite folder, object folder and texture group named "Room Editor". Assign all sprites from said folder to said texture group. Set the texture group to not export to any target platform.

Create a new object named par_roomeditor. Create individual objects for each room editor annotation and assign sprites to them accordingly. Set their parent to par_roomeditor.

In par_roomeditor, upon creation, destroy the instance. Alternatively, make a "Room Editor" layer, put all room editor annotation instances on it and delete the layer when the room starts.
 
I feel like the room editor is lacking, in terms of showing GUI or just draw events.

The biggest struggle I face with my projects is spending a lot of time editing GUI/object positions, even when I use GMLive.

Some sort of GUI editor would be very appreciated. Unless if everyone knows something that I don't to making GUI/object editing faster/easier.

Editing your GUI or draw events in the IDE of the room editor and then being able to toggle it on/off with it initially being deactivated would be a dream, in my opinion.
 
Last edited:

Mike

nobody important
GMC Elder
A lot of the GUI issues will go once sequences are here I suspect. It's gonna be a pretty big upgrade........ in fact, you're not gonna believe what you can do with it.
 
A lot of the GUI issues will go once sequences are here I suspect. It's gonna be a pretty big upgrade........ in fact, you're not gonna believe what you can do with it.
And here I thought sequences was aimed towards absolute beginners who don't know how to use the lerp() function. There is so little information on sequences that it is hard to tell how it will benefit everyone, lol.

I don't know what exactly sequences is, but if it solves GUI issues/workflow, then I am going to be hyped! (I actually don't have a clue how sequences will solve the GUI workflow issues either, since isn't sequences just a timeline where you can animate an object's x/y/scale/rotation??)

Well, in about a month we will finally get to see what sequences is going to give us. :)
 
Last edited:

Toque

Member
And here I thought sequences was aimed towards absolute beginners who don't know how to use the lerp() function. There is so little information on sequences that it is hard to tell how it will benefit everyone, lol.

I don't know what exactly sequences is, but if it solves GUI issues/workflow, then I am going to be hyped! (I actually don't have a clue how sequences will solve the GUI workflow issues either, since isn't sequences just a timeline where you can animate an object's x/y/scale/rotation??)

Well, in about a month we will finally get to see what sequences is going to give us. :)
That would be good. Im not exactly clear what sequences will actually do..............
 
Top