Jump to content
IGNORED

Road Rash pre-alpha on Jaguar at 30 fps


VladR

Recommended Posts

Sorry for late reply, I meant to reply right away, but was busy coding.

 

I cant speak from a technical point of view, since i dont have the knowledge, but i was never blown away by Crash and Burn. Sure, it looks pretty with its big prerendered cars and the impressve draw distance, but the engine feels very limited, even more so than Road Rash, let alone Need for Speed.

I guess I can't really look at the games anymore just from the gamer standpoint. I always, instantly, break down the scene to wireframe, point cloud, shaders, particles, and algorithms chosen to handle the scene complexity. So, it's interesting to hear that C&B's engine feels limited, from a gamer standpoint.

 

Also NFS has about as good draw distance as Crash and Burn, and is doing a whole lot more, no comparison.I get the feeling of more freedom of movement on 3d space, on the Jaguars F1 World Tour, than any of those 3DO games. The tradeofff is the frame rate, i guess.

NFS has nowehere near as good a draw distance. It's masking it masterfully by adjusting vertical position of the background bitmap (so you can suddenly see the lowest parts of it, and adjusts yaw/pitch/roll of the camera accordingly to enhance the effect), but it just does not have those polygons in the distance. Trust me, I can see the wireframe in the distance from the way texels pop.

 

In each track, I'm talking about PC version, there are select few points in Alpine, where you can roughly see to about the 50% of the distance of C&B, but each of those sections absolutely kills the framerate. I clearly remember framerate falling down to below 10 fps on my PC at the time, and almost always messing the time records, as one of them happened in the middle of a long jump and took 2 seconds of flying to figure out if your car will spin or if you actually made it, in that horrible framerate.

 

In short, NFS criminally failed to handle the drawing distance. That's one of the reasons why I over-appreciate C&B engine's achievements. In NFS, it was an occasional level design feature, that just screwed up the gameplay.

But in C&B:

- it works 100% of the time

- at easily double the drawing distance (of those select few spots in NFS)

- it has some pretty crazy level-design ideas

 

I did notice, from YT, that NFS on 3DO has basically different tracks. They reused majority of art assets, but looks like they built new tracks for 3DO.

 

 

Well, NFS is a corridor, just like plenty modern FPS games. It's not a generic 3D engine where you could drive wherever you want, as the engine is set-up differently. F1 has to be a generic 3D free-roaming engine, but NFS is just a corridor, so it does not have to do view frustum calculations each frame, as it knows exactly what polygons it's going through, and all those can be preprocessed into chunks, offline (or during loading). It's just a 3D illusion, basically.

 

I have read in the past that all those 3DO games i mentioned, are dependant on some sort of spooling from the CD to achieve its performance, while Jag racers use more "traditional" 3d engines, which i guess are more demanding. This is an example of the 3DO doing a more traditional 3d engine, F1 GP:

That spooling is simply splitting the track into chunks, and for each chunk, creating a list of polygons that player can see.

It's still 3D polygons that are being rendered, by the 3D engine, yes. Basically, whatever the rasterizer function needs, it's all preprocessed, and the engine "only" rasterizes the list of polygons and 2D bitmaps.

But, the engine could not handle if you turn around. That's why there were always those invisible air barriers that you hit, so that the illusion is not broken.

 

 

 

When you have cars on screen, its not that diferent performance wise, when compared with the Jags F1 World Tour. Even the fabled 3DOs texture mapping had to be greatly reduced compared with the other 3DO racers in order to mantain the not so good frame rate.

Do you happen to remember the framerate of C&B ? Was it locked, or did it jump up/down during gameplay, depending on where you were in the track ? This is almost impossible to guess from YT video, so I'm curious how they handled that.

Link to comment
Share on other sites

I've played CnB extensively. Here's my 2 cents

 

So, it's interesting to hear that C&B's engine feels limited, from a gamer standpoint.


