Road Rash pre-alpha on Jaguar at 30 fps

[+Sauron]

VladR, how about you stop arguing with people and get to coding? Seeing some results would shut everyone up.

[VladR]

yes but we are talking about roadrash, and there is not a single inch of cameramovement or cameraturn or whatever. in best case there is a zoom at finish, and that is also no problem for 2d scanline .. (see link below)

 

False, on case perspective look here: http://codeincomplete.com/games/racer/v4-final/

and by the way.. wher did 3DO roadrash change perspective???

 

however, i just wanted to tell you that they did the same on RR 3DO and save you from braking your brain on this topic

 

and for sure, a 2D scanline racer got some "values" that you can convert / align to some texture dimension think about it.

would be a much more easy way to add/sync a 50% "3D textured" object over/to the "2D scanline" object / engine.

 

some basic housealignment, some hills/mountains, and as the crown of 3d a tunnel

thats all of the RR 3DO 3d texture science, sorry if that sound disappointing, but everything else is 2D scanline.

 

the preferences of RR3DO are (graphic and game) design, speed, gameplay, sound, presentation and not its eyewash visuals

 

get it as hint

 

ps.: drTypo seems to be a specialist for affine perspective (gemrace, fallen angels, tubeSE) on the Jag, he could maybe help you on this topics

Actually, I was watching a wrong youtube video (different platform)! Damn!

 

You are correct ! 3DO's RR's road is completely scanline! Not a single 3D angle adjustment! And while at NFS, you can clearly see the polygonal curvature of the road, in the 3DO's RR, the road is pixel-smooth curved. The hills go up/down, curves turn left/right exactly like in any other scanline-based racing game.

 

