What kind of 3D calculations were used in SuperFX games?

[koitsu]

I'd like to politely request someone take control of this thread and formulate all the questions that people want answered. I really need something clear/concise, like an itemised list, not just random jumbled posts intermixed with questions and statements (that doesn't apply to all of you by the way, just some :-) ).

I will bold and enlarge the font for this statement: the questions need to be precise and as terse as possible (within reason).

If someone could please do that, and reach a general consensus of what's wanted, I can submit them to Krister and see what he says. There is no guarantee he will respond (I sent him Email a week ago relating to work stuff and he hasn't responded, so I think he might be on vacation or just very very busy), so just please keep all that in mind. (The work he does where we're employed is quite important)

If there are general questions that are more vague, I'd suggest reading interviews like this one, and see if your questions are already answered there.

[Myask]

Like so?

1)How does the SuperFX compare against the DMA at filling pixels?

1) What algorithms are used to process the vertices? Both transformation and projection.

2) What algorithm is used to raster (render) the triangles?

3) [split, trim] Related, is there any special calculation [in Starfox/the SuperFX?] to discard backfacing triangles?

4)[trim] What were the biggest bottlenecks when programming [with] the SuperFX?

1)What was the development process like?

2) [paraphrase]Did you debug on a PC or on the SNES? If on the SNES, how?

3) [trim] Did/Does the SuperFX CPU itself have any sort of debugging features?

4) [trim] Although I realize you were working on the software, but do you recall any discussions about why the SuperFX boards had to start using a dedicated clock resonator circuit instead of the 21 MHz signal from the cartridge edge?

1)[paraphrase, trim]How did they handle interoperability between the scpu and gsu; how exactly did they split the tasks between the two processors and which one did what?

1) What I'd love is a timeline about the whole Argonaut project.

2) I'd love any info about projects, both successful and cancelled.

I have a few technical Super FX questions

Revised List:

1) What are the absolute hardware bottlenecks on blitting (using PLOT with color #0 not written, or only PLOTting part of a pixel cache, so it has to read the old data from RAM before writing the new data back)?
1b) How many cycles does it take to empty the secondary pixel cache under those circumstances?
1c) How about transferring the primary cache to the secondary, once the secondary is free?

2) Apparently ROM access in high speed mode (21 MHz) is 5 cycles instead of 3. Is the same true of RAM access? For both reading and writing? And does this impact the answer(s) for (1)? Did this change at all between chip/board revisions?

3) Is the instruction cache on the latest version(s) of the GSU 256 bytes or 512 bytes? I'd like to be sure.

ed: bolded questions specific to SuperFX
ed2: updated 93143's questions

[Myask]

[double-posting to provide partial answers when possible, and to definitively separate from the question-list]

2) [paraphrase]Did you debug on a PC or on the SNES? If on the SNES, how?

I have an unsourced recollection that devs did not have to burn chips, but had a cable-driven SNES. This is most likely a mangled memory from watching the Making of Solstice videos...which had a hint of Equinox. Take with several grains of salt.

1)How does the FX compare against the DMA at filling pixels?

The interview koitsu linked suggests 40x.

3) [split, trim] Related, is there any special calculation to discard backfacing triangles?

Yes.[/useless] If you don't mean specifically in Starfox/SuperFX, either "dot product of the plane" or a cross-product of two edges will let you determine a triangle's facing.[source: Flights of Fantasy] Note that this is basically telling you from which direction the vertices are ordered clockwise-thus, one has to be consistent about that being the in- or outward direction. I expect other methods exist.

[Sik]

I'd like to politely request someone take control of this thread and formulate all the questions that people want answered. I really need something clear/concise, like an itemised list, not just random jumbled posts intermixed with questions and statements (that doesn't apply to all of you by the way, just some ).

Yeah, seriously, this went out of hand, this was supposed to ask just about some specific working internals of the code >.>' (specifically SuperFX code) I wasn't even expecting people to ask other questions. At the rate this is going, soon we'll end up with people asking about stuff not related to even the SNES at all. If you want a good set of questions, just stick with the initial list I posted for now (except question #4 to which we already settled the answer was "yes").

