Please bear in mind that this was originally intended to be an image exporter, not an image editor. The editor functionality has evolved over time, but it is not intended to be a replacement for proper image editors like GIMP.
Also please bear in mind that because it evolved rather than being properly designed there are some limitations. I hope to overcome some of these in the future with a bit of a redesign when I have the motivation to do so.
In the mean time, bug reports are welcome. Feature requests will be noted but chances are my answer to most feature requests will be either ‘maybe at a later date’ or ‘oh no, feature creep’.
About a week or so ago (April 2022) I started thinking about making some better tools for doing sprite conversion since my personal-use tool wasn’t really fit for public use and a handful of existing options seemed to be outdated or a bit awkward to use.
Originally I was intending to create a handful of command line tools, but then I made a GUI-based prototype, and then I threw that out and started again. I kept working on it, and now it’s this.
That looks really good and I like the way you have handled frames.
Am I right in seeing that all images are exported as ‘Sprites No Mask’, ‘Sprites Plus Mask’, etc? I wonder if this should be a setting on the image itself so that you can bring out combinations of no mask and masked images. I have found that I only need masks on some images and not others - titles versus players for example - often to save memory. I guess if you bring them out as external masks, you can simply not reference the mask if you do not need it.
One potential enhancement would be to support the FX by simply exporting the files to the \fxdata directory and automatically create the input data for the fxdata.txt file (or allow the user to override). This could also include the namespace declaration that @Mr.Blinky added recently.
The FX uses PNG files with a transparency layer / colour. It looks like you have that capability already.
Yes, every image in the output uses the same format.
I can think of ways to do it, but none that I particularly like.
I’ll put it on the backburner because there’s more important stuff to be handled first, and I’m wary of feature creep.
Would you not normally just put those in different files anyway?
Maybe it’s only me that likes to stick to just a few sprites per file?
It exports to wherever you ask it to export to.
Just manually navigate to the \fxdata directory yourself and it’ll remember where you were (providing you don’t close it, I presume).
And where would the documentation for that be?
I had that capability weeks ago. :P
But yes, it spits out mask data based on the alpha channel.
When someone offers to ship me a free Mac to test on.
(And enough coffee to endure whatever language and framework I’d have to use instead of C#.)
Is Wine really still not an option for Mac though?
I could look into it at a later date, but webdev isn’t really my forte.
The main reason I opted for C# is because I know both C# and WinForms particularly well, so it’s only taken me about a week or two to get something together with most of the bugs ironed out.
Doing the same in JavaScript would probably take me a few months and a lot more effort because I’d have to get used to the language and learn the APIs first.
I could probably get a simple online converter up and running in a week or two (with a lot of internal screaming), but an actual editor with decent functionality would take much longer.
It’s awesome utility. The ability to easily make sprites is something that is going to be critical of making like an “app” version of the emulator so having it available in any codebase is an excellent start. Thanks so much for putting it together!
I got quite a bit done today, so hopefully I’ll be releasing this in the next few days, though I might call it a ‘beta’ release in case any bugs crop up in the first few weeks, or in case anyone has any compelling feature requests.
The things I want to get done before releasing it are:
Provide a way to designate licence text to be placed between the #pragma once and the includes,
I might even stock the software with some commonly used licences so adding the common ones becomes a few clicks rather than a copy-paste job.
Try to get the frame deletion working better.
At the moment I’m having to leave images in the image list because deleting them messes up the UI if I don’t attempt to rearrange the images, and although that’s not a major issue given how much RAM modern computers have, I really don’t like waste either.
I may end up either implementing custom node drawing or just dropping the idea of sprite thumbnails altogether for the sake of publishing the editor sooner rather than later.
Go through add make sure absolutely everything of significance is commented.
I’ve already been commenting things excessively, but there’s a few files I’ve barely touched that could really do with commenting.
Pick and add the licence(s).
Maybe rework a few icons and/or add a few more.
I’m trying to think of a better way to represent ‘file’ than a sheet of paper with lines of text. I’m leaning towards either using a file folder icon or just curling the corner over.
I’ve got a bit more done today, though not as much as I’d have hoped because I ended up doing quite a bit of work the backend (e.g. moving the colour and tool select into separate controls, changing some stuff about how sprites are represented internally) and running into a few snags along the way.
So far I’ve implemented the ability to duplicate frames. I can easily add sprite and sprite group duplication too, though I get the feeling those are going to be less commonly used.
I added them anyway, so now if you’re feeling crazy you can duplicate large subtrees of sprites and namespaces
The major snag I ran into is to do with the image preview feature.
I had intended to fix the imagelist-related frame deletion issue by bypassing the imagelist and rendering the previews manually using custom drawing.
Unfortunately when trying out custom rendering, I discovered that trying to scale down larger sprites to fit in the 16x16 preview often gives really ugly results.
For example, a sprite of concentric squares, alternating between black and white results in either:
WIth high quality bicubic interpolation: a block of grey.
With more or less anything else: a black triangle in the top left and a white triangle in the bottom right (because it’s only picking the pixels at even coordinates)
This is what bicubic rendering looks like (emphasised with a red rectangle):
Use high quality bicubic interpolation, which gives very grey-ish results on large sprites
Use nearest neighbour interpolation, which only shows every other pixel on large sprites
Use a placeholder image for sprites larger than the preview size
0voters
I’ll leave that poll there in case anyone wants to provide an opinion.
(Any of these options will solve the frame deletion issue, which will be another thing off my list.)
Excuse the microblogging, but I’ve just discovered how to do one of my stretch goals and I’m quite excited about it (which is a rarity for me). I didn’t mention it before because I was worried it was going to be too difficult or awkward (for me) to pull off, but it seems not.
So look forward to the ability to drag nodes around the tree to reorder them!
(If I’d known it was going to be this easy, I wouldn’t have wasted time making those ‘up’ and ‘down’ buttons…)
This looks great
+1 to add stock licences like GitHub. Please include Creative Commons too.
Then is it possible to have larger previews? 64x64? You have a lot of real-estate on screen, and upscaling is nicer. The rarer larger images would still need downsampling. In the past I experimented with imagemagick and found sample the best (avoiding resample). This just picks every other pixel for example.
The main post has been updated with the latest features and screenshots.
I’m hoping to be done by the end of the week.
It would have been sooner, but I keep finding tiny little features to add, like having a ‘close tabs to the left’ button (which properly warns you about closing unsaved tabs), the ability to open multiple files at once and a little ‘synchronise dimensions’ tickbox for the sprite adding form.
(Also I quite enjoy making icons for all the buttons/options.)
I did spend a bit of time working on the licence feature today by gathering up licences and adding a tree view with the licence names, but it struck me that I’m not sure quite how people would want to use them.
Most of the licences are too big to realistically be embedded in the header files, so it makes more sense to reference them with some kind of header and include the full licence separately.
I’m also wondering if people are expecting the UI to talk them through the licences (i.e. like some kind of teaching aid) or if they’re expecting it to be geared towards people who already know what’s what in regards to licences.
Perhaps drop the license feature? It may add to confusing situations where the ‘artwork’ (or encoded bitmaps) are licensed differently from the main code. Hold back for a v2.0 if requested?
It is tempting, since I’d like to release sooner rather than later…
I’ll ask the audience please, Chris Jeremy.
Scrap the licence feature for now in favour of an earlier release date
Keep working on the licence feature, potentially pushing the release date back
0voters
I tend to stick an Apache 2.0 header in my image files regardless of the licence I put on the original images.
It’s one of those awkward grey areas where the line between code and data blurs.
Can it handle nested namespaces?
This is why I introduced the tree view in the first place.
My original prototype (see this comment was using some other control that couldn’t handle namespaces.
Originally I was only going to have a single namespace tier as an optional wrapper, but I decided that if it’s worth doing it’s worth overdoing.
Since my drag-drop epiphany the other day you can even drag sprites from one namespace to another.
Wait… it will ingest existing Images.h files and it’s parsed into editable images!? That would be a killer feature!
How would you match up (external) mask data with the correct sprite? Even if we needed to include some ‘magic’ comment lines in the source to enable this- it’d be great.
No, at the moment it only loads image files (.png et cetera).
This means you can grab a bunch of image files, drag them onto the tree view and depending on where you drag them it will either:
Add frames to a sprite
Add a sprite to a namespace
Overwrite a frame
I’ve thought about the possibility of parsing .h files, but the main thing that puts me off is that I’m concerned it will be a magnet for feature creep.
Ideally if I were to add such a feature I’d like to say that people should only expect it to accept files that were actually generated by the editor, but undoutbedly someone will try to use it on files created by other editors/generators or written by hand, and I’m concerned that would lead to people asking for the importer to support whatever they tried to throw at it.
Maybe I’m just being lazy or pessimistic, and I might add it at some point, but for now it’s not something I want to be doing.
This is why I’d want to only accept files generated by the editor itself. If I only have to handle the convention the editor uses (appending Mask to the mask arrays) then that’s not a problem.
There’s also the issue of figuring out which images are using uncompressed bitmap data, which have their width and heigh prefixed onto the data, and which are using the compressed format. I can think of ways to do all those, but it would basically amount to the editor using trial and error - throwing them at the wall and seeing what sticks (i.e. whichever interpretation doesn’t fail/break the rules).
That’s actually given me a really good idea.
I don’t want to spoil it though, in case I don’t get chance to do it.
(Ironically it’s tempting me to make an import feature just for the sake of seeing if this idea will work…)
