It depends of the 'origin' of the sprite. By default the origin is 0,0. Here is an instance at 32, 32:



With a rotation of 160 :



But if you set the origin around the center, you are right. But this is bad news, i didn't take into account yet this property.

[Scaling:]

I am still developing the functions for rotating, scaling, and modifying the alpha property of instances. The methods in Java for displaying images with these properties are trivial :

Code Select Expand


Graphics2D g2 = (Graphics2D) g;

g2.scale(scale.getX(),scale.getY());
g2.rotate(Math.toRadians(-rotation));
AlphaComposite ac = AlphaComposite.getInstance(AlphaComposite.SRC_OVER, (float) (alpha / 255.0));
g2.setComposite(ac); // Alpha

But the code for calculating the bounds of the instance when it is rotated is far from being simple ! (We are not rotating the object around its center, but around its left upper corner. This is how it's done in GM Studio). At least from me : i am far from being a genius in trigonometry. Still, i am confident i will finish soon this problem. I don't intend to implement flipping in this version. Anyway flipping is just a rotation and translation. Here is some new screenshots:

Scaling:



Rotation :



Opacity:

That's cool. Just wandering - what are the rendering capabilities of the Java thing (swing?) that we are using? Like I know you couldn't do something because of that, like render a dashed line or something.
So will it be capable enough to render the transformation controls (so you can click a corner and drag to scale, or rotate)?

For the views, i've already used dashed lines. I don't think there should be any problems rendering the transformation controls :
http://docs.oracle.com/javase/tutorial/2d/advanced/transforming.html

Teasing : 

[image_xscaleimage_yscaleimage_alphaimage_angle (already reported by BreakDown)]

I did some tests. In the creation code of an instance, i tried the following properties, with different values :

image_xscale
image_yscale
image_alpha
image_angle (already reported by BreakDown)

They are not doing anything. In GM Studio, they work as expected.

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.

I added settings for selection also. They are identical to views :

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 ?

I've fixed two errors concerning views :
- It was not working correctly if the OS is non-English (Testing the selected tab with the title was not very optimal  )
- If the room starts with the views tab, the views are displayed now. Before it was displayed only if you switched to the views tab manually.

I've finished to implement the selected instance/tile. If you click on an object in the rooms editor, it will be displayed with a white and black border. This will be useful when more fields will be added to instances (scale,rotation, flip), as the user will know exactly what instance is modified. Also if you click an instance in the list, it is displayed centered in the rooms editor and with a border (similar to views) :



I will do more testing and make pull request tomorrow.

I finished to display the selected instance/tile with a black/white border. I would like also to add the following behavior : when a instance/tile is selected in the list, it is displayed centered in the editor window. This is identical to the view tab.

I don't understand : it seems to me that there is a big elephant in the room, and nobody is talking about it !  Robert made a 'Command Line Interface' : http://enigma-dev.org/forums/index.php?topic=2047.0, so ENIGMA can be easily used from any IDE. Or perhaps i misunderstood something ?

Also, why is LGM version frozen ?  With all the changes added to LGM lately shouldn't the version increment ?  Like 1.8.7 ?

I propose this : let me finish the scaling and flipping functions, and then we will increment the version and make a announcement so people will know that new features have been added in LateralGm.

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.

I see some new features being added, I think those should be updated in the wiki documentation to reflect changes, removal, fixing or adding new functions, features, etc.

As i am not a native English speaker, i don't feel competent to do it, and anyway i was told i write 'horrible sentences' ! 

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 ?