3) [split, trim] Related, is there any special calculation to discard backfacing triangles?

Yes.[/useless] If you don't mean specifically in Starfox/SuperFX, either "dot product of the plane" or a cross-product of two edges will let you determine a triangle's facing.[source: Flights of Fantasy] Note that this is basically telling you from which direction the vertices are ordered clockwise-thus, one has to be consistent about that being the in- or outward direction. I expect other methods exist.

To rasterize a triangle you may want to reorder the vertices to make it easier for the algorithm to scan the lines. You could do this on the assumption a certain winding is always used. If you do it this way, when the wrong winding is used, the two extremes of the scanlines will cross right in the first row, effectively killing the triangle before it even starts getting rendered. The end result is that you get backface culling for free without having to resort to doing any maths.

[rainwarrior]

To rasterize a triangle you may want to reorder the vertices to make it easier for the algorithm to scan the lines. You could do this on the assumption a certain winding is always used. If you do it this way, when the wrong winding is used, the two extremes of the scanlines will cross right in the first row, effectively killing the triangle before it even starts getting rendered. The end result is that you get backface culling for free without having to resort to doing any maths.

I don't follow. To rasterize a triangle, you must trace two vertical lines, one on the left side of the triangle, one on the right side of the triangle. For each pair of trace points, proceeding down, you render the pixels across from one to the other. If you could somehow (how?) arrange the sides to be reversed if the triangle is back facing, yes the horizontal render would be skipped, but you'd still be wasting effort tracing the sides. A simple cross product to determine facing would let you skip the whole operation, why do you want to avoid "doing any maths"?

The usual way I've seen it done is to sort the three points top to bottom, which gives you one long vertical side, and the other side is split into two segments (though if the mid and bottom are on the same line, for example, one of these segments has length 0). This gives you an upper wedge (fanning out from the top point to a flat bottom) and a lower wedge (a flat top converging to the bottom point). You then trace the sides of the wedge, drawing pixels across between them one line at a time. If you do things this way, you have to do the backface culling before sorting the points. Once you've sorted the three points, you no longer have any information about winding because you've changed their order.

There are indeed alternatives to backface culling (e.g. it's not strictly necessary if you have a depth buffer or painter's algorithm), or different ways to specify it (e.g. per-triangle face normal), but winding order of the vertices requires the least amount of extra data (i.e. none) and is very simple to compute. I've never seen any other method used in a game situation; it really is the "standard" way to do it.

[Myask]

Three adds, two multiplies, and a compare to check for discard is cheaper than rendering it. And, like removing those polygons that are behind the viewpoint, it removes about half of them for a mere O(n-polys) operation. Much cheaper than having to determine where to start it and including it in the proper order.

To rasterize a triangle, you must trace two vertical lines,

Well, Bresenham's algorithm is rather cheap...

I've never seen any other method used in a game situation

I suppose the BSP precalculations used by Doom, Quake, and I think Unreal for solid geometry don't count, being more of the "make it unnecessary" variety (and BSP uses two-faced polygons besides). I'm not sure what they use for checking the mobile geometry of elevators, doors, enemies, etc.

To rasterize a triangle you may want to reorder the vertices to make it easier for the algorithm to scan the lines. You could do this on the assumption a certain winding is always used.

I'm not sure I get it either, as that sounds more like y-ordering than winding...?[diagram]

[Sik]

