Could an Amiga with an 030 do Virtua Fighter?

[VladR]

Originally Posted by roondar

Ah, one thing to note on Blitter clears that may not have been perfectly clear: due to the idle cycles the Blitter clear has, it can only reach 50% of it's normal bandwidth. This means that it can only clear at about 3.5MB/sec. Which is not fast enough to clear all of the screen @320x256x8.

OK, I gotta translate those numbers into our target resolution, as they don't really say much in themselves to me.


3.5 MB/s at 60 fps is 59.7 KB per frame.
320x256 is 80 KB.


OK, now I see it

So, the Blitter Clear would completely take first frame and about 25% of second one. But at ~1.4 we would need to already have our framebuffer filled. Ouch


So, we would need some sort of spatial sorting mechanism which would, by design, break down screen into several areas, such that we could simply, without sorting, process it, even though Blitter isn't done yet.


That could be done with games like Prince Of Persia, where you have very distinct 3 areas, by design. But not in VirtuaFighter, as far as I can tell...

[roondar]

If you're intending to run NTSC (60 fps) then the screen does become a bit smaller (max NTSC overscan on the Amiga is 320x241) so it's slightly better. Or you could opt for a PAL based game but keep the 320x240 resolution of the 32X version. Gives you more time per frame.

About the Blitter clear: you could go for a triple buffered display and clear the 3rd buffer while drawing the second and showing the first. No need to worry about complicated draw order in that case

Anyway, the above (and most of my posts) are just flights of fancy really - I just like theorizing about Amiga game stuff and am fascinated by 3D games because I understand polygon rasterizers etc a good deal less than I understand 2D stuff.

[VladR]

Triple buffering brings more problems than it solves, unfortunately. On a paper it seems like a great idea that you can gain half frame CPU time, but the input sensitivity becomes a real issue, especially in driving games.

