Ashley's Recent Forum Activity

  • Frankly I'm just confused now. The thread seemed to start as having concerns about how to import spritesheets. I think importing over the existing animation frames from a spritesheet is a useful idea. Beyond that, I'm still not clear what you want.

    Those screenshots you showed look exactly like what the importer would do. You set the cell sizes and then the editor knows what individual frames are. Whether or not it displays the entire spritesheet in the editor doesn't seem particularly significant to me - why is it useful to see the rest of the frames when editing a collision poly, for example? What does that make possible that was difficult before? It seems fine to just edit that kind of thing frame-by-frame. That seems like a useful view to see when importing a spritesheet, but once the editor knows what the individual frames are... what's the benefit of still treating it like a whole spritesheet?

    Also as I said before, if you force C3 to use an unmodified spritesheet, it effectively is a deoptimisation. You also can't do things like "crop all frames" which allows for a much tighter automatic spritesheet packing which saves memory, and also actually decreases the GPU fillrate which improves rendering performance. Your screenshots could probably save at least half the space, since there's a lot of transparency there. And with other images there could be issues with color bleed. So as far as I can tell, a better spritesheet importer would solve your problem and not have any significant downsides. Am I missing something?

  • My point is even if C3 does all of that, if you then try to import a spritesheet again with a new frame in the middle, how does it know to shunt along all the metadata of the frames after it? That's a tricky problem. However you seem to suggest that is unlikely...

    There would be no need to rebuild all the data because it would be already developed- you would simply shift the frames or animations, and all the data shifted(if the artist decides to reorganize the sheet, etc, which wouldn't happen often because the organization is usually planned).

    ...in which case an "import sprite sheet and replace existing images" ought to cover the workflow of using spritesheets, right? Then the rest of the ideas sound like they're just a different way of presenting the same information.

  • Well, that's why going frame-by-frame also works well - it's unambiguous when you insert a new frame, you know exactly where it will go, or you can copy another frame including all its metadata like collision polys. If you work with spritesheets and add a new frame somewhere, it's not easily possible to tell what changed with the newly imported spritesheet - even if Construct kept animations as single spritesheets. Basically all it can see is it's got more or fewer frames, but it doesn't know where exactly they were added or removed, so where should it move the polys and image points and all that? So spritesheets may be useful as an import format but they don't seem so effective as a way to update existing animations - unless you do an "import the same frames over existing ones" type import.

  • >

    > What's the benefit of that if you can import and export whole animations as spritesheets?

    >

    Construct doesn't have exporting of spritesheets from the sprite editor.

    Yeah, I meant we could add that - so you can export and reimport as a spritesheet.

  • The main thing here is that the whole sheet is shown in the editor

    What's the benefit of that if you can import and export whole animations as spritesheets? That seems to solve the problem of managing art resources as spritesheets, but what's the purpose in showing a whole sheet? If you're going to modify the collision polygon for example, you can do that easily enough frame-by-frame, right?

  • I don't think I understand this question. A sprite is a textured object.

  • I think there's some confusion over how the term "spritesheeting" is used. In our blog post, we meant the optimisation of combining many images in to fewer images, which has many benefits ranging from performance to download size. I think this thread is more about the process of importing and using spritesheets in Construct.

    I don't think it's a good idea to give C3 an unmodified spritesheet and force it to use that. It's effectively a de-optimisation, because currently C3 is able to pack animation frames from a wide range of objects in to a single spritesheet, bringing greater performance benefits. Both C2 and C3 also do extra processing on the spritesheets it generates - for example often naive exactly-adjacent spritesheets have issues with color bleed between frames, especially when scaling them down. Construct does some extra processing like padding and repeating the outer rows of pixels to guarantee there won't be visual artefacts at runtime. If you use the spritesheet your artist sent you directly, it could actually cause these glitches, which we know from past experience users will immediately file bugs for. Also unless it adheres to various technical restrictions on power-of-two sizing, on some systems it could also display with different visual quality - again C3's spritesheeting algorithm is able to guarantee this won't happen. It's really quite a sophisticated pipeline with many non-obvious aspects. So I really think this is something the editor should be doing for you - it both improves performance and helps ensure the best visual fidelity.

    As for importing updated spritesheets to better use them in C3, I'm sure we can make some simple changes to make that easier. It sounds like an "import spritesheet over existing frames" option which keeps all collision polys, image points etc. and just updates image content from a new spritesheet would do a lot to help. Does that sound like what you need?

  • I mean, if I make a mobile game in C2 and export it, can I use the Scirra service to generate the APK ?.

    Yes, that's the idea.

  • We knew this was coming in advance and it was one of the factors in creating our own build service. We're also going to look in to using the C3 build service to build exports from C2 so you can use that as a replacement without having to import your project (which could be tricky if you don't have all third-party addons for C3). Also you can, as ever, still use PhoneGap Build, so nobody's left out in the cold. We're also going to look in to making it easier to use the Cordova CLI for local builds. And you still have a few months to use the Intel XDK.

  • Look at the "Microphone input" example that comes with C2. It shows a spectrum of the audio input.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • We'll be providing the Xbox Live features for both C2 and C3.

  • We know as much as you do about the Switch - Nintendo haven't said a thing to us about it, despite us asking about it!

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,776,087 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs