Studying how GeoLith emulates the NeoGeo's rendering of an individual scanline...
Within the visible portion it looks up a backdrop colour & the relevant portions of the frame & sprite buffers, iterates over a line of that framebuffer looking up the colours in the palette falling back to that background colour whilst zeroing out the sprite buffer, zeroes some variables before iterating over & rendering the sprite table 2 lines in advance, & invokes a pre-chosen callback.
1/3?
On a couple other specific lines it does that some iteration & rendering over the sprite table.
The callback incorporates an overlay by either:
* Iterating over the pixels looking up corresponding data in an array representing VRAM extracting a tile-number & palette-offset before iterating over the tile's pixels for that row copying over the corresponding palette-colours for non-zero pixels.
* A variant which precomputes per-scanline banks.
* Another variant with extra offsets.
2/3?
Which of those callbacks is used depends on which game was loaded, so clearly they're in part emulating mappers in the NeoGeo cartridges!
To render each sprite a couple scanlines ahead (NeoGeo didn't have enough VRAM for a framebuffer, but it did have enough for a scanline buffer) GeoLith extracts sizing properties or computes the x-position as an offset, calculates which row of the tiles to render inverting it if requested, performs hittests, tweaks if its 33, ...
3/4!
... looks up the data from character-ROM inverting if requested, calculates some offsets & retrieves data from VRAM, tweaks tile numbers based on an auto-animation timer if requested, computes some more offsets, & iterates over the tile's data from ROM whilst writing that palette-ID with offset into the linebuffer at appropriate X offset.
This was clearly quite a fancy GPU for the time, but that wouldn't last long!
4/4 Fin for today! Tomorrow: A high-end Yamaha chip!
