Feature Request: Store sprites as separate files

Started by JanetC, Thu 19/10/2017 19:12:44

Previous topic - Next topic

JanetC

It's currently really hard to keep AGS projects in source control, due mainly to the enormous size that acsprset.spr can grow to in any large projects. Could the sprite image sources be kept as links to separate image files on disk, as with the sound files?

eri0o


cat

The question is: can the spr file be rebuilt from the info in the Game.afg and the sprite images in the folder?

Crimson Wizard

#3
Quote from: cat on Sun 22/10/2017 20:33:00
The question is: can the spr file be rebuilt from the info in the Game.afg and the sprite images in the folder?

TBH I do not remember about sprites which keep references to sourcefiles, but the sprites package can also contain sprites copied from clipboard, in which case they do not have any links to real sprites (and there may not be any original files on disk whatsoever).

This should be also kept in mind if this feature is implemented, because unlike AudioCache which you can safely delete if you have original audios somewhere, you won't be able to just delete all sprites from cache.
So probably there should be a special folder in your project where Editor will add sprites created by clipboard copying, or something like that.

cat

In this case I would advice against git-ignoring it. The purpose of source control is being able to restore your project to a specific historic state. But if the sprite file is not included, game data is basically broken and cannot be restored which renders source control pointless.

eri0o

git-lfs would allow to version control your source and store the large binary file, but not version your large file, because each version would require it entirely so it would quickly reduce your available storage.

Alternatively, you can use Dropbox paid account for your project since it allows versioning - if you have a spare server and don't want to spend money on Dropbox, Nextcloud provide the same functionality if you install yourself.

Snarky

... Or we could correct a very poor design decision in AGS so people don't have to hack half-functioning workarounds.

eri0o

#7
if there is support for multiple sprite files, it should be simple to break it in a new one on each import, right? I also think that, if the source links are still available it should be able to rebuild from source - which would help for reimports instead of having to load the sprite window and go on each clicking replace from source.

Crimson Wizard

#8
Quote from: eri0o on Fri 03/11/2017 10:23:40
if there is support for multiple sprite files, it should be simple to break it in a new one on each import, right?
To be precise, currently there is no support for multiple sprite files, there is support for multiple resource files (they may contain other data, like rooms etc).
Technically it is possible to implement sprite archive splitting, as well as creating new part whenever new sprites are created (if I understand your idea right?).
But the point here is to move away from having compiled data packages in the project source, making project sources more open.

Same refers to the room files, actually, currently they are kept as compiled binary blobs in the project source, making it difficult to collaborate on a same rooms (team members should take turns updating them).


Quote from: eri0o on Fri 03/11/2017 10:23:40
I also think that, if the source links are still available it should be able to rebuild from source - which would help for reimports instead of having to load the sprite window and go on each clicking replace from source.
As I noted in my post above, not all sprites keep their links. Sprites copied from clipboard and sprites imported using "tiled import" feature do not have links stored.

Crimson Wizard


JanetC

We know about Git LFS and Dropbox and use both. But it would be much nicer if the sprites were stored as individual files like the sound files are. At the moment "Unavowed" has a sprite file that is several gigabytes in size and stresses even LFS.

The other unmergeable binaries, like room files, are also a small problem too because Dave & I have to be very sure that only one of us is using them! But that's not nearly as much of a problem as the enormous sprite file.

Dave Gilbert

One alternative option, if storing the sprites as separate files isn't doable.

Can there be an option to split the sprite files into smaller chunks? Much in the same way you can split up the game's .dat file?

Crimson Wizard

Quote from: Dave Gilbert on Thu 30/11/2017 16:24:18
One alternative option, if storing the sprites as separate files isn't doable.

Can there be an option to split the sprite files into smaller chunks? Much in the same way you can split up the game's .dat file?

Storing sprites as separate files is doable of course, there should be some kind of specification (rules) made first to know how exactly we are doing that (sprite cache folder similar to audio cache, etc).
Because that will completely change the way how Editor works with sprites, we need to be very careful in planning here.

Regarding splitting sprite file, that won't necessarily be much easier, because unlike game data, which is the final output, Editor uses sprite file during its work.

Crimson Wizard

#13
Alright, this is not going anywhere, and people keep getting into this problem.

So this is my work suggestion.

In Game.agf sprite reference includes following additional information:
- Rectangle, the location of the original image the sprite was "cut out".
- Transparency setting the sprite was imported with.

