Could an Amiga with an 030 do Virtua Fighter?

[Tsak]

Just note that C2P can also be done with the Blitter, as KK/Altair demonstrated with his recent a500 Doom engine. With quite an impressive performance output as well.

[roondar]

Originally Posted by Gilbert

If only that could be done in hardware somehow

There used to be an option for that in the form of the Graffiti card that plugged into the video output of the Amiga, but being a 3rd party and external device it sadly saw rather low use. Apparently, Commodore was offered a license to include Graffiti as an on-board chip around the time AGA was being designed, but they didn't want to pay the license fee/production costs so it didn't happen.

I've defended the A1200/AGA in the past (mostly because the A1200 is by far my favourite Amiga ), but it's hard to deny that not including any form of chunky mode in AGA was a really foolish move by Commodore.

Originally Posted by Tsak

Just note that C2P can also be done with the Blitter, as KK/Altair demonstrated with his recent a500 Doom engine. With quite an impressive performance output as well.

Indeed, KK/Altair's A500 c2p performance in Dread is great. However, the Blitter by itself isn't going to be fast enough (030/fastram will be faster). Not all is lost though, there is a highly optimised Blitter+CPU c2p for 020's/030's that apparently is rather fast.

Don't know how fast, but it's one of the reasons that DoomAttack runs better than say ADoom on my A1200/030.

[DanScott]

Not sure if c2p is any benefit for just flat shaded polygons? The 030 should be able to render these pretty quickly to bitplanes? or am I missing something here....

[coder76]

Like DanScott said, what do you do with a c2p, if the plan was to make a flatshaded polygon game? Even on a 68000 system, the CPU is not much slower than the blitter in drawing filled polygons on screen, when we are not talking about special cases (like just one large polygon on screen, no background gfx, where blitter will win easily, just look at some demos).

There is no advantage in filling scanlines with chunky pixels in fast ram and then transfer that into chip ram with a slow c2p, when you can fill directly into chip ram with CPU, and even hide the latency of slow chip ram writes with some code coming after chip ram writes. Of course, doing the scanline fill with CPU in planar mode requires some special code that is highly optimized, but it has been done before even on 68000 systems.

[chb]

Originally Posted by DanScott

Not sure if c2p is any benefit for just flat shaded polygons? The 030 should be able to render these pretty quickly to bitplanes? or am I missing something here....

I could see a benefit for a scene with lots of smaller polygons, those are quite inconvenient in planar modes - e.g. a 10 pix wide polygon needs 16-32 memory accesses per horizontal span in 8 bit planar mode, compared to 3 to 5(?) in chunky mode. But probably you would be limited by the 3D transformation throughput way before you reach such a level of detail.

[roondar]

I wonder if there's a way to use the Blitter such that faster CPU's benefit more (for instance, clear the screen using the Blitter while your CPU is busy in fast memory doing calculations to prep the drawing). It seems to me you might be able to increase concurrency that way.