Yeah, Y ordering, except you just rotate the vertices (i.e. don't flip their order), that preserves the winding.

[Myask]

I'm not sure which comparisons you're using to decide which of three rotations to pick, that will exclude, say, 1-3-2 (bottom-left) from happening and partially-rendering.

[rainwarrior]

I've never seen any other method used in a game situation

I suppose the BSP precalculations used by Doom, Quake, and I think Unreal for solid geometry don't count, being more of the "make it unnecessary" variety (and BSP uses two-faced polygons besides). I'm not sure what they use for checking the mobile geometry of elevators, doors, enemies, etc.

Yes, that's what I was referring to when I said with a depth buffer or painter's algorithm (i.e. BSP) it's not necessary to reject back-faces.

From what I remember reading, for movable stuff it's just regular backface culling with possibly some sub-sorting of convex objects on a character. It doesn't use a BSP on the triangles of the character, but I think it substitutes a simple stand-in for it into the world's BSP so it gets occluded by the world. That's what I recall, anyway. I am of a mind to dig that stuff up and read it again now though...

There was another fun tidbit about Quake, that perspective correct texturing was implemented, but as a tradeoff for performance it's applied at the endpoints of a horizontal span, and then the span is subdivided recursively (with perspective correction) until individual spans are short enough, at which point the spans are rendered with linear texturing. They tuned the size where rendering starts until they were happy with the balance of visual appearance vs. performance.

I'm not sure I get it either, as that sounds more like y-ordering than winding...?

Ah, is Y-ordering an alternative backface removal technique? Does it put restrictions on rotation to preserve the ordering?

[93143]

I have a few technical Super FX questions, but I'm not sure if they're the sort of thing one would need to ask one of the Argonauts, and anyway they partly overlap Sik's questions. Does anyone happen to know the answer to these?

1) What are the absolute hardware bottlenecks on blitting (using PLOT with color #0 not written, so it has to read the old data from RAM before writing the new data back, if I understand correctly)? How many cycles does it take to empty the secondary pixel cache under those circumstances (I'm thinking not less than 48 cycles for 8bpp, or less for lower bit depth)? How about transferring the primary cache to the secondary, once the secondary is free?

2) Per the manual, ROM access in high speed mode (21 MHz) is 5 cycles instead of 3. Is the same true of RAM access? And does this impact the answer for (1)?

3) Is the GSU2's instruction cache 256 bytes (as byuu keeps saying re: the Super FX in general) or 512 bytes (as the manual claims)? I'm thinking the latter, and that the former was for an earlier chip rev, but I'd like to be sure.

4) Is there anything special that a developer using a GSU2 would need to do in order to use those 6 MB of extra ROM at the top of the CPU's memory map? (Preferably in FastROM mode?) As far as I know no games ever did...

[Myask]

2) Per the manual

Where is this?

Y'know, it'd be useful for both the SNESDev and GBDev subfora to have stickies with links to reference documents/knowledge bases.

[Sik]

1) What are the absolute hardware bottlenecks on blitting (using PLOT with color #0 not written, so it has to read the old data from RAM before writing the new data back, if I understand correctly)? How many cycles does it take to empty the secondary pixel cache under those circumstances (I'm thinking not less than 48 cycles for 8bpp, or less for lower bit depth)? How about transferring the primary cache to the secondary, once the secondary is free?

Isn't 8bpp (mode 7) packed instead of planar? That'd make it much faster than 2bpp and 4bpp since one pixel would need only one byte access (also, the documentation says that 48 cycles is the maximum for PLOT if I recall correctly)

2) Per the manual, ROM access in high speed mode (21 MHz) is 5 cycles instead of 3. Is the same true of RAM access? And does this impact the answer for (1)?

Where is this mentioned? The opcode documentation seems to assume the clock doesn't affect the speed (it mentions three different speeds depending on whether it's running from ROM, RAM or the cache, but nothing else except for opcodes that may be affected by the GSU status)

4) Is there anything special that a developer using a GSU2 would need to do in order to use those 6 MB of extra ROM at the top of the CPU's memory map? (Preferably in FastROM mode?) As far as I know no games ever did...

Doesn't it use the same bank numbers the 65816 uses?

Y'know, it'd be useful for both the SNESDev and GBDev subfora to have stickies with links to reference documents/knowledge bases.

You'd have some people here complain about copyright infringement then. It's in chapter 2-9 of book II if you get the SNES documentation though (it describes every opcode of the SuperFX).

[93143]

Isn't 8bpp (mode 7) packed instead of planar?

I can't find that data in the manual. Did Doom use Mode 7? I saw a reference that said it didn't. The SNES has two other modes with 8bpp layers, and they're planar. Plus I don't see anything in the manual that indicates radically different behaviour when plotting 8bpp.

