Road Rash pre-alpha on Jaguar at 30 fps

[skip]

I think he meant people like sporadic himself and VladR on their free time projects.

Ahh, fair enough. My bad...not enough sleep here

Edited February 1, 2017 by skip

[sd32]

The only problem with WipeOut is that music is kinda an integral part of experience. Unlike , say, NFS, that I played without any music whatsoever, Wipeout experience actually needs great music (which in turn requires a lot of bandwidth). So, for Wipeout, we'd be overloading bus from GPU, DSP, Blitter and 68k. I can't, yet, predict the exact performance impact of that.

 

Yeah, music is a big part of WipOut. Would adding CD suport to your engine bog it down too much. I have heard that using the CD systems cripples the Jaguar even more, due to it getting more restrictive on the use of the 2MB of RAM, and having to waste resources to control the CD unit. And it makes sense even for a non tech guy like me.

 

But judging from games like Iron Soldier 2, Battlemorph, Hoverstrike CD, F1 World Tour Racing, Robinsons Requiem, etc, they perform as good as their cart based counterparts (in cases there are), and actually look better. And now we get CD music and FMV, and storage for a lot more content. Also you save some resources by not having to use the chipset to play music.

 

So in the few examples we got of CD games, i failed to se the penalty for using it, compared to the cart versions. Sure, you can say, that Battle Morph and Hover Strike CD are sequels and engines got improved, but they still were "first generation" CD titles. And there is Iron Soldier 2, the cart game runs no better than the CD versions, and is missing all the benefits of the CD, content-wise.

 

So, is using the CD really that crippling?, do you feel it would cripple your engine as it is right now.

 

Honest doubts from a guy with no technical knowledge.

[VladR]

 

Yeah, music is a big part of WipOut. Would adding CD suport to your engine bog it down too much. I have heard that using the CD systems cripples the Jaguar even more, due to it getting more restrictive on the use of the 2MB of RAM, and having to waste resources to control the CD unit. And it makes sense even for a non tech guy like me.

 

But judging from games like Iron Soldier 2, Battlemorph, Hoverstrike CD, F1 World Tour Racing, Robinsons Requiem, etc, they perform as good as their cart based counterparts (in cases there are), and actually look better. And now we get CD music and FMV, and storage for a lot more content. Also you save some resources by not having to use the chipset to play music.

 

So in the few examples we got of CD games, i failed to se the penalty for using it, compared to the cart versions. Sure, you can say, that Battle Morph and Hover Strike CD are sequels and engines got improved, but they still were "first generation" CD titles. And there is Iron Soldier 2, the cart game runs no better than the CD versions, and is missing all the benefits of the CD, content-wise.

 

So, is using the CD really that crippling?, do you feel it would cripple your engine as it is right now.

 

Honest doubts from a guy with no technical knowledge.

I'm a benchmark guy, and every single routine I write, I note down into my excel sheet how it performs on jag under various loads and parameters (I try to proceduralize each and every one, so it's more generic). I do not have numbers on CD audio as I do not own CD ROM for jag. Hopefully, jag-SD card will be here soon, so that I can design my engine around accessing 4+ GB of storage (you'll need it for large-scale terrain for Bethesda-style RPGs).

 

That being said, the question really boils down to:

Is jag using more bandwidth playing audio tracks from CD-ROM compared to doing audio synthesis via DSP ? The answer will vary based on bus load of each game. 700 MB corresponds to what - 74 minutes of audio ? That's roughly ~150 KB/second, but at CD quality. I'll have to take a look at some of atari's audio code samples, to get a better idea, OK ?

 

As for the buffer, that the audio takes up in memory. Look, even if you sacrificed , say, 0.5 MB of 2 MB. You just design the engine around that. Remove one texture per level, or make the level area slightly smaller - there's plenty places where you can cut and nobody will ever know.

Plus, everybody, conveniently, forgets to mention that the audio you have in your 2 MB binary takes up some space. It may very well take up more than 0.5 MB!

But, on the other hand, for that 0.5 MB, you get access to 700 MB of content. That's a fantastic deal, if you ask me! Suddenly, the visual variability is only limited by your budget - e.g. how many artists can you hire. You got 5 artists ? Fine. You got 20 artists ? Great, we'll just add another CD or two.

 

 

But, if we're talking about wipeout-style game, the last thing you want, is to halt in the middle of the curve for 4 seconds, while the CD is spinning

Slow-paced RPG / FPS ? Sure. Fast-paced racing/shooter - hell no

[Rick Dangerous]

Keep on trucking Vlad the impaler.

 

If road rash ever sees the light of day it will easily be a top ten Jag game. You could even add code/feature so you play your own rad 90's alternative mix in the Jag CD unit.

[MAYAman]

 

He kind of brought it on himself by deciding to call his primitive render tests "Road Rash pre-alpha".

 

LOL by who's judgement? He's trying, he working on a dead system, he is doing what most can't. Cut the guy some slack and be less sensitive.

[VladR]

Keep on trucking Vlad the impaler.

 

If road rash ever sees the light of day it will easily be a top ten Jag game. You could even add code/feature so you play your own rad 90's alternative mix in the Jag CD unit.

ROFLMFAO, I kinda do look like one, actually (been told many times in US), which is strongly enhanced by my thick 'russian' accent : )))))))

 

