AzureBlaze

You will always be switching textures, it's a part under every engines. You can't avoid it, but you can minimize it. Most 2D engine are structured that it can render multiple images to the screen with one call to the GPU, as long as the environment (the image file to render, shaders, etc...) does not change. This is called batch rendering. So every time the environment has changed (you want to render a different image file), the engine have to stop rendering, setup the new environment, and then resume rendering. This interrupt is very costly, my computer can only handle a few hundred of these before FPS drop below 60. Imagine your work is to copy some pages from books in the library. Your order will instruct you to copy from a book at once. You receive your order, drive to the library, borrow that book, drive home, copy the designated pages with your ultra fast copier. than you check your next order, borrow another one, and so on. In today's computer world rendering the pixels(copying pages) is fast, but switching texture (borrowing books) is slow. Modifications could be made so you can borrow multiple books at once, but then your order become more complex to execute, and you certainly can't borrow the whole library at once. Also everything must be done in order, so A-> B -> A still count as three switches, even two of it is same. So in your case, you drive 89 times to the library to borrow 89 one-paged books. All your time are wasted to commuting. Texture atlas is combining those 89 pages into one book, so you can borrow once and do everything. Sometimes the book will get too heavy so you'll need two or more, but it is still better than 89. I don't own a pro license so I don't know how the texture atlas generating pipeline is (or even if it is completed yet). But you should look into how to do it in your engine. Texture atlas is a must if you really need 89 layers.

Unused spaces could cause performance problems in extreme cases like rendering them tens of thousands of times, but I think your problem is mostly caused by switching textures. Switching texture is a slow and costly operation, having 89 layers means switching texture 89 times per entity, that is quite huge. Using a texture atlas will help a lot by merging everything into one big texture, thus no texture switching is needed.

Hi, I need to swap a series of image for my animation. The user manual 0.5 suggests that using a series of image with same dimension and pivot, but I would like to trim all the transparent spaces to conserve memory, which would result in different dimension and pivot. I could trim them when I am generating the texture atlas (planned to write a tool to convert SCML into my own binary format and generate the atlas), but I think letting Photoshop do the work will be easier. I tried to remove the translation between keyframes by moving all the pivots to the same absolute world position, but lerping of the pivots still cause the images to move. I observe in the pseudo-code implementation that if a object does not have pivot_x and pivot_y, "useDefaultPivot" should prevent lerping of pivots, but the free version of Spriter seems not to support this. Also aligning pivots with the file pallet is a bit hard, especially when there's no obvious point to put it. In my opinion pivots should not be lerped at all. It is something that is related to a single image not the next nor previous keyframe. Maybe adding something like "rotation_center" that is defaulted to the pivot will be better. Is there anyway around this or could modification be made to Spriter?

Tried implementing with this document today and found some typos: In SCML format spec of Timeline attribute "type" should be "object_type" In SpatialInfo::unmapFromParent() line 8,9: xScale and yScale should be scaleX and scaleY In SpriteTimelineKey::linear() line 3: useDefaultPoint should be useDefaultPivot Otherwise this doc works great, have successfully implemented mine with it.