Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / SetSpriteDepth BUG

Author
Message
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 5th Apr 2012 16:45
I use SetSpriteDepth a LOT.

If I do:

SetSpriteDepth (sprite1, 11);
SetSpriteDepth (sprite2, 11);
SetSpriteDepth (sprite3, 11);

All works fine. sprites 1, 2 and 3 are drawn in Order.

If I do AGAIN the same thing:

SetSpriteDepth (sprite1, 11);
SetSpriteDepth (sprite2, 11);
SetSpriteDepth (sprite3, 11);

The sprites seem to be drawn in REVERSE order!!!!

If I do again:

SetSpriteDepth (sprite1, 11);
SetSpriteDepth (sprite2, 11);
SetSpriteDepth (sprite3, 11);

They are now in the right order again!!!!

This has driven me CRAZY for the past 3 days!!!!!!
I have more than 160 sprites so you can imagine how my mind feels boggled right now!!!!!!!
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 5th Apr 2012 18:38
Have you considered using a different depth for them?

The idea of the command is to let you draw sprites in any order you like and you can use up to about 10,000 depths I think. This isn't a bug, it's user error.

If you add sprites to the same depth you are saying the depth doesn't matter. AppGameKit is just drawing them in whatever order it sees fit because you are saying it doesn't matter.

Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 5th Apr 2012 19:09
As baxslash says, sprites at the same depth have no defined order in the rendering engine so it draws them in whatever order they happen to be in the rendering list.

Having said that a lot of people have complained so the next version will have a command SetSortCreated which will order sprites at the same depth by the order that they were created, note that this will introduce some overhead for sprites at the same depth and the preferred method is separating sprites that need to be drawn in a particular order to different depths. Sprites that will never overlap such as box2D sprites can still use the same depth value without worrying about creation order.
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 5th Apr 2012 21:14
Wouldn't it be simpler just to tell people to use a loop to set the Z-order? Please let's not have too many "Get Out Of Jail Free" commands to clutter things up!

-- Jim
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 5th Apr 2012 21:23
Actually sprites on the same depth are always drawn in the order they were created.

SetSpriteDepth() is the only command that is altering this order. But it's not happening all the time, only when there are a substantial number of sprites.
DVader
20
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 5th Apr 2012 21:31
bjadams, it is not a bug. You are using it incorrectly. What is the point of setting a sprite depth to the same value? You may as well just leave it to the set default depth that AppGameKit uses. If you set a sprite to the same depth the one you create is always the one in front. If you want to control that, as everyone has said, just set the depth different for all sprites. I use the Y position value when I want to to this, although you have to reverse it to use it properly as the y goes down the screen and you (normally) want the depth to go from the bottom up.

bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 5th Apr 2012 21:51
My point is AppGameKit is always drawing the sprites in the order they are created.

Only SetSpriteDepth() disrupts this order.

I need to put all sprites on the same depth layer else GetSpriteHitGroup() won't return the proper values.
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 5th Apr 2012 22:19
To get more technical, when a sprite is created it is inserted into the render list by depth, and once there it will maintain its relative position in the draw queue until something changes. One of these changes is calling SetSpriteDepth which forces it to remove the sprite from the draw list and then reinsert it, which can result in a different position from before since other sprites are now present from when it was first added.

GetSpriteHitGroup also orders sprites by depth when detecting the top most sprite and if two are at the same depth it depends which one it checks first, this order is not guaranteed to match the rendering order for sprites at the same depth.

SetSortCreated adds an offset to the depth value so two sprites at depth 10 would actually be at 10.01 and 10.02 internally with this turned on, and everything will work as you expect. But for this there is some slight overhead in calculating the offset every frame.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 5th Apr 2012 23:11
Thanks Paul for the clarification.

Unfortunately due to my ignorance I wasted 3 days coming to these same conclusions.

All seems to be working just fine as I want (now that I know why it was not working) even if you say that GetSpriteHitGroup's checking order is not guaranteed.

