I have a sprite with a 1x1 distortion map. The vertex positions are thus (0,0) (0,1) (1,0) (1,1). Four points in total. I also have a 2x2x3 array which stores precalcualted distortion values. X is Column, Y is Row, Z is distortion in X,Y and Z. Since I have 4 points, I have a looping event (looping 4 times) which updates each vertex with the proper distortion values. The problem is, no matter what I do, the last row never acquires the displacement values at all. They are in the array.

For"" from 0 to (Sprite.MeshRows+1)*(Sprite.MeshCols+1)-1

->

Set Absolute Displacement at

Row: floor(LoopIndex/2)

Col: (ceil(LoopIndex/2)-(LoopIndex/2))*2

X Distortion: Array((floor(LoopIndex/2)+1),((ceil(LoopIndex/2)-(LoopIndex/2))*2+1),1)

Y Distortion: Array((floor(LoopIndex/2)+1),((ceil(LoopIndex/2)-(LoopIndex/2))*2+1),2)

Z Distortion: Array((floor(LoopIndex/2)+1),((ceil(LoopIndex/2)-(LoopIndex/2))*2+1),3)

The formulae seem correct to me. The only way I found to mitigate the problem, was to add another row to the distortion map - basically adding empty space to the sprite and doubling its height -then my second row would acquire the distortion values while the third one would not.

it's difficult for me to decipher all that, but I'll give you some general info, arrays in construct are 1 based instead of 0 based, so the first index is 1, not 0.

also, your formula there is needlessly convoluted and unreadable, the (Sprite.MeshRows+1)*(Sprite.MeshCols+1)-1 make sure to use enough () to be sure about the order of operations even if it's superfluous just for readability. instead of using one loop with weird formulas to get what you need, why not just have nested loops?

for "x" from 0 to meshrows

for "y" from 0 to meshcols

then use loopindex("x"), and loopindex("y)

also, another thing that would make it less confusing would be not using a 3rd dimension to the array, and instead use 3 separate arrays named x, y, and z

other than that, using those alterations, it'll be quicker for you to find the solution than for me to. also, just for general info purposes, if you're sacrificing readability for optimization purposes, construct can have hundreds of objects all being acted upon and thousands of evaluated conditions and actions per frame with no slowdown, so you don't really need to do stuff like that except in extreme cases that most users never reach

I'm aware of how the ceiling function works. It returns the smallest integer not larger than the input. In the example I posted, ceil(0/2) gives 1. 0 divided by 2 is 0, which is an integer, so ceil should return 0.

EDIT:

I see what you mean. Whenever a number formated as a non-integer is passed to ceil, it takes the next one, even if that was a whole number. Ceil (1.0) will give 2. I still consider that wrong behavior, since even written as 1.0, 1 is an integer.

Additionally, the floor function works as expected. floor(1.0) will give 1, not 0.