0 Favourites

Pre-baking sprite sheets for faster preview?

  • Yo. I've been wondering if it's possible for construct to bake sprite sheets for faster preview times before compiling the main build? Looking for options on how I can improve load times during preview.

    Thanks

  • Construct 3

    Buy Construct 3

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

    Buy Now Construct 3 users don't see these ads
  • Don't think you can. Would be great if you could though. I'm getting about fifteen seconds of waiting time for previews right now and I have many more animations to add so..

    +1 for this feature.

  • I'm not the only one! *high five*

  • There's a plugin that can load animations after game has loaded, you can try experimenting with that

    http://c2rexplugins.weebly.com/rex_spri ... oader.html

  • +1

    It makes no sense to break spritesheets down into individual frames/images in the first place, especially when C2 compiles them back into sheets upon export. It's too late now but if we had an animation system like Pyxel's that'd be awesome. You could change the source sheet as well for multiple characters / costumes.

  • Well I really enjoy the user-friendly aproach of importing individual frames. As I export most my animations out of after effects as PNG sequences, making sprite sheets manually is just a hassle. However I would really like the possibility to get these frames turned into sheets while working in the editor. Too much precious time is lost loading the preview again and again.

  • It makes some things a little easier I suppose, but ultimately is kind of limiting. Truth be told it's the same animation system as Klik 'n Play had...20 years ago. Besides, any decent image editing program can compile sheets for you (though Pyxel is still the best for animation/sheets).

  • Construct 2 does not build spritesheets on preview, only export. So you can rest assured the time spent building spritesheets when pressing preview is exactly zero.

  • Construct 2 does not build spritesheets on preview, only export. So you can rest assured the time spent building spritesheets when pressing preview is exactly zero.

    Seems to be a slight misunderstanding. If we say I have 100 frames of animation as 100 individual images. Wouldn't that take longer to load in preview than 10 sprite sheets containing 100 frames in total? I would imagine it speeding loading up if there's a ton of image loading requests on boot up?

    If this is not the case, what are the most dominant factors that make loading in a compiled build (node webkit) that much faster than preview?

    Hope you can clarify.

  • I think any speed up from spritesheeting on preview would be more than offset by the time spent building the spritesheets. Previewing is local so there is virtually zero latency and unlimited bandwidth, so I doubt there is much extra cost from having to make extra HTTP requests, plus most browsers can decode images in parallel on all CPU cores.

    I'm not sure what you're seeing when you talk about slow preview: if you're seeing a progress bar in the Construct 2 editor, then it's most likely building the JSON data for the project, but if you're seeing a progress bar in the browser itself, then it's most likely downloading and decoding images (as well as sounds if you have 'preload sounds' enabled).

    I find Node-webkit specifically can take a couple of seconds to start up, and you can avoid that by treating it like a browser - leave it open and press preview again in C2, and it will refresh the same instance of node-webkit rather than starting a new process.

  • Ashley If you do that too many times (usually 5 or so) NW will glitch up...instead of running the game a random, blurry, scaled up sprite from your project fills up the screen and flickers. Should I post a bug report or take it up with rogerwang ?

  • I think any speed up from spritesheeting on preview would be more than offset by the time spent building the spritesheets. Previewing is local so there is virtually zero latency and unlimited bandwidth, so I doubt there is much extra cost from having to make extra HTTP requests, plus most browsers can decode images in parallel on all CPU cores.

    I'm not sure what you're seeing when you talk about slow preview: if you're seeing a progress bar in the Construct 2 editor, then it's most likely building the JSON data for the project, but if you're seeing a progress bar in the browser itself, then it's most likely downloading and decoding images (as well as sounds if you have 'preload sounds' enabled).

    I find Node-webkit specifically can take a couple of seconds to start up, and you can avoid that by treating it like a browser - leave it open and press preview again in C2, and it will refresh the same instance of node-webkit rather than starting a new process.

    I'm referring to the browser loading yeah. Main reason why I'm addressing the image decoding. Webkit and Chrome are both very slow decoding images. Firefox usually gets it done much quicker, but I often encounter firefox freezing consistently for around 15 seconds shortly after booting up before straightening up. Not sure if it's some kind of image loading delay?

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