Well, after posting this was actually thinking that it would be handy to have an option to save a 'default loading path' (which can be changed).
You might even be able to re-use the current mru (without the file+ext) but save it in another file, one which may hold even more save option in the near future as mentioned in an earlier post.
It would be nice to also add the current way of path loading when browsing for a source image (open last used folder) as an option, so the user can choose between 'last used folder' or his/her's default but changeable loading folder.
BrocantyGames
Creator of
Recent community posts
wish: remove the pre-loading of the mru file and don't pre-fill the 'Source image' field
Why:
The app now first tries to pre-load the last used sprite sheet. Which is saved/logged in the ini logfile within the [mru] section. But in the case this file is missing, a warning message correctly pops up.
I'm not sure why it even tries to load a previous loaded sprite sheet, but maybe I'm overlooking something.
So maybe this pre-load previous sprite sheet function plus the pre-filling of the ' Source image' field can be removed?
Repro:
Given I have loaded a sprite sheet
When I close the app
And remove/relocate the sprite sheet
And reopen app
Then it first shows the error popup message: "Could not find file, '<path+filename>'.
When I click the popup OK button
Then the slicer app start correctly
But the mentioned path and file are loaded and shown in 'Source image'
Expected behavior:
When I restart the app, it does not try to pre-load the last loaded sprite sheet (logged as mru), as the intention of restarting the app is to load and slice a new sprite sheet.
Misc:
Ini Logfile section app tries to load:
[mru]
filename=<path>\<filename.ext
Is this still a thing?
The current version (2024-12-24, as there's no version or about info within the app) uses this ini file as a logfile,
logging sheet-name and used settings, which is actually a nice feature. May I suggest though to change the extension from .ini to .log, since it only logs)
But, as I was reading through this post, it looked like ZeroX4's wish was slightly misunderstood.
I think he was trying to ask for a feature that the user can actually save ('non-sprite sheet specific') settings.
Why:
That way, when restarting the program, these settings are read and auto-set, so the user doesn't have to set these options/choices manually each time.
The options to save:
This would only be the following two options:
- 'Ignore tiles with solid color' being auto-activated/deactivated
- 'Slice by rows and columns' or 'Slice by cell' radio button being selected.
All other options can be dismissed for the save feature as these are depending on the loaded sprite sheet itself or are calculated or auto set after loading/slicing
Wish: after loading another sprite sheet, auto-clear the previous sprites preview
Why:
It might be confusing seeing the new sprite sheet in the lefthand panel while in the righthand panel the sliced preview sprites from the previous sheet are still shown.
Repro:
Load and slice a sprite sheet
load another sprite sheet
notice that in the righthand panel the sliced preview sprites from the previously sprite sheet are still shown.
Issue (cosmetic): after slicing non-square sprites, they are shown as distorted square sprites.
(Note: the actual export files are correct)
Assets/settings used:
- Sprite sheet 31x51 pixels, 1 row, 3 columns.
- Slice settings:
- cell size: 13x51
- margin: 0x0
- gap: 1x0
- Ignore tiles with solid color: Yes
After slicing the result sprites are shown distorted as squares in the right panel:
Wish: add a zoom option for the loaded sprite sheet + option to save zoom setting or/and an option to ' lock' zoom setting within the current session.
Why:
Zoom function:
I work often with sprite sheets containing rather small low-res sprites. My native screen resolution is 3440x1400.
When I load for example a sprite sheet with 1 line and 3 columns, and each sprite having a dimension of 14x5,
the sprite sheet is obviously shown really small.
Therefor a zoom option would be handy where you can zoom in with rounded steps (100%, 200%, 300%, 400%, etc) on the loaded sprite sheet.
Save and/or lock the zoom setting function:
Adding a way to save a changed zoom setting would be very handy. This way after reloading the slicer program it will use the save zoom setting.
Or otherwise a way to 'lock' the zoom setting, so you would not have to set it again each time when you load another sprite sheet, but only within the current program session. After restarting the program the locked zoom is set back to normal/default.
Or better: add both save and lock :)
First of all, great tool!!
Wish: add a check on the 'slice by cell' settings before trying to slice
Why:
Currently if cell size, margin and gap settings are wider and/or higher then the loaded sprite sheet,
an error popup warning is shown with label ' Out of memory'.
This isn't much user friendly and also doesn't give the user any information he/she might need to 'solve' the issue .
Reproduction:
Given I load a sprite sheet
When I select the option 'Slice by cell size'
And I set either or both cell size for Width and or Height 1 pixel wider /higher
And optional I set a gap or margin
Then the canvas to be cut is wider and or higher then the loaded sprite sheet
When I click the Slice button
Then the program shows a ' Out of memory' error popup
Expected situation:
After clicking the Slice button, but before starting the actual slice proces, run a check on the cell size, margin &
gap settings for both width and height to assert they are still within the dimensions of the loaded sprite sheet.
If check fails, show warning popup with info regarding wrong cell size settings.
Hi oldschooljoe, why would you like the c64 version specificallyspecifically to be remade?
As in gameplay the amiga, c64 and dos versions are identical. Graphic wise they the c64 is close to the amiga and dos version, which are both identical. Only the music is different per version, the c64 and amiga music are slightly identical, but the dos version is quite different.
Thank you!
I found out about this game via IndieRetroNews which reported about your released remake. As I'm always on the lookout for 'lost gems' as I call these obscure, often non-english games, I felt this one definately deserved a remake/port to Windows, Linux and Mac as well. And so it was done :)