Do you even need the PLOT functionality if you're using packed-pixel?

2) Per the manual, ROM access in high speed mode (21 MHz) is 5 cycles instead of 3. Is the same true of RAM access? And does this impact the answer for (1)?

Where is this mentioned?

Page 2-7-2, right before section 7.1.2 begins. There may be multiple versions out there...

4) Is there anything special that a developer using a GSU2 would need to do in order to use those 6 MB of extra ROM at the top of the CPU's memory map? (Preferably in FastROM mode?) As far as I know no games ever did...

Doesn't it use the same bank numbers the 65816 uses?

The ROM area I'm talking about is outside the GSU's jurisdiction. It outright can't see it, nor can it cut off the S-CPU's access to it. I thought the GSU was limited to 2 MB of ROM (or possibly 4 MB if you fiddled with the memory map?), but this is a totally separate block and that limit doesn't apply.

I don't see any real reason why an actual game couldn't have used it (except that a GSU was expensive, ROM was expensive, FastROM was expensive, add 'em all up and...). I'm mostly worried about unemulated behaviour, either in an emulator or on the SD2SNES when/if it supports Super FX, but I don't understand SNES memory mapping well enough to be confident that there isn't a gotcha hiding in there even in terms of real/original hardware...

[Sik]

I can't find that data in the manual. Did Doom use Mode 7? I saw a reference that said it didn't. The SNES has two other modes with 8bpp layers, and they're planar. Plus I don't see anything in the manual that indicates radically different behaviour when plotting 8bpp.

What modes are actually supported by PLOT?

Do you even need the PLOT functionality if you're using packed-pixel?

Yes, because the main advantage of the PLOT instruction is that it converts screen coordinates into tilemapped coordinates.

Note that it's possible to draw without that instruction (by writing to RAM directly). It's perfectly possible Doom isn't even using the PLOT instruction, when drawing vertical spans there isn't much of a problem (every consecutive pixel is always at the same distance in bytes).

Page 2-7-2, right before section 7.1.2 begins. There may be multiple versions out there...

Looks like I skipped it =/ Odd that they didn't mention it in the opcode details though.

The ROM area I'm talking about is outside the GSU's jurisdiction. It outright can't see it, nor can it cut off the S-CPU's access to it. I thought the GSU was limited to 2 MB of ROM (or possibly 4 MB if you fiddled with the memory map?), but this is a totally separate block and that limit doesn't apply.

I don't see any real reason why an actual game couldn't have used it (except that a GSU was expensive, ROM was expensive, FastROM was expensive, add 'em all up and...). I'm mostly worried about unemulated behaviour, either in an emulator or on the SD2SNES when/if it supports Super FX, but I don't understand SNES memory mapping well enough to be confident that there isn't a gotcha hiding in there even in terms of real/original hardware...

Well, technically the GSU is wired directly to the cartridge (it could even be wired to access parts not accessible to the 65816), so in the worst case they could just wire the banks to the relevant portions... The only limitation here would be Nintendo's policies =P

[ARM9]

I can't find that data in the manual. Did Doom use Mode 7? I saw a reference that said it didn't. The SNES has two other modes with 8bpp layers, and they're planar. Plus I don't see anything in the manual that indicates radically different behaviour when plotting 8bpp.

What modes are actually supported by PLOT?

2bpp, 4bpp (tile and sprite, the latter behaving differently iirc) and 8bpp. You also have some settings in the plot option register for dithering and "transparency" (skipping on color 0) etc.. 8bpp can be used for both mode7 and mode3/4, it depends on how you upload it to vram (port $2118 byte transfers interleaved or word to 2118/2119) and how you build your map.

Well, technically the GSU is wired directly to the cartridge (it could even be wired to access parts not accessible to the 65816), so in the worst case they could just wire the banks to the relevant portions... The only limitation here would be Nintendo's policies =P

The gsu sits between the cartridge rom/ram and the scpu so the address bus on the gsu is the limit here, which can only address 2MiB on all but the first version. Shouldn't be too much of a hassle to increase that on something like the sd2snes.