Tile Caching: Render Optimization

Summary

Implemented Tile Caching in the renderer to dramatically optimize rendering performance. Instead of decoding 23,040 pixels pixel by pixel in each frame using PixelArray, they are now cached the 384 unique VRAM tiles (0x8000-0x97FF) as 8x8 pixel pygame surfaces and are rendered using fast blits. This reduces the workload from ~1.3 million operations per second to ~360 blits per frame, allowing you to reach 60 stable FPS without frame skip.

Hardware Concept

The Game Boy has 8KB of VRAM (0x8000-0x9FFF) which contains the graphics data in 2bpp format. The first 6KB (0x8000-0x97FF) contains 384 unique 8x8 pixel tiles, each occupying 16 bytes (2 bytes per 8 pixel line). Traditional rendering decodes these tiles pixel by pixel on every frame, which is extremely expensive in pure Python.

Tile Cachingis a standard technique in emulation that takes advantage of the fact that the tiles they rarely change during execution. Instead of decoding each tile in each frame, they are decoded only once when they change and are saved as pre-rendered surfaces. The rendering then you just need to make blits (quick copies) of these surfaces, delegating the heavy lifting to C (SDL).

Source: Pan Docs - VRAM Tile Data, Emulation Optimization Techniques

Implementation

A complete Tile Caching system was implemented with the following components:

Components created/modified

• renderer.tile_cache: Dictionary that maps tile_id (0-383) to 8x8 pixel pygame.Surface
• Renderer.tile_dirty: List of 384 boolean flags that indicate which tiles have changed
• Renderer.bg_buffer: 256x256 pixel surface to draw the full tilemap
• Renderer.update_tile_cache(): Method that decodes tiles marked as dirty and caches them
• Renderer.mark_tile_dirty(): Method called from MMU when writing to VRAM
• MMU.set_renderer(): Method to connect MMU with Renderer for dirty tracking
• MMU.write_byte(): Changed to mark tiles as dirty when writing to 0x8000-0x97FF

Design decisions

1. Cache range (0x8000-0x97FF):Only the first 384 tiles are cached because They are the most used for Background and Window. Tiles at 0x9800-0x9FFF (tilemaps) are not cached because they are indexes, not graphic data.

2. Large buffer (256x256):The entire tilemap is drawn in bg_buffer and then the visible window (160x144) is cropped using blit with crop area. This is more efficient than calculating offsets for each tile individually.

3. Dirty tracking:Tiles are marked dirty when the MMU detects writing in VRAM. This avoids decoding tiles that have not changed, maximizing the benefit of the cache.

4. Fallback for tiles out of cache:If a tile is outside the cached range (rare, but possible with signed addressing), it is decoded directly as a fallback.

Affected Files

• src/gpu/renderer.py- Tile Caching implementation: cache, dirty flags, update_tile_cache(), mark_tile_dirty(), and complete rewrite of render_frame() to use blits
• src/memory/mmu.py- Integration of dirty tracking: set_renderer(), and modification of write_byte() to mark dirty tiles
• src/viboy.py- MMU-Renderer connection: calls to set_renderer() after creating the Renderer, and setting BATCH_SIZE from 64 to 128 T-Cycles

Tests and Verification

Performance validation:

• FPS before:~20 FPS with Batch=64, Skip=0 (bottleneck: PixelArray pixel by pixel)
• FPS after:60 Stable FPS with Batch=128, Skip=0 (blit rendering)
• Improvement:~3x faster, completely eliminating the rendering bottleneck

Functional validation:

• Graphics render correctly (no visual artifacts)
• The scroll (SCX/SCY) works correctly with the new blit system
• The Window is drawn correctly on top of the Background
• Sprites render correctly on top of the background
• Tiles update correctly when they change in VRAM (dirty tracking)

Test ROMs:

• Tetris (user-contributed ROM, not distributed):Verified that it runs at 60 FPS without lag, smooth movement of pieces

Note: No specific unit tests were run for Tile Caching because it is an optimization performance that does not change functional behavior. Validation was done through tests visuals and FPS measurement.

Sources consulted

• Bread Docs:VRAM Tile Data, Background Tile Map
• Optimization techniques in emulation: Tile Caching is a standard technique mentioned in educational emulator documentation

Note: The Tile Caching implementation is a general optimization technique in emulation, not specific to Game Boy hardware. It was implemented based on general optimization principles of rendering and knowledge of how blit operations work in SDL/pygame.

Educational Integrity

Next Steps

• [ ] Optimize sprite rendering using Tile Caching (currently uses PixelArray pixel by pixel)
• [ ] Consider caching tiles with multiple palettes to avoid re-decoding when BGP changes
• [ ] Profile performance with more complex games to identify potential additional bottlenecks
• [ ] Implement support for 8x16 pixel sprites (currently only 8x8)