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

[kool kitty89]

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.

I forgot to mention before that, whole Siplheed is not, Stellar Fire is full polygonal 3D on the CD, though not texture mapped.

You're going by the assumption the ASIC is just 4-bit. In fact, we say ASIC to refer to the renderer, but if I recall correctly the ASIC actually contained all the custom hardware in the Mega CD (much like its ASIC counterpart in the Mega Drive side), so it's already pretty complex for starters. It's still less complex than the ASICs in the MD though, meaning it should have had enough die space for 12 more bits...

Because of your own flawed assumption. If the ASIC only manipulates 4 bits at once, but memory needs 16-bit, it needs to buffer 16-bit of data from memory, modify the 4-bit that are affected, then write them back. This also means the ASIC already has a 16-bit buffer to hold the data... by which point you may as well just modify all 16-bit at once. See my logic?

No, I'm going by the assumption that it only has logic to work on 1 pixel at a time, like the scaling/rotation feature of the Jaguar's blitter (which can work on up to 32-bit words, but always works on single pixels per read/write -so that 32-bits is only for 32bpp- though the blitter does block copy, fill, and other things at up to 64-bits at a time, the affine renderer can only work on single pixels -which is also why one of the fast texture mapping routes is to render textured primitives into the GPU scratcpad and then 64-bit block copy the result to the framebuffer -also making use of fast page mode accesses all the while and 37 ns reads/writes in the scratchpad)

If added buffering logic was added for a multi-pixel write buffer, the jaguar (or CD blitter) would be much faster, likewise, if the CD blitter was at least more like the jag and able to do 8 or 16-bit pixels, it would have been much more useful with the 32x too (or dithered 16 color MD stuff too). Making it more like a general purpose blitter (block copy, fill, etc) would have made it far more flexible in general.

