Possible bug in #incchrpal directive when loading 8x8 tilemap

[lunoka]

If I'm right, #incchrpal is meant to create a palette array for a corresponding 8x8 tileset and an according map instead of #inctilepal working with 16x16 tileset.

But using this directive trashes the screen, whereas just setting an empty palette array loads the screen correctly ( minus palette index affectation ).

Is there something I'm missing? Wrong use?

TestIncChrPal.zip

[jbrandwood]

Yep, it's a bug (a stupid typo) in .inchcrpal

Wow, you must be the first person to actually try to use that capability since it was added nearly 6 years ago!

There will be a fix for this in a while.

[lunoka]

Haha, I keep digging! Found this during the port of my SMS hombrew, I update things in the background in 8x8 mode. I could have use load_vram() or sprites instead but it's worth mentioning it.

[jbrandwood]

OK, it should be fixed now.

FWIW, I highly recommend that you take a look at 0x8bitdev's MAPeD and SPReD thread on the forum, and that you consider using those tools instead of HuC's built-in methods and library code.

And if you want a better random number generator, there are some in the examples/asm/elmer/include/random.asm, but they don't have wrappers to use them in HuC.

[lunoka]

Tested and working, thanks! Maybe the palette list ouput should be limited to -vv or -v option on HuC?
Thank you for your suggestions, I'll have a look.