Jump to content
IGNORED

Road Rash pre-alpha on Jaguar at 30 fps


VladR

Recommended Posts

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.

 

Great. Can't wait to see what you have once you start actually taxing the bus.

  • Like 1
Link to comment
Share on other sites

 

Great. Can't wait to see what you have once you start actually taxing the bus.

And what in your opinion would constitute taxing the bus ? More concurrent textures on screen in single rendered frame, higher resolution of textures, or some combination ?

Link to comment
Share on other sites

And what in your opinion would constitute taxing the bus ? More concurrent textures on screen in single rendered frame, higher resolution of textures, or some combination ?

 

It doesn't matter what his opinion is. You don't value anyone else's here, apparently.

  • Like 2
Link to comment
Share on other sites

 

It doesn't matter what his opinion is. You don't value anyone else's here, apparently.

Incorrect. Sauron is not a bullshitter, hence his opinion actually matters to me.

 

Notice also, how he was the first one in this thread, who actually formulated a valid technology question.

Link to comment
Share on other sites

Incorrect. Sauron is not a bullshitter, hence his opinion actually matters to me.

 

Notice also, how he was the first one in this thread, who actually formulated a valid technology question.

 

Asking about real hardware is a valid technology question? Fantastic. :)

 

I don't see anyone else here bullshitting you. Everyone has been asking the same questions that we've all asked you ever since you first came here to tease with crude demos that were running in VJ and then disappearing before they got anywhere.

 

To answer your earlier question, though...more textures along with more sprites, all happening with sound effects and a soundtrack, all while maintaining 30fps. Chances are you won't get far enough with this for us to see this happening, though. As usual.

  • Like 4
Link to comment
Share on other sites

 

Asking about real hardware is a valid technology question? Fantastic. :)

 

I don't see anyone else here bullshitting you. Everyone has been asking the same questions that we've all asked you ever since you first came here to tease with crude demos that were running in VJ and then disappearing before they got anywhere.

 

To answer your earlier question, though...more textures along with more sprites, all happening with sound effects and a soundtrack, all while maintaining 30fps. Chances are you won't get far enough with this for us to see this happening, though. As usual.

More textures ? How about I quadruple their current amount ? Let me combine the materials in PaintShopPro, recombine them into single texture, import it to engine and adjust number of available materials in the TextureTable.

 

Gimme 2-3 hrs ...

Link to comment
Share on other sites

More textures ? How about I quadruple their current amount ? Let me combine the materials in PaintShopPro, recombine them into single texture, import it to engine and adjust number of available materials in the TextureTable.

 

Gimme 2-3 hrs ...

Took less than 2 hrs, actually.

 

New features:

- Raised the texture resolution for building textures from 32x56 to 64x128 (e.g. more than quadrupled)

- Raised the total number of building textures from 2 to 8 (quadrupled) - a total of 65536 texels (compared to 3584 (32*56*2) in previous build, e.g. more than 18x more !)

- Framerate remains unchanged at 30 fps lock, despite raising the number of potential texels by a factor of 18:1 (65536 / 3584). Sorcery :-D

