How capable would the Neo Geo MVS/AES be in 3D polygon graphics?

[Chilly Willy]

SRAM is only option there. you'd probably want 2 banks... one that VDP reads and other than CPU writes to... a double buffer

At least large SRAMs are cheap these days. While virtually impossible to do before at an affordable price, the memory today wouldn't be very expensive at all.

[Jasper061992]

At least large SRAMs are cheap these days. While virtually impossible to do before at an affordable price, the memory today wouldn't be very expensive at all.

So how much SRAM would be required for purpose? You would still need your regular graphics ROM for storage right? I'm somewhat confused about why extra RAM chips are needed within the cartridge simply for software 3D rendering, instead of somehow, interfacing both the graphics ROM and Instruction ROM together via some chip, unless it doesn't work that way in the Neo...

[Guntz]

The CPU needs access to some graphics RAM in order to do software rendering. It's been said before in this thread, that the Neo's 68k has no access to graphics RAM, so you'd need to provide some on the cartridge.

[Jasper061992]

The CPU needs access to some graphics RAM in order to do software rendering. It's been said before in this thread, that the Neo's 68k has no access to graphics RAM, so you'd need to provide some on the cartridge.

Yeah I already got that notion. I was asking why there needs to be RAM on top the already existing ROM chips. Thats what was stated, unless the others are saying the 68k needs beyond 64k of RAM (which it already has access to) for 3D polygon storage.

Maybe that 64k RAM is strictly for program storage only so the 68k needs another pool of RAM within the cartridge for writing the polygon graphics to. Hmmm, so in essence that SRAM pretty much unifies the idea of the separate graphics ROM and the instruction ROM together if wired to standard ROM chips (containing code and graphics together) and wiring to the 68k and the graphics hardware. Hmmm, I think I got it along the way unless someone wants to further correct me.

This also gets me thinking, I suspect this trick is impossible for the Neo Geo CD seen as everything on the motherboard is already all hardwired for it's purpose? The memory setup on the CD, while the memory pools are of a different size, I suspect it faces the same problem with the 68k only having access to it's 2MB of instruction RAM and all the other chips for the other respective processors. The memory setup on the CD if anything, reflects that of the MVS/AES's memory setup...

[Guntz]

Yeah, the 64k of memory for the Motorola isn't designed for graphics. The CPU apparently is inherently blind to the graphics chip's RAM, so we need to put some new graphics RAM on the cartridge so the CPU can see it and from there, software render our polygon graphics.

[kool kitty89]

SRAM is only option there. you'd probably want 2 banks... one that VDP reads and other than CPU writes to... a double buffer

Or 1 bank at 2x the speed with interleaving support. (it is SRAM after all)

68K in NeoGeo has no access to the graphics on cartridge at all, you'd need some custom cart which maps some CPU ROM space into GFX ROM space and RAM so you could do some software rendering

