[Resolved] Build 759 Sprites not displaying correctly

Solar2D Daily Builds and Public Releases
#21

just wanted to post that the sprite sheet issue is still present in build 762. I’m in the same boat as martin.edmaier. I have a fairly large library of sprite sheets that I’d really only want to resize if absolutely necessary.

If we can get some insight as to whether or not the “power of 2” dimensions are now a requirement, I’ll know whether or not to start the long tedious process of recreating all my sprites/code/etc.

But if there is a plan in the works to “fix” the issue by allowing arbitrary sizes again (as before build 759) I’d like to know that too, since I can instead focus on other issues. [import]uid: 49447 topic_id: 22756 reply_id: 91801[/import]

#22

@producerism finally somebody in the same boat. I am so screwed with that stupid sprite sheets.

They don’t know how much time and money it would cost to resize and recreated all the sprites and code etc for me.

[import]uid: 86417 topic_id: 22756 reply_id: 91806[/import]

#23

We are also in the similar boat. We’ve had to spend a whole day updating sprite sheets and code, and to top it all off we’re having issues even after the sprite sheets are sized properly.

Our biggest issue at the moment is that when we try to play an animation sequence, we are getting a delay when a new animation is supposed to be called. E.G. when our character is stationary, a standing animation is played. When the character starts to move, a different animation should play instantly, but after the new sprite API was implemented, a 1-2 second delay started happening meaning our character would slide along the floor in his standing animation for a few seconds. Is anyone else experiencing this issue? [import]uid: 87279 topic_id: 22756 reply_id: 91811[/import]

#24

First of all - it’s daily build so you are beta tester if you use it :slight_smile:
Second - OpenGL ES and graphic accelelator prefer “power of 2” images/sprite size so it’s natural way to improve performance. [import]uid: 12704 topic_id: 22756 reply_id: 91814[/import]

#25

OpenGL ES and graphic accelelator prefer “power of 2” images/sprite size so it’s natural way to improve performance.

There’s no disputing that, it’s a fact. However, that may be something that could be abstracted by the API, and then extra pixels added during the compiling process, or some other process similar to how it was previously done.

Either way, I supposed I’ll just redo all my sprites anyways so I can test out the rest of the new API once the docs are released.

update: so I updated most of my spritesheets, and that did the trick. Just to point out, only the final spritesheet image itself needs to be a power of 2, and the individual sprites themselves within that sheet can be any size you want.

This means a very quick fix could be to simply add empty pixels to the bottom and right of each image, so that the final dimensions are 512x512, or 1024x512, or some other power of 2. That should be easy enough to do without any changes to the code whatsoever! (And since it’s so easy to do, it seems it could be “baked in” to Corona’s compiling process or OpenGL implementation…)

p.p.s. I didn’t notice the issue pagodawestgames mentioned, which I was looking out for as well. [import]uid: 49447 topic_id: 22756 reply_id: 91818[/import]

#26

Hey guys,

I believe that this power of 2 sheet dimensions thing is something we’re trying to find a way around so that it is not simply a new requirement.

However yes, if you’re effectively a beta tester for the new builds/features then for the time being there isn’t a way around this. Lots of great stuff comes in the form of daily builds but there are still going to be some pitfalls.

I have seen many of you from this thread have filed bug reports and I’ll be trying to respond to as many of you as possible this evening.

Peach :slight_smile: [import]uid: 52491 topic_id: 22756 reply_id: 91869[/import]

#27

If you mean proper docs and not notes then we don’t update docs immediately for all daily builds. [import]uid: 52491 topic_id: 22756 reply_id: 91894[/import]

#28

Same issue here.

Also, where are the docs of new releases?

My sheets are multiples of 2, and I am able to draw other stuff off the image.
However, when I’m using the image as the spritesheet, my sprites are invisible (but clickable)

nm… it seems i have to rewrite some of the code…
Must say I’m very happy with this… My current process is as follows:
In development mode, my functions load the sprites directly from disk (getImage(sheet, “blabla/blabal.png”))
In when I change the loading mode to non-development, I need to export my sheet. The code stays the same, as my spriteAtlas data file contains the original filenames as well (instead of just frame-numbers).

In this new API, I could just add a table that maps filename -> index. It seems to be a logical step as the frame-numbering can easily change due to optimized sprite-packing.
[import]uid: 5942 topic_id: 22756 reply_id: 91889[/import]

#29

Ah ok… I just read the blogpost… but I only found out about the info after I was struggling.
Maybe it’s an idea to generate the (api)docs for daily builds in form of local html files? [import]uid: 5942 topic_id: 22756 reply_id: 91896[/import]

#30

God! I wish I never posted this thread or where part of it :frowning:

