Flipping, scaling and rotating instances

[egofree]

I would like to add for each instance the following fields : Scale X, Scale Y, Flip X, Flip Y, Rotation and Alpha. It's the same fields as in GM Studio. I think to add them in the 'Edit instance 'group below the x,y fields. This means i would decrease a little bit the size of the instances list.
TheExDeus said it would be possible to do this in the creation code of the instance. First i want to check if it's possible to do it with EDL methods. I am wondering : would be a lot of work to add these properties directly in ENIGMA, instead of putting them in the creation code ?

[TheExDeus]

Well the problem with "adding these properties directly to ENIGMA" is they are not actually separate properties. They really do just mean image_xscale, image_yscale, image_angle, image_alpha and so on. So those are the properties that are going to be changed anyway. Changing the plugin to export starting values for these properties separately seems impractical, as you would have to send it for all of the instances in the room. I personally don't see any negative side for the creation code method. It should be a lot easier to implement, it should allow easy expansion in the future (like if you want to change even things like default shader it is render with, it would trivial to add), and it allows overriding in the creation code itself. So you can rotate it in the room, and then still add "direction = 19;" in Instance Create Code and it will work. On the other hand if you add them as separate codes to be run, then it's basically as adding another event which is again, a waste.
So unless someone has an argument why my idea wouldn't work, then I think it's the most practical. And as I said, if you do it this way, then ENIGMA doesn't even care about those room options. They would work no matter what you add and ENIGMA wouldn't have to be changed.

[Goombert]

TheExDeus said it would be possible to do this in the creation code of the instance

Do not do it that way, if you want I can add them to the compiler and everything. They need to be in there so I can update the command line interface to accept them as well as. Josh should weigh in.

So unless someone has an argument why my idea wouldn't work, then I think it's the most practical.

Because nobody has tested Studio to see at what point those locals are set, what if they are accessible in the create event? Then having them in instance creation certainly won't work because they won't be available, same as X, Y which are available in the create event. I'd prefer this be tested first to ensure.

If it is necessary I can update the back end and everything for him, he'll only have to change LGM.

[Goombert]

I decided to run the tests for you.

I created a new project, 1 object and 1 sprite. I then created a room and placed the object in it.

The following code was placed in the create event.

Code: (EDL) [Select]

show_message(string(image_angle));

With the instance angle set to 20, the create event reported 20.
With the instance angle set to 20 and image_angle set to 30 in the instance create code, the create event reported 20.
With the image_angle set to 30 in the instance create code, the create event reported 0.

So my initial hypothesis was correct. Just focus on adding the ability to the room editor and the properties being saved to each format. I will update the back end for you and everything after a discussion with Josh and once you get everything working and commit it.

[egofree]

I will update the back end for you and everything after a discussion with Josh and once you get everything working and commit it.

Fine, i will start soon to implement these features in the rooms editor. Before i want just to display a white rectangle for selected instances.

[TheExDeus]

Because nobody has tested Studio to see at what point those locals are set, what if they are accessible in the create event? Then having them in instance creation certainly won't work because they won't be available, same as X, Y which are available in the create event. I'd prefer this be tested first to ensure.

Pre GM8.1 creation code was before create event. But I guess now it's the other way around. Anyway, I still recommend this way even if you have to create another creation code - the Pre-Create Event Creation Code. Because I just don't want you to hard code each changed variable, like if LGM can change rotation, color and alpha, then you just add 3 variables to the plugin, to the compiler and then to the game. That will be pain in the ass to extend and maintain. So I suggest just appending code that plugin/compiler can write.

[Goombert]

You seem to be missing the entire point Harri, X and Y are passed in the constructor of objects to be made available in the actual create event, so the compiler must pass them that way as well. And yes the creation code order did change in Studio. However the results of my test my be inconclusive because Studio has a bug apparently where it is not saving my instance creation code, but this doesn't change the fact that image_angle must be set before the create event which therefore requires it to be passed in the constructor as X and Y are.

