When developing 2D games in SL currently scripters either load individual textures per sprite (which is inefficient) or we hand adjust the code to load and display the sprites from a single larger sprite sheet texture ourselves.

I've personally developed a tool that helps me to import JSON files from TexturePacker to help auto-load the sprites without having to manually code in all the UV coordinates, although TexturePacker's Unity export format is a bit more compact so I've been looking into that instead. The problem is that this can run out of script RAM loading that much information if there's a lot of sprites in a sheet.

My feature request is:

Allow an Upload button in Build menu for uploading a Sprite Sheet, when this is chosen the user is prompted to choose a JSON file. The Uploader then reads the top of the JSON to find out the name of the .png texture associated with the json spritesheet file and queues that for upload too. Then, a preview window appears, and displays a window with a drop down combo box that contains the names of all of the Animations stored in the spritesheet. When one of the animations from this combobox is selected, a thumbnail of the animation is played back in the preview window. The user can then decide if they like what they see, and then click the Pay $L To Upload button. A Spritesheet file type will appear in their inventory.

If this spritesheet inventory type is double clicked, it opens a preview window so you can see the animations similar to the one that was used during Upload.

Now, from the perspective of the scripter they just have to drag the Spritesheet file from their inventory into the Contents of their prim. This would be a new inventory type in the inventory system that points to the Texture UUID of the spritesheet texture that was uploaded and the information contained in the JSON for where the frames are located for each animation. In their script they now have access to new API calls:

string name = "spritesheetNameInContentsOrUUID";

list animationNames = llGetSpritesheetAnimationList(name);

if (llGetListLength(animationNames))

{

string anim = llList2String(animationNames, 0);

// starts the animation at the frames per second, if fps is negative it reverses direction

// loopCount is how many times to loop (e.g. 1 for one shot) or 0 for infinite looping

key animHandle = llStartSpritesheetAnimation(name, anim, face, framesPerSecond, loopCount);

// get the frame count for the animation

integer frameCount = llGetSpritesheetAnimationFrameCount(animHandle);

// jumps to the middle frame number in the animation

llSetSpritesheetAnimationFrame(animHandle, frameCount / 2);

// gets the current frame number of the playing animation

integer curFrame = llGetSpritesheetAnimationCurrentFrame(animHandle);

// if X or Y are set to -1 then flip image horizontal or vertical, 1 normal, and 0 no flip

llFlipSpritesheetAnimation(animHandle, -1, 0);

// pause at whatever frame the animation is currently at

llPauseSpritesheetAnimation(animHandle);

// resume a paused spritesheet animation from the frame it was paused at

llResumeSpritesheetAnimation(animHandle);

// for stopping the animation completely (resets face back to frame 0)

llStopSpritesheetAnimation(animHandle);

}

Note: LL can even submit a custom export format to the TexturePacker dev team and the creator of that tool can include it in the already vast list of supported game engines. TexturePacker is here: https://www.codeandweb.com/texturepacker

These formats can also include 2D normal maps for reacting to lighting (e.g. sprite walks past glowing torches), pivot points, rotating/trimming/packing the sprite atlas to save memory, collision information, etc.

I think this would revolutionize gaming development on SL if included. And, with Lua scripting arriving someday soonish, it would lead to a major boom in products.

TileMaps and 9-slicing sprites would be nice to have too.