This was one of the first home console polygon racing games, and perhaps the first that the CnB dev's worked on. Despite the 3D environment, the actual gameplay is pretty much identical to the 2d scanline racing games such as Outrun (or Road Rash) - you can move forward and left and right, but it feels more like you are strafing left and right as in Outrun as opposed to turning and feeling like you are actually changing where the front of the car is pointing, as in a game like NFS. Your pre-rendered car always points forward, again, like Outrun. Naturally this gameplay also lent itself to the relatively fixed camera/fixed view area, which allowed the dev's to determine what geometry should be rendered for anyone's drive down the track, and have that data on the disc to be read to ease the computational load.

 

Do you happen to remember the framerate of C&B ? Was it locked, or did it jump up/down during gameplay, depending on where you were in the track ? This is almost impossible to guess from YT video, so I'm curious how they handled that.


I would say it almost always felt to me as if it was a steady 20 or so FPS on the real hardware and it did not vary regardless of whether you were in a tunnel and had limited geometry on screen or looking down a hill and having tons of geometry in view. There was one exception to this, where I noticed a particular point on a particular track caused the game to start stuttering and get choppy, and that same spot on the same track regularly caused that issue, but this was like 1 out of 35 tracks in the game and in this day and age, it could perhaps also have been a fingerprint on my CnB disc interfering with reading the spooled data or my 25 year old 3DO laser failing ;)

Edited by sirlynxalot
  • Like 1
Link to comment
Share on other sites

Here's a short video showing wireframe of the LOD on the terrain (camera only moves up and down unfortunately right now).

 

I need to fix line-drawing clipping bug, so it can handle fly-through forward, but I needed that functionality for debugging long time ago anyway, so I might as well do it now.

 

The Wireframe and LOD takes 0.55 of frame time currently, so I'm still at 60 fps (despite processing 1,024 triangles per frame), obviously (after all - it's just few lines, eh).

 

I estimate that texturing will eat at least another vblank or two (e.g. framerate of 30 fps or 20 fps), depending on number of pixels drawn. It would be great if flatshading could keep it at 60 fps, but I doubt I can flatshade it under 0.45 of frame time. if the track wasn't full-screen width (or more), it could be possible, though. I'll get to it, once I fix the wireframe (I need it as generic as possible).

 

 

Link to comment
Share on other sites

So now that you're learning GPU ASM do you think someday you'd be able to create your own HVS style GPU manager?

 

And have you tried the GPU tool JWARN yet?

I'm at 2.5 KB right now, so inevitably, it's going to have to happen very soon. I should be able to fit there terrain texturing too (under 4 KB), hopefully.

 

All terrain data is being hauled from main memory right now, so it's really just the code [in cache] at the moment.

 

Few days ago I have greatly reduced the code size for line rasterizing (among other things), but I've obviously broken the clipping (you can see few glitches in video), so gotta look into that.

 

What's JWARN ?

Link to comment
Share on other sites

- I've fixed the culling bug, so a fly-through is now possible
- I've overriden a LOD (the computations are still happening for each and every vertex, they're just ignored), just to see what processing 1,024 polygons and drawing 1,024 lines will do with the framerate
- It's taking 1.15 of a frame, so it almost did it at 60 fps
- right now, I locked it to 30 fps (but 85% of second frame time is idle)
- turning off rasterizing the lines (I only have a slow, reference rasterizer for lines right now, computing a lot, regardless if it's 1 pixel or 100 pixels long) results in whole terrain processing + transformations taking 255 out of 500 frames - meaning quite a surprising lot of processing can be happening, even for crazy-large (for jaguar) datasets

 

Here's the video of the fly-through over 1,024 terrain polygons:

 

 

Now, if we combined both GPU&DSP for 3D processing, that could result in some really complex 3D scenes on Jag...

 

 

BTW, I just played Hasbro's Risk on PS4, and they're using wireframe graphics for all land/air machinery, so it's not really a complete stretch, to use the wireframe, in a game...

  • Like 1
Link to comment
Share on other sites

I've played CnB extensively. Here's my 2 cents

 

 

 

This was one of the first home console polygon racing games, and perhaps the first that the CnB dev's worked on. Despite the 3D environment, the actual gameplay is pretty much identical to the 2d scanline racing games such as Outrun (or Road Rash) - you can move forward and left and right, but it feels more like you are strafing left and right as in Outrun as opposed to turning and feeling like you are actually changing where the front of the car is pointing, as in a game like NFS. Your pre-rendered car always points forward, again, like Outrun. Naturally this gameplay also lent itself to the relatively fixed camera/fixed view area, which allowed the dev's to determine what geometry should be rendered for anyone's drive down the track, and have that data on the disc to be read to ease the computational load.

 

 

 

 

I would say it almost always felt to me as if it was a steady 20 or so FPS on the real hardware and it did not vary regardless of whether you were in a tunnel and had limited geometry on screen or looking down a hill and having tons of geometry in view. There was one exception to this, where I noticed a particular point on a particular track caused the game to start stuttering and get choppy, and that same spot on the same track regularly caused that issue, but this was like 1 out of 35 tracks in the game and in this day and age, it could perhaps also have been a fingerprint on my CnB disc interfering with reading the spooled data or my 25 year old 3DO laser failing ;)

 

