0
\$\begingroup\$

I am currently working on a customizable Player-character for my top down view 2D pixel game. I am using libgdx and aiming for android devices as well as desktop applications.

I am wondering about an efficient, but yet simple concept. So far my character is build up from different parts ( Feet, Body, Shoulder L, Shoulder R, Hand L, Hand R, Head, Haircut). Every part has its on layer, thus they are 8 layers already. My animations (for example walk cycle) has 8 frames. My character fits on a 24 x 48 px image, thus the naked walking character sprite sheet, with all body parts having their own image and keyframe ends up in having 8 layers x 8 images (24x48 px) = 64 frames.

body parts sprite sheet

This fills up 40% of a 512 x 512 sprite sheet. This is only for the walking down animation, weapons would be rendered from a separate sprite sheet, underneath the hands. So for the other 3 directions ( okay maybe they fit here), but certainly for other states (dying, hitting, casting spells) I would need separate character sheets.

Now my questions:

Since my character is customizable, it could end up that every layer has to be taken from a different sprite sheet ( naked head, metal armor, poor gloves, icy shoes etc) thus I would need to switch my textures a lot since they can't possibly fit on one sheet. Sometimes I have to use a sheet again later like: render body and so on naked, bind sword sheet, render weapon, use body parts sheet again and render hands on top.

Questions:

1. In an old book by Mario Zechner I read that sprite sheets with a size of 512 x 512 px are good to go for, since older devices still support this size. Is this still up to date or can I go for bigger Textures (which I then split in TextureRegion Arrays to use for the Animations).

2. Currently I tested using one sprite sheet (the one above) and took 7 TextureRegion Arrays to store the images of all body parts, then I created 7 Animations, which I render all on top of each other in the corresponding order.

Is it good to do so? Should I rather combine all the textures in a pre rendered TextureRegion (or so) and use this in ONE animation instance?

What are the expensive calls? Are they hidden in the use of the many animation instances? Is it the use of many TextureRegion instances?

As far as I can see I only use the texture ( sprite sheet ) in the beginning anyways to then split it up in my TextureRegion Arrays, which are then used in the render method. So does it even make any difference if I would be using different textures which I'd split up at the beginning? Would this splitting-up and preparing take much time if done during the gameplay? Currently I set it up in the create method. How much / many TextureRegions can be stored in memory simultaniously (since if all sprite sheets fit into memory I could preload them like this during the splash screen). Do I even need to worry about this with my low Pixel Resolution Assets? How to get a feeling for this?

test screenshot

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

Atlas/texture size 2048x2048 is safe. (https://answers.unity.com/questions/563094/mobile-max-texture-size.html). You can even check it on the fly and select correct atlas, or even generate atlas based on current hardware.

private static int getMaxTextureSize () {
  IntBuffer buffer = BufferUtils.newIntBuffer(16);
  Gdx.gl.glGetIntegerv(GL20.GL_MAX_TEXTURE_SIZE, buffer);
  return buffer.get(0);
}

To optimize your idea, try different settings and count total render calls in draw method. At start of draw method set batch.totalRenderCalls=0 and at the end log/view it. Lower better.

If you need more optimization, create atlas dynamically, based on needed textures. Also don't do premature optimization ;)

\$\endgroup\$
1
  • \$\begingroup\$ It may also be worth considering an array texture here to switch between the various sheets without having to bind them between draw calls. \$\endgroup\$
    – DMGregory
    Sep 19, 2021 at 12:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .