Transformation Matrix.. pleaseee

Solar2D Daily Builds and Public Releases
#1

I noticed one thing : accessing display object’s properties is a very expensive operation

for 1,100 do
obj.x= obj.x+val1
obj.y= obj.y+val2
obj.xscale=val3
obj.yscale=val4
obj.rotation=val5
end

is way more expensive than :

for 1,100 do
obj:translate(val1,val2)
obj:scale(val3,val4)
obj:rotate(val5)
end

the performance difference is very noticeable so I’m not sure what you’ve done in those transformation functions. Now, calling 3 functions is (I assume) will be more expensive than calling a singular transformation call using a transformation matrix.

It doesn’t seem like a difficult thing to do rite, I’ll do it for you if you let me edit the code :)? If you can add this new function to transform based on transformation matrix to the new build that will be wonderful!

Thank you
.someone who desperately needs to add another 10 fps [import]uid: 76697 topic_id: 17453 reply_id: 317453[/import]

#2

Wow, that’s a very interesting finding! I’ve been trying to figure out how to speed things up. I wonder if this would speed up the tweening library I’m using as well.

Also, matrix support would be awesome. [import]uid: 27183 topic_id: 17453 reply_id: 66284[/import]

#3

+1!

also, thanks for posting this observation. I’m sure I’ve read it a few places before, but this was a great reminder. [import]uid: 49447 topic_id: 17453 reply_id: 66285[/import]

#4

Any idea if this will be available anytime soon? Or if my assesment on how to speed things up is false?
[import]uid: 76697 topic_id: 17453 reply_id: 68821[/import]

#5

I’ve confirmed yanuar’s experience using the test code below. If you access the sprites properties directly instead of the ‘cached’ properties performance drops by 10 fps.

[code]
display.setStatusBar(display.HiddenStatusBar)

system.setIdleTimer(false)

require “sprite”

local uma = sprite.newSpriteSheetFromData( “uma.png”, require(“uma”).getSpriteSheetData() )

local spriteSet = sprite.newSpriteSet(uma,1,8)

sprite.add(spriteSet,“uma”,1,8,1000,0)

local count = 75
local rows = 3
local sp = {}

for i = 1, count do
for j = 1, rows do
local spriteInstance = sprite.newSprite(spriteSet)

spriteInstance:setReferencePoint(display.BottomRightReferencePoint)
spriteInstance.x = 220 + i*10
spriteInstance.y = 120 + j*150

spriteInstance.cx = spriteInstance.x
spriteInstance.cy = spriteInstance.y
spriteInstance.crotation = spriteInstance.rotation
spriteInstance.crotation = spriteInstance.rotation
spriteInstance.cxScale = spriteInstance.xScale
spriteInstance.cyScale = spriteInstance.yScale
spriteInstance:play()
table.insert(sp, spriteInstance)
end
end

require(“fpscounter”).fpscounter()

local ef = function()
for i = 1, #sp do
local s = sp[i]
s:translate(s.cx - s.cx, s.cy - s.cy)
s:rotate(s.crotation - s.crotation)
s:scale(s.cxScale/s.cxScale, s.cyScale/s.cyScale)
end
end

Runtime:addEventListener(‘enterFrame’, ef)

[/code] [import]uid: 27183 topic_id: 17453 reply_id: 70247[/import]

#6

what i dont understand is, according to the Corona guideline :

Note: the methods object:scale(), object:rotate(), and object:translate() merely change the value of the underlying geometric properties. The order in which you call them does not affect the final result, so you should not think of them as matrix transformations.

if that’s the case then why accessing display object properties directly and through methods have performance gap?

we could use a better understanding of the pipeline to make sure we optimize our game to the max.
[import]uid: 76697 topic_id: 17453 reply_id: 70928[/import]