Documentation bug or library error?

techdojo

I noticed another issue (not sure if this introduced with 2012.8.1 or if it was already present).

The documentation for Sprite:addChildAt(child,index) says that indices start at 1, so in theory :addChildAt(child,1) should add a sprite as the first child of the parent, in fact it adds it AFTER the first child making it the second child in the chain.

However :addChild(child,0) works and add's the child correctly at the start of the chain.

atilim

uuuhhh... this is a bug. I've checked the source code and understood that I've forgotten subtracting 1 from index parameter of addChildAt. (the functions removeChildAt, getChildAt and getChildIndex are correct) And it seems this bug exists for a long time.

What scares me is that fixing this bug will change the behaviour of addChildAt. I hope fixing will effect your games only a little.

Thank you @techdojo.

techdojo

I think in this instance it might be easier to leave the code as is (it's obviously not caused too many hassles or else you would have heard earlier). Instead I would change the documentation to state that the new item is added AFTER the instance specified so that as the index starts at 1, inserting at 0 will add at the head of the list and inserting at 1 will insert at position 2 (after 1 and before the previous number 2).

Obviously making sure all the edge cases are checked so you can't add at position 6 if there are only 4 entries in the list.

Failing that (assuming you do fix the bug) can you leave in a check so that inserting at position 0 has the same effect as inserting at position 1 please ???

atilim

I totally agree. I cannot risk breaking the codes that uses index 0.

ar2rsawseen

Never, ever ever ever used addChiledAt method

techdojo

Nor me - until today (which is how I found the bug)

alexzheng

I have used this function and noticed this strange behavior.
I have not checked all of my code whether I have write something like addChildAt(0).
I think to keep consistent, it would be better to subtract 1 from the index in addChildAt, but if the index is already 0, just keep it untouched,is that OK?

And addChildAt(1) will add the child as the first child and the original child at index 1 will move index 2 just the same as the insert for table.(Currently addChildAt(1) will add child at index 2 and it's a little confused)

techdojo

FWIW - I'm only calling it with 0 as a parameter so fixing it but leaving in 0 as a valid start case will be more than fine for me

atilim

After a second thought, breaking the backward compatibility doesn't cause so much trouble. Because it's really easy make this function work as before:

local originalAddChildAt = Sprite.addChildAt function Sprite:addChildAt(child, index) originalAddChildAt(self, child, index + 1) end

You'll have two choice: Either you update your code where addChildAt functions are used or add this modification to init.lua.

IMHO, If we don't change this function now, it'll cause more trouble in the future. What do you think?

techdojo

Fine by me - I'll make the changes to my code (effective with the next release?)

atilim

Most probably yes. We're planning to release a new version (bug fix only) because also @glennbjr reported Xperia Play keys doesn't work.

techdojo

Render to texture ???

Would actually be really useful as I want to experiment with caching a sprite group as a single bitmap to see if I can improve performance with my table view control.

*squeak squeak*

alexzheng

After a second thought, breaking the backward compatibility doesn't cause so much trouble. Because it's really easy make this function work as before:

local originalAddChildAt = Sprite.addChildAt function Sprite:addChildAt(child, index) originalAddChildAt(self, child, index + 1) end

Then if I do not care about the index of the child so much, will addChildAt(0) cause any trouble or crash without add this code in init.lua?

OZApps

Render to texture ???

where, what!! ... is it released in the current update? Also looking for GLScissor... or masks.

Nascode

Render to texture ???

where, what!! ... is it released in the current update? Also looking for GLScissor... or masks.

Feature request time!

sorry for being one-liner, cant resist the urge

techdojo

Something to do with the "it's the squeaky wheel that get's the most oil"
Besides @Atilim know's we love him and we'll just wait patiently, but a gentle reminder from time to time can't hurt much, can it ???

Scouser

Also waiting for GLScissor or equivalent and also isometric / hexagon TileMap

Squeak, squeak

OZApps

squeak, squeak?? Is there a mouse in here? or am I supposed to believe that Cinderella's Pumpkin is coming with the squeaky wheels and mice at the helm?

techdojo

Maybe the roadmap / feature request section should be renamed the "squeak list"

OZApps

Maybe the roadmap / feature request section should be renamed the "squeak list"

or the "Oil bet it needs to be darned fixed" List