SetSortCreated should make it safe for me.

I am trying to do a colouring shape app, and there are around 60 shapes on each screen, and most of the shapes overlap.

The shapes are all set up in Photoshop by the artist. I have written a very complex Photoshop script to output the positions of the shapes, which I then integrate in AGK. Having to add different depths for every shape will make things much more complex for me. Having all shapes on the same depth is much easier and works fine.

Knowing how the render queue system works helps a lot.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 5th Apr 2012 23:14
Paul, what will this slight overhead impose? A hefty drop in fps or nothing noticeable in today's 1ghz multi processor iphone4s and ipad3s?
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 6th Apr 2012 00:24
I wouldn't expect it to be noticeable, it is a simple loop over each depth value (1 to 10000) and then a loop over the sprite list, all in C++.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 6th Apr 2012 10:56
I think that the SetSortCreated is needed for people who like to put many sprites on the same depth. Judging from the comments/feedback there are quite a few, since this seems to be a user request.

The $100million question now is: when can we finally get hold of 107, since for me, this is the version that has the necessary command set where I can actually finally release something!
Rich Dersheimer
AGK Developer
14
Years of Service
User Offline
Joined: 1st Jul 2009
Location: Inside the box
Posted: 8th Apr 2012 17:31 Edited at: 8th Apr 2012 17:33
Paul, when SetSortCreated() is added to AppGameKit, please please please try to make sure that any old code is not broken by the change.

So, sprite sorting should default to the way it is now, and any new command should change from the default behavior.

That way nobody's code is broken.

I'm just remembering the mid()/right() problems when the string length indexing was changed.

Thankee.

@bj - yah, I'm almost finished with a new game, but I'm kind of hanging back to see what the new version will bring to the table.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 8th Apr 2012 19:22
Rich sprite order will be reversed in 107 as apparently this is not the way it should behave!!! that's why I am holding all development back!!! This has nothing to do with SetSortCreated()
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 9th Apr 2012 04:26
There will be a slight change in the order, if sprites at the same depth call SetSpriteDepth and are still at the same depth, previously it would change order, now it is more likely to keep it's position. But this is to match what the documentation says which is that sprites will be drawn in the order they were created so it is technically a bug fix.

SetSortCreated is an extra level of protection if you must be absolutely sure that sprites are drawn in creation order, and things like GetSpriteHitGroup return use the same order.

If you are using separated depths, or sprites at the same depth that don't overlap, you will not see any difference.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 9th Apr 2012 10:29
Paul, I am checking every day for 107, as my app will use more than 300 sprites all on the same depth (not all visible at once)
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 16th Apr 2012 10:44
Sorry to resurrect this thread but I'm back from holiday and had a thought regarding this statement:
Quote: "I need to put all sprites on the same depth layer else GetSpriteHitGroup() won't return the proper values."


Just use setSpriteGroup() maybe? What kind of improper values are you getting?

It seems there might be a better way to get around your problem to me.

bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 16th Apr 2012 13:12
Baxslash, thanks for your support. Don't worry I tried out all possible combinations.

As soon as 107 is released I will try to start my next project using AGK.
victordavion
12
Years of Service
User Offline
Joined: 3rd Jan 2012
Location:
Posted: 16th Apr 2012 22:33
I'm hoping you're making SetSortCreated() an optional overhead added. If an overhead isn't necessary then it shouldn't be introduced. In my experience with AppGameKit so far it's already pretty slow on Android devices.
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 17th Apr 2012 00:55
SetSortCreated is off by default, you have to call it to turn it on.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 17th Apr 2012 09:44
As soon as 107 is out I will do an FPS test on my iphone 3gs with SetSortCreated on and off (I have around 300 sprites on the same depth) to see if there is any real overhead or not.

I guess the overhead will be close to 0 on new generation iphone4s or ipad3.

Login to post a reply

Server time is: 2024-05-08 08:42:12
Your offset time is: 2024-05-08 08:42:12