Request/discussion: Changes to editor resource handling

Started by tzachs, Tue 05/03/2013 12:42:25

Previous topic - Next topic

tzachs

Quote from: Calin Leafshade on Mon 04/03/2013 11:41:33
That would require checking all the files every build for changes which might be problematic on a large project.

Not necessarily. You can use FileSystemWatcher, register for file changes events, and reload the sprites in the background.

Calin Leafshade

#1
That is true, I forgot about that.

However do we really want to be messing with the sprite cache without the user's permission? Seems like that could be an issue, especially for inexperienced users.

Ali

It might be tricky to do a changeover like that, inexperienced/student editors can struggle with the idea that NLE software like Premier and Final Cut link to files rather than the projects actually containing the media.

I think it would be worth it, though. In fully implementing this kind of system, it would be nice to be able to have the additional option to re-link to files at a different path or with a different name.

Snarky

I won't guarantee the accuracy of this in every detail, but if I remember correctly, in Visual Studio, the IDE detects that the resource has changed, puts a little icon on it in the project tree, and lets you decide whether to refresh it. (I don't remember whether it explicitly asks you every time you build, though.) I think Eclipse just uses whatever is in the current resource file (that being the Java way). I think either of those would be a perfectly acceptable solution.

The implication of doing it this way for sprites should be to do the same thing for audio files, and maybe even room backgrounds, it seems to me. (More or less getting rid of the binary project blob.) That might quite possibly be a bit too radical a change for the next release, though.

tzachs

We could add an option in general settings to let the user decide.

I currently work a bit with Flash Develop, it uses the assets from the file system and it's definitely a lot more convenient. I think the major reason that it doesn't bother me is because all the assets are located under the project folder (in a separated Assets folder), so the distinction between in-game art and in-progress/backup art is quite clear.
No need for an "Import Sprite" at all, just putting the file in the folder is enough, which makes me question if we even need the sprite manager (thinking long-term here).

Crimson Wizard

Quote from: tzachs on Wed 06/03/2013 11:29:15which makes me question if we even need the sprite manager (thinking long-term here).
To cut image pieces, to define transparent colors, to import animated GIFs as a set of frames.
To provide sprite IDs.

DrJone.s

I just thought it would be good to mention that having to load separate files/textures for every frame/sprite has more memory overhead than having cached sprite sheets, and it's noticeably slower, especially when using software rendering and on mobile platforms.

http://stackoverflow.com/questions/3473151/what-are-the-pros-and-cons-of-a-sprite-sheet-compared-to-an-image-sequence
https://www.scirra.com/blog/87/under-the-hood-spritesheets-in-construct-2
http://wiki.wesnoth.org/GSoC_Sprite_Sheets_Shuger

