S.T.U.N. Runner, how could this be SOOOOOO bad????

[jotd]

Galahad sped up the whdload version by relocating code in fast ram. This is often pretty effective with 3D games, but also 2D (to speed up loading and global game response time)

(I failed to do that with Red Zone, though)

Won't show on emulators, though. The original version is probably smooth if you use 'fastest possible'. Chipram latency isn't (AFAIK) emulated by WinUAE.

[PatmanQC]

I remember I had the cracked version when it first came out and there is a bug that would not let you get past the first level. Never did see another version of it until years later when I tried it on and emulator.

[Superman]

Here is a quick video of part of level 2 on my A1200 Whdload speeded up version.

[ Show youtube player ]

[S0ulA55a551n]

Originally Posted by Superman

Here is a quick video of part of level 2 on my A1200 Whdload speeded up version.

[ Show youtube player ]

Thats sped up, dear lord

[gimbal]

well at least you have some idea of speed there...

[ZEUSDAZ]

I think we can safetly agree the original A500 release was crud,...apart from the title tune.

I have another SGT Amiga review coming up so stay tuned, It's a driving game that's all I'll say for now ;-)

[AmigaHope]

Powerdrome had a similar engine that performed way better -- especially on better hardware, albeit flying around the course instead of sticking to the sides like in S.T.U.N. Runner.

[saimon69]

Originally Posted by ZEUSDAZ

I think we can safetly agree the original A500 release was crud,...apart from the title tune.

I have another SGT Amiga review coming up so stay tuned, It's a driving game that's all I'll say for now ;-)

Two major candidates are Hard Drivin and Good'ol Outrun (the original, not the STE remake) but there are other cruddy titles like Days of thunder and the actual underpowered incarnation of Power Drift so wonder which one is...

[Gryfon]

Originally Posted by jotd

Prime Mover wasn't 3D

There are good Domark games. Not a lot I can remember now But some arcade conversions were okay. For me Domark is almost on par with US gold...

Good ones: Super Space Invaders, Escape from the planet of robot monsters, Badlands for instance

My main memory of Domark was that they published the Vektor Grafix version of Star Wars for the Atari 8-bit and as much as I loved that some version came out for the Atari 8-bit at all, you only need to look at Mercenary - Escape from Targ to realise it could have been so much better.

However Domark also published an excellent version of Trivial Pursuit for the Atari 8-bit too, which my whole family loved to play.

[VladR]

Originally Posted by grond

I think in the tunnel scenes the FPS could be improved quite a bit if only areas with coordinates made up of the previous screen and the current screen were redrawn/updated. This would correspond to the areas that may have changed. Obviously this would need some additional CPU complexity but it should pay off on the filling time (always hard to predict for plain 68000 without actually trying it).

Differential renderer is quite a beast in itself. Easily more complex technology than writing the core 3D engine in itself. I have spent few days on researching base scenarios for a differential renderer 2 years ago on jaguar.


The complexity very quickly ballooned exponentially. And on top of that you have clipping (that further multiplies the number of codepaths), unless you are willing to pay a per-scanline cost (of course).

Differential renderer can be written in a weekend for something simple like a road - where you have simple axis-aligned quads, so the number of all potential scenarios is quite low. And the road doesn't have to be clipped against top screen edge. And the bottom screen edge clipping is a simple single condition outside the scanline loop.



I would reckon it is doable in about a week for a base StunRunner 3D mesh (like the attached screenshot).

But the tube would get way more complex, especially the clipping against top screen edge (that one is a b*tch) requires more codepaths.

I reckon it's doable in 3-4 weeks, full-time...

[VladR]

Originally Posted by ZEUSDAZ

I give you S.T.U.N. Runner shit game time video review, I hope you enjoy it and would love to hear your thoughts of this utter dire conversion

If I understand this correctly, you are running it on a base 7 MHz A500 ? That's a very tall order for a high-speed 3D racer!

Long time ago, I did some work on Jaguar's version of StunRunner:
[ Show youtube player ]

That vid doesn't have tube segments, as there were quite a few clipping cases that were not implemented yet (back then), so I understand intimately why the performance drops in A500 version in the tube segments.


Now, I eventually optimized it enough to run at 60 fps a 640x200@256, but that's 13.3 MHz 68000 + 26.6 MHz RISC GPU + Blitter (filling scanlines).


At one point I had a version that ran just on 68000 (no Blitter, no GPU). It might be an interesting exercise to dig it up and see how fast pure SW rasterizer would run this.


I wonder what's the closest Amiga config to the 13.3 MHz 68000 ? 68020, perhaps ?

