How To Rotate Rendered Objects (Creator-Defined Displayables)?

[Spacepiratehacker54]

Hi, I would like to rotate a custom render object while it is already constantly being redrawn on screen.
I noticed that the method renpy.blit or renpy.rendy (https://www.renpy.org/doc/html/udd.html) do not contain an option to rotate an imagefile and then draw it.
Since the normal label and screen language of renpy has a way to rotate Images (viewtopic.php?f=51&t=21978)
with

Code: Select all

show clockmin:
    xalign 0.5 yalign 0.5
    rotate 0 #This puts the minute hand at the starting position of 12
    block: #Everything in this block repeats over and over
        linear 3600.0 rotate 360
        repeat

I thought there should also be a way to rotate custom render objects.

I thought maybe something like

Code: Select all

add custom_object

works, since it also takes arguments like 'xalign 1.0' and such.
However, what do I do if my custom_object has already been added to the screen?

Since

Code: Select all

self.displayable_render = renpy.render(self.displayable, width, height, st, at)
renpy.redraw(self, 0)
render.blit(self.displayable_render, (self.x, self.y))

in the render method of my class for my custom_object
does not contain any option to redraw my object at a different position with a different angle.

Even though I have a lot of experience with Python I just started working with Displayables in Ren'Py so go easy on me, please.

[trooper6]

In my signature is a link to my clock tutorial in the Cookbook section. That clock has rotating hands and the final version of it is a s custom displayable. You might want to check that out for some inspiration.

[Spacepiratehacker54]

Thanks for your answer! Kind of stupid of me that I did see that part of your recipe (http://lemmasoft.renai.us/forums/viewto ... 51&t=21978). I now read through all of that last part and I have two questions left:

1.I saw that there is a 'self.offset' defined in the code to correct the errors caused by the rotation. For other purposes you would not really need that, right? (For example a rotating enemy in a minigame). So is it correct that just putting the transformed image (using Transform with rotate=...) into renpy.render is enough?

2.I also saw that at the 'render.blit' parts of the code the base is always rendered first, then the minute and then the hour render. I guess the order of these blits is important. So when I have multiple classes with their own render method how can I control which instance of a class is rendered on top of the others? In the case of this cookbook recipe the renders were all children of a class, so it was no problem (just make sure they are in the right order before 'renpy.redraw' and 'return render'). But what if I have multiple objects of multiple classes? How can I, for example, make sure the player is always rendered below (/before) an enemy?

But all in all that cookbook recipe is surprisingly very informative about displayables, I wish some of that info was included in the docs...

[trooper6]

Hello!

1) Those offsets are to deal with the hour/minute/second hands needing to rotate, but the images being squares. Without the offset for the second, minute, and hour hands would move all over and it wouldn't look right. Note that the base doesn't need to use the offsets because it isn't rotating. If you don't have multiple layers on top of each other all rotating, you probably don't need the offset.

2) The order of the blits is important because the layers are blitted in the order they are given within that object. What if you have multiple objects rather than one object in multiple layers? This would be just like any other show. You want the the player to be rendered below they enemy? You show the player first and then you show the enemy. That should do it. If you are concerned, or if it isn't working just right for you, then use the zorder for your images. Check out the Show statement in the documentation: https://www.renpy.org/doc/html/displayi ... -statement

Hope that helps!

[Spacepiratehacker54]

Thanks for your quick answer!
Sorry, but I had another question concerning the rotation while I was writing my code.

If I rotate a Creator-Defined Displayable and want to get the width and height by using 'self.displayable_render.get_size()' am I automatically getting the actual height and width of the rotated image?
For example, if I rotate an image with height = 50 and width = 70 by exactly 90 degrees using Transform, then does self.displayable_render.get_size()[0] (the width) return 50 and self.displayable_render.get_size()[0] (the height) 70 without doing anything extra?

And is height and width automatically updated in 'def render(self, width, height, st, at)', too?

[trooper6]

One of my first questions would be, does this need to be a creator defined displayable at all? Or is the only thing you want to do rotate an image...because that could be done with a simple ATL Transformation. CCDs are really powerful and often more than a person really needs. Do you actually need a CCD? What are you actually doing?

Next question. Why do you need width, height? What do you plan on using that information for?

About rotation: When images are rotated they are placed in a larger square that can hold the hypotenuse of the object (that is why I use the offset). I don't know if get_size will return the original height/weight of the image, the rotated hight/weight of the image, or the height/weight of the new box that is created to hold the rotated image. What I'd do is create a test project with a rectangle CCD, call get_size and display that data, then rotate it 45 degrees and display that data, then rotate it 90 degrees and display that data.

When I don't know the answer to a question, I aways just make a test project to check.

[Spacepiratehacker54]

Alright, then I'll try to create a test project myself sometime. It is not really important for my project, at least yet, but I was just interested.
What I'm trying to do is to make enemies in a shooting mini game, they can rotate and depending on their rotation I want to alter their hitboxes.
For instance, you have a giant object on screen with the form of an ellipse which is rotating the whole time until it leaves the screen.
I think I've found another way for determining the hitbox without the width and high value, so it isn't that important anymore.

But thank you for all your answers! It really helped me out.

[trooper6]

If all you want to do is rotate an object, I don’t think you need a CCD. I think you can just use ATL, it is much easier!