C3 Spritesheet feature isn't true spritesheeting :(

Post » Thu Mar 16, 2017 9:04 pm

vybr wrote:
Prominent wrote:I wanted to be able to create my spritesheets in a paint program and import that sheet, because then I could just edit the sheet in the program more easily to redraw parts if necessary, etc. That way I can just work on one image file instead of have to split it up into different images and import each one.


You can already do this, no?

Nope. As far as I know, the best you can do is re-import single-frame images.
B
39
S
16
G
6
Posts: 542
Reputation: 7,617

Post » Thu Mar 16, 2017 9:14 pm

You can currently import an animation from a spritestrip, but this doesn't solve all the issues. This effectively forces you to reset all the imagepoints as well as collision polygons (because they import as new frames), and it only imports for one animation. You still have to manage multiple images this way instead of just one.
B
43
S
19
G
65
Posts: 1,104
Reputation: 37,945

Post » Thu Mar 16, 2017 9:28 pm

Supposedly C3 was to give us a way to implement things like this via an editor sdk.
Its one of the main features imo, but it's only been six weeks of blogs, and 2 years of silently waiting for updates.
Image ImageImage
B
169
S
50
G
169
Posts: 8,286
Reputation: 108,216

Post » Thu Mar 16, 2017 9:40 pm

newt wrote:Supposedly C3 was to give us a way to implement things like this via an editor sdk.
Its one of the main features imo, but it's only been six weeks of blogs, and 2 years of silently waiting for updates.

An editor sdk that allows such feature to be implemented would be C3's saving grace for me. I don't know why they wouldn't announce that sooner rather than later.
B
43
S
19
G
65
Posts: 1,104
Reputation: 37,945

Post » Thu Mar 16, 2017 10:14 pm

Reading between the lines of the blog posts it seems like the editor SDK wont be a launch feature
B
59
S
21
G
9
Posts: 641
Reputation: 9,787

Post » Fri Mar 17, 2017 11:59 am

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?
Scirra Founder
B
395
S
232
G
88
Posts: 24,371
Reputation: 193,762

Post » Fri Mar 17, 2017 12:10 pm

This is a pretty nice feature. Currently I'm using sprites on different animations, and frames, so when I export I get spritesheets. So if I'm understanding this right it will have the benefits of tilemap object, but not restricted to power of two sizes?
Follow my progress on Twitter
or in this thread Archer Devlog
B
38
S
15
G
17
Posts: 949
Reputation: 12,320

Post » Fri Mar 17, 2017 12:25 pm

@Ashley
If by sprite sheet you mean a packed texture atlas and not simple animation strips then yeah, that would be a great help in my case at least. As long as we're able to import sprite frames from texture atlases outside C3 easily it doesn't matter if the ones C3 use internally are different.

Import from animation strips would also help if C3 was able to boundary crop each animation frame so we don't get a lot of wasted image space.
B
39
S
16
G
6
Posts: 542
Reputation: 7,617

Post » Fri Mar 17, 2017 12:38 pm

Not trying to be the party pooper here, but the competition allows both actually.. import an artist made sheet, define cuts and all and keep that structure for re-imports of updated artwork AND allow packing and output of an automatically optimized version of it or mixture with other atlases, depending on draw call optimizations etc, if the user so chooses.

That helps the noobs to avoid suboptimal sheets and at the same time allows more sophisticated pipelines things like using an external packer that might even be better than what the engine manufacturer has implemented ;)
B
75
S
28
G
32
Posts: 480
Reputation: 19,711

Post » Fri Mar 17, 2017 3:40 pm

Ashley wrote: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?

It would certainly be a step in the right direction, and help improve the process in my opinion.
Like Eisenhans mentions, it would be great to offer something more substantial, as the current method construct provides can be slow and cumbersome to work with if you have sprites with many animations and frames.

What I would envision is basically importing a spritesheet, and viewing the entire image in the editor, with tools to select frames from the sheet.. You could have the same UI, but instead of showing a single frame in the editor, it shows the whole sheet. If you add an animation, you can add frames in the same way, but adding frames draws a rectangle in the spritesheet that you can move around and adjust size. If you add an image point, it shows that as well depending on which frame you have selected.
The main thing here is that the whole sheet is shown in the editor, and the frames simply show a rectangle drawn over that sheet- and the collision poly and image points can show as well depending on the selected frame.
This wouldn't be that big of a change to implement in my opinion, because it would use the same UI essentially. The benefit here is that you can import/export one image, and work with one image in the editor or in an external paint editor- making the process more efficient.
What do you think about this @Ashley ?
I think it would be very simple for you to implement as it uses the same UI, you might even be able to include a way to switch between modes. I suggest a way to switch as it would offer more flexibility, but If not, I suppose you could create a new object and call if Spritesheet, similar to how you have the 9patch.
B
43
S
19
G
65
Posts: 1,104
Reputation: 37,945

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: Pooya72 and 2 guests