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

[Jasper061992]

Bit late here, but been wondering recently.

We all know how the Neo Geo was touted to be the 2D sprite monster of it's heyday, destroying every other console prior to the 5th gen consoles when it came to graphics literally bringing the arcade within the confines of one's home, the absurd asking price of the system let alone it's games up to this VERY day, the abundance of awesome 2D fighters, you name it.

I also been hearing its completely incapable of pushing 3D polygons. Well I know is's custom 2D chip doesn't render 3D polygons, everyone knows this. But how competent would it be at software 3D rendering with the fast 12Mhz M68000 CPU is what I'm really curious about. I don't think it has been even attempted unfortunatly. I know it will pale in comparison to even the 32x in raw 3D rendering, but just wondering if it can throw at least half decent nontextured 3D polygons with the quality of say, the Arcade version of Hard Drivin' with a decent framerate. I mean, consider the huge cart storage advantage the system has over any other console prior to the 5th gen consoles, I'd say it can run a very sizable 3D game with some potential textures. Only problem would be performance IMO.

It would be interesting still...

[Sega Genesis]

Well, max cart size is about 80mb so that with the super blast-off processing I think the neo geo could at least be able to pull off some 3D even though it wasn't designed for it.

[Sik]

The problem is that sprite graphics are stored in ROM if I recall correctly. That automatically means it's impossible to do any software rendering at all. You'd need to replace it with RAM to make it possible to render triangles at all. Otherwise the best you can do is cheat and try to use triangle-shaped sprites =P

That said, 12MHz 68000 is essentially the CPU in the Mega CD, and that one doesn't have any issues writing to its own RAM at all, so you could probably use that for measurement purposes. Then again, it'd be even better to just use the ASIC with adequately shaped sprites to render textured triangles and get faster rendering and nicer graphics =P

[kool kitty89]

Maybe they could have used RAM on the cartridge to render to. (even if there's no facility for RAM expansion via the cart slot, there's always hacks, and it probably would have been a good bit easier to deal with than the 2600 -getting around a lack of read/write line isn't the hard part there, it's the lack of the phase 2 clock signal the 6502 needs -and using some very careful timing to get around that)

That said, 12MHz 68000 is essentially the CPU in the Mega CD, and that one doesn't have any issues writing to its own RAM at all, so you could probably use that for measurement purposes. Then again, it'd be even better to just use the ASIC with adequately shaped sprites to render textured triangles and get faster rendering and nicer graphics =P

Yeah, though even without the ASIC at least you've got 4-bit packed pixel tiles, so you could work on byte boundaries (write 2 pixels at a time) and be fairly OK with software rendering (ie easier than the Atari ST or EGA PC -Amiga has the blitter to overcome the planar pixel problems).

The ASIC also has the facility to convert 8-bit chunky bitmap graphics to 4-bit packed tilemaps iirc (which would make CPU rendering on a pixel basis a lot easier), though you could also directly render with the ASIC.

Fonzie mentioned that the ASIC is also capable of line drawing (vector lines for wireframe stuff), but that's not so great for polygons by itself.
I'm not sure, but I don't think the ASIC has a fast fill function either (from what Chilly Willy mentioned, if it does do a fast fill to clear RAM regions, it embeds that function within the texture rendering ability -unless I misread what he posted), so you'd have to fill polygons on a pixel by pixel basis, or perhaps "trick" the ASIC by using special textures for filling lines of different lengths and setting the blitter/ASIC to render a line and then resetting it for the next. (not nearly as fast as a true line fill operation could be, but faster than the CD's 68k could do it -and running in parallel with the 68k on a separate bus)

I don't know much about the ASIC beyond what's been discussed on the boards, so maybe I'm missing something that's really obvious. (in which case, it would probably be silly to "trick" the ASIC like that)
Hmm, for that matter, if it can draw vector lines, that same function should at least be applicable for simple line filling as well.

The biggest thing the ASIC would accelerate over plain software rendered 3D is texture mapping. You can use the ASIC's scaling/rotation rendering (which is basically affine texture rendering) to fill lines of texture instead of solid colors at about the same speed you would get with solid filled polygons. (of course limited by the textures you can fit into RAM -and textures not fitting into word RAM would need to be updated by the CPU periodically)