- Added ramp-up and ramp-down in road speed (not yet sync'ed to the building speed)

 

Sauron - I'll add the props during the weekend. I could quickly port what I had last year in C code, but I want this more generic this time and especially more reusable, so that when I get to NFS, I'll just reuse the same component.

 

Here's the video of new build:

Link to comment
Share on other sites

I just realized, that if I dropped the texturing, and opted for a "clean" flat-shaded polygonal look, I should be able to keep stable 60 fps. Something like Checkered Flag, but at 60 fps.

 

Gotta implement the proper 3D terrain, first, but this sounds to me like an interesting coding detour, while still keeping to the racing genre.

  • Like 1
Link to comment
Share on other sites

I disagree, the theory here is that the Jag is 3D textured poly challenged, now not that there are too many good flat/gouraud shaded 3D poly games on it, but there's enough to believe it is something the Jag can handle within reason.

So by detouring you'll prove that it is actually hard to have a fully textured 3D poly game as many of us believe already hence lending more credence to the theory that games like RR, NFS, Quake etc... are beyond its reach at least without heavy compromising.

 

And all the nonsense about people's opinion being void when they have not "done a 3D engine" themselves is also ill advised. I don't need to be a rocket scientist to know it ain't gonna be a solid-propellant rocket that is going to propel us all the way to alpha centauri.

If 3D textured poly games were relatively easy to pull off on the Jag we would have seen them already bitd, there weren't many and the few that were made were kind of laughable surely because of a combination of ill-fitted hardware and poor dev support.

 

So told lemme volunteer a piece of a story about POC and real products with complete feature set. A few years ago we were working to build a storage solution and we were looking to replace the back-end portion with a very promising replacement. it was the early days of that prototype and early benchmarks gave us a 30x increase, mind-blowing if you ask me but one of the engineers in the team cooled off the enthusiasm and warned us to wait until the missing features were implemented, fast forward 1Y and the difference was reduced to 2x if that .... still worthy for a different set of reasons but the lesson was clear.... add all the pieces before trusting back-of-the-napkin math out of an incomplete POC. If we would have promised a 30x perf increase to management we would have ended up being an embarrassment for the company and making a fool of ourselves.

  • Like 3
Link to comment
Share on other sites

Incorrect. Sauron is not a bullshitter, hence his opinion actually matters to me.

 

Notice also, how he was the first one in this thread, who actually formulated a valid technology question.

 

 

More insults. One year later, still no change.

  • Like 2
Link to comment
Share on other sites

If 3D textured poly games were relatively easy to pull off on the Jag we would have seen them already bitd, there weren't many and the few that were made were kind of laughable surely because of a combination of ill-fitted hardware and poor dev support.

Oh, but I never said, it was very easy to pull off textured 3D in fluid framerate on Jaguar. Even the word relatively, is actually (based on my jag experience) more-than-slightly misleading :)

 

If it was so easy, then there wold have been at least a dozen 3D engines for jag or at least prototypes coded in last decade. There's hardly a handful, and as far as I know, zero textured ones. Let alone ones that run at 60 fps (like my platformer renderer) or this one.

 

There's usually one game that is being mentioned - LiveWire, and even that one has only flat-shaded perspective polys.

 

Now, as for your other example with the rocket engineering - you certainly don't have to be one, to try and offer your viewpoint.

Just don't expect that particular rocket scientist to take you seriously, that's all I'm saying ;)

 

You may think that reading input and updating xp,yp for a bitmap in OP list takes longer than 3D transforming, clipping and rasterizing 10 polygons that are partially offscreen. And that's OK, everybody is entitled to their opinion.

 

 

But it just so happens, that I actually have hard, actual benchmark numbers, taken from real jag. I know exactly how many vertices I can transform per frame, how many edge lines I can render, how many texels I can read from main memory and how many I can write back. and about 12 other throughput numbers, around which I designed by GPU engine.

Seriously, is there a single person here, on this forum, that also has those actual numbers ? Really ? Please, I want to talk to him/her !

 

Yet, somehow, everybody feels like a rocket engineer here and is saying - "Oh, I never coded a 3d engine on jag, but you got it wrong" :) Hmmm, interesting....

 

I've played NFS in a framerate under 25 on my PC at that time. And it was still incredible fun. I believe I can pull off a version that will do comparable environments at 20+ fps on jag. It's not gonna be next week, and probably not next year (with my burn-outs). I'm quite certain however, that with an interior view from inside the car, the 20-30 fps will be completely realistic on Jag. The fillrate numbers do not lie.

 

But this very build of RR, is not just a step closer to that, it's really only few steps away (need 3D terrain, and cars).

Link to comment
Share on other sites

 

But it just so happens, that I actually have hard, actual benchmark numbers, taken from real jag. I know exactly how many vertices I can transform per frame, how many edge lines I can render, how many texels I can read from main memory and how many I can write back. and about 12 other throughput numbers, around which I designed by GPU engine.