But adding such a phrase buffer would mean more silicon, and possibly something that just couldn't fit into the PGAs being used. (or not in the time span they wanted)
Lots of potential reasons for leaving that out . . . for the jaguar it was obviously cost/complexity for a feature felt to be relatively low priority in 1990/91. (when the Jaguar's core logic documentation was set down and initial chip design began)



And again, I don't think the 3DO or Saturn VDP1 featured phrase buffers either. (3DO would mean buffering 2 16-bit pixels for a 32-bit write to the framebuffer or 2 8-bit pixels for the Saturn)

[saturndual32]

Ok, now, how good would the Neo Geo be at Wolfenstein 3d type of engines, (i wont mention Doom, since that might be too much or the NG).

[Sik]

At Kool Kitty: the renderer in the MCD ASIC probably works completely different from the Jaguar blitter, so to be fair I really doubt any parallelizations are going to be correct. Also, the Saturn VDP1 behaves more like triangle rasterizers in 3D hardware than 2D blitters, so stop bringing it into the discussion - not to mention it had direct access to its own memory so it could do whatever it wanted with it probably.

Oh, also I checked, and nowhere in the docs it says the ASIC has to deal with any kind of page boundaries. The nearest I found was the ability to set the table addresses (which have to be aligned to some boundary, but that's probably more of an optimization than a paging issue, just like the tables on the VDP).

Ok, now, how good would the Neo Geo be at Wolfenstein 3d type of engines, (i wont mention Doom, since that might be too much or the NG).

It may work! ...though I believe the sprite limits will kill it. To render the walls you'll need 320 single-pixel-width sprites next to each other. I believe that hits the sprites-per-line limit. You could get away with it by making the strips thicker - e.g. two or three pixels width. Uglier, but it may work.

Something else that may work is this (the entire map is made out of objects), assuming the floor can stay as a flat color so you don't need to show how it rotates.

[evilevoix]

http://www.youtube.com/watch?v=d50YE00hO98


Couldn't you cheat a little? Look at the game above, how about a rendered car and then a lot of frames of animation for the track?

[Kamahl]

http://www.youtube.com/watch?v=d50YE00hO98


Couldn't you cheat a little? Look at the game above, how about a rendered car and then a lot of frames of animation for the track?

Congratulations, you've just made an FMV game lool. Not a 3D game.

[saturndual32]

I have always wondered about how well the Neo Geo would have handled stuff like Wolfenstein 3d, Out Run, maybe something similar to Star Fox.
Maybe if SNK had pushed for something like the "Home Lineup", you know, games exclusive for the home marked that used small cartridges to keep costs competitive with the home consoles, obviously this in tandem with their arcade stuff. That way we may have seen more genres covered on the NG. They may even have gotten third party support...haha, i have always dreamed of seeing Street Fighter 2 and Mortal Kombat on the Neo Geo, heheh.

[Chilly Willy]

Rather than doing the walls as strips as traditional, the NeoGeo would have been better with the 64x64 wall textures done at different sizes and angles, then displayed as a single sprite. That should reduce the number of sprites onscreen to a manageable level. You'd just use a lot of display rom for all those rotated and scaled textures and items.

[kool kitty89]

At Kool Kitty: the renderer in the MCD ASIC probably works completely different from the Jaguar blitter, so to be fair I really doubt any parallelizations are going to be correct.

The functionality is very similar though (for the texture mapping feature, not the general purpose blitting features in the Jag), both drawing scaled/rotated rectangles, and that's it.

And from what I've gleaned on the MCD's ASIC it does seem to go a pixel at a time (though Fonzie would probably be the one to ask . . . Chilly Willy seems pretty sure, but Fonzie is one of the most experienced MCD homebrew devs).

Also, the Saturn VDP1 behaves more like triangle rasterizers in 3D hardware than 2D blitters, so stop bringing it into the discussion - not to mention it had direct access to its own memory so it could do whatever it wanted with it probably.

Chilly Willy already described it as a direct evolution of the CD's ASIC (at least in concept) with the 2D drawing modes being very similar . . . just with the warped mode also added. (he also pointed out that your suggested method WOULD be a nice option for triangle renderers on the Saturn over line by line rasterizers or folded quads).

Oh, also I checked, and nowhere in the docs it says the ASIC has to deal with any kind of page boundaries. The nearest I found was the ability to set the table addresses (which have to be aligned to some boundary, but that's probably more of an optimization than a paging issue, just like the tables on the VDP).

If it doesn't have special features to deal with page boundaries, that meas it must have no fewer than 3 80 ns cycles per read/write.

It may work! ...though I believe the sprite limits will kill it. To render the walls you'll need 320 single-pixel-width sprites next to each other. I believe that hits the sprites-per-line limit. You could get away with it by making the strips thicker - e.g. two or three pixels width. Uglier, but it may work.

Or you could go the software rendered route for the BG with hardware sprites and scaling. (or separate walls, ceilings, and floors to different sprite sections for better color use) Since you're software blitting, you'd obviously deal with pairs of 4-bit pixels at a time for best speed (and probably 1/2 res with paired pixel dithering for all BG stuff -scaled 2D objects could be full-res).
Well, for a Wolf3D type game, there's little need for floor/ceiling optimization, but Doom would need it.

Of course, that means having the necessary bridge/buffer RAM to work with on-cart.

If you DID use sprites for the BG (as lines for textured floors/ceiling a la Doom and columns for walls), aside from what Chilly Willy mentioned (using LOTS of ROM), you might get by with 1/2 res stuff (2 pixel wide sprites) and limited screen window size. Still, that would mean a max of 96 double wide columns (due to Neo sprite limits) and thus 192 pixels max (leaving no bandwidth left for 2D scaled objects).
Doing columns as 3 or 4 pixel wide sprites might be workable at a reasonable screen size, but a bit coarse for horizontal movement.

Doing a paired pixel dithered (1/2 effective horizontal res, pseudo 8bpp packed) 16 color background with hardware sprites for scaled 2D objects would probably be the best compromise.


Hmm, on the Neo Geo, are scaled sprites still limited to the same size, or proportionally the same size? (ie would a 2x scaled 16x16 sprite take up 32x32 screen pixels? -important since the Neo is 16 pixels wide max)
Given the size of the PC original sprites (assuming you didn't use the high-res 3DO/Mac/Jag ones -which also ruined the stealth/strategy elements by making enemies always face you), you'd need at least 2 sprites horizontally for proper resolution (all enemies -aside from Dogs facing forward- are more than 16 pixels wide, though some objects are within 16 pixels) which makes the software rendered BG route even more necessary. (a single BG could be done for 288 pixels wide -which fills Neo Geo to overscan on average TVs- with 18 sprites, leaving 78 more for scaled 2D objects)





Wait, another important issue:
Does the Neo Geo used packed pixel graphics or planar? (if it's planar, that would be a massive disadvantage over the MD or for software rendering in general -SNES's Mode 7 is a great workaround that also gives zooming for large windows of low res graphics and full 256 color 8bpp graphics, though still requring cell/tile organization and limited to 16k pixels max)

Rather than doing the walls as strips as traditional, the NeoGeo would have been better with the 64x64 wall textures done at different sizes and angles, then displayed as a single sprite. That should reduce the number of sprites onscreen to a manageable level. You'd just use a lot of display rom for all those rotated and scaled textures and items.

Even if you did do that, it wouldn't be a single sprite, as Neo sprites are 16 pixels wide max (but can be taller than the visible screen).

And you'd obviously need lots of ROM for that solution . . . well, since you'd be limited to 16 pixels anyway, you might as well optimized totally around that and save some space with the flexibility. (less than 16 pixels would use even less ROM due to added flexibility of given textures, but then the sprite bandwidth gets to be more of a problem again -and you need to consider BG and objects)

[Kamahl]

The Neo Geo doesn't scale sprites, it only shrinks them afaik.

[Sik]

The letters in the credits screen of Metal Slug 2 are individual sprites (checked with an emulator), and they're 32x32... So either strips can be wider than 16 pixels or they're being scaled up.

[TmEE]

NeoGeo can link up sprites horizontally, so the 32x32 is actually 2x 16x32 sprites. Linked sprites behave like one sprite.

[evilevoix]

Ok, now, how good would the Neo Geo be at Wolfenstein 3d type of engines, (i wont mention Doom, since that might be too much or the NG).

Check out The Super Spy, one of the systems first titles and their is an extremely limited hallway walkup frame that is just terrible IMHO. Otherwise you scroll left or right.

Congratulations, you've just made an FMV game lool. Not a 3D game.

Hence the qualifier "Cheating". Render the car animation for all frames and then run the bacground like say Crusing USA and so on.


Why couldn’t the system have included a Super FX Type chip like Virtua Racing or SNES Version of DOOM in its large cart? That seems to be the best solution.

[Sik]

Because the issue is that the graphics are actually read from ROM, and the video hardware expects permanent exclusive access to it =/

[evilevoix]

Because the issue is that the graphics are actually read from ROM, and the video hardware expects permanent exclusive access to it =/

No work around or complete system defeat with the cart?

[Guntz]

Dude! Were you high when you made this comment? Every time I read it I nearly fall out of my chair laughing. What's even worse is you actually came straight from NG.com. Comedy gold!

Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.