With all the complaining. C’mon like Peach said people need to remember these are daily builds not release. Besides the blog post Jon wrote is very helpful with how to use the new api and answers many questions most people have. Besides we should all create better sprite sheets for better performance and size. Sure I’m in the same boat as everyone. It took me a lot of time fixing my hundreds of sprites. But, I’d do it again if I had to in order to get an increase in performance for my game.
http://blog.anscamobile.com/2012/03/image-sheets-image-groups-and-sprites/
[import]uid: 38820 topic_id: 22756 reply_id: 91900[/import]

#31

Just wanted to add what i experienced as well trying to work with the new build. Most of you already mentioned the problems above but i met with 2 other problems that probably wasn’t mentioned here:

  1. I understand that the new sprite API doesn’t allow trimmed or cropped spritesheets and before that i was testing it with a trimmed or cropped spritesheet. It still works but when you try to play the animation sequence, the sprite flips itself while playing the animation. It’s not really a bug as the it was mention that it was included. Just thought i point it out just in case anyone met with it and was left wondering what happened.

  2. After i made everything work, i noticed a slight 1 - 2 seconds lag. I think pagodawestgames mentioned this and i am also having the same issue. This happened when i play between different sequences. I will file this as a bug later. [import]uid: 39846 topic_id: 22756 reply_id: 91908[/import]

#32

For those using texturepacker, I’m using this piece of code to convert the data:

[lua]function updateTpsToComplex(data)
local lookup = {}
for i, v in ipairs(data.frames) do
v.x = v.textureRect.x
v.y = v.textureRect.y
v.width = v.textureRect.width
v.height = v.textureRect.height
lookup[v.name] = i
end

data.lookup = lookup
end[/lua]

after the texturepacker data is updated, you can also just get an index by name:

[lua]data.lookup[“items/supersword.png”][/lua]

You can use this to get your image (instead of using numbers).
By keeping the names around, you can also easily create a function which searches all framenumbers with a specific prefix (such as: “anims/hero/walk_left_”

btw. I also have the 2 second delay. It seems that the delay is caused by FIRST waiting X ms, and THEN changing the image of the sprite.
If you increase your time, it will increase the delay.

instead of:
frame1 delay frame2 delay frame3 delay

it seems that the following is happening:
delay frame1 delay frame2 delay frame3
[import]uid: 5942 topic_id: 22756 reply_id: 91910[/import]

#33

Most people aren’t “complaining” so much as they are simply reporting back the issues they are finding with the latest builds, which is exactly what a beta tester is meant to do. If people don’t report the issues they’re having, they will never get fixed. That’s the whole point of having these daily builds.

I’m glad to see I’m not the only person having the animation delay issue, I hope it can be fixed soon! [import]uid: 87279 topic_id: 22756 reply_id: 91961[/import]

#34

@pagodawestgames I stand corrected. You’re right :wink:

Yes, I get the delay too.

Also I don’t know if anyone else is having this problem. But, when using the new sprite api and I go to the next scene in storyboard the scene loads the images but my touch listener stops working. I get no error messages, nothing, everything just freezes. Weird. [import]uid: 38820 topic_id: 22756 reply_id: 91967[/import]

#35

@glennbjr I also had that same exact issue. I updated my code to use the new sprite API, and while it seemed to work just fine (once I fixed my sprites since API currently doesn’t allow trimming) I noticed that upon a scene change, I the app appeared to freeze.

It makes sense that it wasn’t responding to a touch event as you mentioned. I didn’t look into it further because it was getting late, but what you described is exactly what I experienced as well. [import]uid: 49447 topic_id: 22756 reply_id: 91970[/import]

#36

Hey jbverschoor - Our programmer wants me to send his love for that bit of code you posted, it’s made his life a ton easier. Nice job! [import]uid: 87279 topic_id: 22756 reply_id: 92063[/import]

#37

Hey everyone,

We are hoping that the next daily build will fix these sprite issues.

When it’s up if you could please update and report back on any ongoing issues that would be most appreciated.

Peach :slight_smile: [import]uid: 52491 topic_id: 22756 reply_id: 92116[/import]

#38

You’re welcome :slight_smile:

For what it’s worth, in my code I had created my own newImage() function, which can be configured to load single pngfiles instead from a textureatlas. Saves me a lot of time trying to tweak images, as texturepacker can be reasonably slow with a lot of images.

[import]uid: 5942 topic_id: 22756 reply_id: 92117[/import]

#39

wanted to post an update. As of build #765, I’m not having the issue where the app was either freezing, or touch events weren’t registering. Whatever the problem was, it seems to be resolved now, without any changes to my code.

@glennbjr, wondering if it’s resolved your issues as well. [import]uid: 49447 topic_id: 22756 reply_id: 92441[/import]

#40

@producerism Thank you for the update. I just downloaded and tried the latest build and scenes are now changing fine.
[import]uid: 38820 topic_id: 22756 reply_id: 92453[/import]