The inconvenience is that all frames on a sprite sheet have to be in memory at the same time (even if they aren't currently needed), editing spritesheets isn't as easy in the case of frames that have to be shortened/enlarged, and also that you need a separate file with the frame offsets if all frames aren't the same size (which slightly impacts performance).

As a result, it might be faster (runtime) to have the engine generate its own sprite sheets from the sprites in the sprite manager, grouping the sprites sheets by folder. The problem is that compilation would be slower due to the extra step, so either that optimization is left to an option called "compile for production", or the engine has to check which sprite folders haven't changed to not generate their sprite sheets again.

I have no idea if AGS already does this, so excuse me if none of this is relevant to the engine.

Crimson Wizard

No, the engine does not do anything like that, and using spritesheets would require to rewrite the way bitmaps are referenced and drawn for animateable objects.

tzachs

Quote from: Crimson Wizard on Wed 06/03/2013 11:33:35
Quote from: tzachs on Wed 06/03/2013 11:29:15which makes me question if we even need the sprite manager (thinking long-term here).
To cut image pieces, to define transparent colors, to import animated GIFs as a set of frames.
To provide sprite IDs.
The sprite IDs could be the file paths.
All the rest can be dedicated tools activated by menu items, no need for a dedicated window.

Crimson Wizard

#9
Quote from: tzachs on Wed 06/03/2013 14:06:17
The sprite IDs could be the file paths.
People are using arithmetic formulas to get numeric sprite IDs for drawing.
This would require implementing objects like "ordered sprite sequence".
I had an argue with Iceboty (Gilbert V7000) sometime ago about using numeric indices...

tzachs

Well, folks that want to do that would still be able to name their files sprite1.png, sprite2.png, sprite3.png and use the arithmetic formulas.

cat

Are we talking about absolute or relative paths?

tzachs

If we agree that all assets will be under the project folder, then I think relative paths make more sense.

Crimson Wizard

I think this deserves a separate thread, and more thorough discussion.

Potential concern is:
- sharing same resources between two and more projects;
- parent and partition objects, for example sprite sheet bitmaps, that may be "virtually" split to number of sprites, or wave file, that may be split to virtual clips.

Snarky

If we're thinking about major changes to the sprite manager, could we also look at how views and characters are defined? This was one of the things I had the hardest time wrapping my head around when I first started using AGS, and it still doesn't really make sense to me.

I always feel like there's unnecessary duplication of effort between organizing the sprites, creating the views, and assigning them to the character. The number of steps you have to go through seems excessive, and non-obvious to a beginner. Like, "I drew the walk cycle and imported the frames, why can't I just assign them to my character?" Part of the problem is that I often want to make a character before I have made the full set of views, maybe with just a single placeholder sprite, but I still have to go through the process of creating views and assigning that sprite to all the different loops.

Really, Views seems like a strange construct, because it is exclusively or at least primarily relevant to characters (which can be viewed from many different angles). That every animation has to be part of a view, within a loop that is hardcoded as being for a certain angle, like it was a walkcycle, is just weird.

I guess my suggestion would be to get rid of Views, and instead just have loops/animation sequences, which could maybe be generated automatically from the frames by making a selection in the sprite manager (by marqueeing a bunch of sprites, or simply picking a sprite folder).

Then you could assign sprites and animations to characters the same way you assign views now, but it would make more sense because it'd be tied specifically to that character, and they'd all be optional, so that if you only wanted a basic pose, or just a left-right walkcycle, that'd be fine. (I'd also suggest that you should be able to auto-generate animations from that dialog too, just by selecting multiple sprites.)

I can see cases where not having Views as an abstraction separate from characters would lead to a bit more work (like if you wanted to have multiple characters who shared the same graphics/animations), but overall this seems simpler, quicker and more natural to me.

cat

I never understood why every new view has up/down/left/right loops, even when it is just for object animations. This confused me a lot when starting to use AGS.

Crimson Wizard

Yes, views are one of those hard-coded things in the engine. IIRC it crashes, or throws an error if there's no appropriate walking loop found during the game.

Calin Leafshade

I like the concept of views but the implementation is weird.

They should probably be renamed "animations" and be groupable in folders like any other resource for organisation.

Snarky

What AGS calls loops make sense as a way to represent a sequence of frames. I think we could streamline how you create them, edit them and manage them, but the basic abstraction is sound.

But if I want to animate a door opening, or a star twinkling, or a branch breaking, etc., why do I have to pretend that it's a "walk right" (or whatever) walkcycle?

The whole concept of views only really makes sense for characters, where you need versions of the same animation for different directions (most obviously walkcycles and talkcycles, but also things like pick-up animations, etc.). And in those cases, it's really something that should be defined as part of the character, no?

What if views as we have them now (more or less) were something you set under the character pane, where you could collect every character animation (or at least any animation that you have in different angles) conveniently?

Crimson Wizard

I think Views may be thought about as a model of (visual) behavior. Like in 3d, where visible objects have models with set of animations, similarily a 2d object may have a model with set of animations.

AGS problem seem to be certain overcomplication, and inconsitency. A Character may be assigned a view, but Object cannot, it has to use Graphic instead; and still the object has to refer to view when animating.
The loop names, on other hand, are mere distraction. As soon as you learn they have meaning for characters only, you may simply ignore them, when you work on object animation. Same thing for views, containing custom animations for characters, meant to played only at defined moments.

However, this does not make views useless for objects, for they may be a solution to group logically related animations.

In my opinion, the Views may be reworked to be more customizable and transparent to user (game developer).
Instead of having strict set of loops, with hard-coded names, they may have a custom set of entries, or States, named by user, each entry being either single graphic or animation (the sequence of frames). For characters, there could be predefined names for walkcycle and speech, that may be inserted in the view (or not), which order being not important anymore.

I do not think the View should be a "part of character", because same view may wanted to be shared between different characters, and also character may switch walking views.

SMF spam blocked by CleanTalk