[TheExDeus]

You seem to be missing the entire point Harri, X and Y are passed in the constructor of objects to be made available in the actual create event, so the compiler must pass them that way as well. And yes the creation code order did change in Studio. However the results of my test my be inconclusive because Studio has a bug apparently where it is not saving my instance creation code, but this doesn't change the fact that image_angle must be set before the create event which therefore requires it to be passed in the constructor as X and Y are.

I'm not missing any point. I even gave you a implementation idea on how to do it the way you want it. Just add another code that will be run pre-create event. We could even allow that to be modified by the users, like the creation code, so they have more options.

[Goombert]

Uhm, do you realize the changes that would require to the compiler? Instead of just adding the variables to the backend which takes me like 3 seconds to do and then you all update, you want me to dick around for a couple of days adding a pre-create event? What you are proposing is like a pre-constructor for C++?

I am a tad shocked at what you're suggesting...

[TheExDeus]

Instead of just adding the variables to the backend which takes me like 3 seconds to do and then you all update, you want me to dick around for a couple of days adding a pre-create event?

I'm 100% certain this "adding variables to the backend" will just be rewritten in 3 months. So I am suggesting doing it extendable from the get go. Also, if you knew how Creation Code was made, then you wouldn't have much problem adding a Pre-Creation code. It doesn't even have to be an event. Like this how Create code works right now (which you didn't probably know because you added a confused comment in roomsystem.cpp line 184):
1) The gotome() in roomsystem.cpp is called to go to room.
2) Then createcode() is called in line 194.
3) That calls something like "roomcreate0" in IDE_EDIT_roomcreates.h.
4) And that calls "room_0_instancecreate_100001" in the same IDE_EDIT_roomcreates.h which has the creation code.

So what I suggest is adding "room_0_instanceprecreate_100001" with the variable changes. Then add "roomprecreate0". And then call it from roomsystem.cpp in before instance create, like in line 177. You can add all the required code in write_room_data.cpp line 191 to 218. I might even do it, though I don't want to right now.

Anyway, it was just as suggestion I feel has merit, as it allows not only adding the room options, it allows more flexibility in the future and we might even give this option to users. As some IDE's allow running a code before some other code just for configuration (usually graphical IDE's like Visual Studio). And as I pointed out it should be easy to add.

I wanna hear Josh's thoughts on this, as he might appreciate the "elegance" of that solution, although he might just as well hate it.

[Josh @ Dreamland]

That is exactly what I was going to have him do, Harri. There's no point in adding arbitrary numbers of variables to our list format when 99% of objects won't use all of them, and more than half of objects won't use any of them. Just prefix it to the creation code. This allows injecting arbitrary variable assignments. Plus, the code is executed inside the frame of the instance in question. There's no reason not to do it this way.

[Goombert]

Ok, that sounds fine then, I just didn't originally hear about this proposal and didn't think it would be feasible, but alright I am on board with this then.

[egofree]

I am not sure to understand : are we talking about adding a 'pre-creation code' ?  But how it would be accessed in LateralGm ? Would it be a new property of the instance, like the creation code ?

[TheExDeus]

I am not sure to understand : are we talking about adding a 'pre-creation code' ?  But how it would be accessed in LateralGm ? Would it be a new property of the instance, like the creation code ?

It probably would be accessible just like the creation code. Just opening the instance settings in the room editor. But exposing it is not actually required, it would just be a positive thing as it allows more possibilities for the users. The whole point of the "pre-creation code" would be that LGM automatically generates it from the instance transformation settings in the room editor.

[egofree]

It probably would be accessible just like the creation code. Just opening the instance settings in the room editor. But exposing it is not actually required, it would just be a positive thing as it allows more possibilities for the users. The whole point of the "pre-creation code" would be that LGM automatically generates it from the instance transformation settings in the room editor.

I was thinking more from a programming point of view. I prefer that the user doesn't have to deal with this pre-creation code directly. I think it would be better that he modifies the fields values in the instance properties.