I guess that for a RR prototype, I can go and save about half of a vblank and just let OP render the scanlines, I need to reimplement that (I have it in my C code from last year's prototype) under GPU, but that should not take too long.

 

It's certainly going to improve the final performance, as the only 2 things that are 3D will be the buildings and terrain. And that terrain in 3DO's RR is not exactly fully 3D either, and is not really rerasterizing all terrain polygons each frame either...

[VladR]

VladR, how about you stop arguing with people and get to coding? Seeing some results would shut everyone up.

I didn't realize I was arguing. My apologies.

I'm back to coding now

[Otto1980]

You are correct ! 3DO's RR's road is completely scanline! Not a single 3D angle adjustment! And while at NFS, you can clearly see the polygonal curvature of the road, in the 3DO's RR, the road is pixel-smooth curved. The hills go up/down, curves turn left/right exactly like in any other scanline-based racing game.

 

yes.. i also think is basical the "old" roadrash with some 3d objects on the side plus the graphics are replaces by digitised trees, cars, bikers... what ever.

the typical eyewashing of that time

 

however the result is looking and feeling good

by the way i think crash n burn uses the same tech (2d scan + 3d sideobjects)

 

what i wanted to say: if you handle to align some 3d environment (in sum max up to 50% of screen) attached to the 2d scanline engine, you are the man!! you did it!!

the holy jag roadrash coder :-DDDDD

i will errect a small shrine in my basement

[+madman]

Not to get OT, but here is how Crash N Burn was done: https://groups.google.com/forum/#!topic/rec.games.video.advocacy/Jojzp1BxduQ

[Otto1980]

Watch at 1:30 ..

There you can See it clearly

 

https://youtu.be/Pq33jkRbzX0

[sirlynxalot]

Not to get OT, but here is how Crash N Burn was done: https://groups.google.com/forum/#!topic/rec.games.video.advocacy/Jojzp1BxduQ

Thank you! Not only was this a very entertaining read to get a sense of the 3DO - Jaguar rivalry from the early adopters in that 1994 thread, but it satisfies the ultimate question many people have, about whether Crash n Burn was rendering polygons or was a pre-rendered FMV like Megarace. I've always been in the "rendering polygons" camp because you can shift the camera slightly and see different angles of the scenery, but that's not sufficient proof for some folks. Needless to say, this game probably has one of the furthest draw distances outside of the dreamcast/PS2/Xbox generation, pretty epic for the time (1993).

[JagChris]

Good catch Otto

[LianneJaguar64]

Impressive! That's all I can really say, I'm not technical minded enough to have a proper contribution

[VladR]

Thank you! Not only was this a very entertaining read to get a sense of the 3DO - Jaguar rivalry from the early adopters in that 1994 thread, but it satisfies the ultimate question many people have, about whether Crash n Burn was rendering polygons or was a pre-rendered FMV like Megarace. I've always been in the "rendering polygons" camp because you can shift the camera slightly and see different angles of the scenery, but that's not sufficient proof for some folks. Needless to say, this game probably has one of the furthest draw distances outside of the dreamcast/PS2/Xbox generation, pretty epic for the time (1993).

I never heard of Crash n Burn (despite having watched several "best of 3DO" videos in past), so I became curious about its drawing distance, that you mentioned, and it's actually absolutely insane! I cannot believe 3DO pulled off something like this ! The framerate looks like it's only around 15, occasionally 20 fps (e.g. 60/15 = 4 vblanks per frame), but the engine is absolutely amazing. I watched and rewatched the HD YT footage 10 times and there was zero level-of-detail popping. Either they have a crazy high-quality threshold for the LOD pop, or the 3DO actually pulls it off in brute force without LOD scheme!

 

This is, like, a generational HW difference to NFS (even though NFS's environment may look visually nicer), and, like two generations to a simplistic scanline RoadRash. I'm floored.

 

Screw it, I'm going back to the drawing board with my heightmap rasterizer. It's roughly working already, but I just got an engine idea from watching Crash n Burn's terrain that I really need to implement, like right now. Obviously, jag can't remotely handle drawing distance like this, but I sure as hell wanna try...

[sd32]

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.

 

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.

 

By the way, Crash and Burn engine is the same one used on later Crystal Dynamics games, like Total Eclipese and Off World Interceptor, right?

 

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:

 

https://www.youtube.com/watch?v=YqbVfkTmqbA

 

 

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.

Edited January 19, 2017 by sd32

[JagChris]

Yeah I believe what is impressing Vlad is spooled graphics. I remember that too.

 

Vlad read down. The developer talks about doing that right there.

Edited January 19, 2017 by JagChris

[sirlynxalot]

Relevant quote from the CnB thread:

 

The entire track is still in memory. The track consists of tons-o-polygons.

Far too many for any machine to display in real-time. On part of displaying
something in 3D is figuring out which parts you can see and which parts you
can't. For example, if you are driving down a race track and you are
looking forward you can't see behind you therefore you don't want to draw
the stuff behind you on the screen. So, you do some math to tell you what
parts of your 3D world you can actually see. This takes alot of time. In
fact it is probably this single biggest problem with anything that works in
3D. All programs deal with this in different ways. Flight Simulator does
it while it's running. It keeps a list of all the things you can see and as
you fly around it adds or removes things. To see it in action, fly in skew
mode and skew really fast and then stop. You will see different 3D parts
pop in one at a time as the program finds new things that are now in your
view.

On CnB we wrote a program that would 'drive' down the track and for each
section of the track it makes a list of all the parts that can actually be
seen. These 'lists of visible parts' are then stored in the CD and as you
drive down the track the 'list' for the part of the track you are currently
on is loaded. This makes it run faster because we don't have to do all the
calculations for which things are visible while you are racing.

[JagChris]

Yeah he doesn't read links or docs. He went and saw a c&b video and ran off half cocked.

[+CyranoJ]

Yeah he doesn't read links or docs. He went and saw a c&b video and ran off half cocked.

 

Now, now - don't be like that.

 

I'm interested to see where this goes, to be honest. Carry on, Vladr.

[phoenixdownita]

 

Now, now - don't be like that.

 

I'm interested to see where this goes, to be honest. Carry on, Vladr.

Given the previous rounds ... I believe it's gonna be another pre-alpha prototype of something that is not a full game but that would teach him some new tricks to incorporate in HERO 3D-ish, the engine not the game.

 

I know I am not been too positive and Vlad is indeed coding so there's that but it seems he's once more keen on chasing the new squirrel passing by than get something more concrete and stable and complete and actually build a game out of it .... but what do I know I don't code 3D engines.

[VladR]

Yeah he doesn't read links or docs.

Yeah, I didn't understand your "read down" comment yesterday, but today I noticed that there was a full thread on that google site and am reading it now (will finish after breakfast).

 

 

He went and saw a c&b video and ran off half cocked.

But, we're talking pure tech-porn here, dude ! There's no distracting 2D visual fluff (ala NFS / RR) hiding 3D (or 2D scanline) artifacts - like bitmaps of cows, birds, humans, buildings and especially trees, covering half of the screen (and a terrain).

 

It's just a 3D track and a terrain. But what an incredible drawing distance (given the HW platform)! I understand it does not look that way from player's point of view, but for a 3D-engine coder, this is like equivalent of Gears Of War running on, say, PS1. I'm like - how the hell did they pull this one off ?!? That's one hell-of-a genius coder who wrote this, and I don't believe I used that phrase more than 2-3 times in my life.

 

 

Now, as for my yesterday's experiment, I had to modify all components that load, pre-process, create and store 3D vertices, as I initially [obviously] wasn't targeting this amount of polygons, so all components had to be generalized, which unfortunately slowed them a bit down, as I could not use binary shortcuts anymore (as when the vertex array size was 64 or 128).

Then I had to modify the perspective calculations to get all vertices on screen, even though I'm only at point-cloud at this moment (wireframe will be next).

 

I was targeting that track segment from CnB that has this insane tall hill and 90-degree turn left into the tunnel. I believe I got the full hill, that at default camera settings, when you are its bottom, reaches to the top of the screen. I'm at 1,024 (!!!) polygons already. And that's half (or even less) of what's actually visible in C&B, when you are at the bottom of the hill !

 

So, my current estimate, for the C&B scene above, is 2,048 - 4,096 polygons of a source polygon mesh, to get appropriate distance. It's not surprising to me, I expected a similarly ridiculous number, and that's exactly why I was so excited seeing that YT video.

 

Now, a proper LOD (Level-of-detail) scheme can bring this number easily down to something like 200-300, which is renderable on jag at real-time. I implemented that several times in past on PC, XBOX and WindowsPhone. However, that was in C, C++ or C#. Never a low-level RISC assembler. This would easily take weeks (but, full-time coding weeks!), and as such is incredibly risky, that it won't be ever finished.

Also, the slowest CPU, I implemented that terrain LOD scheme on, was, like 650 MHz. We're talking ~30-times slower CPU here, so just an initial thought is - screw it, it just can't work.

 

I'll keep thinking about it bit more. I believe I came up with a different LOD algorithm that will still remove 66% of polygons at distance, but is not so complex to code (as the one I built in past for PC). The trade-off is, that it won't remove as many in the distance as the first algorithm (but is simpler to code).

I just need to be reasonably sure it will work, before I dive into it, so I'm going to spend some time in excel and with pencil&paper.

[VladR]

Given the previous rounds ... I believe it's gonna be another pre-alpha prototype of something that is not a full game but that would teach him some new tricks to incorporate in HERO 3D-ish, the engine not the game.

[sirlynxalot]

Can we get crash n burn on jag? I like that game more than road rash ☺

[VladR]

Can we get crash n burn on jag? I like that game more than road rash ☺

Not a full game, for sure. The best I could be bothered to do is attempt one track. Once it's at level-design category, I'm out.

 

Yesterday, I didn't believe it would be remotely possible on jag. But:

- I just finished with my paper scriblings and some formulas in an excel, on my compromise LOD algo (compared to LODs I implemented in past on XBOX or PC) that might work on jag

- the excel says, I can reduce the current visible dataset of 1,024 triangles into 264 (which is 25.7%) and that's renderable

- the compromise LOD algorithm looks like it's implementable on GPU within a weekend (a key difference to a full-blown LOD that would take weeks), so I'm sure as hell going to try

 

What's questionable at the moment is the performance of the LOD algorithm, and there's only one way to find out : Do the Shit, MF

 

I promise, I'll post benchmarks/video from jag, even if the framerate is horrible.

[VladR]

Turns out I was wrong. Very wrong.

 

Originally, I was estimating it would take me a weekend to implement the LevelOfDetail scheme in an error-prone, tedious GPU Assembler.

 

 

 

 

 

 

 

 

 

 

 

 

Actually, it took me only one afternoon :- )))))))))))))))))))))

