I do the same in my game but yours is abnormally smooth for the NES? I run your game in Mesen and its like the fade in/out does 256 shades of colors. I honestly don’t get it. Maybe Mesen is going something here..
Uncle Dan
Creator of
Recent community posts
I meant canvas size. This morning I am not experiencing this issue anymore. The only manoeuver I can remember, is that I had my original file as a 32x30, then converted it to 32x26, then saved it to a new file without overriding my existing one. Then the warnings started.
Just a theory: could it be related to the clipboard having something in memory outside of 32x26 at that moment then got confused after updating the file?
Another issue I found this morning: I think still related to custom canvas size.
I have a 32x26 and when saving as a .map without attributes, I get a file of 892 bytes instead of an expected 832 bytes (32x26).
However, the option “Saving canvas as ASM” gives me the correct amount of bytes (832).
I inspected some the hexdump of the .map file and line 300 to end of 330 are expected, however anything beyond that (FF, FF, 33…) …. ah.. As I am writing this I get it. These are the attributes that shouldn’t be exported since the option is deactivated.
Since I changed my screen size to something other than 32×30, I’ve been getting a lot of these error messages:
It would also be helpful to support custom grid sizes instead of forcing the 32×30 format. Additionally, making the grid lines between screens bolder would help visually separate them. For example, I reserve 6 vertical tiles for player information that don’t need to be designed, and this offset doesn’t work well with divisions like ×2, ×4, or ×8.
I appreciate your approach and the heads-up. I wasn’t sure myself how feasible it would be to implement column loading with a lookup table to track column boundaries under RLE compression. Coming from a frontend background, these concepts are still pretty new to me.
I’ll definitely keep your suggestion in mind about using metatiles for compression. It sounds much easier to maintain and navigate.
Thanks as always for your fast and thorough response.
I was thinking about how I could tackle compression in my game using 2x2 metatiles, and before writing my own command-line tool, I was wondering if it’s already possible to do this with NEXXT.
I’ve played around a bit with the Metatile window and managed to create some metatiles, but I’m still a bit confused about how to actually use them.
There are some bugs when exporting *metasprite banks* VS *individual metasprite* to clipboard. When exporting individual metasprites, negative values are prefixed with a low byte operator, but it's not the case when exporting banks.
Front: .byte <- 8,<- 8,$00,0 .byte 0,<- 8,$01,0 .byte <- 8, 0,$10,0 .byte 0, 0,$10,0|OAM_FLIP_H .byte $80
VS
Front: .byte - 8, - 8,$00,0 .byte 0, - 8,$01,0 .byte - 8, 0,$10,0 .byte 0, 0,$10,0|OAM_FLIP_H .byte $80
This results in Error: Range error (-8 not in [0..255])
Also, when exporting individual sprites, animation data are not included. They are included when exporting banks, however the value often overflows. We get things like .byte 300.
For instance, with this Metasprite GnomeStillFront, I get .byte 300 as animation data.
I have being playing around with the software for a couple of days now and managed to do simple stuff. I noticed that the software is shortcuts oriented and that does not make it intuitive. I found some resources on this message board and some videos on Youtube, but that only covers the basics.
If only I could I would help and make the documentation, but I don't understand the software enough!
My concern is that users will eventually get frustrated and abandon their project for a lack of understanding.
To the author: Your software is amazing but it became complex. My suggestion would be to make a 1-hour Youtube video where you cover every items and explain how to use them.
You can just build it yourself on any OS:
https://github.com/HackerPoet/MarbleMarcher