Could an Amiga with an 030 do Virtua Fighter?

[roondar]

Originally Posted by AmigaHope

Well, yeah, the power of the hardware doesn't mean a port isn't DOABLE, but, well...

Yeah, except that is not at all what I meant.

[Phantasm]

I'm sure tiertex would have put something out which claimed to be virtua fighter if they had the chance.

[jotd]

closest we have is 4D sports boxing.

[DamageX]

The Sega 32X also has a port of Virtua Fighter, this would be a closer comparison to an '030 system without 3D hardware.

I have both the 32X and an A2000 with 50MHz '030 and I have run code on both. I'd say the 50MHz '030 is in the same ball park as ONE 23MHz SH-2 (and you should be aware that the 32X has slow ROM access timing and only a 16-bit memory bus). Although the comparison falls apart if your code is doing a ton of multiplication or division. Multiply is around 28 cycles on an '030, but only 3 cycles on SH-2. Peak video memory write bandwidth on the 32X is around 9MB/sec, which is only slightly better than AGA and not as good as a Zorro 3 card.

The 32X Virtua Fighter uses the MD video to display the background scenary which reduces the amount of stuff that has to be rendered on the 32X side. Maybe something like that could be done using AGA dual playfield mode but it would have limited colors. Otherwise a Zorro 3 chunky screen might fast enough for full software rendering. I am reminded of the old PC game Roller Coaster Rumbler which had a few untextured polygons flying around at decent speed on a 16MHz 286...

[gimbal]

Originally Posted by AmigaHope

Actually every single Playstation game and almost all Saturn games used fixed-point 32-bit math. The Playstation had zero floating point capability in any of its hardware, and while the Saturn DSP could do floating point the rasterizer was still integer.

Heck, the same for Quake 2 and any game built on it's engine.

[d4rk3lf]

Now, here is a rose tinted glasses view:

I've looked several times at this thread, and several times at virtua fighter (both arcade and sega version), and I see absolutely nothing in it, that plain A1200 can't do.

Let me elaborate:
Few days a go I googled about it, and someone mentioned (in the forums) that arcade version had few (2-3) thousands polygons, and sega version had approximately 550 polygons per character. I looked again at the game, and my though was that 550 polygons are too much for this type of details.
Today, I found masterpieces with 200 polygons models.

So, this crap looking 3D game can't work on 030? and No Second Prize can work on plain A500 (same as Z-wolf, and Frontier).

Ofcourse, rigging (and linking) takes it's toes... so.. is the rigging most prominent problem for the Amiga? Rather then polygon count?

[eXeler0]

Originally Posted by d4rk3lf

Now, here is a rose tinted glasses view:

I've looked several times at this thread, and several times at virtua fighter (both arcade and sega version), and I see absolutely nothing in it, that plain A1200 can't do.

Let me elaborate:
Few days a go I googled about it, and someone mentioned (in the forums) that arcade version had few (2-3) thousands polygons, and sega version had approximately 550 polygons per character. I looked again at the game, and my though was that 550 polygons are too much for this type of details.
Today, I found masterpieces with 200 polygons models.

So, this crap looking 3D game can't work on 030? and No Second Prize can work on plain A500 (same as Z-wolf, and Frontier).

Ofcourse, rigging (and linking) takes it's toes... so.. is the rigging most prominent problem for the Amiga? Rather then polygon count?

The Model 1 arcade kicks the shit out of an A1200 that is a fact that rose tinded glasses can't do much about.
However, it's usually possible to cheat your way to a *decent enough* result.

Rigging a character with a few nodes shouldn't be much of a problem, I think a much bigger challenge would be vertex/meshdeformed characters. In The first Quake games they didn't have mesh deformation so we can ignore that bit. I think original Quake characters are in the 100 polys ballpark, but with textures you can get away with that. Flat shaded polys without textures require a bit more if you want some more detail.. Like details in a face.. In Quake it can be a box with a texture of a face, but a flat shade box is not much to look at. Virtua Fighter characters have a lot of details for this reason. I estimate you'd need about 200 polys for a decent enough character. so 2x 200 polys + say 50 polys for some ground, then you have bitmap backgrounds should be enough on Amiga.
I'm not a coder so someone else can tell you the limits of an AGA Amiga.. (Computing the geometry fast enough is one thing, drawing it /fill rate is another).. so there are several limitations..

[AmigaHope]

Originally Posted by DamageX

I have both the 32X and an A2000 with 50MHz '030 and I have run code on both. I'd say the 50MHz '030 is in the same ball park as ONE 23MHz SH-2 (and you should be aware that the 32X has slow ROM access timing and only a 16-bit memory bus). Although the comparison falls apart if your code is doing a ton of multiplication or division. Multiply is around 28 cycles on an '030, but only 3 cycles on SH-2.

Vertex calculation *is* tons of multiplication, unless you're using just lookup tables. You can store all "frames of animation" of a 3D fighter in tables and perform one set of vertex calculations for the model and then calculate all the other vertices using offsets, but that would take a ton of memory for fluid motion as opposed to calculating movement between a smaller number of keyframes. In fact, this is how old-school 3D polygon games worked on the Amiga etc, which is why 3D entities move so choppily even on fast CPUs.

Virtua Fighter was part of a new breed of 3D games where motion was fluid by recalculating the vertices of moving objects independently. You need fast multiplication to do that.

[roondar]

Well, the 68030 is quite fast at doing lookups in fast memory. There are also table based ways to accelerate general multiplication. And most Amiga's with 68030 have much more memory than a 32x does. These factors might alleviate the need for heavy use of the multiplication instructions.

