Feature request C2/C3: Texture atlases in editor

  • I've made this one before but I think it's important so I'll make it again

    I'm developing a game that's heavy on character animations, 200+ frames for playable characters-heavy. I plan to have several color choices available for these but the only way I can achieve that right now is to duplicate the sprite object in question, and then *manually* replace each and every frame with the new color sprite. Try doing that for hundreds and hundreds of frames

    There's also the issue that I don't put finalized graphics into C2 and then never touch it again. I modify and refine and tweak along the way. This is something graphics artists tend to do, especially when throwing something together to prototype new functionality. But again the image editor in C2 makes it very cumbersome.

    This could all be rectified by exposing sprite sheets/texture atlases in the editor. Now I know the way things work right now is they get assembled on export and not before, so I guess it would be a big undertaking to work into C2. But could we have it for C3 maybe? Please?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 200+ frames is bound to have other issues as well.

    You might want to consider a webgl alternative.

  • For real? You mean I'll run into memory issues with webgl?

  • newt is suggesting using a webgl shader. If you used a shader to change the colour you can avoid the impact of extra colour changed versions of your sprite.

    Can I ask. What is the resolution of your character. I can imagine 16x16 based character sprites running at 200+ frames. But I can't image much larger using 200+ frames. I can barely think of any games that need so many animations. And the few that I do know tend to very limited graphicially. Such as fighting games which are just 2 characters and a background set pieces.

    So you have a sample of what needs 200+ frames.

  • You shouldn't duplicate frames to change a couple of colors - you'll use a lot of memory and add a lot of download size for that. WebGL shaders can replace colors or apply a tint, so that would probably be a better idea. Or you can just compose the changing bit as a separate object.

  • Double-post

  • newt is suggesting using a webgl shader. If you used a shader to change the colour you can avoid the impact of extra colour changed versions of your sprite.

    Oh right haha. I did consider it, but it won't work unfortunately. A shader along the lines of Tint will recolor the entire sprite with an even color ramp. It'll look cack. If I could write a shader that used some kind of lookup table for the palette I could change single colors but I don't have the skills to pull off something like that.

    Can I ask. What is the resolution of your character. I can imagine 16x16 based character sprites running at 200+ frames. But I can't image much larger using 200+ frames. I can barely think of any games that need so many animations. And the few that I do know tend to very limited graphicially. Such as fighting games which are just 2 characters and a background set pieces.

    So you have a sample of what needs 200+ frames.

    I'd say an average of 30x60 for each animation frame. So far I have 500 frames loaded at once with no noticable issues, even on an old netbook(!). I posted a screenshot in this thread with the sprite size in question:

    You shouldn't duplicate frames to change a couple of colors - you'll use a lot of memory and add a lot of download size for that. WebGL shaders can replace colors or apply a tint, so that would probably be a better idea. Or you can just compose the changing bit as a separate object.

    I know. It's a bad way to go about it, but since we don't have 8-bit modes to tweak palettes in I don't see many good alternatives. As mentioned the Tint shader won't work for me but a color replacement shader would. I might look into paying someone to make one.

    In the meantime, I still think it would be a handy feature. It makes things more manageable for art assets that need updating.

  • ErekT I think people were refering to the set color effect rather than the tint one.

    As for texture atlas, well, having the same texture being centralised in the project so it can be edited once to apply everywhere is a nice idea I think, but the current way textures are saved in c2 seems to not go well with it, but that may not be an issue in the end.

  • 200+ frames is still too much to put into a single object, the atlas/tile sheet would be huge, and loaded into memory all at once.

    You'll have to use multiple objects loaded when needed, rather than when starting a layout.

    It will hang, unless timed very efficiently. Plus we have no set way to handle that other than families, and loading via url.

  • I think you should aim to have 5 animation frames per second. Or aim to have 5 frames for any particular animation. Otherwise I suggest using Spriter. A lot of games are made in a less than 10 frames per animation constraint. Most games even when they run at 30/60fps don't actually have 30/60 frames. They often range from 3 to 12 per animation. 3 for quick animations and 12 for really smooth animations, but those smooth ones are aimed at very few objects on the screen.

    Otherwise I suggest Spriter.

    Now that I understand your art a little more I can see the desire to maintain a higher quality retro style. good luck. There is a colour plugin you can try. It shifts specified colours to a different range. May or may not have a range level to it to effect close colours. may be one of Podes plugins.

  • If you make the part to be colored a separate object overlaid on top, then you can tint it without affecting the rest of the object.

  • 200+ frames is still too much to put into a single object, the atlas/tile sheet would be huge, and loaded into memory all at once.

    You'll have to use multiple objects loaded when needed, rather than when starting a layout.

    It will hang, unless timed very efficiently. Plus we have no set way to handle that other than families, and loading via url.

    Checking the package.nw I see I get 75-100 frames squeezed into each 512x512 sprite sheet atm, depending on the animation and base sprite size. That's three 512x512 png's per playable character object. Only one or two of those objects in circulation during runtime so even weak computers shouldn't get stressed out by it. Unless I'm missing something that is. Has been known to happen

    I think you should aim to have 5 animation frames per second. Or aim to have 5 frames for any particular animation. Otherwise I suggest using Spriter. A lot of games are made in a less than 10 frames per animation constraint. Most games even when they run at 30/60fps don't actually have 30/60 frames. They often range from 3 to 12 per animation. 3 for quick animations and 12 for really smooth animations, but those smooth ones are aimed at very few objects on the screen.

    Ah my animations actually do range from 3 to 12 frames depending on the action, for instance 12 for walk/run cycles and 5 for jumps. It's just I have a lot of animations

    Spriter is a cool approach, I remember seeing big enemy dudes being animated that way in various Castlevanias to save on memory. But not sure how well it would work for smaller sprites. I've also gotten real comfortable animating in blender and rotoscoping the renders. It turned out to be a good method to produce good looking animations fast so I'll stick with that for now.

    [quote:1lobt7xm]There is a colour plugin you can try. It shifts specified colours to a different range. May or may not have a range level to it to effect close colours. may be one of Podes plugins.

    Really? I'll check that out if I can find it, thanks for the tip!

    Thanks for the suggestions everybody

    EDIT:

    Just found this on the OpenGL page. Super-simple, might be just what I need I'll see if I can figure out how to implement it as a plugin.

    //Fragment shader
    #version 110
    uniform sampler2D ColorTable;     //256 x 1 pixels
    uniform sampler2D MyIndexTexture;
    varying vec2 TexCoord0;
     
    void main()
    {
      //What color do we want to index?
      vec4 myindex = texture2D(MyIndexTexture, TexCoord0);
      //Do a dependency texture read
      vec4 texel = texture2D(ColorTable, myindex.xy);
      gl_FragColor = texel;   //Output the color
    }[/code:1lobt7xm]
  • Its all about the total memory. If you can keep that under control then should be fine.

    Also Podes plugin uses a html5 canvas, or css feature so I don't think it will work under webgl.

    So basically no gpu acceleration for objects that use it.

  • Yeah I saw it also functions as a color overlay so I couldn't use it anyway.

    In the meantime I discovered the ReplaceColor plugin in the C2 effect list. No idea how I missed it but it does exactly what I need. Absolutely lovely stuff!

    Only, there's a small problem with it that I suspect is to do with where in the render effect chain it's being applied. Is there any way to control in what order effects get rendered? Probably not, but thought I'd ask.

  • Its usually top down by layer, but I think that can vary by blending mode. Ashley was grumbling about it some time ago on Twitter.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)