Seriously, is there a single person here, on this forum, that also has those actual numbers ? Really ? Please, I want to talk to him/her !

 

Yet, somehow, everybody feels like a rocket engineer here and is saying - "Oh, I never coded a 3d engine on jag, but you got it wrong" :) Hmmm, interesting....

 

 

Benchmark numbers on a simple engine with hardly enough assets in it to tax the entire system are meaningless.

 

Look, I'll try to explain everyone's skepticism here so you can understand where we're coming from. First of all, no, I've never coded a 3d textured engine on the Jag. In fact, my own coding abilities are extremely limited. My own coding contributions consist wholely of writing a flag handler on the 68k, inserting scrolling credits into a game (and I didn't even write the scrolling routine), making a ball bounce around a screen, and changing various input options. So yes, I could be completely talking out of my ass here, considering my own meager contributions. However, I've been involved with Jag game development long enough to notice a few things about the hardware.

 

What you've done so far is write small demos that use virtually nothing but the GPU and OP. I don't think anyone who has ever written a line of code for the Jag could possibly dispute the notion that these two processors are absolute beasts. They are extremely powerful processors in their own right, and it's not surprising that they're capable of producing decent looking texture-mapped 3D polygons. The problem, though, lies in the rest of the Jag's architecture. Most games do not consist wholly of simple 3D engines with only a handful of textures. Sooner or later, you're going to end up with quite a few more textures and bitmaps streaming across the bus, having to fight for bus time with whatever audio the DSP is handling. Once you start having to deal with bus contention issues, you're going to start seeing the Jag spring some nasty surprises on you.

 

This is basically the main point of all of the skepticism directed towards your projects. You have yet to write anything that really starts hammering the bus, causing the different processors to have to fight for bus time. From my own recommendation, what I would recommend is inserting a sound engine into your project, playing mod music and using some simple sound effects, and then start working from there with thowing in more textures and sprites. Again, though, I could be talking out of my ass here, based on my own meager knowledge of the Jag's hardware, but I think it's safe to say that no one is going to be impressed until you can show that you can balance everything together on the Jag's bus while still maintaining a decent framerate.

 

Having said all of that, though...I would love for you to prove us all wrong.

  • Like 8
Link to comment
Share on other sites

 

Benchmark numbers on a simple engine with hardly enough assets in it to tax the entire system are meaningless.

 

Look, I'll try to explain everyone's skepticism here so you can understand where we're coming from. First of all, no, I've never coded a 3d textured engine on the Jag. In fact, my own coding abilities are extremely limited. My own coding contributions consist wholely of writing a flag handler on the 68k, inserting scrolling credits into a game (and I didn't even write the scrolling routine), making a ball bounce around a screen, and changing various input options. So yes, I could be completely talking out of my ass here, considering my own meager contributions. However, I've been involved with Jag game development long enough to notice a few things about the hardware.

 

What you've done so far is write small demos that use virtually nothing but the GPU and OP. I don't think anyone who has ever written a line of code for the Jag could possibly dispute the notion that these two processors are absolute beasts. They are extremely powerful processors in their own right, and it's not surprising that they're capable of producing decent looking texture-mapped 3D polygons. The problem, though, lies in the rest of the Jag's architecture. Most games do not consist wholly of simple 3D engines with only a handful of textures. Sooner or later, you're going to end up with quite a few more textures and bitmaps streaming across the bus, having to fight for bus time with whatever audio the DSP is handling. Once you start having to deal with bus contention issues, you're going to start seeing the Jag spring some nasty surprises on you.

 

This is basically the main point of all of the skepticism directed towards your projects. You have yet to write anything that really starts hammering the bus, causing the different processors to have to fight for bus time. From my own recommendation, what I would recommend is inserting a sound engine into your project, playing mod music and using some simple sound effects, and then start working from there with thowing in more textures and sprites. Again, though, I could be talking out of my ass here, based on my own meager knowledge of the Jag's hardware, but I think it's safe to say that no one is going to be impressed until you can show that you can balance everything together on the Jag's bus while still maintaining a decent framerate.

 

Having said all of that, though...I would love for you to prove us all wrong.

I extremely appreciate you being nice and explaining in detail the source of scepticism.

 

It's true I don't really know the impact of audio, as I haven't written the audio component yet. But, even in worst case, let's say the audio consumes 1 frame time due to the virtue of constantly hitting the bus (just like GPU for texturing) and not the 10-15% I usually expect.

 

That'd mean a jump from 30 fps to 20 fps or if it was at 20 fps down to 15 fps.

And since there are lots of 2D games where audio is playing at 60 fps, my worst case scenario sounds actually quite pessimistic.

 

But that's one thing I haven't actually benchmarked, so I will not argue there (other than the fact the biggest performance impact I'll ever attribute to audio is one frame/vblank).

 

I'll get back to coding now. Either a quick 2D props (hydrant/trees/...) feature or a complex 3D terrain feature.

 

I'm truly wondering, what will all of you be complaining about, once I have the input, audio and it'll still hover around playable 20-30 fps. We'll see...

Link to comment
Share on other sites

About it not being on Jag CD so it can play those sweet music videos on the 3DO version! = D .. Pet tha dawg, pet tha dawg, pet the daaawg.

Actually, you know that once you have a 3D engine, you can script an in-engine videos, right (which only take up few KBs, instead of hundred MB) ?

 

So, even without the CD, you could script the engine for some videos.

 

Throw in some nice per-pixel car shader into the engine mix (the videos can have lower framerate than the game), and it actually can look quite good (considering the HW, that is) :)

Link to comment
Share on other sites

FPS aside, it looks like it's going about 50mph - is that top speed or how do you increase the speed enough to simulate faster riding?

That speed is just a simple camera position adjustment - e.g. it is a simple constant in a code. You change the constant and the speed of moving through world changes automatically.

 

Once the input is implemented, that constant will be coupled accordingly.

 

More importantly, as I have two different texture routines (one customized for road, another customized for buildings), I need to synchronize both, as right now the speed of road and buildings are two different coordinate spaces.

 

Well, technically, I still have the last year's OP-based road texturing, so that's a third method. But, I'd rather keep things generic for a full NFS-style 3D terrain.

 

What the above means, when I'm using OP-based road texturing, I can actually reach 60-fps right now - so RoadRash-specific environment could run at 60 fps. But Road Rash is not a target here (merely an intermediate semi-goal), it's the NFS.

Link to comment
Share on other sites

I extremely appreciate you being nice and explaining in detail the source of scepticism.

 

It's true I don't really know the impact of audio, as I haven't written the audio component yet. But, even in worst case, let's say the audio consumes 1 frame time due to the virtue of constantly hitting the bus (just like GPU for texturing) and not the 10-15% I usually expect.

 

That'd mean a jump from 30 fps to 20 fps or if it was at 20 fps down to 15 fps.

And since there are lots of 2D games where audio is playing at 60 fps, my worst case scenario sounds actually quite pessimistic.

 

But that's one thing I haven't actually benchmarked, so I will not argue there (other than the fact the biggest performance impact I'll ever attribute to audio is one frame/vblank).

 

I'll get back to coding now. Either a quick 2D props (hydrant/trees/...) feature or a complex 3D terrain feature.

 

I'm truly wondering, what will all of you be complaining about, once I have the input, audio and it'll still hover around playable 20-30 fps. We'll see...

 

The impact of the audio will most likely depend on what kind of audio you're using, the size of the sound effect samples, etc. That's why you probably want to try putting in that audio before going any further with the 3D engine and making claims about its performance. Really though, if you want to see a good example of what can happen with bus contention, look at the Checkered Flag Alpha compared to the release version, and see what simple gouraud shading did to the 3D engine there. It's not an apples to apples comparison, but it's not that dissimilar either.

 

And if you can truly put in everything you want to put in to show an example of a real game environment while maintaining a decent framerate, then no one will be complaining about anything, I'm sure.

  • Like 2
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...