Road Rash pre-alpha on Jaguar at 30 fps

[VladR]

I've finally made the switch to GPU coding and ported majority of features of my C code for the Road Rash prototype (that was in past running only under emulator) into GPU.

 

This build is obviously very early, but shows all the most performance-hungry engine features, like:

- 3D transformation (World+View+Projection)

- World Frustum culling

- Polygon clipping

- Texturing of buildings and road (texturing on GPU gives much higher quality/precision than via Blitter)

 

Processors used:

- Blitter : 0%

- DSP : 0%

- OP : ~10%

- GPU: ~65%

- 68000: 5%

 

Level:

- currently only 5 buildings, on a loop, as I don't want to waste time creating a mesh for big city manually, before I have working hills/curves

 

Framerate:

- Locked to 30 fps (e.g. stable, exact 30 fps, never less than 30)

- Without the lock, the framerate actually oscillates around ~42 fps. It's entirely within the reach to get it to run at 50 fps on PAL jaguar. Here are the reasons:

- 1. I am currently using very generic texturing functions, and all texture data gets fetched from slow main RAM.

- 2. I did some benchmarks with different versions of those routines (I wrote about 5 different versions), that had partial local caching from within GPU, and their performance jumped more than 25%, so 50 fps is entirely reachable (if I can be bothered to optimize it)

- 3. There is literally 0% use of DSP, and quite a few engine features could run in parallel from DSP. The Audio won't use more than 10-15% of DSP anyway, so it's free to help GPU.

- 4. Road texture is very high-res, gets sampled too much, which means it's hitting the bus more often than needed (as you can't even see all the texels even at closest camera position)

 

Memory footprint:

Binary has 175 KB:

- 78 KB : Textures

- 64 KB : Framebuffer

- 20 KB: 68000 Code (from initialization, through loading of textures, to handing over control to GPU)

- 5 KB : Data

- 4 KB : GPU code

- 0.5 KB : Level

 

Video:

Here's the YT link, captured on my $10 AV device (the capture quality obviously corresponds to price of the capture device).

 

Next Features:

- 2D Props (hydrant,trees)

- basic terrain layer

- Curves/Hills

 

Since I just made the jump to GPU, I'm very curious about its various performance characteristics, so I'm going to get distracted by various experiments/effects (e.g. won't be working just on this).

 

Ultimately, I was always a huge NeedForSpeed / Screamer fan, so eventually I'd like to create one fully playable track with a proper 3D terrain, and I believe 3D textured cars are also within playable framerate (e.g. 20+).

[bmx]

Looks nice. Looking forward to see more.

[Austin]

Meh.

[+Sauron]

Is this running on real hardware?

[TXG/MNX]

Can you tell us how the GPU code works?

 

Options:

 

1) Load gpu code and then that gpu program did wait for a command to be set, then the gpu wakes up, stops the 68K, and when it finished it will waiting for command and the 68K is running again.

 

2) Load gpu code and the gpu is in control, shutdown 68K and starts the 68K when the GPU is finished and GPU stops

 

3) load gpu code, 68K in control start and stops gpu

 

4) load gpu code, gpu program runs local and 68K parallel at the same time.

[TXG/MNX]

Your memory footprint of the GPU is 4KB so the full ram of the GPU is used, the only solution to use bigger GPU code is to swap GPU code in/out.

[+CyranoJ]

- 64 KB : Framebuffer

 

You should try Quad, Hexa, or Dodecahedrabuffering that

 

I jest, but seriously, go and read up on double buffering.

[VladR]

Can you tell us how the GPU code works?

 

Options:

 

1) Load gpu code and then that gpu program did wait for a command to be set, then the gpu wakes up, stops the 68K, and when it finished it will waiting for command and the 68K is running again.

 

2) Load gpu code and the gpu is in control, shutdown 68K and starts the 68K when the GPU is finished and GPU stops

 

3) load gpu code, 68K in control start and stops gpu

 

4) load gpu code, gpu program runs local and 68K parallel at the same time.

You could say, it's the 4th option, as 68K does technically run in parallel, but once all loading/initialization is done, it really only "runs" an endless loop of doing nothing - e.g. just constantly jumping one line back - so it's not doing anything meaningful at run-time - hence I said it's only used on 5%.

