why can't charmaps be 16-bit about rgbds HOT 5 CLOSED

This seems to be about the same as #97 (please see there for further details): there's no reason against them (see #265 for implementation ideas), but they would require a lot of effort to implement in the current codebase, and neither of the current maintainers are up for it.

from rgbds.

It's probably worth mentioning that you're expecting the assembler to treat the number of digits you write as meaningful, which it never does. That's the source of your initial confusion here. $02, $0002, $00000002, and even just 2 are all the same exact value — they will not be processed any differently. charmap "！", $0002 is exactly the same as charmap "！", $02 or charmap "！", 2.

from rgbds.

It's probably worth mentioning that you're expecting the assembler to treat the number of digits you write as meaningful, which it never does. That's the source of your initial confusion here. $02, $0002, $00000002, and even just 2 are all the same exact value — they will not be processed any differently. charmap "！", $0002 is exactly the same as charmap "！", $02 or charmap "！", 2.

well, you could always have a charmap16 or something that expects there to be a 16-bit value, and normal charmap could keep being 8-bit

for instance,

charmap16 "A", $01   ; will be treated as $0001
charmap   "a", $0002 ; will be treated as $02

from rgbds.

charmap16 would be a restricted version of #97 and #265. And, anyway, the problem is in the complexity of implementing of emitting 16-bit charmaps, not in the directive itself.

from rgbds.

Hi, try using a customised version of rgbds that adds support for 16-bit charmap
https://github.com/SnDream/rgbds
Currently at version 0.6.1
example: https://github.com/SnDream/pokecrystal_cn/blob/release_cn/charmap_cn.asm
There is a MACRO version of #97 without compiling custom rgbds, but it's not well suited to existing large projects.

from rgbds.