Lemma Soft Forums

So, I'm working on the transformation language that will be part of Ren'Py, probably starting with the next release. The idea of the transformation language is to provide a convenient way to specify the placement, rotation, scaling, and opacity of images. It will also provide a way to define animations. The idea is that this will become the preferred way to specify aspects of display that vary with time.

Let's see the most trivial transform:
This is the equivalent of the current "right" position, displaying an image on the right of the screen.

This is pretty boring, so let's take a look at a transform that starts the image on the left, moves it to the right, then back to the left:
We now have multiple lines. Each gives a time, and a position. So at 0 seconds it's at the left, at 2 seconds it's at the right, and then at 4 seconds its at the left again. By default, the values are linearly interpolated, but that can be changed, using (for example):
Which would use the ease function to do the interpolation.

Giving the repeat statement causes the current block of code to repeat from 0.
By nesting statements, the amount of time the repeat is for can be controlled:
By separating them with commas, one can include multiple properties on a single line. (Note: I need a better word than property here, as properties is used by the style system.)
Other properties include "rotate", "scale", and "alpha". The following spins its child forever:
While this scales it to full size:
The "parallel" statement lets you run both transforms at the same time. So the following will scale the child while spinning it, and then keep it spinning even after the scaling is done.

I'm not sure about the syntax, but I'd also like for it to be possible to define an animation using this mechanism. So one could probably do:
Of course, this would compose with other transforms.

I have some other ideas (like the ability to respond to events such as idle and hover), but these are the basics, and I thought I'd run them by the community before I start the implementation work. Any comments? Suggestions?

I haven't done anything with transformations so I don't know if this would be obvious or not, but when would the repeat statement end if there's nothing in the transformation after it? Would it just wait until the image is told to hide?

Yes, unless there's something to end it, it would go on forever. (Until hidden.)

I'm not sure whether I like a new kind of baseline block in addition to init and label blocks.

This is a very good idea, opening up a LOT of possibilities. Syntax seems fairly easy to get a grasp on, too.

Will something similar be available for text? (Y'know, showing several lines at once in NVL mode for example, with various text effects here and there, etc.)

Well, Ren'Py does not offer a lot of text effects anyway, there isn't even a property for kerning bonuses. If there was, it would be a neat (but not crucial) effect to adjust it over time.

http://www.renpy.org/wiki/renpy/doc/ref ... m_Language

I've posted up a specification for how I plan to implement the new animation and transformation language. I think I've simplified it a bit compared to what I have above. Some examples.

An animation:
Move from the left side of the screen, to the right side of the screen, and then back to the left.
Grow to 120% of the usual size when hovered, shrink back when unhovered.
The idea is that the ATL will provide a high-level way of expressing things that are currently done by Animation, TransformAnimation, SMAnimation, Zoom, FactorZoom, RotoZoom, Move, Pan, Transform, and probably a bunch of other functions I can't remember offhand.

Cool. That does look... "Ren'Py-ish". As in, it's a very simple, punctuation-free way of expressing some very powerful and versatile concepts.

Ooh. I think that this will be quite cool.

Is 'pause' a pause between transformations, a pause during which transformations take place, or the duration of a transformation? If the lattermost it might be better to call it 'duration'.

In the definition for parallel:

The blocks within a set should be independent of each other, and manipulate different properties. When two blocks change the same property, the result is undefined.

In a likely-to-change-between versions sense, a likely-to-change-between-executions sense, or an exceptionthrowing sense?
(Eying the possibility of epicycle transforms. Even though I don't really need them.)

The pause is a pause during which transitions occur.

For now, if you were to do:
The result would be that one of the two blocks (probably the second) would manipulate xalign, and the other one would not. I might eventually look into relaxing this (which would be a change between versions), but probably not in the first version. For many of these, composing two values is a meaningless operation... it's not clear to me that an xalign of 0.0 and an xalign of 1.0 should compose to 0.0, for example.

If someone wants to take it upon themselves to write sensible rules for composing property updates, by all means do so.

Would it be too hard to have both just change the value whenever and the last written one wins? And if the pauses are equal in length and alter the same event just have it undefined or random?

Or are you compiling it so it can execute fast or doing something else to keep maintaining it easy?

But MAN this is going to really rock.

That's how I plan to do it. But I want to reserve the right to alter this in the future, so for now it's undefined.

Okay... I thought so.

If a position transformation is in progress with ease or linear and gets interrupted by an event, the "from" coordinates are going to be from where the displayable currently is right? And not the coordinates from the end of the first transformation?

PyTom wrote:

Code: Select all

transform bounce_once:
    0: xalign 0.0
    2: xalign 1.0
    4: xalign 0.0

We now have multiple lines. Each gives a time, and a position. So at 0 seconds it's at the left, at 2 seconds it's at the right, and then at 4 seconds its at the left again. By default, the values are linearly interpolated, but that can be changed

This syntax is really easy on the eyes, being in turn quick to understand, especially if the sequence is longer. I'm all for it!

I've actually bounced off that syntax a bit. The new syntax for the same thing would be:
You can also use pause, which can be written as:
Since a number is a pause, this can also be: