Gb-studio: [Request] Character tiles for text input

Created on 28 Aug 2020  路  4Comments  路  Source: chrismaltby/gb-studio

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.

enhancement

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:

  • How do we define the repeated tiles to be animated.
  • How do we ensure the vram location is right.

Dynamic Ascii characters in designated areas of the background layer (just vram swap)

  • How do we define the tiles that should always be unique for text. (character tiles?)
  • How do we ensure the bg is compiled with enough free vram space, and this modified tile data.
  • How do we ensure multiple vram locations are correct.
  • How do we modify the tiles (variables on tick would be slow, an event?)

Dynamically placed tiles in the background, from a prepacked tile set.

  • How do we include these new tiles in the background tileset.
  • Resolve errors for too many tiles in a background + prepack.
  • Document that screen scrolling will overwrite edited tiles.

Dynamically placed tiles in the background with reserved Vram space.

  • How do we exclude this background map from dynamic packing or limit to size + reserve.
  • How do we define the amount of reserved Vram space for this scene/bg.
  • Once reserved, loading and placing from Ascii or a new type such as sprites or image stamps.
  • Document that screen scrolling will overwrite edited tiles.
  • (Alternatively, same as Ascii designated areas (no dynamic position), but support for more than just Ascii)

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"

All 4 comments

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:

  • How do we define the repeated tiles to be animated.
  • How do we ensure the vram location is right.

Dynamic Ascii characters in designated areas of the background layer (just vram swap)

  • How do we define the tiles that should always be unique for text. (character tiles?)
  • How do we ensure the bg is compiled with enough free vram space, and this modified tile data.
  • How do we ensure multiple vram locations are correct.
  • How do we modify the tiles (variables on tick would be slow, an event?)

Dynamically placed tiles in the background, from a prepacked tile set.

  • How do we include these new tiles in the background tileset.
  • Resolve errors for too many tiles in a background + prepack.
  • Document that screen scrolling will overwrite edited tiles.

Dynamically placed tiles in the background with reserved Vram space.

  • How do we exclude this background map from dynamic packing or limit to size + reserve.
  • How do we define the amount of reserved Vram space for this scene/bg.
  • Once reserved, loading and placing from Ascii or a new type such as sprites or image stamps.
  • Document that screen scrolling will overwrite edited tiles.
  • (Alternatively, same as Ascii designated areas (no dynamic position), but support for more than just Ascii)

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

JasonB32 picture JasonB32  路  3Comments

Veund picture Veund  路  3Comments

meaninglessname picture meaninglessname  路  5Comments

CamburgerHelper picture CamburgerHelper  路  4Comments

cubicstyle picture cubicstyle  路  3Comments