Prominent's Forum Posts

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

    How would it know which cells correspond to which frames?

    If I have a spritesheet with 10 animations on it, and 5 of them share the same frame, or if any of the animations have frames that aren't organized in a linear fashion, how would the importer understand how to import that?

    The method I proposed would cover that possibility. So, I'd like to know how your importer would handle that.

    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?

    Seeing the whole spritesheet allows more flexibility for editing the image, and making any potential changes to the organization of frames.

    You haven't shown how your importer would solve the issue of correspondence. So with your method there is potential to have to rebuild the polygons.

    How would your importer handle changes to frame correspondence? Say I have imported a spritesheet. Then I make changes externally that have modifications to the frame order, frame sharing, new frames inserted, frames subtracted, etc. If I reimport the spritesheet, how does your importer handle all of it without having to rebuild the polygons or imagepoints, frame speeds, animation loop/speed settings?

    So far you haven't explained how it would solve these concerns.

    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?

    It allows the user to edit ONE image without having to click through a bunch of panels to edit a whole animation. It essentially smooths the workflow so the user can focus on working on the graphics. If I want to make some pixel modifcations on all the frames, I can do it quicker if I don't have to click through all the animations and frames, changing tools constantly in the process.

    It also allows the possibility of adding a contiguous option to the floodfill tool that can make adjusting colors across all frames with one click.

    Basically any edits you can make to one frame now becomes easier because you are editing just one image.

    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?

    You could still optimize the spritesheets on export. Maybe some people might not want them optimized, so maybe it could be optional.

    You seem to imply that the methods I proposed would prevent you to optimize the spritesheets further, but that is a lie. You can cut the spritesheet up into individual frames and reoptimize them when exporting the project if you wanted to. The purpose of having workable spritesheets in the editor is to make editing graphics/sprites a lot easier- to make the workflow smoother.

    Everyone who wanted spritesheets, wanted a workable form inside the editor to solve the workflow issues, and they expected it to be in c3 because you said it would be in it. If you don't want to implement it, just say so and I won't waste my time anymore.

  • What Prominent is trying to explain is how to use a single image as a basis from which C3 is to derive multiple frames. To work with a single spritesheet (image) is the very point. Placing it in the animation (film strip) window nullifies the main idea because the film strip shows discrete frames, and whole point is to have a full spritesheet to work from.

    In my view, in this system that prominent is suggesting, the film strip could be the means of viewing the animation frames as defined by the 'spritesheet editor'. But yes, the window to edit the spritesheet may look different (ie different spritesheet-centric functions) for the user to immediately see the context of the edit.

    I think each Animation could have a property that controls which image and context its sourcing from: single frames, spritesheet. If single frames, then a list of image frames is populated, and we are working in the same way we do in C2.

    If we use the spritesheet as a source, then that's a different data, where we are sourcing a 'spritesheet object', whereby a single image is used, and then bounding boxes defined which extract the pixel information, then generates a list of images based on the extraction.

    Yes, exactly. Thanks for explaining it so well

    And I really like your idea of having a property for each animation where you can choose the image/context!

  • If you're not open to suggestions that's fine, just don't expect it from others.

    I never asked for suggestions. You criticized my suggestions, so I'm criticizing yours because I feel your arguments don't carry much weight. All you have said has been very vague and aren't very constructive. So maybe you should invest more time in your posts and make clear what you mean when you criticize other people's work.

    I've gone into detail about how I see a spritesheet feature implemented, even working within the design of Construct's existing UI; showing images to illustrate my points.

    I've been in this business 20 years. I think I know a thing or two about this stuff.

    So you can make your vague posts and pick at little things, but I'm trying to make a point here for the benefit of all users- don't get in the way of that please.

  • >

    > > Show the strip in the animations window rather than the image editor.

    > > The image editor is for editing images.

    > > It would seem appropriate that the animations window would be for all elements of editing animations.

    > >

    > You'd still be able to edit the image in the image editor. So I don't understand your point, because you already use the image editor to place imagepoints and collision polygons- why not use the image editor to position where the frames correspond to as well. So the way I present it allows for the user interface to remain the same instead of changing things as you seem to be suggesting.

    >

    It would be easier to redo an element that does very little rather than change one that does a lot already, to add something it's not designed to do.

    Its designed to show one frame at a time.

    Im saying anything that is to show multiple frames should be in a separate window.

    It still would only show one image. I don't think you understand the implications. The benefit here is you work with ONE image. My suggestion requires less work than your sugestion. And this can be used in a new object type named Spritesheet, it doesn't have to be the Sprite object.

    It would need to be this way so you can still paint across the entire spritesheet, edit it as a whole, etc.

  • Show the strip in the animations window rather than the image editor.

    The image editor is for editing images.

    It would seem appropriate that the animations window would be for all elements of editing animations.

    You'd still be able to edit the image in the image editor. So I don't understand your point, because you already use the image editor to place imagepoints and collision polygons- why not use the image editor to position where the frames correspond to as well. So the way I present it allows for the user interface to remain the same instead of changing things as you seem to be suggesting.

  • Why couldn't the animations window show all that rather than some dumb film icon?

    I don't understand what you mean. What are you referring to when you say "all that"? and what do you mean by "film icon"?

  • >

    > My point is that it wouldn't need to do that automatically. The user could manage that more efficiently if the frame/animation data is controllable independently of the spritesheet.

    >

    Based on what you wrote, I imagine a new window with the imported spritesheet displayed and coloured rectangles on top of it with the collision polygons to represent the frames. Then the user could drag and drop those rectangles to reorder them manually on the spritesheet while the frames would keep their data (collision polygons, image points, etc.). Is this what you're proposing?

    Maybe- let me show some images of what it would be like just to be clear (I made these sprites by the way).. This is just a rough concept, but shows how the gui doesn't need to change at all.

    In this first image, it shows all the boxes for the currently selected Animation in the animation list:

    Also note how I've added a new tool on the toolbar- these new tools could be used to position/resize the boxes that define where the frames reference the spritesheet.

    In the next one I show what happens when you select a frame from the frames list on the bottom:

    You'd be able to position/resize it via new tool(s) on the left toolbar and the x,y,width,height inputs above.

    Next I show how the polygon is displayed for the currently select frame when you have the polygon tool in use:

    As you can see, the frame thumbnails in the frame list show the corresponding area on the spritesheet. None of the gui has changed. The main window shows the spritesheet.

    And yes glerikud, if you reposition one of the boxes, it would reposition the corresponding imagepoints/polygons as well.

    There could possibly also be a way to click a button to hide the rest of the spritesheet and just show what is within a box.

    Ashley

    edit: also, faulknermano explained it well and added another idea that would make it even more flexible:

  • As far as I understand, the more the renderer has to change tiles when it renders them, the slower it goes. So if you have a big space of the same tile, it will render quicker than a space consisting of different tiles.

    Also, if you stack and overlap tilemaps, that also adds to the rendering process, therefor slowing it down.

    This is what I have experienced.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

    >

    My point is that it wouldn't need to do that automatically. The user could manage that more efficiently if the frame/animation data is controllable independently of the spritesheet.

    Your proposed addition doesn't solve the issue of managing frame/animation data whenever the sprite animations are changed externally, because how would it know the correspondence with those changes.

    In either your case or my case, it wouldn't be able to know the correct correspondences to all the potential changes. In my case however, the frame/animation data is independent and can remain present regardless of additions/subtractions from the spritesheet. This would allow flexibility in the workflow.

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

    But your proposed method can't determine correct correspondence to all potential changes to the spritesheet being imported. What if frames are reordered in the spritesheet, removed, added, changed, resized, etc. You proposed method wouldn't cover these cases.

    However, my proposed method allows for this flexibility. Regardless of whatever changes are made to the spritesheet, the frame/animation data remains as defined by the user and can be adjusted manually for whichever changes they made to the spritesheet without having to recreate the data. Nothing is lost while the spritesheet is being developed- the animation/frame data can be modified to reflect the current designs of the spritesheet.

  • 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

    That's not true though- you must be seeing this in a way that makes you believe that the spritesheet format would be ambiguous. It doesn't have to be.

    You could still create frame and animations in the same procedure as it is done currently, however it would simply place the frame over the spritesheet. You'd still have the frames displayed in the animation panel, and could reposition them(to determine the play order), select them, etc. When you select them, a box on the spritesheet would display to indicate where that frame is located on the spritesheet. If you select the animation in the animation list panel, all the boxes could display in the spritesheet, allowing you to easily see the correspondence.

    The great thing about this method is you can make changes to the spritesheet with lesser impact on the corresponding frame data, because that data would remain in tact and can be adjusted independently. 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). Or you could remove or add the frame data, even duplicate it. This would all be done independant of the actual spritesheet, so you can work with the spritesheet without effecting the frame/animation data.

    At the moment the sprite image is tied to the data too closely- the spritesheet method allows more flexible workflow that is simpler and less of a hassle with working with many frames/animations. Most sprites have lots of frames and animations, so the spritesheet method I describe makes more sense.

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

    Yeah, but what happens if you add or remove frames, or whole animations? How does Construct interpret those changes?

    If I export all the animations to one sheet. How do I import all the animations from a sheet.

    How do I import a whole sprite sheet with multiple animations(not just frames), into the editor without any prior animation data existing?.. How do I tell construct which frames correspond to which animations in the spritesheet?

    If I'm forced to split the sheet into multiple sheets per animation, it doesn't solve the issue.

    You're saying all this can be done and still have imagepoints/polygons stay intact? frame speeds? loops settings?

  • 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. It only exports per frame, so you have to reassemble them in an external paint editor before doing further work to them, especially if you want to animate them in the external editor. So it becomes redundant work that takes away time.

    Then you have to reassemble them into a form that can be reimported back into construct- more time taken away. And what happens if you add or remove frames in the process- there becomes inconsistencies.

    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?

    Showing the whole spritesheet has many benefits:

    +You can paint anywhere on it without flipping through frames/animations. This lowers the amount of times you must click and reposition the mouse- allowing work to be done more fluidly without pauses. You can apply changes to pixels/details across multiple frames this way more fluidly without swapping between tools/panels.

    +If you show the whole sheet, you can rely on one image. So you can export that one image instead of clicking through each frame/animation exporting each one having to reassemble them all into something workable in an external editor.

    +You can then reimport just one image, and still have all the frames/polygons/imagepoints still positioned on the sheet where you have assigned them previously. If you have added another frame somewhere in the sheet, or inserted a frame, you can include tools to drag/position those frames to their new locations(you can reposition the frame and it would reposition the corresponding imagepoints/poly relatively). You could just click a frame and drag it across the spritesheet to the new location- duplicate if necessary for new frames.

    The frames would have a relative position to the spritesheet, and the imagepoints/poly would be relative to the frame.

    Basically this way would lower the amount of redundancy involved, improving the workflow. It would also open up other possibilities, like applying effects across the entire sheet- like changing the color palette.

    Also, it might open the possibility of exporting/importing to certain formats that spritesheet editors use.

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

    I don't see the problem. People can't fork out $129 (or is it $99) a year to have the ability to make an UNLIMITED amount of games every year.

    Just curious, but how many games have you made with construct since you began using it a year ago? I mean games that have been completed.

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