Doesn't the NES have the same problem, or does the CPU have access to VRAM/ROM? (otherwise games like Elite would either need a mapper to allow CPU access to a framebuffer or a separate coprocessor handling the rendering with access to the video bus -I assume it's the former)
The CPU must have some way of accessing onboard VRAM (for sprite/character table/map updates), but the cart bus would be needed for a full framebuffer. (even at 1bpp, you'd need a lot more than 2 kB)

NES PPU can write to its memory space, NeoGeo video setup cannot, its only designed to do reads from video ROMs

Yes, but how could you move CPU written data to an external char-RAM buffer? (does the PPU have DMA to CPU RAM -or CPU to VRAM, with PPU copying to char-RAM)

Or do like was suggested above and just connect RAM to both CPU and video buses (on NES or Neo) with bank selecting (like MCD word RAM in 1M mode or 32x buffers) or fast enough SRAM to simply interleave accesses.

At least large SRAMs are cheap these days. While virtually impossible to do before at an affordable price, the memory today wouldn't be very expensive at all.

At the resolutions and color depths we're talking (288x224 would show no boarder on most NTSC sets), you wouldn't need much RAM anyway. 64-128k would be fine, or less than that if you limited screen size or single buffered. (Star Fox only used a 32k SRAM buffer -I thought it was 128k, and maybe some Super FX/FX2 games used that much, but Star Fox was just 32k)
Actually, Atari 7800 games were using 32x8 SRAM chips on-cart in 1987/88. (only a few games did that -mostly Epyx releases, and a bit surprising given the low-cost aim of 7800 games, and only 16 of the 32k was actually used -2 8k chips wouldn't fit on the cartridge apparently and they opted not to use an oversized one; the games were still cheaper than most NES contemporaries too, though about double that of most new 7800 games at the time -at least from anecdotal accounts -makes you wonder if they could/should have just slapped a POKEY+32k RAM onto a lock-on cart and offered enhanced games that way -especially since no POKEY or RAM expanded games were released until '87/88 anyway)

The SCD ASIC can do a fill two ways: One way - set the source to point to the color to fill and set the source increments to 0. It will then fill the specified output rectangle with the color. The other is to set the source to the color (or a small fill pattern) and set the WRAP flag. It will then fill the output rectangle with repeated blocks of the fill color/pattern.

Will both of those methods still require a read before each write? (even if you don't have any FPM supporting fill operations -or writing more than 4 bits at a time, consecutive writes for fills would still mean 3 ASIC clocks per pixel rather than 6 or more -more than 6 depending if there's additional waits between reads and writes, not sure on the ASIC's timing but I know the Jaguar's blitter has one additional cycle when texture mapping -11 cycles per pixel, with 5 cycles per DRAM read/write)

If you must do reads and single pixel writes at a time, the sub-CPU should be faster at filling polygons using the full graphics function (more so since you could write 1 or 2 pixels at a time, not just 1), though then you wouldn't have drawing in parallel with the 68k. (except it would probably take some pretty tight programming to get the sub CPU multitasking -ie setting up a line for the ASIC to draw, getting in a few cycles on setting up the next line or something else while the ASIC draws, etc -unless you could buffer a string/list of ASIC drawing commands into word RAM and not have to tightly interleave tasks)

Plus, if you always need reads before writes for the ASIC, textured polygons would be rendered just as fast, but of course limiting memory use more. (and more complexity for the CPU to point to the appropriate texture block rather than a generic color or simple pattern)

It's possible to do textured triangles though, if you're willing to waste some memory. Look near the end of this post to see what I mean =P

Yes, textured triangles (or warped quads) were used in several games to limited extent. (Batman Returns, Batman and Robbin, F1 Beyond the Limit, Joe Montana NFL)

Too bad Stellar Fire didn't use textured ground and polygons.

Use a flat texture?

Chilly Willy already addressed line filling and it seems like you just have to "trick" it like I first mentioned. (pointing to solid colors or simple patters as the source texture) I'll have to wait for his next reply, but it doesn't look like there's any way to tell the ASIC to just fill a line (or block) with a solid color.

This is what they should have done instead of putting emphasis on FMV. Everybody would have jumped over it =| (EDIT: derp, was thinking on marketing, screw that comment)

Well, yes, there's a marketing/software end to it too after the fact (ie with the current MCD hardware and not a hypotnetical alternative with more or different hardware rendering support).

FMV and pushing 3D wouldn't be mutually exclusive . . . that combination (multimedia and 3D) is what the PSX championed after all, but the Sega CD just lacked the software support to really push anything hard (without changing things to get more support -which is a bigger discussion), though more 3D would have been interesting. Sega of Japan's in-house support was surprisingly lacking, especially given its year earlier release and obvious intent to push against NEC's market. (Sega of America -and western associates- seemed to give significantly more support in general -not just FMV- than Japan -Game Arts was the big exception on Sega's JP end)
After all, Sega of America commissioned the Clockwork Tortoise developed games (some of the most technically impressive on the system -Batman and Robbin also had some of the best looking FMV), though the ads did seem to focus too much on the FMV side. (ignoring multimedia -including interactive movies- would have been stupid, but promoting them alongside the diverse library and other advantages of the CD more evenly would have been smart -promoting the graphics and sound improvements with more games to back that up would have been significant, and more games in general obviously -the latter would risk a lot of money if it failed to really get big, though they at least should have been supporting more ports of popular games -even ones with minimal enhancement could have been much cheaper than cart versions and cater to promoting low cost of the media and the ability of the system to pay for itself in the long run)

