Ashley's Forum Posts

  • I quite like using the colored icons to identify each section and having an 'Add' shortcut in the header. I'll see if I can work that in somewhere.

  • The SDK is architected such that while you could in theory do any manipulation to the app, using anything outside of the official SDK APIs will likely just break things. In other words while it's technically possible to do anything, it's not useful unless you work with the SDK.

  • Please report bugs to the Bugs forum following all the guidelines.

  • The current spritesheeting method has worked fine for some of our large test games - but as I say if there are any issues we can make some changes. We'll see how it goes in the public beta.

    Jank has in the past been a major concern for a lot of users. So we have carefully designed the engine to pre-load all the textures it needs based on what's placed on the layout. If you don't care about jank, we still have to design the engine for people who do.

  • It's a shortcoming of spritesheets that you can only load entire spritesheets in to memory. In the extreme case there would be all content in a single sprite sheet, and you therefore load all content in to memory at once. However spritesheets themselves save memory by packing multiple images together, and they tend to be fragmented over a set of different spritesheets anyway. For example one of the demo games we test with is very large, and still uses 100 sprite sheets, which allows for quite a lot of granularity around what is loaded.

    TBH unless your player animations are absolutely huge with loads of frames, splitting things out in to separate objects is probably a micro-optimisation that doesn't make much difference. It also can jank the game as it loads textures mid-frame if the object isn't already preloaded by being placed on the layout. And currently the engine doesn't release textures until the end of the layout, so the peak memory usage will be the same.

    I don't think the spritesheet system will cause any memory issues, but if there are cases where it causes a problem then we can look in to figuring out how to address that. If we had to do that, I'd try to avoid any kind of manual configuration, the groupings can probably be determined by which objects are used together on layouts.

  • AFAIK, PhoneGap Build has identical support to the XDK. So you can just use PhoneGap Build now. They are both based on Cordova.

    The main reason we postponed our own build system is the XDK did the job for free. It's a shame they are retracting a free service, but since nobody ever paid for it, it's not really that surprising.

  • It could be enabled, but even just enabling it comes with some downsides:

    • currently we reduce rendering overhead by omitting Z positions - they're all assumed to be 0. Sending Z positions of 0 with every sprite is extra data and a bit more performance overhead.
    • there's no depth buffer, since we don't need it. Enabling it might make GPUs do more work to redundantly check the depth buffer, when it has no effect, adding a bit more performance overhead.
    • in the past I researched new rendering features like front-to-back rendering, which made use of the depth buffer for optimisation. Using it for 3D could significantly complicate future optimisations along the same lines.

    Having said that, we could possibly have it enabled per layer (so you could for example enable 3D on just one layer, then all 3D content has to appear on that - all other layers are still 2D and are treated as underlay/overlays). But I think it's odd to add a checkbox that says "Enable 3D" when nothing in the editor actually uses that!

  • Looks like Safari doesn't support it yet, sorry. Apple need to add support. We really avoid cordova plugins wherever possible because it can be extremely difficult to guarantee 100% compatibility with the browser-standard features, and usually browser vendors add it eventually anyway, making it very hard work which is ultimately wasted.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • >

    > 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?