Thanks a lot for the summary. I'm surprised they fixed the framerate, as during that era, everybody was just squeezing each and every single frame from the consoles. Personally, I prefer locked framerate in driving games, as it's just awful, if framerate jumps all around the place - e.g. I'd rather have 20 fps locked (but never less), as you can get used to it, compared to experiencing 4 different framerates in a span of, say, 10 seconds.

  • Like 1
Link to comment
Share on other sites

And there was a pretty cool looking wireframe mode as a secret in Wipeout 2097 on Saturn

I've seen Rez, but that Wipeout Wireframe looks just absolutely stunning !

 

I'm afraid, that on Jag, we'd have to combine both DSP and GPU, for a Wipeout- but it's not such a super-crazy stretch anymore, as I would have thought, say, 2 weeks ago.

A wireframe would be in playable framerate for sure :)

  • Like 1
Link to comment
Share on other sites

And there was a pretty cool looking wireframe mode as a secret in Wipeout 2097 on Saturn

 

Sir, I have to officially thank you for this link :)

 

I was rewatching it for 5th time, while drinking coffee, and then it hit me, how exactly Wipeout is cheating.

 

There's huge amounts of triangle set-up, line set-up and 3D transform set-up code chunks (quite a few pages of code per each vertex!) that could be entirely avoided by using the WipeOut Cheat (I just named it :) )

I've tested the idea on 2 polygons by quickly bypassing the code above (and interpolating appropriately) and it actually works!

 

 

I don't have the scene benchmark numbers, as I'd need some proper WipeOut track 3D data. I'll see about creating few rooms and chaining them together tomorrow. I also made sure it's generic enough for any type of polygon orientation, I tested it on skewed rotated polygon whose edges were shaped in all kinds of angles - so it's going to work nicely in a generic form (not just vertical or horizontal walls - like in RoadRash).

 

And while the bandwidth cost of rasterizing the wireframe can't really be avoided, this should still raise the scene complexity and vertex density significantly.

 

I wouldn't have gotten this idea today, if you didn't provide me with this link, so let me give credit where credit is due ;)

Link to comment
Share on other sites

for now the engine you made is relatively easy, until you get to the 3D clipping part, that was always my main problem with 3D engine, once the coordinates goes behind the camera, fixed point math always goes bananas ...

 

in your first post you say "- World Frustum culling / - Polygon clipping", I can't see any of these on your videos

expect if "clipping" for you means "if coordinate < 0 -> wipe out the entire polygon"

 

about Wipeout, it's not cheating ... that's the 3D engine job to optimize the geometry so you have the minimal amount of math to do on low end machine

Edited by Orion_
  • Like 5
Link to comment
Share on other sites

for now the engine you made is relatively easy, until you get to the 3D clipping part, that was always my main problem with 3D engine, once the coordinates goes behind the camera, fixed point math always goes bananas ...

 