[rothers]

Originally Posted by Konrad

Stardust is just a prerendered animation in a straight tunnel. How would this work with a game like this?

Because the Amiga isn't capable of running the original at 50fps with polygons.


So, if I was porting it, I'd use either 4 or 8 colours + sprites + copper + lots of prerendered + colour cycle.


I think for getting the speed right that's the only way to go. The gameplay is pretty simple from what I've seen.

[Keops/Equinox]

This video really makes me uncomfortable. 15 minutes repeating endlessly the word "shit" and throwing some at the authors without the slightest pragmatic analysis of what's actually going on on screen.

Could the game as it is have run better? Probably. How much faster? Probably less than you think on a stock A500.

Did the authors make the right choice to try to make an almost exact visual conversion of the arcade game with all its 3D complexity? Probably not. As Galahad pointed it out, different approaches with less 3D and more 2D would have given a faster game. However, we have no idea what kind of obligation and level of freedom the authors had with their contract and what level of fidelity they had to deliver.

Now, about the 3D:
Anybody who has ever spent a significant amount of time coding a 3D polyfiller on a 68000 machine will instantly see that making this game run at a decent speed on a 7MHz machine is simply a nightmare.

The tunnel alone seems to have around 150 visible triangles, basically ending up filling the entire screen.
For comparison, Powerdrome seems to have something more like 50 visible triangles for its circuit, a smaller gameplay area and a circuit that usually only fills around half or two thirds of the gameplay area anyway.

So, that's already 150 triangles to render and to mask since they can overlap because the circuit is not just a straight line. But more importantly, That's around the same number of vertices to rotate and project, which is quite a lot on a 7 Mhz machine. Most demoscene tricks were not usable in the context of a game that had so many degrees of freedom (usually for memory or constraint reasons)

Now, for fidelity reasons I suppose, and unlike Interphase and Powerdrome, you can see your entire ship in third person view. That ship seems to be made out of at least 30 more triangles to render and rotate.

Also, you sometimes have up to seven 3D stars displayed on the tunnel, each star seems to be made of 12 triangles.

Finally, that more's than 200 triangles, filling almost the entire screen, and more or less the same number of vertices to rotate/project without any actual big trick to save on calculations because of the nature of the game and its free motion.

I don't know the authors, but I see that they were two programmers to make everything, gameplay, math, rendering, probably in a very short amount of time.

There are probably usable optimizations for the rotations as some elements rotate around only one axis or two axes (the tunnel has slopes it seems, so we can discard only one axis of rotation), but that's still a lot of vertices and polygons to handle anyway (maybe they did it, maybe they just did not have the time to take care of those cases and they made a generic 3D engine)

I have no doubt that the game could have run slightly better if they had more time, but again, probably not as much as you would expect.

PS: one could argue that using quads instead of tris for convex shapes would speed things up (they possibly did, I assumed tris because I have always worked with tris), but overall, the gain would not be that big anyway as one of the bottlenecks is the number of vertices and their calculations to begin with and the size of polygons on screen.

PS': hardware spec of the arcade game
Main CPU : 68010 @ 8 MHz
GSP : TMS34010 @ 48MHz - Rasterizer : to render the polygons and graphics
PSP : TMS34012 @ 50MHz - (labelled SCX6218UTP) to expand pixels
MSP : TMS34010 @ 50MHz - (optional) to handle in-game maths calculations

[VladR]

Originally Posted by Keops/Equinox

PS: one could argue that using quads instead of tris for convex shapes would speed things up (they possibly did, I assumed tris because I have always worked with tris), but overall, the gain would not be that big anyway as one of the bottlenecks is the number of vertices and their calculations to begin with and the size of polygons on screen.

I disagree based on personal experience and benchmarks. I have actually made the quads-vs-tris benchmarks on StunRunner scene itself, on Jaguar.

Quads are way more faster simply because you are halving the single most expensive stage of the entire pipeline - scanline traversal.
The Quad set-up is slightly slower due to sorting of points but it's more than compensated by halving the scanline traversal. I have seen scenes where that number dropped by 10,000.

That's 10,000 scanlines less to traverse (loop, end-point, clip), which - even with fixed-point math, is a major expense - hence the brutal framedrops.

The downside is, it's a b*tch to debug and catch all non-obvious corner scenarios

Originally Posted by Keops/Equinox

PS': hardware spec of the arcade game
Main CPU : 68010 @ 8 MHz
GSP : TMS34010 @ 48MHz - Rasterizer : to render the polygons and graphics
PSP : TMS34012 @ 50MHz - (labelled SCX6218UTP) to expand pixels
MSP : TMS34010 @ 50MHz - (optional) to handle in-game maths calculations

Of course, it's actually beyond ridiculous to even attempt conversion from such HW to a puny 7 MHz A500.

On another hand, we have no idea how much parallelism were the original arcade coders able to extract. For all we know, they might use only 15-20% of the RISCs instruction throughput.

Also, Arcade version runs in a higher [non-standard] resolution. I forgot what it was, but it was close to 640x480, I believe - so there's more CPU bandwidth needed to fill all those pixels.

[Keops/Equinox]

VladR: yeah sorry if it was not clear, you are right, it would be faster. I meant overall, it would probably not double the framerate for that game, because of many other factors (like computing rotations and all) but that was not the point of my post

My former point was merely to count the number of primitives (tris or quads, it's not important) and compare it to other games like Powerdrome, and point out that this one was way more complex and that polygons filled the entire screen.

By the way, correct me if I'm wrong but I don't even think Stun Runner US Arcade ran at 60 FPS anyway, I remember something running at 25/30.

Stun Runner's hardware supported 512x288 max if I'm not mistaken

[VladR]

Originally Posted by Keops/Equinox

VladR: yeah sorry if it was not clear, you are right, it would be faster. I meant overall, it would probably not double the framerate for that game, because of many other factors (like computing rotations and all) but that was not the point of my post

My former point was merely to count the number of primitives (tris or quads, it's not important) and compare it to other games like Powerdrome, and point out that this one was way more complex and that polygons filled the entire screen.

By the way, correct me if I'm wrong but I don't even think Stun Runner US Arcade ran at 60 FPS anyway, I remember something running at 25/30.

Stun Runner's hardware supported 512x288 max if I'm not mistaken

Yeah, it's impossible to estimate how much the final framerate would have been sped up even if they used quads without detailed benchmarks of all of their pipeline stages.

Of course, halving the time taken on pixel fill doesn't double the framerate - that much I reckom is certainly obvious to anybody with at least a passing interest in SW rasterizers, let alone someone who writes them.

But the framerate drops certainly correspond with scene complexity, as expected. Transform, Clip, Edge Set-up, PixelFill all linearly rise.

I don't recall the resolution of StunRunner arcade, it was some uncommon res.

But you are right, even the arcade itself, which has more then an order of magnitude (probably close to two orders given the RISCs) more MIPS than a puny 68000 had framedrops and didn't run at 60 fps.

I personally don't think that the Amiga's StunRunner is a bad job from coding perspective. It simply should not have been considered in the first place, to display same scene complexity as an arcade.


But someone made the decision and coders were paid to do the job, regardless of how stupid that decision was.
I'm sure they protested and asked to be allowed to implement some kind of LOD or something, but were denied, as is basically, always the case in these kinds of conversions...

[rothers]

The bonus stage in sonic2 is how to do this game right on the Amiga.

[ Show youtube player ]

You could probably improve on that quite a bit too with the copper.

[VladR]

Originally Posted by rothers

The bonus stage in sonic2 is how to do this game right on the Amiga.

[ Show youtube player ]

You could probably improve on that quite a bit too with the copper.

Now that's a great find ! Looks similar to Trailblazer (precalced scene) on A800.

Even if we spent full 4 frames (60 / 4 = 15 fps) on updating a more complex scene, it would still be plenty smooth (assuming no framedrops).

And while a fully precalced tunnel like this can indeed run at 60 fps, I believe we could have more immersion and interactivity even at 15-20 fps (locked) but we would have some parts of tunnel updated dynamically (as long as camera is static!) and not just 2-3 types of curves.

The tunnel approach that I am talking about is basically this:
- keep tunnel vertices 3D
- reduce visibility (mostly to reduce scanline count)
- pre-transform/clip ahead of time into RAM
- keep edge information (for scanline traversal and 2 coord lerp), as without dynamic camera, edge is same
- during rendering, just lerp between 2D transformed vertices
- replace 3D stars with pre-rendered sprites

I think 7 MHz 68000 should be able to fill whole screen in 4 frames in tandem with Blitter.

We would probably want to use the blitter mask/fill approach for front segment of the tunnel (not scanline traversal).

There would be nothing fake about this, it just wouldn't allow player to strafe camera up.down.left.right, that's all.

And it shouldn't take more than 2-3 days to implement.

[saimon69]

To give a better experience we could use a similar method as Stardust, with tunnel area bigger than the visible screen so to have some scroll that will enhance the 3D effect
[ Show youtube player ]