The video player: VDP command engine

The idea of using VDP block commands on top of the VDP I/O hammering by the CPU came about when I saw that my engine could not fully reach 30 FPS for all frames in Bad Apple. I needed to find out how to get the VDP working in parallel with the CPU. The 4 frames in the scheme giving ~ 200 000 cycles weren’t enough.

I figured I could:

• Use a fast fillrect (HMMV) if there are large blocks of similarly colored areas
• Use block copy in particularly “noisy” areas

Challenges with this:

• To analyze and find those noisy, bang-for-the-buck areas
• The data for the block copy needs to already be present in VRAM

This feature is both strong and weak at the same time:

• It gives me some additional pixel budget within my frame scheme
• It does not help to scale above the aforementioned point
• It increases data size: Any rect ends up non-diffed and takes W x H pixels

I still went ahead and tried this approach, because:

    ✅  It was a PoC — test what is possible
    ❌  Target was Bad Apple running within the scheme

    ❌  Only used when exceeding four-frames per update

So, I found the biggest possible areas which the engine could perform for fillrects (~5500 bytes) and copy (~3500 bytes) during one frame. As the VDP command is async with no notification about when it is finished, we cannot plan for more than one VDP command per frame. At least not if I want this to be simple and efficient. In turn this means that I could allow up to four commands per page update.

For debugging purposes we use these distinct colors for the blocks that are handled by the VDP command engine:

    •  Red, blue, yellow, green: Fill rects

    •  Pink: Block copy

Here are some examples:    

The data size of a fillrect in the data stream is really small, but the data size of the pink copy rect is quite sizable. Copy rects need to be pushed to pages 2 and 3 during up-front frames that otherwise have no other work, and there are normally plenty of those.

The data for the copy rects is uploaded to VRAM page 2 and 3 in a standardized size: 80 x 64 pixels (40 x 64 bytes). That’s a 3 x 4 grid in each page, totaling 24 slots. These are filled up in a circular list manner to enable reuse. Slots are being freed as soon as they have been used.

Here’s a dump of how page 2 and 3 can look mid-video with a 3 x 4 array of slots.

< Optimized VRAM writes | VDP command engine | Storage >