itch.io

Now I tried it, and the undo functionality is quite nice indeed! It certainly makes the experience a lot smoother by removing the pain caused by mechanical mistakes.

I noticed that the simulation doesn't really follow the rules though, even a simple level like Counters from the default set breaks. My C64 version is actually pretty solid (even when it comes to tricky combinations of stickers), so you can use it as a reference. Processing order matters a lot! The Kye 1.0 port written in Python also seems to be quite faithful to the original in its behaviour, so just replicating that logic should get you pretty far. The others with source (e.g. the Unity one) are not to be trusted.

Yeah, it's annoying when you know how to solve a level and make that one mistake while executing your plan... Not sure how undo would work in this game though, since the levels evolve without player input unlike PuzzleScript games, e.g. a bouncer could move a block you just pushed. The only solution that comes to mind would be a quick save system, maybe with just a single slot. An exercise for the reader, as the game is open-source. ;)

I'd just like to inform you that this tool has been invaluable in helping me port Stunt Car Racer to the Plus/4, so thanks for creating it!

After using the tool for a while, here are some of the pain points I ran into:

• I really could have used global keys for various cursor actions: moving around in the character set/map view, changing current chroma/luma etc. without having to click in the respective window. Being able to keep the mouse in the character editor and drive everything else from the keyboard would make life much easier.
• Global color replace (i.e. specific source to destination colour), also limited to selected chars, would have saved quite a bit of manual work too. 
• Ability to offset bitmap horizontally when importing (to find better fits for the character boundaries). Maybe even having an automatic "minimum error" mode that just cycles through all 32/64 possibilities for sub-char positions could be interesting.
• I found that the luma values were somewhat off. Luma levels 0 to 3 shouldn't brighten so quickly, because there's supposed to be a bigger jump between 3 and 4. Especially 2 and 3 look overly bright compared to both emulated and real machines. In the help you wrote that you're using the Yape palette, but this doesn't look like it to me. I'd look into taking the Multipaint palette into use, or even the one used by Vice (all three programs seem to be in close agreement about the luma levels).
• For the C16 and Plus/4 it would make sense to have an importer for the Multi Botticcelli format, since it seems to be the standard used by the community.

Note that I was basically using it as a bitmap editor to translate the original C64 graphics (and partly the Amiga one as well), and it's possible that I should have used Multipaint instead for some of that work. However, CharPad has a much better importer, and it also has much better export options, so I think it was the better choice overall.

This is all food for thought, not really feature requests, since it all depends on the direction you want to take with the editor. The only clear issue from the above is the mismatch in luma levels from all the other tools, I think you should review that more carefully.

Thanks again for the excellent tool!

Sure, feel free to distribute the unchanged versions of the game, just please link back to this page.

Thanks for the feature! I see there was a bit of struggle. ;)

Thanks for the boost!

If CharPad is associated with CTM files or SpritePad with SPD files, opening these files starts the respective application but with an empty project. Would it be difficult to have them load the selected project file right away?

Hi,

Thanks for the quick response! I don't think target memory requirements are an issue per se, since it's anyway the responsibility of the developer to make the trade-offs for their particular use case. It's more of a problem in practice if an authoring tool imposes limitations that are hard to work around. However, I do see how this request can lead down a deeper rabbit hole.

In any case, thanks for your work, CharPad makes life a lot easier already!

I'm missing a colouring method where the source of colour is the map itself, as opposed to the characters or the tiles. With this mode, a separate map-sized colour buffer would be saved (one per character or tile depending on whether tiling is enabled). Especially when working in ECM having to introduce an identical character to get a different colour seems rather wasteful.