Rem Demo

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
none
Posts: 38
Joined: Thu Sep 03, 2020 12:56 am

Re: Rem Demo

Post by none » Sun Sep 13, 2020 11:28 am

I've made a faster alternative implementation of the window clipping:

https://github.com/rmn0/rem/commit/f496 ... 196bf4a739

This one accelerates the clipping with hardware using indirect HDMA. It uses a 256-byte indirect table with the scroll coordinate mapping, which itself is created via DMA. The HDMA tables for the images themselves are now stored directly in ROM. While these are larger than with the other approach, the overhead isn't that bad because of the inherent run-length encoding. Vertical scrolling works by triggering HDMA late with IRQ, so that the line counters and table addresses are not automatically initialized. Clipping against the top screen border is the trickiest part, because the starting table row is not known because of the RLE. Because of this, a small 64-byte index table is stored alongside the data to accelerate seeking in the HDMA table.

The main downside with this one is that it requires four DMA channels instead of just one, because each window border needs its own indirect lookup.

Compared to the other approach, this one is very fast, it takes 2 or 3 scanlines in most situations and 5 or 6 scanlines when clipping against the top screen border.

Also this implementation can be easily extended to use images larger than 256x256px without any big performance losses.

One thing I don't really know how to handle is the updates of the indirect table... I don't want to waste any vblank time doing that, but updating it mid-frame produces tearing. Double buffering could maybe work by having one table in the low ram bank and the other one in the high ram bank, and using bank switching for double buffering.

Post Reply