Script properties (of vector types) animation generate garbage for no reason

Feature requests
#1

When we have script property of vector type and we animate it via go.animate, every frame we get new userdata of this type, referenced by that property.
In most cases this is not convenient, and in every case this is not effective.
It would be best if go.animate change vector components instead of generating new vector every frame.

#2

Do you have some example code that exhibits this behavior?
Most of the time, we only update an existing vector4, so this behavior is a bit surprising to me.

#3 
go.property("test", vmath.vector4(1, 0, 0, 0))

function init(self)
	self.ref = self.test
	go.animate("#", "test", go.PLAYBACK_LOOP_PINGPONG, vmath.vector4(0, 0, 0, 0), go.EASING_LINEAR, 1)
end

function update(self)
	print(self.ref, self.test)
end

DEBUG:SCRIPT: vmath.vector4(1, 0, 0, 0)	vmath.vector4(1, 0, 0, 0)
INFO:DLIB: SSDP: Started on address 10.0.1.5
DEBUG:SCRIPT: vmath.vector4(1, 0, 0, 0)	vmath.vector4(0.96666669845581, 0, 0, 0)
DEBUG:SCRIPT: vmath.vector4(1, 0, 0, 0)	vmath.vector4(0.93333333730698, 0, 0, 0)
DEBUG:SCRIPT: vmath.vector4(1, 0, 0, 0)	vmath.vector4(0.89999997615814, 0, 0, 0)

prop_test.zip (3.2 KB)

2 Likes
#4

Indeed, looking at the code, it seems that animations always update their Lua values with new userdata structures (objects).

I can’t say exactly why it’s implemented this way, but my best guess is to keep complexity down, and keep systems more apart. I do feel that it should be possible to update existing values.

Also, sSince the assignment operator is a Lua assignment, changing the current behavior might have unintended consequences for existing games. Although one might consider it a bugfix, which would make the change easier to justify.

I do see room for several improvements on the backend of things, like the one you suggested.
But unless you are blocked by this, I’ll add it to the “good things to improve”-list.

2 Likes