Game project has a new folder:
- Resources/Sprites - Editor puts automatically created sprites there that serve as actual source files.
This is images copied from clipboard mainly. But you also allowed to put your own sprites there (Editor must take precaution not to overwrite existing file when generating new one). Alternatively, call folder Resources/Sprites/Generated.
"Resources" may be replaced with "Assets" if you like that word more.

Bonus feature: contents of Resources/Sprites match the folders in the Sprite manager.

Workflow:
- Editor loads sprites by reading information from Game.agf and referenced source files.
- If sprite is imported from file, game saves reference to that file.
- If sprite is imported from clipboard, game creates a new sprite in Resources/Sprites/...
- Same if sprite is imported from GIF.
- If sprite is tile-imported, game saves reference to source file and position of every sprite in there.
- If sprite is opened for edit in the paint program, game saves the changes in Resources/Sprites/.... It creates new sprite if original sprite was outside of that folder, or changes existing one if it was originally in that folder. Alternative: save changes back in the sprite is anywhere inside project folder.


Compiled sprite file is removed from the game project. It is only created when the game is compiled.
Probably for convenience we need extra subfolder in Compiled, something like "Intermediate" or "Temp" where the intermediate result of compilation is stored.


Related questions: importing/extracting compressed sprite file from the older project.

morganw

My suggestion:
- Remove the sprite manager entirely (or reduce it to become a sprite viewer)
- Game compiler builds the sprite file (so as you describe)
- Sprites are are just read from disk and not duplicated anywhere

I'm not sure what the benefit is of maintaining copies of the sprites? If just to assign ID numbers, why not just start the filenames with a number, and read the filenames?

Crimson Wizard

#15
@morganw, you say "duplicates" and "copies" but what are these? I did not mention copies anywhere.
EDIT: Okay, I used word "copies" in:
Quote
Editor copies automatically created sprites...
I changed it to "puts", because these are not copies.

Quote from: morganw on Tue 03/07/2018 19:30:54
- Remove the sprite manager entirely (or reduce it to become a sprite viewer)
What's the difference between manager and viewer? Or rather, what will be removed from it?

morganw

I'm suggesting there be no import controls at all. If there was an internal sprite editor (some sort of mini paint program) there would be an argument for keeping sprite management, but everyone is already using external tools and is then forced to go through the import process. If people are already saving their sprites and masks to disk to do an import, they may as well just save them to the game folder:
QuoteD:\MYGAME
|   MyGame.agf
|
\---Sprites
    |   apple.png
    |   banana.png
    |   pineapple.png
    |
    \---Grapes
            green_grape.png
            red_grape.png

If storing the mapping of ID number to path in the project file, you would only have to assign numbers for any new file paths which show up. Potentially though, just reading 10_apple.png as sprite 10 means no ambiguity about the sprite number, and the project file wouldn't have to track it at all. Compared to how it works at the moment, even renaming a directory full of files is a lot easier than trying to re-arrange numbers assigned by the sprite manager.

Crimson Wizard

#17
Quote from: morganw on Tue 03/07/2018 21:21:25
I'm suggesting there be no import controls at all. <...> If people are already saving their sprites and masks to disk to do an import, they may as well just save them to the game folder.

This makes certain sense, but do you do parts import in this case at all? Right now you may have tilemaps or whole animation in a single file, with that you will have to keep 1 tile/frame per file?
I don't really know how people usually do that. Maybe they prefer to have 1 frame per file anyway?

morganw

As long as you can read the frame count of the file, I think it would be okay for a whole animation in a single file, but I think people tend to export as a sequence of images anyway. Potentially you can just have the editor assume a single image with alpha channel (where available) and just store exceptions to that, either in the project file or write it as metadata into the sprite folder (you could probably reserve a sprite number range this way too).

I think I've linked to this before in another thread:
http://thebrotherhoodgames.com/blog/2013/10/visionaire-engine-powering-stasis/

...but have now also found where I read the direct comparison:
http://thebrotherhoodgames.com/blog/2010/12/adventure-game-engines/

Crimson Wizard

#19
Quote from: morganw on Tue 03/07/2018 22:09:26
As long as you can read the frame count of the file, I think it would be okay for a whole animation in a single file, but I think people tend to export as a sequence of images anyway. Potentially you can just have the editor assume a single image with alpha channel (where available) and just store exceptions to that, either in the project file or write it as metadata into the sprite folder (you could probably reserve a sprite number range this way too).

But if there is no sprite manager, how do you tell it about these exceptions? I think I am missing something in this plan.
Also, do you mean that file format itself stores frame count? If not, what did you mean by "read the frame count of the file"?

Could you write all this in a form of a task, with all points elaborated?

SMF spam blocked by CleanTalk