Home Page Forums MAME MAME The SNES WIP topic

I mean the fact that afaik the screen is drawn correctly without any artifact on a real screen if you toggle gfx modes 1/5 or 5/1, something that's imho impossible to not be noted if the resolution is changed during the frame (otherwise games like Seiken Densetsu 3 weren't programmed like that if it was suicide for the eyes).

Buh? The SNES doesn't have an "internal framebuffer". I don't know if it even has a linebuffer (byuu?). AFAIK each scanline is rendered directly to the video outputs in real time. Don't confuse multi-thousand-dollar arcade PCBs that could afford to throw on hundreds of kilobytes of RAM with consoles that had to retail for $200.

That Seiken Densetsu 3 screenshot is definitely not what the game looks like on real hardware--the Japanese text is too blocky and almost unreadable.

Every CRTC/video chip has an "internal framebuffer(s)", the sprites / tilemaps / blitters / polygons stuff is just a layer that is then always converted internally by the video HW. It's only a recent "invention" that you can control/write this framebuffer directly, but it was still there from the dawn of times...

About Seiken Densetsu 3, there's certainly a bug regarding that garbage at the top of the talk bar, surely there's a couple of bug in the current mode 5/6 implementation (see also the vertical stripes in that Tokimeki Memorial screen).

I sincerely doubt it. The closest they have is a sort of pre-fetch line for OAM, to handle all the RTO stuff and sorting. That's why scanline 0 is black, OAM is preparing. And yes, modifying certain registers mid-frame will thusly throw off OAM rendering really bad.

Outside of that, yes. It almost certainly outputs one pixel at a time and moves on.

SNES definitely draws on-the-fly. If it has any sort of *buffer, byuu's right: it's for sprites only.

Reasoning? Why would Nintendo add a framebuffer to the SNES, when the NES didn't have one? The hardware *is* directly related. Also, thwe SUperscope is a heavy argument against a framebuffer.

It's been calculated which way sprites are handled, and the basic answer is "there's no way to tell". The data necessary to hold the tiles and x position info are roughly equal to the demands of plotting the sprites out as tiles are fetched, and only handling priority and palette lookup during rendering to screen.

anomie's research always said that p-hi-res was simply double-pumping the DAC, and there was no reason to think modes 5 and 6 were different.

Yeah, that's exactly what I meant by a "linebuffer". I meant a double-buffered setup for sprites--there's no reason to double buffer the BG layers!

When 2D arcade hardware is described as line buffered (e.g. Sega System 16A/B) or frame buffered (e.g. Sega X-Board) it refers to how the sprite generator works--BG layers are practically always rendered directly to the mixer. On a frame buffered system the fact that sprites, but not the BG, are double-buffered is what causes "sprite lag", where the sprites appear a frame or two out of sync with the BG if an emulator (or the original game code!) doesn't take the double buffering into account.


I wasn't just talking about the garbage. Any time there's even a single visible scanline of hires anywhere on the screen you need to render the entire frame at 512 resolution, otherwise you're throwing ("half-")pixels away.

well, the SNES backgrounds are double-buffered as well, sort of.

The system doesn't have enough bandwidth to render the worst case scenario unless 2 complete sets of BG tiles are loaded at the start of rendering. It also explains why the left tile in Mode 2/4 is not offset

I'm having a hard time wrapping my brain around what you mean by that. What exactly is "double buffered"--the tile pattern data? And how does that help with bandwidth? What is the "worst case scenario", and what happens if it occurs on more than one scanline, or even on every scanline?

You have to load the second tile of the line before rendering starts. That means tilemap and tile data for up to 4 BGs must be present for 2 complete tiles before you start.

you can load 2 bytes per dot, and you render one pixel or 2 half-pixels in high res in that time.

worst case, you have to reload everything after 1 pixel. The SNES can't do that, but 8 pixels is just enough to do that, necessitating caching a second tile. (1 dot = 1 16-bit read, so 1 tilemap or 1 2bpp chunk of 8 pixels). This is why every time you raise the bit depth, the layers drop: to shift bandwidth to accomodate more planes being fetched.

Work it out, you NEED 2 tiles to draw at all with 7 pixels of the first tile scrolled off the left edge of the screen. Can't work any other way (although the order BGs are fetched in isn't assured, and it's unknown how tiles and tilemaps are interleaved)

This only affects a given line. The whole proces restarts on the next line.

Oh, you meant double buffered in terms of tiles. I was thinking scanlines, since we were previously talking about line buffering sprite generators. Your explanation makes perfect sense (whereas buffering a scanline ahead makes no sense at all)

I figured that the reason the SNES PPU has the modes it does is because of memory bandwidth as soon as I noticed that the total number of 2-bit planes (doubled in the hires modes) plus the number of layers (counting the OPT table as a layer) always adds up to no more than 8:

Mode 0: 4 layers + 4 planes (1 + 1 + 1 + 1) = 8
Mode 1: 3 layers + 5 planes (2 + 2 + 1) = 8
Mode 2: 3 layers + 4 planes (2 + 2) = 7
Mode 3: 2 layers + 6 planes (4 + 2) = 8
Mode 4: 3 layers + 5 planes (4 + 1) = 8
Mode 5: 2 layers + 6 planes (2*2 + 1*2) = 8
Mode 6: 2 layers + 4 planes (2*2) = 6

ETA: I just noticed that this also explains the limitations of Mode 4 compared to the other OPT modes (i.e. each tile can only have a horizontal or vertical offset applied, not both)