Road Rash pre-alpha on Jaguar at 30 fps

[Lost Dragon]

Just for the hell of it:

 

Ballistic on PC

 

Hover Racing PS1:

 

 

Hover Car:

Edited June 30, 2018 by Lost Dragon

[VladR]

What is the problem with PS1 games?

3 things:

 

1. The sheer brute-force computational power

2. People are still not convinced that PS1 is greatly faster than jaguar

3. I was sure that something like Saturn would have at least a dozen games, given how popular Wipeout was. Well, as you read, I found exactly ONE such game on Saturn. So, at least for inspiration, PS1 is now game.

 

PS1 can do full-body rigid physics in a split of a frame without even registering it was doing it. I just don't feel like arguing that PS1 > Jaguar, that's all...

 

 

Note that I'm not saying that it's impossible to do 60 fps on jag including triple axis physics. But we would have to take that performance from elsewhere (like, scene complexity, resolution, ...), and I don't want to do that for this game. Also, it's not a weekend thing to write in ASM (well, in C it is, but considering jag's bugs and issues, just debugging that would take 2 weekends, after it was actually written).

[JagChris]

Episode 1 Racer?

 

[Lost Dragon]

If you mean future Racer type games, the Saturn had:

 

Gran Chaser

High Octane

Wipeout

Wipeout 2097

 

Scorcher :

 

 

And back to PS1...

 

This could be the platform's Club Drive, it's that bad, Japan only release i think:

 

 

Then there's Streak :

 

Edited June 30, 2018 by Lost Dragon

[Barone]

3 things:

 

1. The sheer brute-force computational power

2. People are still not convinced that PS1 is greatly faster than jaguar

3. I was sure that something like Saturn would have at least a dozen games, given how popular Wipeout was. Well, as you read, I found exactly ONE such game on Saturn. So, at least for inspiration, PS1 is now game.

 

PS1 can do full-body rigid physics in a split of a frame without even registering it was doing it. I just don't feel like arguing that PS1 > Jaguar, that's all...

 

 

Note that I'm not saying that it's impossible to do 60 fps on jag including triple axis physics. But we would have to take that performance from elsewhere (like, scene complexity, resolution, ...), and I don't want to do that for this game. Also, it's not a weekend thing to write in ASM (well, in C it is, but considering jag's bugs and issues, just debugging that would take 2 weekends, after it was actually written).

Saturn's racing library is actually pretty thin; especially if you remove the cheap PS1 ports.

Wipeout was popular but on the PS1 for the most part.

 

A couple more:

 

 

 

 

 

 

 

And this for the PC which I find very interesting graphically speaking:

 

 

EDIT:

And this is a 1998 arcade game:

Featuring short clips with the development team:

EDIT 2:

 

By the end of the video you can get an idea of its physics model:

Edited June 30, 2018 by Barone

[philipj]

If you mean future Racer type games, the Saturn had:

 

Gran Chaser

High Octane

Wipeout

Wipeout 2097

 

Scorcher :

 

 

Scorcher was made by the people who did the famous 32X demo for the Sega genesis add-on module... You should check out some the work they've done on the Sega Genesis; next to "Codemasters" these were real good in tweaking the living crap out of a computer with a Motorola 68000 thus they came from the Amiga demo-scene. I'm not going to post any of their Sega Genesis stuff, but the 32X demo seems very appropriate this topic. I wish there was more info on how they were able to pull off their tricks... The Sega Saturn doesn't really have the kind of hardware that the PS1 have where the inner components tested and tried in the computer graphic workstation market versus the Saturn based off of Arcade hardware where Sega clearly did their homework before the release of "Virtue Racer". Sega is another company that is king of the scaling and rotating sprites starting with "Buck Rogers Planet Of Zoom" and making a slew of other pseudo 3D games afterwards like Out Runner, Hang On, Space Harrier just to name a few taking good advantage of the 68000, but I can go on and on with that stuff so I'll end here. lol

 

ZYRINX 32X Demo Video

Edited July 1, 2018 by philipj

[Lost Dragon]

I simply adored Sub-Terrania on the Mega Drive,it just needed more levels.

 

Red Zone blew me away on a technical level, but man it was too tough to play.

 

But yes,they really pushed the hardware and got fantastic results.

[Clint Thompson]

Absolutely loved that Zyrinx 32X tech demo, thanks for sharing that! Too bad about the draw distance but that thing had some really cool capabilities overshadowed completely by the next gen consoles coming through.

[philipj]

Absolutely loved that Zyrinx 32X tech demo, thanks for sharing that! Too bad about the draw distance but that thing had some really cool capabilities overshadowed completely by the next gen consoles coming through.

 

I know right...? Another thing I noticed about "Scorcher" for the Sega Saturn is that the racing track is highly modular just like "Checkered Flag" for the Jaguar, but doesn't use high detailed polygon backgrounds the way CF did. A game like "Wipeout 2097" for the Playstation 1 seems to work within draw distances limitations much like "Ridge Racer" both the track and the background are reasonably rendered fully in real-time without it looking like the edge of the world are a few feet away because all of the polys aren't rendering fast enough... Got to get around the polygon limitations somehow or at least work within it. Here's a video of "Wipeout" for the PS1 the tracks meets the limits of draw distances; the scenes fully rendered enough to not dissipate within distance. Well... There's a little polygon dissipation, but just barely.

 

Note: The video is in HD so it's clearly emulated.

Edited July 2, 2018 by philipj

[+Stephen]

Wipeout XL on the PS1 (along with Need for Speed, and Crash Bandicoot) really let me know I had entered the next-generation of gaming when both my Jag+CD and PSX were new.

[Barone]

@philipj
One of the tricks/design choices that Wipeout 2097 uses is to have a background image which blends with the track scenery as you can see around 1:33 of the video below (real hardware capture):

 

There are some different ways to try to hide the limited draw distance depending on the hardware and software engine you're running the game.
If you compare 3DO's NFS to Saturn's, you'll notice that 3DO's far view is mostly composed by a static image instead of draw in polygons. PS1 version adds a lighting variance to smooth out the draw distance limitations.

Saturn's Daytona USA CCE forces a track scrolling speed reduction to keep both draw distance and frame rate stable. PS1's Formula 1 97 lets you choose if you want to lock frame rate or draw distance.


@VladR
IMO one of the main factors in terms of controls/physics/gameplay for games of this genre is if you're able to feel that the ship/vehicle has some weight (and thus inertia) to it or not.
More crude games such as Saturn's Cyber Speedway are weak in such aspect; the vehicle is pushed around too much by any touch or seems to bounce exaggeratedly and abruptly.
The first Wipeout on the PS1 also has full stop on collisions.

The more you can avoid things like that and smooth out the collisions' and driver input's impact on the vehicle, the better IMO.

The more polished games seem to go in this direction.

Edited July 2, 2018 by Barone

[Lost Dragon]

The design documents for the original Wipeout on PS1 can be found here:

 

https://www.eurogamer.net/articles/2015-10-01-the-original-wipeout-design-document-revealed

[philipj]

@philipj

One of the tricks/design choices that Wipeout 2097 uses is to have a background image which blends with the track scenery as you can see around 1:33 of the video below (real hardware capture):

 

I hear you man... There's a trick I learned concerning how they implemented background images when I took up a 3D modelling course a few years back... You create a low polygon filled half-dome and apply a texture-map background image to it. The dome should be bigger than the actual 3D scene and usually the bigger the better to simulate open sky/world that's why the background in Wipeout seems to move with the scene instead of the flat background image you'll see in Checkered Flag for the Jag. At least that was the old school way of doing it; I think today they have some kind of HDR thing with background image in modern games???

 

Edited July 2, 2018 by philipj

[philipj]

The design documents for the original Wipeout on PS1 can be found here:

 

https://www.eurogamer.net/articles/2015-10-01-the-original-wipeout-design-document-revealed

 

Thanks a bunch for the link... The attention to details on the racing vehicle 3D model is very interesting to say the least considering the PS1 or the Saturn couldn't handle such high detail models, but it's very evident in the "design document".

[+Stephen]

So sorr

 

The design documents for the original Wipeout on PS1 can be found here:

https://www.eurogamer.net/articles/2015-10-01-the-original-wipeout-design-document-revealed

So sorry it's off-topic, but if anyone here pas a PS4+VR, you really need to get the newest Wipeout.

[Barone]

 

I hear you man... There's a trick I learned concerning how they implemented background images when I took up a 3D modelling course a few years back... You create a low polygon filled half-dome and apply a texture-map background image to it. The dome should be bigger than the actual 3D scene and usually the bigger the better to simulate open sky/world that's why the background in Wipeout seems to move with the scene instead of the flat background image you'll see in Checkered Flag for the Jag. At least that was the old school way of doing it;

PS1's NFS implements it. Saturn's doesn't.

[philipj]

It's a bit related and not related at the same time I just ran into this old commercial concerning the "S.T.U.N.Runner" arcade hardware. At the moment I'm just posting for kicks; I thought about this post when I saw this. The arcade used 2 TMS DSP processors for "Hard Drivin" simulator/arcade... The commercial highlights the "TMS 34010", which I thought was very interesting worth posting.

 

http://www.system16.com/hardware.php?id=770

 

[VladR]

I know you first asked for non-PS1 games but maybe one of these can be useful to you:

 

NGEN Racing

 

360: Three Sixty

 

Air Race:

 

Air Race Championship:

 

Thanks, looks like there are quite drastic differences in richness of the physics implementation even on PS1, where clearly the HW performance is not a problem (as it is on jag). I'm definitely not going to do camera roll and 3-axis physics for this game. I could justify such development for next game, though.

 

Episode 1 Racer?

 

Yeah, I actually bought remaster of that one recently on PS4 (or I think it was that one, it was a star wars racer, so highly likely this one). It's definitely an overkill game, in terms of features.

 

Saturn's racing library is actually pretty thin; especially if you remove the cheap PS1 ports.

Wipeout was popular but on the PS1 for the most part.

My greatest disappointment with Saturn's library is that I played all its great games already on PC, and in higher resolution and overall visual quality, so for me - no point in revisiting them on Saturn.

 

I really found only about 2 games in that vid covering whole saturn's library that were interesting and I haven't already played them on PC.

[VladR]

 

Scorcher was made by the people who did the famous 32X demo for the Sega genesis add-on module...

 

ZYRINX 32X Demo Video

 

I played the Scorcher on PC when it was released and in high resolution. I actually own it on Saturn, but am largely disappointed by its abysmal framerate. Clearly whoever wrote it for Saturn didn't spend any time on optimization, as there's nowhere near as many texels as to warrant the brutal framerate drops. Must have been a pretty hasted release...

 

I'm really glad I enjoyed Scorcher on PC.

 

 

Here's a video of "Wipeout" for the PS1 the tracks meets the limits of draw distances; the scenes fully rendered enough to not dissipate within distance. Well... There's a little polygon dissipation, but just barely.

The 3D engine can only go so far. You really have to pair with great level design to max out the visuals.

 

What you're describing is pretty standard level design trick of those times - you just keep flipping curves so that the polygons at the end of the curve that suddenly jump into the view are covered by the inner side's polygons of the curve/tunnel.

 

It just so happens, that it also makes for a more interesting track, than a simple straight, so it works out just fine (as far as limitations go)...

 

Wipeout XL on the PS1 (along with Need for Speed, and Crash Bandicoot) really let me know I had entered the next-generation of gaming when both my Jag+CD and PSX were new.

For what it's worth, the technological jump to implement [once this is done and released on cart] something like Wipeout (outside of texturing) is minimal - 3-axis physics and camera roll, as the basic combat and racing will be there already. But, I'd personally go for a formula racing game after this, not another scifi setting. That's still far, though - I have at the very least another 2 months of work ahead of me...

[VladR]

There are some different ways to try to hide the limited draw distance depending on the hardware and software engine you're running the game.

If you compare 3DO's NFS to Saturn's, you'll notice that 3DO's far view is mostly composed by a static image instead of draw in polygons. PS1 version adds a lighting variance to smooth out the draw distance limitations.

Saturn's Daytona USA CCE forces a track scrolling speed reduction to keep both draw distance and frame rate stable. PS1's Formula 1 97 lets you choose if you want to lock frame rate or draw distance.

I already have dynamic LOD scheme working. I could make it a graphics option and thus up to the player, but given how little performance the distant track takes, it's not really worth it.

 

In an ideal scenario, assuming it won't be too much level design work, I'll definitely shoot for zero polygons jumping into the view.

 

 

IMO one of the main factors in terms of controls/physics/gameplay for games of this genre is if you're able to feel that the ship/vehicle has some weight (and thus inertia) to it or not.

More crude games such as Saturn's Cyber Speedway are weak in such aspect; the vehicle is pushed around too much by any touch or seems to bounce exaggeratedly and abruptly.

The first Wipeout on the PS1 also has full stop on collisions.

 

The more you can avoid things like that and smooth out the collisions' and driver input's impact on the vehicle, the better IMO.

The more polished games seem to go in this direction.

Yes, I currently have the weight and inertia physics. I have couple presets - from the ultra-twitchy to a slow tank, and few in between.

The collisions are currently a simple boundary check, but once I import the track from 3dsmax, I will discover what needs to be implemented, based on how the game controls and plays. Can't do much before, unfortunately...

 

Also, there's going to have to be some kind of feature/technology compromise - I can't spend 3-6 months full-time working on physics and tweaking it, as those teams did in past.

 

 

 

The design documents for the original Wipeout on PS1 can be found here:

 

https://www.eurogamer.net/articles/2015-10-01-the-original-wipeout-design-document-revealed

Never saw that one before. I'll go check it out during weekend. It might definitely come in handy in my current stage of development. I'll let you know. Thanks!

[Lost Dragon]

@ValdR:Saturn Scavenger supposedly built around the 32X tech demo game engine, converted to Saturn hardware.

 

Coding team were:

 

Main programming: David Guldbrandsen+Karsten Huidberg

Main graphics: Mikael Balle

Music + sfx: Jesper Kyd

System programming: Jens Bo Albretsen

Mathematics: Sami Badawi

Additional gfx: Jacob Andersen + Sami Badawi

[VladR]

I suspect they only had the time to get the high-level C code working and never got to assembler optimizations.

 

Saturn was amazing in that regard - fully working C compiler, allowing devs to target specific SH just via compiler switch. HW support for texturing - 3D coding on Saturn is breeze, but it doesn't matter in the end, if you're not given enough time to optimize...

 

Of course, from business perspective, it's amazing - you can get a basic 3D engine with rudimentary clipping running in 2 weeks, so the development is much cheaper. Art assets still cost roughly the same, though...

[+Gemintronic]

Ever thought of using RAPTOR Basic+ to speed up development VladR? Seems to me you could focus on gameplay rather than technical issues that way.

[tschak909]

At the risk of speaking for VladR: It seems from the get-go, this has been a technical exercise, to see just how much juice can be squeezed from the Jaguar. It's been proven, even just counting through the course of this thread, that the Jaguar's hardware architecture is woefully underutilized by most of its games (for far too many viable reasons), and so it seems that this whole thing is an exploratory exercise with the side-effect of maybe producing a game.

 

-Thom

[VladR]

Ever thought of using RAPTOR Basic+ to speed up development VladR? Seems to me you could focus on gameplay rather than technical issues that way.

 

Well, first of all, I have written my own VR Basic compiler (about 3-5 yrs ago), that I'll eventually link with my 3D engine (very long-term goal). And I could do it even now, if speed of dev was critical, and just bash out the menus, physics, HUD, gameplay in high-level Basic that would get compiled to relatively fast 68000 code.

 

Second, there's no way raptor can remotely allow the level of control over the timings and parallelism between gpu, dsp, 68000 and blitter that I have in assembler. I could make some required changes to my VRBasic backend that would allow me this fine-tuned timing and multithreaded synchronization from the VRBasic, but there will be time for that later.

Don't forget I need full 4 KB of GPU cache.

 

Third, and this is the most important part - I need to be able to say that I was crazy enough to have coded whole engine and game in pure assembler in my free time

 

 

 

It is, indeed, extremely time-consuming to code all that non-essential functionality in assembler. Many times the C code would be done in half an hour, but may take half day or more to get working in 68000 (if it needs debugging and doesn't work right upon first write). Many times I scrap the working code and rewrite from scratch to gain 8 cycles per inner loop

But, my debugging functionality has improved substantially over last 2 months, as well as actual 68000 skills.

 

There is an upside to this - there's no way all that C code would run at 60 fps, as I spent a lot of effort in past, doing 3D from C (the H.E.R.O. engine), so I know exactly what is the performance limit of C.

Of course, it remains to be seen if the final game will run at 60 fps, as the art design will dictate final performance.

 

The 3D complexity of Stunrunner can, indeed, run around 60 fps. But, the track that I recently modelled in 3dsmax, well - we'll see

But, if I won't be willing to compromise on the art design, I will at least provide option for high/low detail so that player can choose for himself...