Then you would need to run the input logic (+physics+collision detection) at least twice per game frame (regardless if it's 2 or 3 frames), otherwise the input sucks quite bad.

Bringing this problem back to our game - Virtua Fighter, I believe it was Karateka that had a ridiculously high input lag. I somehow could play it 30 yrs ago, but it's absolutely impossible for me now to suffer such an insane input lag.

I don't know if VF has some complex combos, where you have to press certain keys in certain order in short time, but this problem alone could make it unplayable as the code might simply not register a keypress as it key.up and key.down events happened when game wasn't looking (but perhaps some of the Amiga's OS input libs can take care of that by keeping a buffer of pressed keys).

[robinsonb5]

Originally Posted by VladR

I don't know if VF has some complex combos, where you have to press certain keys in certain order in short time, but this problem alone could make it unplayable as the code might simply not register a keypress as it key.up and key.down events happened when game wasn't looking (but perhaps some of the Amiga's OS input libs can take care of that by keeping a buffer of pressed keys).

The best way to deal with that would be to do input handling - including combo-detection - within a VBlank interrupt. The game loop would see combos as extra "buttons".

[VladR]

Yeah, VBI sounds like best solution.

[coder76]

Flatshading in the Amiga native screenmodes does not require a c2p. Instead you should draw directly to framebuffer with the CPU.

This means you need to deal with start part of line first and then draw 32 pixels at a time with a move.l, if the fill line is longer (or in some cases 16 pixels with move.w). And then end part similarily. Also, all planes need not be filled, if you don't need all the colors. With 8-bit chunky pixels you have to always use a byte for each pixel, but in planar mode any amount of bits per pixel can be used.

For example 2 color bits per pixel gives 10/16 colors in 4 bitplanes, and 2 bits in 5 bitplanes gives 16 out of 32 colors. This is 4 times less data than with 8-bit chunky pixels. Moreover, you can optimize the plane colors so that the most used colors get an assignment that needs least bits, as there are a few color combinations that only needs one plane to be filled (0001, 0010, 0100, 1000).

If you move to other combinations like 3 color bits/5bitplanes you get almost all colors out of 32, but the workload is just 3/5, and you have 5 different colors that needs only one plane filled and a lot of colors that need only 2 planes filled.

So a polygon filler in planar mode is something very different from 8-bit chunky mode, and should be used on Amiga with flatshading, because of the obvious advantages. Even if it gives much less colors, you don't need all those with flatshading.

[VladR]

I admit, my only experience with planar modes was a gfx library I wrote in asm on PC during the 386DX 40 MHz era for a resolution 360x480, which was planar (4 planes).

But yes - 16 colors could look fine for flatshading.

Is there any demo that would run well only on 060, but push for this flatshaded look ? That would be interesting to see what 060 could extract out of this set-up (not having to spend ~60% of frame time on C2P).

[d4rk3lf]

Hey VladR how's going with the game?

Really glad to see this thread goes both ways: Helping you figure out best approach for your game, and, at the same time, answering the thread question.

My (unprofessional) thoughts:
Give Team 17, in the nineties the same task, and they would do it for A1200 and some additional fast ram.
Of course, ponytail of the girl won't be 3D model, and some other (minor) stuff could be cut. Res way down. Colors way down. But I think they would manage it.
I think, best approach to this would be: "Can A1200 manage stick figures at the framerate of VF of arcade quality". That should be a good start.
Then we add character with 50 polygons... then more...
As I said, I have no clue about the code, but somehow, I feel that you're starting counting numbers, from the end, and not from the beginning.

Question to all:
Is it possible making VF game type on A1200 with stick figures? So, very thin rectangles (for the limbs), boxes for the joints, everything rigged and all?

[VladR]

Originally Posted by d4rk3lf

Hey VladR how's going with the game?

Really glad to see this thread goes both ways: Helping you figure out best approach for your game, and, at the same time, answering the thread question.

My (unprofessional) thoughts:
Give Team 17, in the nineties the same task, and they would do it for A1200 and some additional fast ram.
Of course, ponytail of the girl won't be 3D model, and some other (minor) stuff could be cut. Res way down. Colors way down. But I think they would manage it.
I think, best approach to this would be: "Can A1200 manage stick figures at the framerate of VF of arcade quality". That should be a good start.
Then we add character with 50 polygons... then more...
As I said, I have no clue about the code, but somehow, I feel that you're starting counting numbers, from the end, and not from the beginning.

Question to all:
Is it possible making VF game type on A1200 with stick figures? So, very thin rectangles (for the limbs), boxes for the joints, everything rigged and all?

I burnt about a month on 640x480 and benchmarking, but it really is worth it, visually. I don't think the perceived sharpness difference from 640x480 to 1920x1080 is as big as 320x240 to 640x480. So, it was worth it from where I'm standing.


As for stick figures - just how detailed stick figures are we talking here ? 5 quads (3 + 2 joints) per each leg/hand ?

[robinsonb5]

Originally Posted by VladR

Is there any demo that would run well only on 060, but push for this flatshaded look ? That would be interesting to see what 060 could extract out of this set-up (not having to spend ~60% of frame time on C2P).

I get the feeling that by the time the '060 came along everyone was obsessed with doing texture-mapping and chunky-based effects - so I don't think there are many, if any, that really explore the limits of flatshading.

Originally Posted by d4rk3lf

Question to all:
Is it possible making VF game type on A1200 with stick figures? So, very thin rectangles (for the limbs), boxes for the joints, everything rigged and all?

Based on nothing more than gut feeling, I'd say graphically yes, definitely. Rigging-wise I suspect it'd have to be interpolated keyframes rather than proper inverse kinematics - especially if you're talking about a stock A1200 rather than one with Fast RAM.


Also, a well-made stick-man-fighters game could be awesome in its own right!

[Retro1234]

maybe totally stupid but couldn't the 3D object be made in memory as one object and then displayed as a sprite.

[DanScott]

Originally Posted by VladR

Triple buffering brings more problems than it solves, unfortunately. On a paper it seems like a great idea that you can gain half frame CPU time, but the input sensitivity becomes a real issue, especially in driving games.

No.. wrong, because draw to display is the same latency... you just clear the 3rd buffer before it comes back round to be rendered to again

[DanScott]

Originally Posted by robinsonb5

I get the feeling that by the time the '060 came along everyone was obsessed with doing texture-mapping and chunky-based effects - so I don't think there are many, if any, that really explore the limits of flatshading.

[ Show youtube player ]

[jizmo]

Looking back into games and demos of the past, the minimalistic flat shaded 3D looks more like a stylish choice of design, and thus seems to have fared better the test of time compared to the early low-resolution texture mapped 3D where the technical limitations of the era are very apparent.

[d4rk3lf]

Originally Posted by VladR

As for stick figures - just how detailed stick figures are we talking here ? 5 quads (3 + 2 joints) per each leg/hand ?

Between 14 (no joint boxes) to 22 (all joint boxes).
So,
22 boxes x 6 = 132 polygons (264 triangles)
Or,
14 x 6 = 84 polygons (168 triangles)

Attached image is (rough) sketch of the 22 boxes.

Edit:
And another image of rough sketch in pose, with 14 boxes.

[hooverphonique]

Originally Posted by VladR

Could we, in theory, interleave our C2P code with some other code that would, basically in parallel with C2P, compute something else (say, 3D transform) ?

IIRC, a lot of demoscene productions use this kind of interleaving for performance - basically you do stuff while waiting for a write to chipmem to complete.

[Juz400]

Originally Posted by jizmo

Looking back into games and demos of the past, the minimalistic flat shaded 3D looks more like a stylish choice of design, and thus seems to have fared better the test of time compared to the early low-resolution texture mapped 3D where the technical limitations of the era are very apparent.

Indeed!
Now these flat shaded examples are pre rendered and come off Laserdisc
(May well have been rendered on a 68000 based Silicon Graphics machine)
They could do with a little more light sourcing in places but I think they still look stylish for 36 years old!
[ Show youtube player ]


[ Show youtube player ]

[ruinashiro]

Originally Posted by ruinashiro

Honestly, what's a good example?

Without going to a graphics card, the only reasonably fast 3D I saw on amiga was when using my PPC board to play Quake or the few PPC-only demos. And I wouldn't doubt there are many more polygons in Virtua Fighter than on the average Quake screen.

So, can anyone present a good example of fast 3D throughput on an AGA (non-gfx card) Amiga using an 060? I don't mean to sound combative at all, I just think the Amiga's strengths were always in what magnificent (if limited) things it could pull off in 2D.

Also, I like the flatshaded approach but most examples are 4-bit color and very limited polys compared to the likes of Virtua Fighter. Maybe a B&W version of the game to limit the palette?

[d4rk3lf]

Originally Posted by ruinashiro

So, can anyone present a good example of fast 3D throughput on an AGA (non-gfx card) Amiga using an 060?

Well, if you look at the "No Second Prize" game, it is very smooth even on 68000 - 7Mhz.
Zeewolf 1 and 2 is another example.

[roondar]

Many of the old untextured 3D games run very nicely on an 060 indeed. Though some suffer from the CPU being too fast