Is your feature request related to a problem? Please describe.
Since you can now use variables to display characters from the _ascii.png_ file on dialogues, I'd like a way to display those variables/characters on a scene.
Describe the solution you'd like
A character tile. A tile which changes dynamically according to a variable. For example, if the variable is 0, it should display a space. If the variable is 1, it should display an exclamation mark.
Describe alternatives you've considered
I thought of using actors, but there aren't enough frames for text input. That's why I'm requesting this.
A method for "drawing" text directly on the background layer would be a cool feature. Draw Text At Position: X, Y, Text, just like the Text Display
I didn't expect to start writing an essay, but here we are 馃槅
The issue is a battle against optimization.
ggbgfx, our dynamic tile compiler designed by chris, is configured to combine as many reused tile sets together up to 192 tiles, as a game grows, 4 low tile maps that share a few tiles may have their tile map combined into a single set, with set size up to 192.
Basically, the optimized and dynamic nature of tile sets makes a stable feature quite difficult.
For advanced users, i'm sure a "print Ascii to vram" or "set tile to vram at x/y" would be appreciated in any sense, but as you add more backgrounds to the project, vram locations for existing bgs could randomly change. Using the ui reserved 192+ space would cause bg to be overwritten whenever a text box appears, so only useful in a small use case, maybe good enough for a dirty advanced feature.
This eventually encompasses a wider area of features:
Vram animated tiles, like water:
Dynamic Ascii characters in designated areas of the background layer (just vram swap)
Dynamically placed tiles in the background, from a prepacked tile set.
Dynamically placed tiles in the background with reserved Vram space.
Your idea of Character tiles is a good suggestion, Something like defining an area of a trigger, or placing actors, but for tiles.
It may require the background to be duplicated in rom, if the background were to be reused with new character tile placement, the map data may have to be duplicated again, as well as the background being flagged for no tile set merge optimizations.
I'd love the feature too, but getting it right could take a lot of work, and might be out of scope for 2.0.
Of note, i have debated a catch all Toggle to force tile set merge optimizations to 128 tiles,
This would free up 64 tiles of shared space vram, with the high 64 still being UI.
Not only could this be useful for reserved space character tiles, but sprites overlap this area, and could alternatively support up to 16 more sprite frames of animation.
Maps between 129-192 tiles would not optimize/merge correctly, but have the same unofficial support like 193-256 tile maps.
If this were an option for max dynamic tileset on a per bg basis, that could be a great start for this, coupled with a dirty "print Ascii to vram" and "set tile to vram at x/y"
@RichardULZ very good writeup. A bit unrelated, but a solution for animated water tiles and the likes, could also be implemented with palette swapping, which I think should now be possible?
Yes! Palette tile swapping for water/animated tiles has been rampant in the discord, and results are incredible (some neat 1bit games can cram in animation too) but sadly, it is cgb exclusive, so that feature could still be useful.
Most helpful comment
I didn't expect to start writing an essay, but here we are 馃槅
The issue is a battle against optimization.
ggbgfx, our dynamic tile compiler designed by chris, is configured to combine as many reused tile sets together up to 192 tiles, as a game grows, 4 low tile maps that share a few tiles may have their tile map combined into a single set, with set size up to 192.
Basically, the optimized and dynamic nature of tile sets makes a stable feature quite difficult.
For advanced users, i'm sure a "print Ascii to vram" or "set tile to vram at x/y" would be appreciated in any sense, but as you add more backgrounds to the project, vram locations for existing bgs could randomly change. Using the ui reserved 192+ space would cause bg to be overwritten whenever a text box appears, so only useful in a small use case, maybe good enough for a dirty advanced feature.
This eventually encompasses a wider area of features:
Vram animated tiles, like water:
Dynamic Ascii characters in designated areas of the background layer (just vram swap)
Dynamically placed tiles in the background, from a prepacked tile set.
Dynamically placed tiles in the background with reserved Vram space.
Your idea of Character tiles is a good suggestion, Something like defining an area of a trigger, or placing actors, but for tiles.
It may require the background to be duplicated in rom, if the background were to be reused with new character tile placement, the map data may have to be duplicated again, as well as the background being flagged for no tile set merge optimizations.
I'd love the feature too, but getting it right could take a lot of work, and might be out of scope for 2.0.
Of note, i have debated a catch all Toggle to force tile set merge optimizations to 128 tiles,
This would free up 64 tiles of shared space vram, with the high 64 still being UI.
Not only could this be useful for reserved space character tiles, but sprites overlap this area, and could alternatively support up to 16 more sprite frames of animation.
Maps between 129-192 tiles would not optimize/merge correctly, but have the same unofficial support like 193-256 tile maps.
If this were an option for max dynamic tileset on a per bg basis, that could be a great start for this, coupled with a dirty "print Ascii to vram" and "set tile to vram at x/y"