You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ASMotor has this feature as a :C format specifier in its interpolations. For example, "{65:C}" gives "A".
It's been occasionally asked-for in RGBASM over the years; I don't recall the specific use cases (most likely to do with metaprogramming or debugging), and it's not a critical feature, but there are times it would be "nice to have".
The main argument against it, I expect, is that there could be more than one charmap to the same value(s). I think any simple consistent tiebreaking logic would be fine in this case (give the first or last defined one, the least or greatest one in strcmp ordering... whatever's most natural to implement, it's an arbitrary choice). There could be an opt-in -Wambiguous-reverse-charmap warning for such cases.
This is slightly complicated by the fact that charmaps can now exist for multiple values, like charmap "A", 1, 2, 3. It would be consistent to allow converting 1, 2, 3 back into "A". I think the natural way to handle this would be a var-arg function.
REVCHAR(65)
MAPCHAR(1, 2, 3)
CHR(42) (Python-esque)
CHARSTR($C3, $A9)
...the name could be bikeshedded
The text was updated successfully, but these errors were encountered:
I'd say the best tie-breaking criteria would be to pick the last defined character, as it's both controllable by the user and friendly towards derived charmaps.
Do you happen to recall any specific use cases for this feature? I think mine were for a quine and a Brainfuck interpreter, neither of which is exactly "standard GB dev". :P
A few discussions I found about this feature on Discord:
2024-01-21: "Quick question, is there a way to convert a numeric macro argument to its string equivalent based on the current charmap? Couldn't find any function in the docs to do this"
"I ended up just creating a new charmap entry which is no big deal. Just that the constant is defined in a different file than I wished."
2022-10-11: "how do you insert arbitrary byte values"
"if you're using modern rgbds, CHARLEN and CHARSUB will work"
2021-07-01: "is there a macro which does int_to_chr() conversion?"
2025-01-11: "I'm using No$GBA/BGB style debug log messages in a rom hack of Final Fantasy Adventure and would like to be able to log save file (and main character) names. That means taking values in the game's charmap and converting them to ASCII."
ASMotor has this feature as a
:C
format specifier in its interpolations. For example,"{65:C}"
gives"A"
.It's been occasionally asked-for in RGBASM over the years; I don't recall the specific use cases (most likely to do with metaprogramming or debugging), and it's not a critical feature, but there are times it would be "nice to have".
The main argument against it, I expect, is that there could be more than one
charmap
to the same value(s). I think any simple consistent tiebreaking logic would be fine in this case (give the first or last defined one, the least or greatest one instrcmp
ordering... whatever's most natural to implement, it's an arbitrary choice). There could be an opt-in-Wambiguous-reverse-charmap
warning for such cases.This is slightly complicated by the fact that charmaps can now exist for multiple values, like
charmap "A", 1, 2, 3
. It would be consistent to allow converting1, 2, 3
back into"A"
. I think the natural way to handle this would be a var-arg function.REVCHAR(65)
MAPCHAR(1, 2, 3)
CHR(42)
(Python-esque)CHARSTR($C3, $A9)
The text was updated successfully, but these errors were encountered: