Implement Variable Width Font

[Gronis]

Hi Lorenzooone,

I've started to implement VWF and it's shaping up nicely. I'm opening this issue to track the progress and to ask questions that I have trouble finding myself when working in your codebase. Rendering an entire screen is snappy when flipping between large text sections like the "settings" or "pokemon summary".

Right now VWF is implemented by dynamically allocating/tracking tiles in the bg tile part of VRAM. I'm using slots #32 to #512 (where the static old font used to be in VRAM) so 480 tiles can be used all at once by the VWF renderer.

Sometimes this is not enough to hold enough characters if the tiles are about to run out, and then there can be an annoying flicker when rendering.

One example where this happens is when the user has entered the pokemon summary (a-lot of text), then exits that view and go into settings and edit gen 1/2 settings (also a-lot of text). Because the pokemon summary is rendered into it's own layer, these tiles are still allocated and cannot be reused when rendering the settings page. This happens because tiles are reclaimed when calling reset_screen for the specific bg layer, so even though this layer is re-rendered when the user re-enters the pokemon summary page, the VWF still considers them allocated. Flipping between options in the gen 1/2 settings page with bg layer 4 full with tiles in the back, will run out of tiles to use for the settings page. We need to be able to hold 2 versions of the settings page to avoid flickering if the gba decides to render a frame when we are fiddling with the tiles (the same reason double buffering is used in newer games).

So, a solution is to simple use a few more tiles! we have a total of 1024 bg tiles in the gba hardware, so we could use more than 480. Well this is where the problems happen because something else seems to write data to bg tiles #512 to #1024. However, that data is never shown on screen. I've been trying to figure out what part of the code uses this memory but I'm not able to find it. Do you know?

I could probably call reset_screen before exiting the pokemon summary to clear out the bg tiles, which will fix the issue at hand. But since we are at the limit already, I want to see if there could be a way to give more tiles to the VWF renderer.

Picture with bg tile memory map: I'm thinking about the memory area with all the vertical lines, bellow the text, in the middle of the VRAM bg tile section.

The font looks bad now because the width is hardcoded (not calculated for each character). This is what I will work on next once the VRAM bg tile situation is complete.

[Gronis]

Example of some flickering that can happen:

It's not as noticeable on real hardware though, but still happens.

NOTE: This is the only visual bug/problem I'm currently facing with the VWF renderer.

[Gronis]

Update:

I've managed to fix most problems by resetting the bg layer (which frees up the tiles) when changing back to the previous screen in a few menu navigation functions. However, there is one place left, the "Change Nature" screen:

Here, I have temporary changed "Fix IV" to change into "Change Nature" screen, in order to be able to test inside mGBA emulator. This menu simply has so much text that even though almost no characters are allocated in other bg layers (just the pokemon list and "cancel" backwards text) the screen flickers. So here, a few more tiles are necessary for a smooth experience.

[Lorenzooone]

Hmm... I haven't been able to test this out, however it should be possible to move VRAM arrangements and their shadows to VRAM bank 1...? (ARRANGEMENT_POS and ARRANGEMENT_POS_SUB are the main values you want to check out) (What you are currently overwriting are the VRAM arrangements, btw. They and their shadows live in VRAM to very quickly swap between the two during VBlank) Reducing the amount of preloaded numbers for decimal conversions from 10000 to 1000 to free up some space in VRAM bank 1 should be fine, since most printed numbers don't go above 999.

[Gronis]

Thanks! I've updated ARRANGEMENT_POS to start at VRAM_1 and reduced decimal pre-computed conversions from 10000 to 1000. Now I can use 1024 - 32 tiles for VWF and the flickering has been removed. This is plenty of tiles and I don't think there should be any problem with insufficient tiles when rendering any screen now :D

[Gronis]

Some updates with a new font which works better with VWF rendering since it's not overly bold.

Let me know what you think!

The only problem now with the new font is that it is not compressed using LZ77 like the old font, which uses around 2kB of additional ROM memory. I'm having a hard time find a way to compress it.

I haven't pushed any code yet. I'll do that once I'm happy with the functionality and I've cleaned up the code a bit.

[Lorenzooone]

Looks fine. When it comes to sizes, how much space do the fonts take when fully expanded, but still 1bpp? 4KBs? You could, in theory, decompress them to VRAM 1 when init_text_system is called, and copy from there. There should be some space left, right? 16KBs for the VRAM data, 2kBs for the numbers and the other 14 KBs should be free, right? With the added benefit that VRAM is faster than EWRAM. Another way to save space would be to only memorize the actually useful letters (skipping whitespaces), and to also have a table for the decompression process.

[Gronis]

I was thinking more about ROM size of the gba file than RAM size while executing the application. Compressing the font would save roughly 2kB on the rom size. I just skipped compression and the gba file is slightly bigger. The code I've added contributes to around 3kb of additional ROM size (5kB bigger than before in total at this time) so i'm not really concerned atm. If we want to do ROM size optimisation (for faster loading times over multiboot), there are bigger assets to compress anyways.

Runtime memory is not an issue either. I did decide to move the 1bpp representation of the font to the VRAM as well as other buffers needed for the VWF renderer (precomputed character widths and dynamic tile allocation mask to be specific). This is mostly for making it faster when it sits in VRAM rather than EWRAM, while also leave room in EWRAM which is pretty taxed already.

[Gronis]

I've added a MR which should be final. I've tested this version quite alot so I don't think there are any visual rendering bugs.

Note: The sprites are moving slow because of low fps in gif converter. They move at the same speed as usual in reality.

Here is the final visual result: