15 March 2021, 21:21 | #21 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,164
|
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. |
16 March 2021, 05:55 | #22 |
Registered User
Join Date: Jul 2018
Location: Bettendorf
Posts: 349
|
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.
|
16 March 2021, 13:23 | #23 |
Super Member
Join Date: Sep 2014
Location: Wakefield
Age: 48
Posts: 1,334
|
Here is a quick video of part of level 2 on my A1200 Whdload speeded up version.
[ Show youtube player ] |
16 March 2021, 13:47 | #24 |
Registered User
Join Date: Nov 2010
Location: South Wales
Age: 46
Posts: 934
|
|
16 March 2021, 14:34 | #25 |
cheeky scoundrel
Join Date: Nov 2004
Location: Spijkenisse/Netherlands
Age: 42
Posts: 6,909
|
well at least you have some idea of speed there...
|
16 March 2021, 19:12 | #26 |
Registered User
Join Date: Nov 2014
Location: England
Posts: 743
|
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 ;-) |
25 March 2021, 04:46 | #27 |
Registered User
Join Date: Sep 2006
Location: New Sandusky
Posts: 942
|
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.
|
25 March 2021, 22:06 | #28 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,519
|
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...
|
31 March 2021, 12:47 | #29 | |
Registered User
Join Date: Oct 2018
Location: United Kingdom
Posts: 97
|
Quote:
However Domark also published an excellent version of Trivial Pursuit for the Atari 8-bit too, which my whole family loved to play. |
|
12 April 2021, 23:20 | #30 | |
Registered User
Join Date: Dec 2019
Location: North Dakota
Posts: 741
|
Quote:
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... |
|
12 April 2021, 23:36 | #31 | |
Registered User
Join Date: Dec 2019
Location: North Dakota
Posts: 741
|
Quote:
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 ? |
|
13 April 2021, 16:10 | #32 | |
Registered User
Join Date: Apr 2018
Location: UK
Posts: 487
|
Quote:
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. |
|
13 April 2021, 19:18 | #33 |
Registered User
Join Date: Feb 2008
Location: .
Posts: 107
|
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 Last edited by Keops/Equinox; 13 April 2021 at 20:32. |
14 April 2021, 04:30 | #34 | ||
Registered User
Join Date: Dec 2019
Location: North Dakota
Posts: 741
|
Quote:
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 Quote:
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. |
||
14 April 2021, 20:35 | #35 |
Registered User
Join Date: Feb 2008
Location: .
Posts: 107
|
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 Last edited by Keops/Equinox; 14 April 2021 at 22:08. |
15 April 2021, 02:07 | #36 | |
Registered User
Join Date: Dec 2019
Location: North Dakota
Posts: 741
|
Quote:
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... |
|
15 April 2021, 19:11 | #37 |
Registered User
Join Date: Apr 2018
Location: UK
Posts: 487
|
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. |
15 April 2021, 21:53 | #38 | |
Registered User
Join Date: Dec 2019
Location: North Dakota
Posts: 741
|
Quote:
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. |
|
15 April 2021, 22:08 | #39 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,519
|
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 ] Last edited by saimon69; 15 April 2021 at 22:13. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Bode Runner ? | Critter | request.Old Rare Games | 19 | 07 January 2024 23:05 |
Trap Runner | Predseda | Games images which need to be WHDified | 17 | 11 March 2022 13:10 |
Ghost runner | coco55 | New to Emulation or Amiga scene | 2 | 28 February 2021 20:47 |
Ghost runner | coco55 | request.Old Rare Games | 2 | 28 February 2021 19:35 |
The Runner | Kodoichi | HOL suggestions and feedback | 0 | 16 December 2004 22:23 |
|
|