On a more serious note, while technically possible (e.g. game would load current track data, including music, into RAM) and you could exchange the CD for some audio CD.

 

But who would do that with such an expensive add-on ? Imagine swapping discs, like, 20 times, within an hour (after each new track). You'd destroy that poor plastic unit after couple play sessions. I know, that plenty people will say that it could survive armageddon (and that their fragility is just a myth), but I've broken countless CD-ROM units in my PC during their heyday - they simply weren't built to last half century. And they sure as hell didn't cost a fraction of what jag one costs now...

 

Now, when we have an SD-card available, oh yeah - I can't wait for that...

[JagChris]

 

The only problem with WipeOut is that music is kinda an integral part of experience. Unlike , say, NFS, that I played without any music whatsoever, Wipeout experience actually needs great music (which in turn requires a lot of bandwidth). So, for Wipeout, we'd be overloading bus from GPU, DSP, Blitter and 68k. I can't, yet, predict the exact performance impact of that.

Would it help if the dsp has its own bus for that sorta thing?

 

*On the DSP, the local bus contains SRAM, DSP control regs, math table ROM and some DSP peripherals (everything mapped from F12-F1F). This means the DSP is able to do CD access (at least the serial kind) and audio playback without touching the main bus. Off-chip stuff like joystick access obviously requires external bus cycles, but so do the UART and timers.*

[phoenixdownita]

Are we there yet?

[VladR]

No, because I've been sick as a dog after my root canal last Thursday - somehow I caught a flu at the same time, so nothing got done over the weekend.

 

I did, however, do a bit of refactoring yesterday, as I started to feel a bit better and was able to fit flatshading within 4KB with the Wipeout codepath (without the LOD, though).

Surprisingly, the reference triangle rasterizer worked fine right away.

 

It runs around 55-65 fps, which is very surprising, as it's a reference rasterizer - e.g. the first method that works, but which is very far from being fast. First ones are always the slowest.

 

However, there are few visual glitches due to the culling that needs to be implemented first. If I do rough culling, the flythrough works fine, but is visually unpleasant - hence no video right now. I'd like to have a smooth, per-pixel culling implemented for next video.

 

 

I have to say, I am quite surprised at the amount of important functionality that fits within the 4 KB. I'm pretty sure if I had some 3D data for Wipeout ships, that I could fit them within 4 KB as well, as everything right now has been generalized (e.g. processing list of arbitrary triangles).

 

If one 4 KB block would be for 3D rendering, another 4 KB block could be for gameplay, input, ai. So, a 3D game in 8 KB, basically. Interesting...

[VladR]

- Implemented the reference arbitrary Flatshading triangle rasterizer (will use it later also for terrain)
- Implemented full 2D clipping (so, polygons can now properly cross against all 4 screen edges, with pixel precision)

- Used it on the WipeOut Codepath of the RR codebase (I have multiple ones in the same source, just being commented out of the build as needed)
- Despite this being the first (reference) version, the performance is completely usable for actual game purposes even without further optimizations - currently simply locked to 2 vblanks - e.g. 30 fps
- After some refactoring, the full GPU code (Camera path + FrustumCulling + 3D Transformation + Clipping + Rasterization) still fits within 4 KB