OTOH, given the limited (and sluggish) support for the more advanced features, one could argue that Sega would have been better off with a more stripped down and basic CD unit that was cheaper (let alone earlier -very important in Japan) . . . or doing that and releasing a separate add-on with graphics+sound enhancement too. (or other things, but I already discussed that here: http://www.sega-16.com/forum/showthr...if...&p=364699 -and for a few pages before that, but that was the final/definitive post on it -though the idea was tossed around a few threads before that too, except never with the the Slipstream comparison . . . I think one was called "early 1992" or something and the other was an alternate reality thread started by Sheath more recently, though that went all over the place with different topics on SMS/MD/CD/32x/Saturn and alternatives)

If you're using the ASIC you may as well just try textured polygons =P

You've got limited RAM too though. (and exceeding word RAM means more updates by the 68k -eventually you exhaust pro-ram too, not to mention contention for other data a game may need)

[Sik]

You don't need two banks of SRAM, just one single SRAM chip big enough to hold both buffers... You can change the buffer being shown on screen by merely modifying the sprite table.

Yes, textured triangles (or warped quads) were used in several games to limited extent. (Batman Returns, Batman and Robbin, F1 Beyond the Limit, Joe Montana NFL)

I meant triangles with arbitrary vertex positions though... As far as I know all those games impose some restriction on how the texture is mapped.

[TmEE]

Or 1 bank at 2x the speed with interleaving support. (it is SRAM after all)

you can completely forget that idea, you don't know when one or the other does an access and you cannot stop anything there

Doesn't the NES have the same problem, or does the CPU have access to VRAM/ROM? (otherwise games like Elite would either need a mapper to allow CPU access to a framebuffer or a separate coprocessor handling the rendering with access to the video bus -I assume it's the former)
The CPU must have some way of accessing onboard VRAM (for sprite/character table/map updates), but the cart bus would be needed for a full framebuffer. (even at 1bpp, you'd need a lot more than 2 kB)

On NES you just do your write through the PPU into VRAM, no extra headache or anything else...

Or do like was suggested above and just connect RAM to both CPU and video buses (on NES or Neo) with bank selecting (like MCD word RAM in 1M mode or 32x buffers) or fast enough SRAM to simply interleave accesses.

That is what I said in the first place, and this is the only viable method to use on NeoGeo

[Chilly Willy]

Will both of those methods still require a read before each write?

Yes.

If you must do reads and single pixel writes at a time, the sub-CPU should be faster at filling polygons using the full graphics function (more so since you could write 1 or 2 pixels at a time, not just 1), though then you wouldn't have drawing in parallel with the 68k. (except it would probably take some pretty tight programming to get the sub CPU multitasking -ie setting up a line for the ASIC to draw, getting in a few cycles on setting up the next line or something else while the ASIC draws, etc -unless you could buffer a string/list of ASIC drawing commands into word RAM and not have to tightly interleave tasks)

You can do a SINGLE write faster with the CPU; if you stored a long, you'd do four pixels in 6 cycles. The problem is the REST of the 68000 code around that single memory access. Remember that most 68000 commands are 8 to 14 cycles long, and you'll need at least a few even with unrolling loops. That makes the ASIC faster than anything but the most basic FILL operation, even though it works on nibbles. So solid color polygons may be faster to draw with the 68000, but that would be about it.

Chilly Willy already addressed line filling and it seems like you just have to "trick" it like I first mentioned. (pointing to solid colors or simple patters as the source texture) I'll have to wait for his next reply, but it doesn't look like there's any way to tell the ASIC to just fill a line (or block) with a solid color.

The ASIC does three things: handle word memory (which includes that funky byte<>nibble mapping), color expansion, and rotate/scale a sprite. That's it.

Color expansion is meant for fonts, but it could be used for other things. The way it works: one register holds two colors (a nibble each - one color for pixels where the bit is 0, and the other for pixels where the bit is 1); you store a word into another register - each bit corresponds to one of the two colors depending on each bit in the word stored; four more registers are then read to get the 16 pixels to store to memory (each pixel being the "usual" nibble for 16 colors). You can see why it's meant for fonts - bitmap fonts are normally stored as single bits with 0 meaning the background, and 1 meaning the current font color. You would set the font color register with the background color and the current font color, store the font word for each line to the other register, then read the color data from the last four registers to store in the tile buffer. While tiles are 8 pixels wide, "wide" characters like some Japanese characters are often 16 pixels wide; hence the 16 pixel wide font expansion support in the ASIC.

I meant triangles with arbitrary vertex positions though... As far as I know all those games impose some restriction on how the texture is mapped.

For arbitrary triangles with any orientation, solid colors would be faster done with the 68000, but texture mapped would be done a line at a time with the ASIC. You would need two tables - one in word ram (the trace table), and one in program ram. While rasterizing the triangle, you would store the screen offset and length of the line to the table in program ram, and the texture coords and increments in the trace table. You'd then go in a loop where you set the ASIC using the program ram table, then wait for the ASIC to signal the line was done, then do the next line until they are all done. The ASIC can generate an exception for the end of the operation that could do the next line until done. Then your rasterizer would only need to start the operation and could go on to other triangles, but you would need a buffer to handle multiple triangles and you add the interrupt overhead to the time spent rendering.

[Sik]

For arbitrary triangles with any orientation, solid colors would be faster done with the 68000, but texture mapped would be done a line at a time with the ASIC. You would need two tables - one in word ram (the trace table), and one in program ram. While rasterizing the triangle, you would store the screen offset and length of the line to the table in program ram, and the texture coords and increments in the trace table. You'd then go in a loop where you set the ASIC using the program ram table, then wait for the ASIC to signal the line was done, then do the next line until they are all done. The ASIC can generate an exception for the end of the operation that could do the next line until done. Then your rasterizer would only need to start the operation and could go on to other triangles, but you would need a buffer to handle multiple triangles and you add the interrupt overhead to the time spent rendering.

...no. Otherwise doing any kind of rendering with the ASIC would be so slow it would be pointless to even bother with it.

Did you even look at the thing I linked? It only does three operations: scale, skew and rotate. It doesn't even change the operations per line (unlike the landscape effect). It's literally just doing some simple transformation on a quad, something the ASIC was designed for. You don't need it to issue an IRQ every line =/

[Chilly Willy]

...no. Otherwise doing any kind of rendering with the ASIC would be so slow it would be pointless to even bother with it.

Did you even look at the thing I linked? It only does three operations: scale, skew and rotate. It doesn't even change the operations per line (unlike the landscape effect). It's literally just doing some simple transformation on a quad, something the ASIC was designed for. You don't need it to issue an IRQ every line =/

Ah! I see what they're doing - they're making the textures match the triangles before hand. That does allow you to render the triangle in one pass with something like the ASIC. Nifty idea. More work at the start to make the end much faster. My explanation was for conventional rendering of triangles where the texture is "normal", not pre-processed. The one thing you lose with pre-processing the texture is space: you have to have a square of cleared space that completely surrounds the triangle, otherwise it will overdraw already drawn parts of the display. You also need to set the memory mode to overdraw for this to work. Oh, that's another thing - it still overdraws the triangle as it will always draw a square surrounding the triangle, but some/much of the overdraw will be zero.

[Sik]

Well, the ASIC will always draw a square either way, it's enough to make this square just large enough to contain the visible part of the triangle and nothing else. Also another disadvantage is the lack of UV mapping. Oh, and then you have to deal with near-Z clipping, but I know a way to work around that (essentially: do the clipping, then attempt to guess the coordinates of the outbounds vertices based on the clipped result).

What you gain doing it this way though is speed, and lots of it. You're essentially using the ASIC as a 3D renderer. It would be nice to see a fully polygonal game on just Mega CD hardware using this method. We really don't know how much can the ASIC do since it's always capped by VDP transfer bandwidth =P

[Chilly Willy]

Well, the ASIC will always draw a square either way, it's enough to make this square just large enough to contain the visible part of the triangle and nothing else.

Exactly, so you have "overdraw", but it's clearly faster even with that.

Also another disadvantage is the lack of UV mapping. Oh, and then you have to deal with near-Z clipping, but I know a way to work around that (essentially: do the clipping, then attempt to guess the coordinates of the outbounds vertices based on the clipped result).

Yeah, it's obviously not going to be perspective correct for the entire triangle. Think of it as 2D affine mapping instead of 1D (raster line). Again, it's a trade-off for speed.

What you gain doing it this way though is speed, and lots of it. You're essentially using the ASIC as a 3D renderer. It would be nice to see a fully polygonal game on just Mega CD hardware using this method. We really don't know how much can the ASIC do since it's always capped by VDP transfer bandwidth =P

Now I REALLY want to work on an example.

[Guntz]

Isn't Silpheed close enough to a fully 3D polygonal Sega CD game? Pretty much every other 3D game I've seen has a bunch of 2D stuff to optimize for speed.

[Kamahl]

Isn't Silpheed close enough to a fully 3D polygonal Sega CD game? Pretty much every other 3D game I've seen has a bunch of 2D stuff to optimize for speed.

It's an FMV game with what SEEM like 3D ships, I won't even bet on that.
Love it anyway. Only game that really used the FMV well during gameplay.