13 replies to this topic

[louisg]

Hi, I saw the S.T.U.N. Runner topic over at http://www.atariage....-for-the-lynx/. Well, I run a page on how pseudo 3d road engines (like Outrun) work, and am always trying to add more case studies of actual games (http://www.gorenfeld.net/lou -- so far I just have a breakdown of Enduro and Road Rash).

So, I was wondering if anyone knew whether S.T.U.N. Runner actually works more or less similarly to a game like Outrun (or Roadblasters, etc). I know the other thread had some source code from the game; does anyone know if the source code has been released in its entirety?

Maybe a little off-topic for this forum, but I was also under the impression that the arcade S.T.U.N. Runner also was basically pseudo 3d in that the view of the road/tunnels is built from the front of the screen to the back, with curves simulated (as opposed to using 3d translations and rotations to move the camera as it goes around a curve the way a game like Hard Drivin' would).

Edited by louisg, Thu Feb 16, 2012 11:54 AM.

[solidcorp]

Hi,

I wrote both Lynx S.T.U.N. Runner and RoadBlasters and you are spot on.  First I'd like to mention that I checked out your page and it is an awesome treatment on the topic, very nice, very detailed.  Frankly, I don't know what more I can add, but I'd be happy to answer any questions you might have or discuss it.

S.T.U.N. Runner draws many cross sections of track as sprites to create the illusion of a solid 3D shape which is much faster than drawing the actual polygons on the Lynx.  The ship, enemies, shots, etc. are all sprites who have 90 degrees worth of rotation frames that are flipped horizontally and vertically to fill out 360 degrees of rotation with 1/4 the storage on the cartridge.

RoadBlasters uses the paletized lines almost exactly as you describe them on your site.  There are no hills so the lines just slide left and right to curve the track, and the palette is changed for each line to animate the yellow centerline stripes, red and white stripes on the edges, and background off the road.  All the objects in the game are sprites with rotation frames stored in the cart as needed.

With scale and palette animations, care must be taken to account for perspective.  Size of sprites varies with 1/depth which is nonlinear.

I have most of the S.T.U.N. Runner coin op C source files in the form of printouts, and all of the Lynx 6502 assembly source to RoadBlasters, S.T.U.N. Runner, and Toki, but I don't think I should share them.  What other Lynx games released by Atari have source that is publicly available?  If someone wanted to take the time to get permission from Atari, I would be happy to release all the source materials.

The coin op S.T.U.N. Runner is truly completely 3D.

D. Scott Williamson

[louisg]

Hi! Thanks for the reply!

solidcorp, on Fri Feb 17, 2012 11:08 AM, said:

S.T.U.N. Runner draws many cross sections of track as sprites to create the illusion of a solid 3D shape which is much faster than drawing the actual polygons on the Lynx.  The ship, enemies, shots, etc. are all sprites who have 90 degrees worth of rotation frames that are flipped horizontally and vertically to fill out 360 degrees of rotation with 1/4 the storage on the cartridge.

If there's one problem of pseudo 3d roads that I've found there are a multitude of ways to solve, it's hills. I was wondering, in Lynx S.T.U.N. Runner, how that was accomplished.

I also wonder whether STUN Runner is a per-scaline slide engine (the way I imagine RoadBlasters is) or whether it's dealing in small 3d chunks of track projected onto the screen (not 3d in the sense that they can rotate, but 3d in the sense that the height on the screen for a given slice of track is found by solving something like y_screen = y_world/z).

Would you be able to share the algorithm that S.T.U.N. Runner uses? And do you remember if overdraw was a concern on that platform?

Quote

With scale and palette animations, care must be taken to account for perspective.  Size of sprites varies with 1/depth which is nonlinear.

Right, I imagine given the density of scenery in S.T.U.N. Runner that the 1/depth relationship is important so that the pieces fit together without gaps or too much overshoot (not to mention the headaches that happen when the relationship is wrong ).

Quote

What other Lynx games released by Atari have source that is publicly available?  If someone wanted to take the time to get permission from Atari, I would be happy to release all the source materials.

Hmm I thought I saw Rampart source kicking around these forums, but maybe that's not official source. Is there anyone I might be able to write to and see if they might approve release of the S.T.U.N. Runner source?

Quote

The coin op S.T.U.N. Runner is truly completely 3D.

I'm surprised! So it's completely 3d to the point that, had the developers wanted to, they could have swiveled the camera to show the track from different angles. I do remember that one running a bit quicker in the arcade than Hard Drivin', but then again I suppose the physics are easier to calculate.

Again, thanks for taking the time to comment
-Louis

Edited by louisg, Fri Feb 17, 2012 3:35 PM.

[solidcorp]

Both games run on a spline, to use the term loosely, that is to say they are on rails, there are specific paths the "camera" will take and everything in the world is scripted by distance.

Actually, objects don't even have 3D coordinates, in RoadBlasters they just have horizontal position from the centerline of the track and distance.  In S.T.U.N. Runner they have angle/horizontal position, depending on whether you are in the tunnel or on a flat, and distance.  The scale of all the graphics was related to 1/Z, and the position of objects was relative to the centerline of the track or tube.  This is not strictly accurate in 3D but has enough scale and parallax cues to give a convincing illusion.  I solved all the perspective curving and placement when I did RoadBlasters.  When S.T.U.N. Runner came up in the office there was talk of doing it polygonaly like Hard Drivin or Steel Talons and no one thought it could be done at a decent framerate so I decided to experiment with extending the horizontal RoadBlaster system to X and Y, which worked nicely in a demo and I got to do the game.

The RoadBlaster track pieces were discrete scan lines, the S.T.U.N. Runner track pieces are quarter pieces I think, they may have been full pieces, I'm not sure.  Quarter pieces would have allowed left right reflection, but not top to bottom because of the shading in the tunnel which is done with dithering.  The pieces had to be drawn back to front (painters algorithm) because there was no depth buffer or anything like that.  Fill was not really an issue, I just had to find an ideal tunnel segment thickness in terms of depth.  In retrospect, if I had to do it again, I think I would break the rings into more pieces so I wouldn't have to raster large rectangles with large transparent areas.  S.T.U.N. Runner also had to deal with split tunnels, there were no forks in RoadBlasters Roads.  What I had to resort to was using full filled in billboard sprites for the splits until the players path was determined and then populate the tunnel that was chosen, which fortunately happened well before the camera reached the split.  They happen really quick, but occasionally, I think you can see vehicles driving through the plane for a brief instant.

This is off topic, but S.T.U.N. Runner really had to manage palettes well too and would interpolate between them as backgrounds changed as you entered different colored tunnels.  In both games the dash boards are completely different pallettes which were changed by a display line interrupt, not an uncommon technique.

As far as the coin op 3D, it was pretty basic geometry, elongated lengthwise, probably looked best flying straight ahead.

[louisg]

To do the up/down hills, are you saying that it basically curves the Y axis instead of curving the X (like a left/right turn, but affecting the other axis)? And, do you recall if the dark/light grey pattern used on the ground is also a sprite in STUN Runner? To me, it seems like Roadblasters is somewhat different from STUN Runner in that STUN Runner's track is broken up into somewhat large sprite chunks (ala RadMobile) but Roadblasters works on a per-scanline basis (like Pole Position). Maybe I'm not fully understanding this though. I do get that the sprites in STUN Runner are tied to the road's position, but solving the hill problem always turns out to be a sort of chicken/egg deal!

I do notice that STUN Runner doesn't seem to have hills at the same time as it's curving left/right, so that should simplify the problem somewhat.

That's an interesting solution to the forking road. I did notice something a little funky about them, but couldn't put my finger on it!

I'm glad STUN Runner was done using sprites-- speed is of course extremely important in a racing game, and it turned out great! In fact, it's the game that sold me on a Lynx in the early 90s.

[Shawn Jefferson]

solidcorp, on Fri Feb 17, 2012 11:08 AM, said:

I have most of the S.T.U.N. Runner coin op C source files in the form of printouts, and all of the Lynx 6502 assembly source to RoadBlasters, S.T.U.N. Runner, and Toki, but I don't think I should share them.  What other Lynx games released by Atari have source that is publicly available?  If someone wanted to take the time to get permission from Atari, I would be happy to release all the source materials.

The value of the source code of those products to Atari is so close to zero, I can't imagine anyone at Atari would care.  What is of value is the trademarks (the name, the logos, branding, etc...) and the "look and feel" of the game-none of which is really a concern as far as release of source code goes.  Just my take on the situtation anyway, the decision is ultimately yours.

These games (STUN Runner and Roadblasters) are just great on the Lynx, nice work!

Edited by Shawn Jefferson, Sat Feb 18, 2012 4:10 PM.

[solidcorp]

Shawn Jefferson, on Sat Feb 18, 2012 4:03 PM, said:

The value of the source code of those products to Atari is so close to zero, I can't imagine anyone at Atari would care.  What is of value is the trademarks (the name, the logos, branding, etc...) and the "look and feel" of the game-none of which is really a concern as far as release of source code goes.  Just my take on the situtation anyway, the decision is ultimately yours.

That's speculative, I'm not comfortable assuming that anything is invaluable to the rightful owner.  If you would like to contact Atari and get permission for me to release those materials, please do.

Shawn Jefferson, on Sat Feb 18, 2012 4:03 PM, said:

These games (STUN Runner and Roadblasters) are just great on the Lynx, nice work!
I'm not sure you can say that the

Thanks a lot.

[solidcorp]

louisg, on Fri Feb 17, 2012 7:41 PM, said:

To do the up/down hills, are you saying that it basically curves the Y axis instead of curving the X (like a left/right turn, but affecting the other axis)?

And, do you recall if the dark/light grey pattern used on the ground is also a sprite in STUN Runner? To me, it seems like Roadblasters is somewhat different from STUN Runner in that STUN Runner's track is broken up into somewhat large sprite chunks (ala RadMobile) but Roadblasters works on a per-scanline basis (like Pole Position). Maybe I'm not fully understanding this though. I do get that the sprites in STUN Runner are tied to the road's position, but solving the hill problem always turns out to be a sort of chicken/egg deal!

Yes... well, it curves both X and Y axis independently.

In RoadBlasters, each line stayed at the same vertical position on the screen and moved left to right by an amount proportional to the curvature of the track, and inversely proportional to depth for perspective.  The vertical timing or spacing of palette changes on the lines also had to take perspective into account.

In S.T.U.N. Runner, the rings are sprites that don't actually have any depth, they have to be drawn back to front (painters algorithm) along with the sprites for the gameplay elements in order for "nearer" objects to draw in front of (on top of) "farther" objects.  Unlike RoadBlasters whos track pieces were lines that just slid left and right, the ring and track segments slid left and right and up and down.  The amount that a piece slid was based on the independend horizontal and vertical curvature of the track (which are orthoganal) and perspective.  Perspective is a 1/depth calculation and had to be applied to the horizontal and vertical displacement of sprites as well as their scale.

I don't recall if the rings actually moved all the way towards the player or sort of vibrated in place at a particular depth.  If they moved towards the player they would always need to be resorted, but if a sprite represented the track at some fixed distance or interval, it would start at the far edge of its range, smaller, scale up, and when it reached the largest size for that interval or the nearest position, it would "become" the next farthest track piece at the far end of its range again, so you would have the seamless illusion that the segment moved continuously from the horizon to the point where you pass through it, but in its lifetime it would have passed through each sprite responsible for each particular depth.

In S.T.U.N. Runner the ring/track segments use different palettes to achieve shading and coloring, there is no color cycling or color per scan line palette manipulation like in RoadBlasters other than the palette change that happens for the dash board.

louisg, on Fri Feb 17, 2012 7:41 PM, said:

I do notice that STUN Runner doesn't seem to have hills at the same time as it's curving left/right, so that should simplify the problem somewhat.

The S.T.U.N. Runner track can and does turn in all directions.

louisg, on Fri Feb 17, 2012 7:41 PM, said:

That's an interesting solution to the forking road. I did notice something a little funky about them, but couldn't put my finger on it!

I'm glad STUN Runner was done using sprites-- speed is of course extremely important in a racing game, and it turned out great! In fact, it's the game that sold me on a Lynx in the early 90s.

I don't think the game could have been as smooth any other way.
Thanks!

[GadgetUK]

louisg, on Thu Feb 16, 2012 11:51 AM, said:

Hi, I saw the S.T.U.N. Runner topic over at http://www.atariage....-for-the-lynx/. Well, I run a page on how pseudo 3d road engines (like Outrun) work, and am always trying to add more case studies of actual games (http://www.gorenfeld.net/lou -- so far I just have a breakdown of Enduro and Road Rash).

So, I was wondering if anyone knew whether S.T.U.N. Runner actually works more or less similarly to a game like Outrun (or Roadblasters, etc). I know the other thread had some source code from the game; does anyone know if the source code has been released in its entirety?

Maybe a little off-topic for this forum, but I was also under the impression that the arcade S.T.U.N. Runner also was basically pseudo 3d in that the view of the road/tunnels is built from the front of the screen to the back, with curves simulated (as opposed to using 3d translations and rotations to move the camera as it goes around a curve the way a game like Hard Drivin' would).

Awesome article on your site, in the years ive been developing ive never looked at producing a none 3D racing game engine but I had always wondering if it was done using rastering but figured the corners would be a nightmare.  I've book marked it and will re-read that after ive had a go at my own.  Even more amazing on this thread, we have 'the' D. Scott Williamson!?!?!   Roadblasters is an awesome game and one of my favourite Lynx games - thanks for producing an awesome piece of Lynx history!  If the world had had 10 or 20 more developers like you back then, we'd probably be on the 5th or 6th itteration of the Lynx now =/  Even more amazing is that most of these kinds of games were written mostly (if not entirely) in ASM.

If we have a developer who ported Xenophobe on here then I will be completely made up!

Edited by GadgetUK, Sat Mar 31, 2012 5:16 PM.

[matashen]

very interesting website... good work.

[ZylonBane]

GadgetUK, on Sat Mar 31, 2012 5:12 PM, said:

If we have a developer who ported Xenophobe on here then I will be completely made up!

So your dream is to become fictional?

[GadgetUK]

ZylonBane, on Sun Apr 1, 2012 8:11 AM, said:

GadgetUK, on Sat Mar 31, 2012 5:12 PM, said:

If we have a developer who ported Xenophobe on here then I will be completely made up!

So your dream is to become fictional?

LOL

Back on the subject of Road Blasters Lynx port - I am interested in how the port was done (question for Mr Williamson - if he doesn't mind?)

Did you start from scratch and replicate the arcade version from new, or were you given access to the original arcade source code and assets (sound and bitmaps etc)? - ive always wondered how some of these ports were done.

What did you develop on, presumably a 286 or something way back then, and presumably you could only run the code on the Lynx itself via cable / EEPROM flash?

Edited by GadgetUK, Sat Apr 7, 2012 5:33 AM.

[matashen]

back in the days all Lynx stuff was created on Amiga Computers that came with the development system.

[GadgetUK]

Wow, I had no idea that Amigas were used.

EDIT: Scrap what I said, I dont think Katz did work for Commodore at any point.  What's even more mysterious is the choice not to use the Atari ST to develop on...  I guess it's due to the development of the Lynx being done by Epyx originally.

Edited by GadgetUK, Sat Apr 7, 2012 7:25 AM.