- I noticed I need to tweak the frustrum culling to consider not just front vertices, but back vertices also, so the nearby polygons disappear sooner than they should right now (as I'm checking front vertices, and not the back ones), but this is good enough to share, I reckon

 

 

Looks like I can now go and try the rasterizer on the terrain. Should work the same, basically.

 

Also, this being totally generic version means, I could start importing some arbitrary 3D meshes (cars, objects, characters, etc.) now. Say, create some simple vehicle for Wipeout in 3dsmax, export to ASE, then convert to an indexed vertex list format and just include in the build.

 

 

[+Stephen]

- Implemented the reference arbitrary Flatshading triangle rasterizer (will use it later also for terrain)

- Implemented full 2D clipping (so, polygons can now properly cross against all 4 screen edges, with pixel precision)

- Used it on the WipeOut Codepath of the RR codebase (I have multiple ones in the same source, just being commented out of the build as needed)

- Despite this being the first (reference) version, the performance is completely usable for actual game purposes even without further optimizations - currently simply locked to 2 vblanks - e.g. 30 fps

- After some refactoring, the full GPU code (Camera path + FrustumCulling + 3D Transformation + Clipping + Rasterization) still fits within 4 KB

- I noticed I need to tweak the frustrum culling to consider not just front vertices, but back vertices also, so the nearby polygons disappear sooner than they should right now (as I'm checking front vertices, and not the back ones), but this is good enough to share, I reckon

 

 

Looks like I can now go and try the rasterizer on the terrain. Should work the same, basically.

 

Also, this being totally generic version means, I could start importing some arbitrary 3D meshes (cars, objects, characters, etc.) now. Say, create some simple vehicle for Wipeout in 3dsmax, export to ASE, then convert to an indexed vertex list format and just include in the build.

 

 

That looks really good.

[VladR]

I didn't have much time last weekend, so I only played a bit with optimizations of the flatshader. First change brought 15% of performance. Second one is not finished yet (commented out of the following video's build), but brings additional 10% when finished. I also noticed a spot where I could get another 10-15% (but that's for later).

I had a bit of time during the week, so here's the latest video:

 

 

Played a bit with the Wipeout codepath of my RoadRash engine:
- created 2 new track segments (in code) and looped them
- proper handling of Z-conflicts/draw order (no glitches)
- attached a fixed color to each of quad's triangles
- slightly optimized the flatshader (15% faster)
- framerate is locked to 30 fps now (2 vblanks)

 

 

I think I'd like to experiment a bit more with flatshading and investigate its performance characteristics a bit more. Especially how much detail can we fit into 2 vblanks (30 fps). To me, the 30 fps feels quite smooth (at current movement speed, that is).

I also very much like that there is literally zero pixel disturbance - no shimmering textures or anything - it's just so nice and clean.

 

Also, there's quite a few popular games, with fixed camera angle, that use flatshading (or a variant thereof) and are entirely possible on jag (in adequately reduced polygonal detail) - like : Bit.Trip.Runner, Strider (PS4), Counterspy (PS4).

And while Bit.Trip.Runner is sensitive to framerate jumps, the other 2 platformers, should be plenty playable in 15-20 fps, as their 3D perspective is fixed (save for FPS view of Counterspy) into axis-aligned form, which as we already know from the H.E.R.O., can run at 60 fps. Obviously, H.E.R.O.'s scene complexity and Counterspy are nowhere near, and characters would have to be 2D bitmaps, but Counterspy's environment looks like it can be easily reduced to ~300-500 polygons, which is totally real-time on jag, once we use 3-4 vblanks.

Of course, the visual appeal of Counterspy is based on lights, so at that point texturing would be required - so I'd have to use the lightmapping approaches from H.E.R.O. and start using Blitter and OP to assist with texturing.

 

I'm not going to switch to Counterspy now, I was just thinking out loud - what is possible, if one is willing to do the heavy-lifting coding work...

[crtfreak]

Looks great, I've enjoyed watching your video clips and seeing the progress. Great job

[phoenixdownita]

 

I think I'd like to experiment a bit more with flatshading and investigate its performance characteristics a bit more. Especially how much detail can we fit into 2 vblanks (30 fps). To me, the 30 fps feels quite smooth (at current movement speed, that is).

I also very much like that there is literally zero pixel disturbance - no shimmering textures or anything - it's just so nice and clean.

 

Also, there's quite a few popular games, with fixed camera angle, that use flatshading (or a variant thereof) and are entirely possible on jag (in adequately reduced polygonal detail) - like : Bit.Trip.Runner, Strider (PS4), Counterspy (PS4).

And while Bit.Trip.Runner is sensitive to framerate jumps, the other 2 platformers, should be plenty playable in 15-20 fps, as their 3D perspective is fixed (save for FPS view of Counterspy) into axis-aligned form, which as we already know from the H.E.R.O., can run at 60 fps. Obviously, H.E.R.O.'s scene complexity and Counterspy are nowhere near, and characters would have to be 2D bitmaps, but Counterspy's environment looks like it can be easily reduced to ~300-500 polygons, which is totally real-time on jag, once we use 3-4 vblanks.

I appreciate your dedication but if I may ask how did we get from achieving RR 60fps fully textured (that was the claim) to WipeOut-ish/platformers at 15-20fps flat shaded?

 

Anyway keep up the experimentation.

[JagChris]

I think we have sir lynxalot to blame. Threw a different squirrel down for him to chase.

[WAVE 1 GAMES]

I would love to see a wipeout style game like this on the Jag. Doen't even have to be a racer, perhaps a driving and shooting game? You could throw some beautiful backgrounds behind the track kind of like Dr Typo did with Gem Race. Can't wait to see how this ends up turning out. Stick with it, I think this could actually go somewhere

[VladR]

I think we have sir lynxalot to blame. Threw a different squirrel down for him to chase.

- That was one pretty darn important squirrel, though ! Yes, you can argue that neither NFS nor RoadRash have LevelOfDetail for terrain.

- But just because they don't have one, doesn't mean I can't use mine to improve the drawing distance in my engine.

- So, I'm personally really grateful to both sirlynxalot and sd32 for showing me best racing games of the era. To this day, I have those YT tabs open and keep switching between them for inspiration and motivation.

 

 

- As for my current progress, I didn't do anything over the weekend, as there was a PS4 sale and I bought Dark Souls II. Damn, what a time destroyer !

- But, last two mornings I've started integrating flatshading with the terrain, and I'm 80% through

- It's not so easy as with the Wipeout codepath, as there's additional layer of complexity due to Level of Detail (LOD) and a second layer of heightmap traversal

- 2 days ago I thought it's impossible to fit terrain+heightmap+LOD+flatshading within 4KB of GPU cache, but after 2 rewrites in last 2 days I'm getting awfully close to actually fitting it all within 4 KB! And I'll keep refactoring till the damn thing fits!

 

 

- I never thought I'd say it, but it's actually a good thing that jag's GPU has only 4 KB.

- You really have to be very careful in coding plus it's a technological challenge in itself, unlike anything one can code in high-level languages. Hell, I now consider a Motorola 68000 Assembler as high-level language :- )))))

- Sure, it eats a lot of time and effort, but fundamentally - that's where the real performance lies - avoiding blitting and syncing data&code chunks left and right, 10 times during a frame - keeping each loop as tight as possible and leaving certain data in slower main RAM, because those few reads totally beat the blit/sync effort of multiple GPU code chunks.

- Because in the end, less amount of code executes in less time (save for major algorithmic differences).

 

There's no way in hell, if I was using a C->GPU compiler that I would have fit as much functionality. I'd be very probably be approaching the third blit by now.

 

Now, I don't know about you, but I'm really curious to see if Checkered Flag's performance is warranted or not. Once I have the terrain flatshaded, I'll go work on some short track, as it looks like what I have now is closest to that kind of game environment (e.g. racing and flatshading).Plus cars.

 

Question: Is there some kind of technical interview / benchmark available for Checkered Flag ? From YT it *looks* like it drops below 10 fps, but it's hard to tell. There's definitely a visible framerate drop once the terrain covers huge portion of the screen (e.g. fillrate issue - which is to be expected from a jag architecture)

Is that game easily available on jag ? I'd like to play it for a reference.

 

Also, am I correct that Checkered Flag is the fastest-moving (in terms of how fast through the game world player moves, e.g. we're disregarding framerate here) flatshading racing game on jag ? I could be wrong, but Club Drive didn't seem as fast. But that could also be a YT encoding/interpolation thing..Note that I'm not talking about framerate, merely speed of moving through the world (e.g. how fast closest objects pass you, as hard as it may be to notice in that low framerate).

[Goochman]

Checkered Flag should be easily available and cheap. There have been numerous threads on CF here in the past - I believe some measuring FPS and such.

[sirlynxalot]

If you want to do some spelunking, think the source code for checkered flag was shared in a years old forum topic here.

[sirlynxalot]

http://atariage.com/forums/topic/121019-checkered-flag-source-code/

[VladR]

Got up at 5 am and spent 2.5 hrs with intense refactoring and managed to fit the damn thing into 4 KB :

 

No video, as I gotta rush to work. Weekend's coming up and as long as I don't accidentally fire up Dark Souls II again, it's good

 

So, right now, this is functionality I have working within the 4 KB of GPU cache:

- Terrain Heightmap traversal / World-space culling

- Terrain Heightmap Level Of Detail

- Double-buffering

- Benchmarking

- 3D Transformations / culling

- Triangle Flatshading with proper clipping against screen edges

- Camera path interpolation

 

This is getting ridiculous, even by my standards For god knows how many years, everybody was bitching that nothing fits the 4 KB cache and that "Atari screwed developers" by saving on the cache size (while everybody knows that fast cache is the one of the most expensive piece of the HW - and this is still true even now, let alone 20 yrs ago).

 

Seriously, I have to consider this myth busted. Can't beat the hand-written Assembler, clearly.

 

One has to wonder, what kind of a demo is then possible to produce on Jag within, say, 16 KB or - how about - 64 KB of an executable (e.g. same size as RAM on Atari 800XL, just for comparison's sake, what could the machine achieve with just 64 KB of code).

 

There are procedural algorithms that generate 3D terrain algorithmically, so we wouldn't even need to store any terrain data within the executable (rather, create it at load-time from scratch). I doubt it would consume more than 4-8 KB of code, but the terrain world size would be basically unlimited (other than by RAM).

 

 

 

I'm curious, are there any demo-scene compo intros/demos for jag in sub-64 KB category ?

[VladR]

http://atariage.com/forums/topic/121019-checkered-flag-source-code/

Most excellent idea !

And truly fantastic timing of it !

 

You've delivered again

 

This will be the first source code of a Jaguar game that I'll go examine in detail.

[saboteur]

I've been enjoying reading this thread and I doff my hat to VladR on his work.

 

However, it's a bit of a stretch to imply that you've acheived something no other devs's have when you have not produced an actual demo that includes sound and/or user interaction.

 

A lot of clever coders still produce superb demo's on lower specced hardware ( just look at some of the stuff on the humble ZX Spectrum ) but they ain't games and could not be reproduced as a playable game.

 

And TBH it's the games taht matter, and that is all anyone ever really considers.

 

That said keep plodding on cos I for one like checking in every day to see where you've go to.

[KidGameR186496]

Most excellent idea !

And truly fantastic timing of it !

 

You've delivered again

 

This will be the first source code of a Jaguar game that I'll go examine in detail.

There's aslo the source codes for Hover Strike, Fight for Life and Alien Vs. Predator out there if you need more

[VladR]

I've been enjoying reading this thread and I doff my hat to VladR on his work.

 

However, it's a bit of a stretch to imply that you've acheived something no other devs's have when you have not produced an actual demo that includes sound and/or user interaction.

 

A lot of clever coders still produce superb demo's on lower specced hardware ( just look at some of the stuff on the humble ZX Spectrum ) but they ain't games and could not be reproduced as a playable game.

 

And TBH it's the games taht matter, and that is all anyone ever really considers.

 

That said keep plodding on cos I for one like checking in every day to see where you've go to.

We've been over this many times in past, so just quick recap:

- if I had to reach out for a controller after deploying every single build, I would probably be at around 15-20% of where I am now. I easily do around 400-500 builds during a weekend. Hell, this morning I did around 50 builds.

- Audio : the DSP usage is 0%, so the only performance impact will be from bandwidth of sound effects (for a racing game)

- input integration : my engine accepts 3D position of camera and then processes everything else - e.g. this is as generic as it gets. If you think, that those few lines of code that translate joystick movement to a new camera position will affect performance in measurable way, then I'm afraid it's useless to try to explain more, as the performance cost of that is realistically below 0.1% of, say, triangle rasterizing stage (and that's just one stage of the whole rendering pipeline)

 

And where exactly did I say that I "acheived something no other devs's have" ?

 

I was obviously mistaken, when I thought that my '10,000 feet altitude' technical descriptions are sufficiently high-level. Perhaps they're still too technical to comprehend, as I said multiple times that my engine just reads the track data from a separate file and then processes culling and transformation in a generic loop.

 

How that could be possibly translated into 'but they ain't games and could not be reproduced as a playable game'. is truly beyond my comprehension...