To be clear, this does not mean that therefore I think it's doable. Just that I don't think the multiplying speed will be the decisive factor.

[DamageX]

Originally Posted by AmigaHope

Vertex calculation *is* tons of multiplication, unless you're using just lookup tables. You can store all "frames of animation" of a 3D fighter in tables and perform one set of vertex calculations for the model and then calculate all the other vertices using offsets, but that would take a ton of memory for fluid motion as opposed to calculating movement between a smaller number of keyframes. In fact, this is how old-school 3D polygon games worked on the Amiga etc, which is why 3D entities move so choppily even on fast CPUs.

Virtua Fighter was part of a new breed of 3D games where motion was fluid by recalculating the vertices of moving objects independently. You need fast multiplication to do that.

Right, but the time for transformations is directly related to the number of verteces. When using simplistic models with low polygon count then the number of multiplies is minimized and it could end up being less than the time for rasterization in the end.

[eXeler0]

Noticed a "funny" (not really) thing when I compared Saturn and 32x version of Virtua Fighter (Yea, these self isolation times does that to you ;-)
Now, the Saturn version was released first, which is of course ironic in some ways, but whatever..

If you watch the 32x version, the polygon density of the characters is of course pretty low, and I guess that (or less) is what an Amiga with a 030 could "hope for" but, if you watch closely, it seems that once you knock out your opponent, you see this sort of a cut scene with the fighter doing a victory pose/dance. In these scenes you only see one character at a time so they can show more polygons. And from what I can tell its a lot more similar to the model used in the Saturn version. Then when fighting continues, the character you see are the low poly version again. So for some controlled camera angles the 32X seems to show Saturn models (ïsh..) (Saturn has better physics/animations for hair etc, which 32x doesn't have)

[hooverphonique]

Without looking at them, the victory "dance" might just be playback of static data, thus allowing more processor time for rendering more polygons..

[Bren McGuire]

Lol

Originally Posted by hewitson

as someone who owns a sega st-v board and virtua fighter remix cart, i'm going to say there's zero chance of any 68k based amiga being able to run a decent version of this game.

[Retro1234]

Is there any obscure game like this on Mac 68k?

[AmigaHope]

Originally Posted by hooverphonique

Without looking at them, the victory "dance" might just be playback of static data, thus allowing more processor time for rendering more polygons..

This depends on whether the "dance" is only displaying individual frames of the model or if there are multiple motion vectors being calculated for the body parts.

Any static physical "object" needs to have only one calculation done for all of its vertices relative to the camera -- once the calculation is done for one vertex all the rest of the the vertices can be done via table lookup using trig tables and the initial calculated offset (all realtime software 3D engines back in the day did trig with tables as hardware trig was incredibly slow or nonexistent -- this is also why initially there was no FOV adjustment back in the day because changing FOV meant you had to reoptimize your tables to get good results -- using unoptimized tables made vertices jump between pixels, or made your tables unnecessarily huge in memory).

A complex physical object like a fighter who has tons of independently moving limbs/clothing/hair/etc. could then be done in one of two ways.

You could either store every position the fighter could be in as "frames of animation" -- essentially each frame of movement would be a unique 3D object. That way the entire fighter's offset would only be calculated once and the rest would be done with tables. This creates weird effects though like the fighter's position updating at 60 frames per second but the fighter's moves only happening at 15 or 30 frames per second, for example. In essence the fighter becomes a 3D "sprite".

The other way is to break the fighter up into individual components (usually based around major skeletal segments) and store the animation as motion vectors, but this means each individual limb segment needed its own relative calculation. Anything with a hardware 3D vertex engine does this at minimum, but it was also done in software on systems that could do lots of fast multiplies.

The limiting factor for number of polygons on systems that use the first method is usually not the vertex calculation but the rasterization engine, the exception being systems that had accelerated rasterization but very slow vertex calculation (solid polygon games on the A500 with stock 68000 for example).

[Reynolds]

What about the character in the demo called Datablade?
Or the girl in yellow bikini in TRSI's Rise? Those prods runs quite well on a 030 based Amiga.

[AmigaHope]

Originally Posted by Reynolds

Or the girl in yellow bikini in TRSI's Rise? Those prods runs quite well on a 030 based Amiga.

This? [ Show youtube player ]

A) Entirely premodeled (no dynamic geometry)

B) Rendered at quarter resolution.

C) Framerate not playable for an action game.

[Reynolds]

ok, I admit. just recalled from memory... :P

[pipper]

Here’s another idea: instead of going full-out 3d; what about a 2d polygon bases fighting game? Think of Mortal Kombat, but based on AnotherWorld/Flashback technology.
It is often said that the memory consumption of the character animations is a was limiting factor on the Amiga. Polygonal animations would allow for smooth animation and may be less taxing. The lack of color would be made up by style, smoothness and good sfx.
Imagine playing this:

[ Show youtube player ]

[AmigaHope]

Originally Posted by pipper

Here’s another idea: instead of going full-out 3d; what about a 2d polygon bases fighting game? Think of Mortal Kombat, but based on AnotherWorld/Flashback technology.
It is often said that the memory consumption of the character animations is a was limiting factor on the Amiga. Polygonal animations would allow for smooth animation and may be less taxing. The lack of color would be made up by style, smoothness and good sfx.
Imagine playing this:

[ Show youtube player ]

Yes, this would be doable, though to get the level of animation of say, One Finger Death Punch, it would still eat a lot of memory. It's obviously completely unoptimized for space, but OFDP is still 420 megabytes.