Since Firefox crashed on me the third time in a row while trying to attach a screenshot of the hill/terrain, the following numbers will have to be enough:

 

- I am replicating a single piece of 128-polygon terrain (with a rolling hill and a space wide enough for a road in the middle) 8 times, each row of vertices rising with the elevation (to create a long steep hill)

- Total number of triangles is 1,024

- After a LOD algorithm runs, this number drops to 208, so we're talking 5:1 ratio

- the benchmark runs 100 times and it takes 15 frames, e.g. it takes 15/100 = 0.15 of a frame time to:

- 1. decimate the 1,024 polygon set into renderable set of 208 polygons

- 2. do 3D transformations (world,view,projection)

- 3. Screen clipping

- 4. Render the vertices

- So, it's way faster than I thought, despite the fact that I am repeating the LOD calculations per each vertex of the current row.

- The algorithm has a quadratically decreasing complexity, so I estimate that throwing another 1,024 polygons in the distance to the mix would raise the performance cost of 0.15 to about 0.20 of a frame time.

 

I am rendering only the vertices as of now - yes I know it's super cheap to render points, but I gotta implement the terrain polygon rasterizer routine first, so I'll now go and start working on that.

 

 

Since the LOD is so fast, I just realized another thing : this actually means that jag is totally capable of processing a large, Morrowind-style terrain with good visibility (though not the same as on PC, obviously).

