Comix Zone: most technically impressive "16 bit" game?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

turboxray
Posts: 104
Joined: Thu Oct 31, 2019 12:56 am

Re: Comix Zone: most technically impressive "16 bit" game?

Post by turboxray » Sat Nov 02, 2019 7:33 pm

93143 wrote:Yeah, both SNES and MD can update almost the exact same fraction of the screen worth of tiles via DMA during VBlank (which console can do more depends on how much of OAM/SAT and CGRAM/CRAM need updating, as they are different sizes). Mega Drive can keep going during active display using the FIFO, but it's horribly slow, completely stalls the CPU, and can cause visible artifacting if you update something while it's being displayed, so you probably don't want to do too much of that under normal circumstances.
TmEE had a trick where he turned off the screen during hblank that allowed him to transfer more per scanline. He turned the display back on right before the screen went active. But yeah otherwise it just stalls the cpu. Didn't cause any artifacting from what I remember. But I don't remember the exact amount he could transfer before artifacting.

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Comix Zone: most technically impressive "16 bit" game?

Post by tepples » Sat Nov 02, 2019 8:19 pm

The Mega Drive VDP FIFO's instantaneous capacity is four 16-bit writes or 8 bytes. With rendering on, writes commit at a sustained rate close to 16 bytes per scanline, though somewhat unevenly. So if you write 8 bytes per scanline, enough for two decompressed tile rows or one SAT entry, you'll never stall it. This can prove helpful if making a bullet curtain game using more than 100 sprites or if you're decompressing background or sprite tiles from ROM and streaming them to VRAM.

User avatar
TmEE
Posts: 760
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: Comix Zone: most technically impressive "16 bit" game?

Post by TmEE » Sat Nov 02, 2019 9:40 pm

There's 18 access slots per line when rendering is not disabled in H320 and 16 when in H256, but you are stalling the CPU when trying to use them all since FIFO will not be emptied fast enough in most cases. If you manage to pepper some processing between the data writes you might be able to get by without any stalls. Line where no rendering happens will give you 205 (H320) or 167 (H256) access slots. For CRAM and VSRAM transfers you lose some of the access slots due to FIFO getting emptied faster than for VRAM (VRAM is 8bit, CRAM and VSRAM are 16bit) when refresh slots are encountered.
Turning rendering off during offscreen parts of a line will eat away your sprites, since they are fetched from VRAM and rendered to the linebuffer during the offscreen part, and various preparations are done during onscreen part such as making the list of visible sprites for the line and fetching their attributes for the render steps ahead aswell as clearing out the line buffer so it can be rendered into again. VDP will only render to transparent pixels in the line buffer.

93143
Posts: 1225
Joined: Fri Jul 04, 2014 9:31 pm

Re: Comix Zone: most technically impressive "16 bit" game?

Post by 93143 » Sat Nov 02, 2019 10:50 pm

turboxray wrote:TmEE had a trick where he turned off the screen during hblank that allowed him to transfer more per scanline. He turned the display back on right before the screen went active. But yeah otherwise it just stalls the cpu. Didn't cause any artifacting from what I remember. But I don't remember the exact amount he could transfer before artifacting.
That may also be possible on SNES. I don't know if it's been tested; it's one of the things I haven't gotten around to yet. As with the MD, this would almost certainly prevent sprite compositing.

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Comix Zone: most technically impressive "16 bit" game?

Post by tepples » Sun Nov 03, 2019 6:43 am

TmEE wrote:Turning rendering off during offscreen parts of a line will eat away your sprites
Will it corrupt the SAT in VRAM or the VDP's SAT cache, like on the NES where OAM is DRAM with a very quirky DRAM controller? If not, then using an opaque status bar's hblanks for uploading something (as if this were a Game Boy) looks like a valid strategy.

User avatar
TmEE
Posts: 760
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: Comix Zone: most technically impressive "16 bit" game?

Post by TmEE » Sun Nov 03, 2019 6:16 pm

Only way to change sprite cache contents is to write to sprite list in VRAM, it doesn't get corrupt on its own. Line buffer and the render evaluation/preparation data retains its previous state aswell when rendering gets disrupted and things carry on where they left off when process is allowed to continue. Doing a fancy status bar is exactly what I'm doing though you will have to make specially crafted lines prior to such a split to eliminate artifacts caused by disrupting the sprite processing.

Code: Select all

Rendering process happens in 4 steps. Steps 1 and 2 happen concurrently,
starting 16 pixels before right border (start of sprite graphics fetches) and
lasting almost until end of blanking period (until start of BG rendering
process) and concurrent steps 3 and 4 starting 10 pixels before left border
(first sprite attribute fetches) and lasting until 20 pixels before right
border (end of BG rendering period).

The memory used to store info for rendering is 680 bits in size and consists
of 34 bits per 20 sprites. Per entry 7 bits are for of Link values of visible
sprites, 16 bits for attributes, 9 bits for horizontal position and 2 bits
for width.


Step 1
   Scan through the Cache and store up to 20 indexes of sprites that are
   visible using their vertical position and size to determine visibility and
   Link value to determine the order. Storing can happen only when Step 2 has
   made use of the data in the index slot first.
   Scanning is stopped when 80 scan operations are done, 20 indexes are found
   or Link value of 0 is encountered. Sprite Overflow flag should be set when
   21st index is found during this step.
   Number of found visible sprites seems to be stored also because unfilled
   index slots retain their previous values and later render steps always
   do full 20 fetches from VRAM according to those values, but don't actually
   use the data.
Step 2
   Use previously stored 20 attribute values to fetch a slice of graphics 
   from VRAM and store it in Line Buffer according to previously stored
   horizontal positions. Since graphics fetches are in order of discovery
   from Link list, a pixel is stored in Line Buffer only if the particular
   spot hasn't been written to before, otherwise observed priority of sprites
   isn't retained and it also allows easy Sprite Overlap detection. Sprite
   Overlap bit should be set during this step.
Step 3
   Use previously stored 20 index values to fetch horizontal position and
   attributes from VRAM and store them for rendering.
Step 4
   Display the rendered Line Buffer while clearing it out so it can be
   rendered into again (only non zero pixels are rendered into).

Post Reply