But it does mean, it is constantly hitting the bus, thus technically slowing GPU down (though I don't yet know by how much, but I will later experiment with it), as GPU constantly accesses main RAM for textures and framebuffer.

 

I'm going to leave 68k running for now, as there will be few small and simple tasks that are unworthy of GPU, like:

- Input

- props (hydrant, trees, people)

- AI

- HUD

- Level loading, once I get to Screamer-style feature-set (e.g. different textures for road, environment (e.g. graass, sand, snow, asphalt, ...), buildings)

 

It's also important to note that this new project/build does not have any C language. This is entirely written in Assembler.

[VladR]

- 64 KB : Framebuffer

 

You should try Quad, Hexa, or Dodecahedrabuffering that

 

I jest, but seriously, go and read up on double buffering.

Wow. Multiple decades of "experience", and you didn't realize this already runs with double-buffering ?

 

1. I explicitly mentioned it runs at 30 fps - which means 2 vblanks

2. This means clearing of FrameBuffer happens during the frame time, and that's very, very visible via ugly flashing, if I was using only one FrameBuffer

3. The only way to avoid that ugly flashing is use the different buffer than the one that OP is currently displaying

 

I actually really WAS right in past that you are a definition of Sub-8-Bit coder - e.g. flashing Atari-800-style graphics on a console that has several orders of performance more available and saying "l@@k - it's 60 fps", as you couldn't figure the above by yourself

 

I apologize for not mentioning the double-buffering earlier. It was 2 am, I was up almost 20 hrs, and I was only going through the 68k code file, when doing the statistics on memory footprint, so the second framebuffer escaped me at that time.

[VladR]

Your memory footprint of the GPU is 4KB so the full ram of the GPU is used, the only solution to use bigger GPU code is to swap GPU code in/out.

To be honest, 1.5 KB of those 4 KB is debugging functionality:

- displaying values

- displaying arrays

- binary/decimal conversions

 

So, the actual engine code has currently fit into 2.5 KB.

 

But, you are right, I very soon will have to figure out a swapping mechanism. Will cross that bridge when I get there.

 

Compared to handling clipped polygons in a fast way, that (copying code back and forth) should be primitively easy, though.

[VladR]

Is this running on real hardware?

Yes, this is running on actual real NTSC Jaguar.

[VladR]

Looks nice. Looking forward to see more.

Thank you for actual positive feedback. I can promise you, there will be more to see, and very soon, just not necessarily from racing genre. There's few game types, I was always curious to see, if jag could handle them.

 

Now, that I got the core 3D engine with texturing running on GPU, and have real hard numbers about the actual fillrate of Jag (at 60 fps, 30 fps, 20 fps), I already know if they can handle certain games. Now, it's just a question of me spending the time on a given prototype.

 

Of course, as I've been saying last 5 years, I burnt out fast and a lot. So, once again, for umpteenth time, I am reminding everybody, that I will soon burn out, and will need a downtime (6+ months), when I don't want to see a jag,

 

I can't predict exact time of that happening, but I reckon that this time, 95% of users will be aware of it (despite me, reminding about it, EVERY single time - though the Sub-8-bit camp is trying hard to persuade others otherwise).

[BillLoguidice]

I appreciate you showing this, but to the non-technical, it doesn't look like much of anything still. Even if you completed a small playable game with non-placeholder graphics as a demonstration, that would do infinitely more to impress people than moving some objects on a screen, no matter the underlying "technology" of said objects moving on a screen.

[VladR]

I appreciate you showing this, but to the non-technical, it doesn't look like much of anything still. Even if you completed a small playable game with non-placeholder graphics as a demonstration, that would do infinitely more to impress people than moving some objects on a screen, no matter the underlying "technology" of said objects moving on a screen.

If you think,

that I care a tiny little bit

about whether some mentally-challenged group of Jaguar geeks

is impressed by my prototypes

then you haven't comprehended what I said at least 20 times already:

 

I want to know if a certain game-style and engine is technically possible on Atari Jaguar.

 

There have been brutal flamewars on AA in past that games like Road Rash, NeedForSpeed or Quake1 are allegedly - totally- out of reach of Atari Jaguar in any sort of playable framerate. None of those persons have written anything close to real-time 3D engine on Jaguar, obviously!

 

Now, if someone is so technically mentally challenged, that their argument will be:

- oh, but you have no audio, input or other 2D bitmaps on screen, so then the framerate will drop from 30 to 3 fps (CyranoJ proved his technical incompetence many times by making absurd claims like that, and every time he was proven wrong).

 

Then, I can't really help him, if that person doesn't understand that the few above features constitute 10%, at best, of performance compared to the 3D engine and texturing calculations.

 

This is not about creating a final game with 10 levels, and selling it to 200 people. It's about seeing, how far the last Atari can be pushed in terms of 3D technology.

 

Clearly, from my initial foray into this area, the jag can go beyond, what certain groups with their agenda, have been claiming last 2 decades.

[Albert]

Enough of your insults or your next sabbatical will be a permanent one away from AtariAge. This isn't the first time you've been warned, but it will be your last.

 

..Al

[VladR]

Enough of your insults or your next sabbatical will be a permanent one away from AtariAge. This isn't the first time you've been warned, but it will be your last.

 

..Al

Are you going to threaten banning all those that keep insulting me all the time, too ? Just want to hear an honest answer, that's all.

[Albert]

Are you going to threaten banning all those that keep insulting me all the time, too ? Just want to hear an honest answer, that's all.

 

First, two wrongs don't make a right. Second, I only see people helping or asking legitimate questions in this thread, so please point out the posts where people are insulting you in a similar fashion to what you're doing.

 

..Al

[VladR]

 

First, two wrongs don't make a right. Second, I only see people helping or asking legitimate questions in this thread, so please point out the posts where people are insulting you in a similar fashion to what you're doing.

 

..Al

Correct. This thread, so far, aside from CyranoJ's insult [on doublebuffering], has been clear of them.

 

But, you know very well, which threads I am talking about, as you were involved with them (closed threads), so you certainly still remember.

 

I am taking your point, however and will tone down my defenses.

 

 

 

You haven't answered my question, btw. I believe it was a fair question (but I may have been wrong about that belief, I accept that).

[BillLoguidice]

I want to know if a certain game-style and engine is technically possible on Atari Jaguar.

 

There have been brutal flamewars on AA in past that games like Road Rash, NeedForSpeed or Quake1 are allegedly - totally- out of reach of Atari Jaguar in any sort of playable framerate. None of those persons have written anything close to real-time 3D engine on Jaguar, obviously!

 

Now, if someone is so technically mentally challenged, that their argument will be:

- oh, but you have no audio, input or other 2D bitmaps on screen, so then the framerate will drop from 30 to 3 fps (CyranoJ proved his technical incompetence many times by making absurd claims like that, and every time he was proven wrong).

 

Then, I can't really help him, if that person doesn't understand that the few above features constitute 10%, at best, of performance compared to the 3D engine and texturing calculations.

 

This is not about creating a final game with 10 levels, and selling it to 200 people. It's about seeing, how far the last Atari can be pushed in terms of 3D technology.

 

Clearly, from my initial foray into this area, the jag can go beyond, what certain groups with their agenda, have been claiming last 2 decades.

 

Who exactly has written a real-time 3D engine on the Jaguar to show Road Rash- (3DO/PS1/Saturn), Need for Speed- (3DO), or Quake- (PC) like performance to prove the so-called naysayers wrong?

 

What you've shown (accompanied by considerable bravado and hyperbole) looks to my admittedly untrained technical eye like the kind of thing a person who's trying to get up-to-speed in a programming language might do to kick the proverbial tires. I don't think my suggestion is an unreasonable one to do the smallest of mini games that shows off this supposed 3D prowess with non-placeholder graphics. To be frank - and I hope you don't take this as a personal attack because I don't do those - what's shown looks like crap and something that could be done on a 16-bit system. If you really have the type of engine you say, would it really be that hard to do something that could impress someone who is "technically mentally challenged" (such as me)? Otherwise, again, being perfectly honest, you could do 50 more of these, and it will still look like nothing much to almost anyone else except you. If that's sufficient, then more power to you, but I do hope you can then at least appreciate why people like me feel the way we do, especially when it's accompanied by the aforementioned bravado and hyperbole.

[VladR]

 

Who exactly has written a real-time 3D engine on the Jaguar to show Road Rash- (3DO/PS1/Saturn), Need for Speed- (3DO), or Quake- (PC) like performance to prove the so-called naysayers wrong?

 

What you've shown (accompanied by considerable bravado and hyperbole) looks to my admittedly untrained technical eye like the kind of thing a person who's trying to get up-to-speed in a programming language might do to kick the proverbial tires. I don't think my suggestion is an unreasonable one to do the smallest of mini games that shows off this supposed 3D prowess with non-placeholder graphics. To be frank - and I hope you don't take this as a personal attack because I don't do those - what's shown looks like crap and something that could be done on a 16-bit system. If you really have the type of engine you say, would it really be that hard to do something that could impress someone who is "technically mentally challenged" (such as me)? Otherwise, again, being perfectly honest, you could do 50 more of these, and it will still look like nothing much to almost anyone else except you. If that's sufficient, then more power to you, but I do hope you can then at least appreciate why people like me feel the way we do, especially when it's accompanied by the aforementioned bravado and hyperbole.

This is a first step in that direction. I'll be slowly adding more features to it, as I feel it, so that it more resembles an actual game, as this build, as I said, is an early-pre-alpha (at best).

 

But it does have the most performance-expensive engine features in it - that's the whole point of this video - that something like Road Rash (and NFS by that extension) is completely possible on Jag.

 

You are not technical, so I don't blame you that you don't see it yet, but:

- The hills and curves will be free, performance-wise, as the same amount of vertices gets processed. The GPU does NOT care,where the vertices represent a hill, curve, or a straight road. It's still just same few instructions it executes.

- The buildings are currently placed along a single line, as like I said, I spent 10 minutes with them. Whether the vertices are along the curve, hill or straight road, again - has zero performance implications, as GPU could not care less.

- Texture variety : I have currently only 2 textures in the texture array, but I can have 25, again - with zero performance implications, as GPU does not care - it simply reads the offset for the material from an array, so whether you have 2 or 2 hundred textures, it's same performance impact

 

I absolutely understand that this looks like crap from a gamer's standpoint. No hills, curves, and proper buildings as RR has. In other words, what you want is art assets done by an actual artist, that will make the tech and engine look the way it's supposed to.

 

Since you seem to have a selected memory, let me remind you : A year ago I was accused that my RR build (running on VJ at that time) was quote "willfully misleading AA that something like RR is remotely possible to run in any sort-of playable framerate" end quote.

 

This video has similar art assets and tech, but it now runs at 43 (30 fps lock) on real HW. Suddenly, when I submit the video from real HW, as you put it "16 bit system could have done the same"

 

Give it a bit time, and it's going to have interactive features you are talking about.

[BillLoguidice]

Since you seem to have a selected memory, let me remind you : A year ago I was accused that my RR build (running on VJ at that time) was quote "willfully misleading AA that something like RR is remotely possible to run in any sort-of playable framerate" end quote.

 

And I'm reminding you that one year later you have still only proven that to yourself it seems.

[+Sauron]

What you have here is less impressive than many games that are already on the Jag, namely Super Burnout. Most of us commenting on this thread aren't complete idiots, like you seem to think. You don't need impressive art assets to show off what the system can be capable of, but you simply haven't done that. But, I'll at least give you kudos for FINALLY showing something that's running on real hardware.

[+CyranoJ]

Correct. This thread, so far, aside from CyranoJ's insult [on doublebuffering], has been clear of them.

 

 

I was not being insulting, but your reply was...

 

The screen is clearly 256 colours, 320x200 - that is 64k.

 

You said your frame buffer was 64k.

 

So clearly, by your own words, that isn't double buffered, or you'd have used 128k.

[VladR]

What you have here is less impressive than many games that are already on the Jag, namely Super Burnout. Most of us commenting on this thread aren't complete idiots, like you seem to think. You don't need impressive art assets to show off what the system can be capable of, but you simply haven't done that. But, I'll at least give you kudos for FINALLY showing something that's running on real hardware.

Sure, right now, it's not very impressive - driving in a straight line in constant speed with 2 different textures on front-facade of buildings.

 

I will gradually keep on adding more features and more art assets.

 

It can only get better from here, though.

[Albert]

You haven't answered my question, btw. I believe it was a fair question (but I may have been wrong about that belief, I accept that).

 

Yes, should I actually see any such insults.

 

..Al