Let's say we have a terrain:

- 64x64 = 4,096 chunks (currently loaded area from CD)

- 16x16 = visible set (in view frustum)

- each chunk being 8x8 = 64 vertices (e.g. 8*8*2 = 128 polys)

- Terrain space in RAM is: 512 KB

- total terrain polycount is 524,288 polys

- total maximum visible terrain polycount is : 32,768 (without the LOD scheme)

 

but through LOD level 3 and 4 (I currently have implemented levels 0,1,2), this number can be reduced 16-fold (compared to LOD 2) down to about 400 renderable ones, that should be possible to rasterize on jag at around 15-20 fps (good enough for 3rd person / 1st person RPG game).

 

Don't worry, I'm not gonna hop to RPG, just wanted to do the math on numbers to see if it's remotely possible or not. Because, for a large-scale RPG, the terrain costs are actually the biggest (the enemies could be simple 2D bitmaps on jag, but large terrain is very complex to process at real-time due to the sheer number of data that has to go through the bus each frame).

[JagChris]

Yeah, I didn't understand your "read down" comment yesterday, but today I noticed that there was a full thread on that google site and am reading it now (will finish after breakfast)

 

But, we're talking pure tech-porn here, dude !

I was sorta ribbing you a little.

Sorta. ?

 

Does this mean the RR experiments are being shelved?

 

Alright who mentioned C&B in this thread to VladR? We need the nearest person to wedgie them.

Edited January 20, 2017 by JagChris

[sirlynxalot]

Can we get a mock jag box for cnb made? ☺

 

Vlad, maybe you'd like to change the vehicle sprite in your demos to a cnb car?

 

(Ps, did I mention I like cnb?

[JagChris]

Can we get a mock jag box for cnb made? ☺

 

Vlad, maybe you'd like to change the vehicle sprite in your demos to a cnb car?

 

(Ps, did I mention I like cnb?

PS, you need a wedgie ?

[JagChris]

Turns out I was wrong. Very wrong.

 

Originally, I was estimating it would take me a weekend to implement the LevelOfDetail scheme in an error-prone, tedious GPU Assembler.

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?