in your first post you say "- World Frustum culling / - Polygon clipping", I can't see any of these on your videos

expect if "clipping" for you means "if coordinate < 0 -> wipe out the entire polygon"

 

about Wipeout, it's not cheating ... that's the 3D engine job to optimize the geometry so you have the minimal amount of math to do on low end machine

Of course the fixed-point math goes 'bananas' once stuff is behind camera. It's the nature of the used formulas. If I didn't handle that particular glitch, you'd see lots of skewed geometry on screen, once it passes the camera. Since those glitches are not present in the videos, I am handling it at run-time - hence they are culled (obviously).

 

Like I said earlier, only the RR's road and building rasterizer have per-pixel culling. However, since the precision of integer world-space coordinates is what it is, the objects near camera disappear fast. This is fixed for road polygons, but not for buildings-yet- as I am getting distracted with terrain and other stuff.

 

But it's a good distraction, as:

- it gives me much better understanding what jag can pull off,3D-wise.

- I'm constantly generalizing currently-working and new functionality

 

Cheating in 3D is OK, that's the only way we can display complex scenes on low-end machines like jag. But the WipeOut cheat is quite astonishing, honestly.

Link to comment
Share on other sites

I've partially implemented the idea behind the WipeOut cheat and here's the result:

 

- I've experimented a bit with the polygon distribution and spaced it more evenly (compared to the terrain)
- The result is a WipeOut - resembling small track segment (repeated endlessly). Only one, as I couldn't be bothered to "design" more complex track in a notepad (but it could be relatively easily done), as the engine is reading segment data from an array
- there's always between 2,048-2,304 triangles in the view (8-9 segments)
- the framerate is locked to stable 60 fps
- there's a very simple color rotation effect (not the palette, the actual rendered colors get rotated)

- video is obviously shot only at 30 fps, as that's what the capturing device handles

- this is a separate codepath, so it doesn't break into the RR stuff

 

 

Turns out, the jag can process quite astonishing number of triangles. If we locked it to 30 fps, the polycount could be more than doubled to 4,096-5,120 per frame. That's quite a crazy amount for such an old machine.

And if I could be bothered to at least slightly optimize the current engine, that number could go way higher, but the wireframe is even now almost resembling the flatshading on good portion of screen : ))))

  • Like 7
Link to comment
Share on other sites

24fps locked on an actual game sounds fine to me.

But you can't get 24 fps locked (not without tearing). Neither on NTSC or PAL. The closest you could get to that is 25 fps lock on PAL.

 

Here are the numbers, when you lock the framerate:

NTSC:

60 : 1 vblank

30 : 2 vblanks

20 : 3 vblanks

15 : 4 vblanks

12 : 5 vblanks

10 : 6 vblanks

...

 

PAL:

50 : 1 vblank

25 : 2 vblanks

16: 3 vblanks

12: 4 vblanks

10: 5 vblanks

...

 

 

It would be interesting to see, how much would have to be sacrificed to keep it running at just under 2 vblanks on PAL, but that is entirely theoretical at this point. We can revisit it, when there's all major elements integrated (2D props, terrain, enemies).

  • Like 1
Link to comment
Share on other sites

The Jaguar can handle (rotate & transform) a quite big poly count the problem is when you try to render it.

Sure, but the memory bandwidth is a problem on every single gaming machine and graphics card under the sun. We're still trying to get enough bandwidth on PC to get smooth framerate in a slightly higher resolution than we had available 15 years ago. And there were how many generations of those cards since ? 20+ by now ? So, Jag is really no exception here, despite the fact that everybody blames its HW design.

 

But why the hell haven't we seen that the jag can do this before ? We're not talking about years of months of effort. Not even weeks. Once I started working in GPU, it quite literally took few days of an effort ! So, the usual excuse of 'Oh, Atari screwed us big time' does not really work here. Why can't space games have big, rotating wireframe maps with lots of polygons or a space tunnel like this ? And there are easily dozens of other applications for games.

 