Similarly, perhaps (though I'm not too clear on this) it may be faster to draw say 1BPL polygons in buffers in fast ram and transferring these over. Though that would require some creative way to prevent copying a full rectangle when only part is filled.

Then again, I have little experience with 3D on the Amiga. Just considering how you might reach better CPU usage.

[khph_re]

Dan and the other ^demogroup people are probably best placed to answer this.


DAN: You could always use 'celebrandil mode'

[coder76]

Originally Posted by chb

I could see a benefit for a scene with lots of smaller polygons, those are quite inconvenient in planar modes - e.g. a 10 pix wide polygon needs 16-32 memory accesses per horizontal span in 8 bit planar mode, compared to 3 to 5(?) in chunky mode. But probably you would be limited by the 3D transformation throughput way before you reach such a level of detail.

Yes, small polygons are faster to render with chunky pixels, but there is also a problem of color wasting, you don't need a 8 bit palette, and on the Amiga the c2p is going to cost a lot to per frame. Plus the problem that you can't use the blitter for the clearing of previous frame with a c2p. With a planar renderer, you're also not going to see 8 planes being used, but rather half of that or less (even 2-3). With larger polygons, planar rendering should be faster than with chunky pixels, because of the more efficient color usage.

[saimon69]

Ok so just to be on the same page, are you telling me that a base 500 cannot do a game like Ballz? After all the vectorball stuff shown by demos? (i know that one thing is rotate something on screen and another is having interact in a 3D space but pleez!)

There is also the Ellipsoid route, used on this sorta-Alone in the dark on Dos in 1994 hence still on a viable calculation window

[ Show youtube player ]

[VladR]

Originally Posted by Daedalus

Yep, in theory that's what Akiko is for indeed, but it still takes time to C2P the data, because each chunk of 32 pixels needs to be transferred to Akiko by the CPU, then transferred back out into the appropriate planes in chip RAM. In other words, Akiko isn't free. But here we're talking about an '030, which is getting into the realm of being faster at doing the C2P itself rather than performing relatively slow writes across the bus to Akiko.

Sorry, I wasn't aware of the Akiko logistics. I was kinda hoping for it to receive two pointers (src,dst) and do the parallel write, even if it would halt CPU during the write.

If you have to hold Akiko's hand every 32 pixels then the Host CPU cost is quite ridiculously enormous and as Samurai Crow pointed out, 030 is faster (unsurprising, given the 32-px inner loop).

Originally Posted by Daedalus

Either way though, you're going to struggle to get anywhere near 50/60Hz doing this sort of thing.

Well, I obviously didn't expect any sort of VF-level 3D at 60 fps.
I was merely curious what kind of 3D scene is possible at 60 fps - mostly from Jaguar perspective - where I can initiate ClearScreen call on a Blitter, in parallel with GPU rasterizing last frame's polygons, in parallel with DSP doing 3D transform and clipping and writing to the double buffered polygon list, in parallel with 68000 handling input,AI and everything else.
This way you can actually get some useable 3D scene at 60 fps.
Of course, on Amiga, you only have one CPU and a Blitter and you must switch bitplanes, so you can't really get a fullscreen refresh 60 fps 3D on slower CPUs like 030.
Probably with 2-3 bitplanes, and just a partial screen redraw, it might work on 030 - say a driving game where half screen is a cockpit and only about 40% is 3D viewport.

I'm wondering if 040 is fast enough for that (060 is, for sure)...

[Gilbert]

Originally Posted by saimon69

Ok so just to be on the same page, are you telling me that a base 500 cannot do a game like Ballz? After all the vectorball stuff shown by demos? (i know that one thing is rotate something on screen and another is having interact in a 3D space but pleez!)

There is also the Ellipsoid route, used on this sorta-Alone in the dark on Dos in 1994 hence still on a viable calculation window

[ Show youtube player ]

I think it can - it doesn't have to run at 50fps.

Ballz is ok but better to try to emulate Super FX Fighter on the SNES. That's a step towards Virtua Fighter at least.

[VladR]

Originally Posted by DanScott

Not sure if c2p is any benefit for just flat shaded polygons? The 030 should be able to render these pretty quickly to bitplanes? or am I missing something here....

The only thing you are missing is my laziness.

I have a flatshader codebase running on 5 different HW platforms across multiple different resolutions, but sadly none of them has bitplanes, like Amiga.
Technically, I have a flatshader running on Amiga / Vampire (dev against 040 WinUAE config) it's just framebuffer-based and relies on CyberGraphX methods to display my framebuffer. I suppose, I could just implement a C2P instead and not have to rely on CGX.

I would have to first implement it and then extensively benchmark to see where exactly is the threshold of the scene complexity between C2P and bitplane switch.

[IanS]

Forget VF... who needs it when we have IK+ ? If you can't drop your trousers, then it's not a proper fighting game! ??

[saimon69]

Getting for one moment back in the subject of Motion Capture, this demo came out last Revision and uses it properly on OCS/ECS

[ Show youtube player ]

[saimon69]

Originally Posted by IanS

Forget VF... who needs it when we have IK+ ? If you can't drop your trousers, then it's not a proper fighting game! ??

An IK+ in 3D with 3D trousers seems interesting