Of course, had they wanted to, Sega could have put 3D-empahsized features in the Sega CD or other things. (lots of different possibilities depending on the R&D constraints, time, manufacturing cost -which would limit gate count in the ASICs used, and other factors -and I'm not sure of the size of the gate array sega was using in the MCD)
After all, look what Flare managed to do several years earlier (in 1988) on some 18k gate array cells. (ie the Slipstream ASIC with a built-in video controller with 3 pixel resolutions/color depths -high res 16 color mid-res res 256 color and mid res 16 color- and programmable screen size in each of those modes with some provisions for genlock, a somewhat primitive but fast and flexible blitter at 12 MHz, I/O ports intended to joystick/controller inputs, a host processor interface for a Z80 or x86 type CPU, memory interface for 256 kB of 16-bit "fast RAM" -intended to be SRAM or PSRAM- and 2 more regions of 256k intended to be mapped to a cartridge/expansion bus for 8-bit "slow" RAM and/or ROM, and a custom RISC architecture 12 MHz "DSP" intended for audio and 3D math processing -with 14-bit stereo DACs to output sound -of course, the DSP could also be used to assist in calculations for scaling and rotation effects, and the blitter would obviously assist as well)

Actually, Flare didn't license that exclusively, so Sega (or anyone else) could have paid to license it as well. (probably pretty favorably too) But that's another topic. (and it might not have been directly feasible to use in conjunction with the MD/MCD either -if it WAS used, it definitely would need to be cart slot mounted to facilitate genlock and use an RGB mixing cable -like the 32x . . . and Sega may have opted to cut out any licensing overhead and design their own custom chipset in-house if they felt that would be more cost effective)

[Chilly Willy]

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.

[TmEE]

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

[Sik]

Yeah, though even without the ASIC at least you've got 4-bit packed pixel tiles, so you could work on byte boundaries (write 2 pixels at a time) and be fairly OK with software rendering (ie easier than the Atari ST or EGA PC -Amiga has the blitter to overcome the planar pixel problems).

Why not just use the bitmap mode, where every single pixel is its own byte and pixels are stored linearly? =P

The ASIC also has the facility to convert 8-bit chunky bitmap graphics to 4-bit packed tilemaps iirc (which would make CPU rendering on a pixel basis a lot easier), though you could also directly render with the ASIC.

...OK, you did think on that >_>

Fonzie mentioned that the ASIC is also capable of line drawing (vector lines for wireframe stuff), but that's not so great for polygons by itself.

It's probably worse at lines than at polygons... To be fair the algorithm used in the ASIC sucks at anything other than 2D transformations of bitmaps (not surprising, since that's what it was designed for). 3D landscape effects are achieved by abusing this.

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

Hmm, for that matter, if it can draw vector lines, that same function should at least be applicable for simple line filling as well.

Use a flat texture?

Of course, had they wanted to, Sega could have put 3D-empahsized features in the Sega CD or other things.

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)

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.

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

Go and try the 3D globe widget for Opera. Technically it's just a ZIP with HTML and javascript code inside, so it should run on any browser if you unpack it (EDIT: well, any browser that supports 2D canvas). Look at the way it stores textures and you'll see how it'd be possible to do textured triangles with the ASIC.

[Jasper061992]

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

Oh yeah, I completely forgotten that the Neo Geo uses two different ROM chips for graphics and the other for code which only the respective chips in the console has access to. I did read it somewhere but forgotten. I know the NES also has that setup with their carts aswell. But how comes I seen some software rendered 3D NES tech demos on Youtube then? Unless the emulated NES ROM uses those atributes that is required to get any software rendered 3D working on the Neo Geo (RAM chips in place of GFX ROM chips I guess). But it wouldn't take any physical modifications to the MVS/AES console themselves to map RAM chips within the cartridge to facilitate the idea would it? Or would it just take a completely custom cartridge?

Either way, sounds expensive and cumbersome, but something NG: DEV TEAM would probably pull off just to prove that it could be done. Hell, look what they released, Fast Striker that is nearly a 200MB cart altogether, with those prerendered 3D videos for the background!

[Sik]

Some NES games have CHR-RAM instead of CHR-ROM, meaning the CPU is indeed writing to that area. Same logic would have to be done for the Neo Geo.

EDIT: and yes, you just need a custom mapper in the cartridge =P

[TmEE]

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

[Jasper061992]

Some NES games have CHR-RAM instead of CHR-ROM, meaning the CPU is indeed writing to that area. Same logic would have to be done for the Neo Geo.

EDIT: and yes, you just need a custom mapper in the cartridge =P

It's awesome that its 'possible', but I'm thinking, is it 'practical' in terms of costs? It'd be awesome to get Homebrew Starfox like 3D shooters or say a Hard Drivin' derivative game on the Neo Geo working. But the question remains, would any indy developer think its worth the cost to try produce a nonstandard Neo Geo cart to produce said 3D games for an almost nonexistant market? Cost is the biggest obstacle. Perhaps it could be a cheap 128Mbit (16MB) Neo Geo cart (with the necessary RAM) seen as pure flat shaded polygon graphics take up minimal data compared to textured polygons and/or detailed spritework.

I'd love to see a tech demo, even if it was just emulated.

[Sik]

If you can find a way to let RAM be accessed by both the video hardware and 68000 at the same time without any interference, there isn't much else to be done, really. Just standard ROM and RAM. You don't even need a mapper really, since you wouldn't be doing bank switching - just wire everything directly.

[Jasper061992]

If you can find a way to let RAM be accessed by both the video hardware and 68000 at the same time without any interference, there isn't much else to be done, really. Just standard ROM and RAM. You don't even need a mapper really, since you wouldn't be doing bank switching - just wire everything directly.

So this RAM would be in place of the GFX ROM within the cart, or an addition to the GFX and instruction ROM? Also, what kind of RAM chip would it function best with?

[Sik]

Basically you'd map the RAM both to part of the 68000 address and as the GFX-"ROM" (technically GFX-RAM now =P). Also no idea what kind of RAM would be needed, but I assume SRAM would be the safest bet. It all boils down to response times, I suppose.

[TmEE]

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