new transition

[e.sobole]

Hello.

Is there a way to make a transition that is not linear?
Parabolic or bicubic perhaps?
I simulate a small star explosion, but the calculations in Lua are too slow. I tested with a Solar2D transition, it’s fine, but I’ll ideally need to manage gravity (or something like it) so that my little stars fall down!

I dream of some kind of a method

transition.cubicTo()

which would take in addition to the destination coordinates, 2 tengants to make the interpolation bicubic (or at worst bezier)

It would be so helpful!

[XeduR]

Check the docs.

Solar2D Documentation — API Reference | Libraries | easing

[e.sobole]

XeduR

easing is the curve of the t (time) parameter ! no ?
I don’t think you can use it to make what I need!

[alanFlickGames]

I’m not aware of any way to do it with the existing transition library.

In the past when I’ve needed to move things along a curve I used a mixture of this for the curve path itself:

nshafer/Bezier/blob/master/Bezier.lua

And this (I think) for the easing:

EmmanuelOga/easing/blob/master/lib/easing.lua

Using these you can just update the position in an enter frame using the output of those 2 libs.

[e.sobole]

@alanFlickGames

Thank you alan.
My main purpose was to increase performance with old phones !

local a2 = a * a
local oStar = tStar[s]
	if oStar ~= nil then
		local dx, dy = oStar.dx, oStar.dy
		local o = oStar.o
		o.x = sx + dx * a
		o.y = sy + dy * a + a2
		o.rotation = dx * a
		o.alpha = (100 - a) * 0.01
	end
end

This simple code was to slow with many stars

It is a little bit faster with transition (not many but every thing is good to take )

It is not very important to optimize for old phones but it’s a kind of challenge for me !
that’s help me to understand how Solar2D works !

I will try to précalculate curve.
I think there is nothing to gain in the above loop but maybe in the overall star management

[alanFlickGames]

If the transition library could do eased paths, I think it would use a similar method to the one I’ve described anyway so I’m not sure there would be much to optimise. I believe that behind the scenes the transition lib is just updating properties in an enterFrame loop anyway.

Regarding your loop, one optimisation you could make is to remove the a2 variable - you only use it once so you may as well just remove it and change the o.y line to:
o.y = sy + dy * a + (a * a)

Similarly, I’m not sure if you need to assign oStar.dx and oStar.dy to local variables in the loops. The time to access oStar.dx would be trivial, so I imagine any performance gain from using dx * a instead of oStar.dx * a would be mitigated by the overhead of creating those local variables on every pass of the loop.

[e.sobole]

Yeap.
I do not know the cost of a local variable ! I will make some tests !

It is difficult to optimize at this stage
Original code was

local a2 = a * a
local oStar = tStar[s]
	if oStar ~= nil then
		local dx, dy = oStar.dx, oStar.dy
		local o = oStar.o
		o.x = sx + dx * a
		o.y = sy + dy * a + a2
		o.rotation = dx * a
		o.alpha = (100 - a) * 0.01
	end
end

Finally I tried to precalculate the motion of the stars
The code is now this one, but I do not know if it is really faster

local a40 = a * 4
local a41 = a40 + 1
local a42 = a40 + 2
local a43 = a40 + 3
local oStar = tStar[s]
	if oStar ~= nil then
		local tMove = oStar.tMove
		local o = oStar.o
		o.x = sx + tMove[a40]
		o.y = sy + tMove[a41]
		o.rotation = tMove[a42]
		o.alpha = tMove[a43]
	end
end

I could replace table of values by a table of objects
the code would be like this

local oStar = tStar[s]
	if oStar ~= nil then
		local oMove = oStar.tMove[a]
		local o = oStar.o
		o.x = sx + oMove.x
		o.y = sy + oMove.y
		o.rotation = oMove.r
		o.alpha = oMove.a
	end
end

I will have to make big loops to see if there is really a code that stands out!

Finally, I saw Lava_Flow particles demo in the sample folder.
It could be the better way to do what I want to !