Yes, I know from my benchmarking, that it's going to take another 2 vblanks to texture those polygons, so the framerate will drop to 15-20 (which, btw, at least to me seems like a norm on that generation of HW), but there's not a single jag video that I know of that someone even tried - and that's my point here.

  • Like 2
Link to comment
Share on other sites

Thinking about it some more, the ideal racing game, that is tailored to jag's full HW potential is a 2D/3D combo:

- Road is 2D (scanline) done on OP/Blitter at 60 fps

- Side objects are also 2D (mipmaps in memory), so framerate is not impacted and still hovers at 60 fps

- Cars are 3D, so with multiple 3D cars, jag's potential is properly used. Cars (rendered to a bitmap that the OP pushes to screen) don't have to be refreshed 60 times per second, so the fillrate cost of filling the polygons is basically irrelevant. The OP still renders the car bitmap 60 times per second (updating xp,yp of car bitmap is almost free anyway), but the bitmap is exchanged with the new one only when GPU is done rendering all cars. If it takes 3 vblanks, it takes 3 vblanks. I seriously doubt anybody could even see the difference, as the cars usually move only couple pixels per second, and barely change more than couple degrees of the angle.

 

Does anybody know of a game on some other platform that has 2D track, yet 3D cars ?

Link to comment
Share on other sites

Sure, but the memory bandwidth is a problem on every single gaming machine and graphics card under the sun. We're still trying to get enough bandwidth on PC to get smooth framerate in a slightly higher resolution than we had available 15 years ago. And there were how many generations of those cards since ? 20+ by now ? So, Jag is really no exception here, despite the fact that everybody blames its HW design.

 

But why the hell haven't we seen that the jag can do this before ? We're not talking about years of months of effort. Not even weeks. Once I started working in GPU, it quite literally took few days of an effort ! So, the usual excuse of 'Oh, Atari screwed us big time' does not really work here. Why can't space games have big, rotating wireframe maps with lots of polygons or a space tunnel like this ? And there are easily dozens of other applications for games.

 

Yes, I know from my benchmarking, that it's going to take another 2 vblanks to texture those polygons, so the framerate will drop to 15-20 (which, btw, at least to me seems like a norm on that generation of HW), but there's not a single jag video that I know of that someone even tried - and that's my point here.

There is a reason for your madness! :P

Link to comment
Share on other sites

Yes, gale racer on sega saturn which is a slightly updated version of the fully 2d arcade game rad racer. Also megarace 2 on pc has real time 3d cars driving on a pre rendered fmv video of a track. It looked very impressive at the time.

Megarace 2 looked absolutely incredibly next-gen for the time. I'll never forget the Tibet track, where you drove under that tree with high-detailed foliage. I think it took well over a decade and a half till NFS could render something like that in real-time (I believe NFS 6 was the first that achieved something similar).

 

Gale Racer is a great find! Reminds me of Atari 800's Great American Country-Cross Race (driving from West to East coast via various routes). Although it uses polygon cars, the track is done using the sprites (like in Afterburner), so that's a very weird design choice, considering Saturn had something like 8 processors, they could have kept sprites for props and have at least a proper scanline track, as the current one has - expectedly- horrendous drawing distance (like, 20 meters - the cars just pop right in front of you).

 

On the topic of drawing distance - in your opinion - which game of that era, that was scanline/sprite-based (e.g. not NFS / CrashnBurn), had biggest drawing distance ?

 

And did any racing game, ever, had higher resolution ? Because jag could most certainly pull off the scanline road in at least double resolution (e.g. 640x240x256), as if the implementation is OP-based, it's merely using the available bandwidth of the system (rather than being dependant how fast you can texture the pixels, be it on GPU, Blitter or 68k), of which there is plenty for 2D (especially if it's just 256 colors).

Link to comment
Share on other sites

This is, as always, an interesting academic read. I have a simple question though that requires a single word answer (not even a paragraph or essay).

 

Do you plan on releasing one or more actual games in the not too distant future? y/n

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...