selmiak
commented
3 years ago That is a great plan! About the specifics, what about calling the sprite folder "SpriteCache"? I, as a frequent AGS user, would have never called my own sprite folder this and it will hopefully not collide with existing folders. To be on the safer side about the user doing crap with the SpriteCache, what about making that a hidden folder?
"Personally I doubt if subfolders within "Sprites" should correspond to the folders in the editor's sprite manager." There are a lot of possible workflows of managing the game assets, so the workflow I suggest is to have the user have a user sprite folder somewhere where the user has his own logic and sorting and probably more source files and photoshop files and references and sketches and more things not needed in the game's sprite cache and the SpriteCache folder where the user usually does nothing with. Thus I suggest to make it a hidden folder. Maybe even add a short textfile to it called "!get_out.txt" and in that explain that the user should not tinker with the files in that folder or noone can help him. The ! at the beginning of the filename should push it to the top of the list, at least under windows. Since we can have folders in the Editor to make it easier to use, why not replicate that structure in the SpriteCache in case some user still looks in there. Is there any downside to replicating the structure of the editor in the cache folder? Non that I can think of atm.
Importing: on import the editor should just make a 1:1 copy of the sprite the user imports in the cache folder (including corresponding subfolder) and call it like the editor sprite number and according suffix. Probably with leading zeros. 00001.jpg, 00002.png etc. When the user imports a spritesheet with 8 frames from a single source image as 8 images in the editor, the editor makes that 8 images in the sprite cache folder with corresponding number filename. And with that workflow of the editor we could have a 00001t.jpg (note the t in the filename) and a 00002t.png generated which is a downscaled version of the image to display in the editor and in the views. Well, I call my thumbnails like that, maybe a dedicated thumbnails folder with files with the same name in it could also work but makes it easier for the user to screw things up by moving files and overwriting the actual images. And a user could have a "thumbnails" folder in the editor, that would make it complicated to replicate the structure.
I think the SpriteCache folder should be treated like the current single-file with all the sprites, a place where the user usually does not interfere with (thus my suggestion to make it a hidden folder)! Whatever the user does with that folder is not a problem of the editor. But in case a user is curious or tech savvy enough to browse through that folder for whatever the reasons may be to not use the editor like it is supposed to be used, why not replicate the folder structure of the editor to make it feel familiar already when viewing the sprite cache on disc? Though when the user deletes files from there, the editor has to check on startup of a project if all sprites exist in the SpriteCache and if not try to reload them from the source directory. And when even reloading from the user folder fails the editor needs to generate a 1x1px placeholder or a default "missing image" file on that number or something similar to not screw up usage of imagenumber in views and in script. The user would have to reimport that sprite number then (or live with the placeholders in game). If a thumbnail is found to be missing on startup of a project that can be generated from the sprite cache again. The thumbnails could be optional in game settings. Or they could be generated new each time on startup of a project and deleted on closing the project to save diskspace, but that could lead to very long startup times of a project. Maybe that could also be an optional setting in the game settings.
ivan-mogilko
persn
ericoporto
Problem
For historical reasons sprites in AGS game project are kept compiled in a single file (aka "sprite file"). Editor saves them there on import and reads them back from there when having to use these sprites displaying a game scene. When compiling the game this file is simply added to the data package as-is, and this is it's only benefit. But this has a number of disadvantages:
Solution summary
Questions and further suggestions follow...
Project storage
Need to define the subfolder to store sprites. "Sprites"?
Personally I doubt if subfolders within "Sprites" should correspond to the folders in the editor's sprite manager. IMO more no than yes. The imported sprites do not 1:1 correspond to the source images, user may import multiple sprites from one image file, even from one tile rect with different settings. Same image may be imported as multiple placeholders too. It may be imagined that at some point editor will be able to display both source images and imported sprites in separate windows - as separate entities.
Importing sprites
On a sprite import editor checks whether the source image is withing "Sprites" project folder, if not then copies it there. If we support subfolders, images cloned by the editor should probably go into a special "unorganized" subfolder. Editor will also have to prevent file name conflicts.
Alternatively we may restrict sprite import to only files that were placed into "Sprite" folder by user. Pros: user will have full control on how files are called, there's no need to guess how and where to clone files. Possibly less confusion about how import works. Cons: possibly extra work for users if they import from other locations.
What to do with "import from clipboard" option? If supported then it must create a new source image file in the project folder.
Upgrading from older project
Existing AGS project has:
Let's suppose that the priority should be given to import original images whenever possible. If they cannot be found, then we may optionally export sprites from the compiled sprite file and save them in "Sprites" folder.
In any case, what to do if there's already a "Sprites" folder created by user and containing some data?
If we are exporting from the spritefile, we will have to deal with possible duplicate image sources and sprites cut out from the middle of an image. E.g. there may be multiple sprites referencing one source image. In such case should we try to reconstruct original image judging by the sprite tile offsets & sizes? Or should we export each sprite to its own image file and adjust source references and import settings? Should the program ask for permission to export from the spritefile to let user opportunity to restore original images, or just warn and go on with it?
Sprites in the Editor's memory
Hypothetically, Editor may reuse existing sprite cache in C++ code with some adjustments. If it's preferable to move away from using C++ code internally in the Editor, then we would have to write another sprite cache or manager for the Editor in C#.
Editor drawing sprites
If we remake sprite cache into a C# cache/manager, then there very likely is a need to remake remaining game content drawing into C# code as well. This task may be stated in a separate ticket.
Compiling sprite file
The existing C++ code relies on sprites stored in a native C++ sprite cache object, which is going to be inconvenient.
The options here are:
Writing stand-alone tool may be picked out to a separate ticket.