Jump to content
IGNORED

Road Rash pre-alpha on Jaguar at 30 fps


VladR

Recommended Posts

 

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.

Oh, but Jaguar is not the only HW platform, that has issues with the bus contention. I've experienced similar issues across various ranges of gfx cards on PC, WindowsPhone and Xbox.

 

Why do you think I incessantly benchmark everything ? Clearly, despite me mentioning it, like 100 times, nobody has obviously understood that yet.

 

It's because once all engine pieces are together, I have all numbers of all components, sorted nicely in the excel and can then choose a candidate component that will give me the necessary bandwidth to get back to proper framerate, once contention hits.

 

That's why I need to know the throughput of vertices, texel read/writes, and all support routines. This way, all the time while coding the engine, I am thinking constantly of where and how I can later adjust the component to tweak its performance characteristics.

 

 

As for the audio, there is a racing game where music is very important - for example Wipeout. There, you definitely need to allocate a lot of bandwidth for audio, as it is an integral part of the experience, and the visuals (textures/polys) have to be toned down accordingly, as the system is quite busy with high-quality audio.

 

But for RR/NFS ? Engine effects are about the extent of audio you really need there. Unfortunately, audio has been historically of lowest interest for me, technologically speaking, across all platforms, so I don't see why jag should be any different. So, I'm afraid, the audio won't appear sooner than after the actual gameplay does (e.g. input, and some AI). It may very well not be this year.

 

Look, the Doom on jag had no music, and everybody raves about it, despite the fact, that it was a very important part of the total doom experience (but I grew up with Doom on PC which had the music,so my expectations were different).

 

If, the sound of the car/bike engine, on a jaguar, does kill the framerate of 30 down to 15, I am prepared to adjust the resolution, textures and vertices to get that performance back. It's same kind of tweaking I've been doing last 2 decades across various HW platforms, so for me it's business as usual.

Link to comment
Share on other sites

How are you throwing this engine together so fast in an ASM flavor you've never used before?

 

You sure you're not dabblin in the risc compiler?

Yeah, well not fast enough. Took me almost two weeks from the moment I opened up a sample GPU project to get here, as the Mandelbrot environment (the original GPU project from Atari's dev env), was giving me terrible headaches, till I noticed that I missed one line where it was writing data,which just happened to be at the same address, as my data, but it gave appeareance of randomness.

 

In reality, I spent:

- 2 days on various basic macros (local stack, loops, variable handling),

- 3 days on debugging functionality (display numbers and arrays from within GPU)

- 1 day experimenting with writing routines to draw pixels and lines from GPU

- 1 day to write a texturing routine

- 1 day to implement proper polygon clipping across all screen edges

- 5 days lost on debugging across last two weeks, till I accidentally noticed an overlooked, uncommented line in Atari's mandelbrot codebase, that was indeed overwriting my data at run-time, as their example is just using HARD-CODED (What.The.Fuck) addresses to write data to. So, adding new texture suddenly meant black screen. Removing a line of unrelated code, again - blank screen. Every third run, blank screen.

 

I have yesterday finally removed the Atari's mandle.s from my build set-up, so it's not messing up my data at runtime anymore and there's no more original Atari's Mandelbrot code that would be interfering with my engine.

 

Should have gotten rid of Atari's Mandelbrot source codebase a week ago - but hey - that's part of the platform experience.

Link to comment
Share on other sites

 

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've been a programmer for a couple of decades, never developed anything for the Jaguar or games for that matter, but I think the big part of his effort is to actually make use of the GPU and DSP chips... (Tom & Jerry). I don't say this with any authority, Albert & CryanoJ... please correct me... but if I'm not mistaken, a LOT of Jaguar games (both homebrew and originals, make use of the Motorola 68000 chip to pretty much do everything. I think what Vlad wants to do, is not do everything with the 68000 chip like most of the Jaguar games do, and instead really try to take advantage of Tom to do most of the heavy graphics processing.

 

Based on what I remember reading on here, is that most developers never really bothered to spend any time using those extra processors because it was too much effort. Instead, it was much easier to just port an existing game from the ST or whatever... onto the Jaguar. Now, when I look at a lot of the more in-depth games... like Rebooteroids, Tempest 2000, Missile Command 3D, and Downfall+, I have to assume they are using the 3D processor.

 

 

 

On another note (for everyone)... there's nothing more frustrating when a bunch of smart people get upset at each other. I work with the greatest number of geniuses in any single organization on the planet, and there's nothing more detrimental to a project than when they cannot get along. I know everyone has their different personalities... but please try to get along. I'm excited for ANYONE that spends any amount of time trying to develop for the Jaguar, whether or not it comes to any kind of fruition... this is a fun place for me to go when I'm procrastinating, and I hate to see people bicker about dumb crap... especially if that leads someone to getting banned.

  • Like 1
Link to comment
Share on other sites

What features are you adding to the terrain?

Well, it's a standard Heightmap-based terrain - e.g. you have a regular 2D grid, at regular spacing intervals, and each point is assigned a different elevation. I'm going to implement different rasterizers for it:

- flat-shading (will be fastest)

- textured - simple textures

- lightmapped (will look best) - textures+lightmaps (e.g. you can have shadows from trees and buildings on it) - I don't think NFS even has that (from the top of my memory)

Link to comment
Share on other sites

Lightmapped would be great, I guess some bends and hills in the road would help demonstrate this more effectively than a straight line though.

Yeah, the bends and hills will come automatically through the terrain, but for really good results for curves, the terrain will have to be designed by an artist manually (which I'm not really doing at the moment). Like I mentioned before, I didn't bother with curves for the previous build, as I knew I wanted a terrain anyway, so it would have been a completely wasted effort.

 

 

The Lightmapping would be especially great if I did a raycasting pre-pass during loading of the track. This could allow for a time-of-day feature, where the length of shadows would be directly dependant on sun's position in the sky, e.g. you could have really long shadows in the evening, or super short shadows at noon. Also, this pre-pass would allow for mixing the sun light's color with the terrain, so you would get blue hues for night, bright yellow for noon, and red at sunset.

 

All that would be just baked into the lightmap, during loading-time, so there would be no actual run-time performance penalty for any of that effect. But, it would greatly enhance the visuals and would allow you to choose day of time (like, say, in NFS3)

Link to comment
Share on other sites

I agree with Sauron.

 

Until you tax the bus you have no idea on final performance.

 

  • Do you have clipping implemented? Some of those buildings seem to just pop as they get near the edge.
  • Also, I noticed the textures were warping a bit as they got to the bottom of the screen, will that be fixed?
  • How about depth sorting?
  • You are only drawing the sides of the houses in this, when you have to draw the fronts and tops of things what about taking occlusion into account?
  • Are you going to be blitting the game objects onto the screen or using the OP? If it's the OP, you will have to re-sort objects each screen for depth and update the bit mangled list. Barrel operations are not cheap.
  • Also, what happens when a polygon occludes an Object Processor sprite, which will happen often when you get turns in? How will you mask that data?

 

Do not underestimate how much the DSP will impact on the bus. CPU load vs Bus load are vastly different.

 

As you were told on Jan 30, 2013...

 

post-11520-0-08880300-1484515944_thumb.jpg

 

But I'm sure you know all this already. Carry on, keen to see more.

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

I'd love 60fps flat shaded vs anything but 60fps with textures! Great old Playstation game called Tobal #1 did that. WAY more fluid than Tekken, I believe it ran at 640*480 too. Never wished to myself that the game was textured.

  • Like 1
Link to comment
Share on other sites

I've been a programmer for a couple of decades, never developed anything for the Jaguar or games for that matter, but I think the big part of his effort is to actually make use of the GPU and DSP chips... (Tom & Jerry). I don't say this with any authority, Albert & CryanoJ... please correct me... but if I'm not mistaken, a LOT of Jaguar games (both homebrew and originals, make use of the Motorola 68000 chip to pretty much do everything. I think what Vlad wants to do, is not do everything with the 68000 chip like most of the Jaguar games do, and instead really try to take advantage of Tom to do most of the heavy graphics processing.

 

Based on what I remember reading on here, is that most developers never really bothered to spend any time using those extra processors because it was too much effort. Instead, it was much easier to just port an existing game from the ST or whatever... onto the Jaguar. Now, when I look at a lot of the more in-depth games... like Rebooteroids, Tempest 2000, Missile Command 3D, and Downfall+, I have to assume they are using the 3D processor.

 

The GPU and DSP are great little beasties that are hampered by a ridiculously small amount of local RAM (4K and 8K respectively). Now if you can make your GPU and DSP programs do their own thing in their local RAMs and not hit the memory bus, you are golden. But in real games, the likelihood of that happening is pretty close to zero (the FACTS demo is the only piece of Jaguar software that I know of that does this, at least with the DSP). The overall system is hampered by its memory bus and having no mechanism to have the various processors be able to access the main RAM at the same time.

 

You cannot underestimate memory bus contention; it will kill the performance of your game. The thing is you have to remember that there aren't just three processors vying for the bus, there's actually the OP and the blitter too, making for five! Every time one of those makes an access to the main RAM, it holds the others up. Emulating this is very difficult--one of the biggest shortcomings of Virtual Jaguar (and there are many) is that it doesn't model bus contention at all.

 

And just to be clear: there is no 3D processor in the Jaguar--not a one. :)

  • Like 8
Link to comment
Share on other sites

Never understood the actual mission here... but I'm a tech-tard so, but still perplexed by all this.

Either one could try to port the actual 3DO Road rash to Jaguar/JagCD, and fail (I reckon)....

Or one could have all the components in the RR game represented in a similar game running on a Jaguar. Lets say a game with the same amount of sprites/moving objects on screen, textures all over, rolling hills together with a turning road, music playing, sound effects, 3D block buildings to smash into, cars or old men to smash into, being able to brawl with other bikers, moving in a speed that simulate the 3DO game feeling/good FPS... all at the same time! All of it running on the real Jaguar hardware. I guess this is the mission... or is it? Is this the case?

If you go for a JagCD let's see-tryout I know FMV would be a part of the deal, to finally be able to see a RR game on the system.



The tracks of rolling hills with forest and tunnels seem a bit over the top for Jaguar, but a street track seems more in the range of being possible. If this is your challenge it's interesting to see the development of it, and to know what finally made it too slow for a race game such as this or not. Edited by Atlantis
Link to comment
Share on other sites

Or one could have all the components in the RR game represented in a similar game running on a Jaguar. Lets say a game with the same amount of sprites/moving objects on screen, textures all over, rolling hills together with a turning road, music playing, sound effects, 3D block buildings to smash into, cars or old men to smash into, being able to brawl with other bikers, moving in a speed that simulate the 3DO game feeling/good FPS... all at the same time! All of it running on the real Jaguar hardware. I guess this is the mission... or is it? Is this the case?

You are actually completely correct. I don't have source code or original art assets of RR (but even if I had, it would not use it, as it'd be illegal, as EA owns the license), so this can only be about trying to match the amount of sprites/objects/textures/buildings (like you said). I'm going to change the art assets very soon after I get the terrain up.

 

 

The tracks of rolling hills with forest and tunnels seem a bit over the top for Jaguar, but a street track seems more in the range of being possible.

Correct. There is no doubt that the outdoor track will have a different framerate than a city one, as the polygon complexity is different. Then again, so does RR. You can see the framerate differences even in the YT video (which is interpolated by YT uploader), so in reality it must be worse.

In ideal case, there will be a 1 vblank difference between city track and outdoor track (e.g. 30 vs 20 fps), but it could very well be 2 vblanks (e.g. 30 vs 15 fps).

 

 

 

If this is your challenge it's interesting to see the development of it, and to know what finally made it too slow for a race game such as this or not.

I was explaining it in deep technical detail in last year's RR threads (it was a heavy argument that the city track in itself is completely within reach of jag - and I was right), but in short - the polygonal terrain will be slower than buildings, as the terrain is made of irregular polygons which take more GPU instructions to process (per same screen area) than building sides.

 

As for my current progress, I have a working test heightmap, that I can simply scale in all 3 dimensions, and have a 3d mesh constructed of it. Right now, I'm working on doing flatshaded polygonal fill of those polys (but that engine feature will be useful for many other games, not just RR), but it will take couple evenings. Not sure if posting a progress screenshot will just aggravate more people or be helpful, so I'll leave it.

  • Like 1
Link to comment
Share on other sites

 

As for my current progress, I have a working test heightmap, that I can simply scale in all 3 dimensions, and have a 3d mesh constructed of it. Right now, I'm working on doing flatshaded polygonal fill of those polys (but that engine feature will be useful for many other games, not just RR), but it will take couple evenings. Not sure if posting a progress screenshot will just aggravate more people or be helpful, so I'll leave it.

 

Post whatever you want to post, don't worry about the reaction from others.

  • Like 1
Link to comment
Share on other sites

 

Post whatever you want to post, don't worry about the reaction from others.

Thanks.

 

Here's the screenshot of the test terrain's point cloud :

post-19882-0-26496800-1484610832_thumb.jpg

 

- The heightmap test data is 8x16 points grid (from a text file), which seems very small, but it's for debugging purposes, so that I can at all times see all points and distinguish between them.

- The code is generic, and does not care if it's 8x16 or 100x10000 (other than the performance hit, obviously)

- the terrain is scaled along all axis (X or Y or Z) using simple constants at run-time - e.g. same data set can be 10 meters wide/tall/deep or 10 miles.

- I didn't post the wireframe, as it's too messy. Point cloud makes it easier to distinguish the terrain elevation changes

- this kind of terrain can be later used for outdoor FPS/RPG/action games too. But, it's quite possible that voxel is a better option on Jag for those games.

 

Right now I'm working on efficient fill of the polygons (flat-shading first, texturing next).

  • Like 5
Link to comment
Share on other sites

Thanks.

 

Here's the screenshot of the test terrain's point cloud :

attachicon.gifP_Jan16_184952.jpg

 

- The heightmap test data is 8x16 points grid (from a text file), which seems very small, but it's for debugging purposes, so that I can at all times see all points and distinguish between them.

- The code is generic, and does not care if it's 8x16 or 100x10000 (other than the performance hit, obviously)

- the terrain is scaled along all axis (X or Y or Z) using simple constants at run-time - e.g. same data set can be 10 meters wide/tall/deep or 10 miles.

- I didn't post the wireframe, as it's too messy. Point cloud makes it easier to distinguish the terrain elevation changes

- this kind of terrain can be later used for outdoor FPS/RPG/action games too. But, it's quite possible that voxel is a better option on Jag for those games.

 

Right now I'm working on efficient fill of the polygons (flat-shading first, texturing next).

 

VLM Rider 2000 ;-)

  • Like 1
Link to comment
Share on other sites

why so complicated?

 

look at WIP: Not Outrun

 

there the basic roadrash engine is already done !!

Just add you "textured" houses and hills on bouth sides of the road and you got your 3do roadrash engine (or better) on the Jag ;-)

(maybe you find a way to align the textures to the old fashioned simple roadengine, thats it.. they done nothing else back on 3DO roadrash)

as you see on Burnout the jag can do much much better roads than the 3DO :-D

 

Your favorit Chairman has spoken

Edited by Otto1980
Link to comment
Share on other sites

why so complicated?

 

look at WIP: Not Outrun

 

there the basic roadrash engine is already done !!

Just add you "textured" houses and hills on bouth sides of the road and you got your 3do roadrash engine (or better) on the Jag ;-)

(maybe you find a way to align the textures to the old fashioned simple roadengine, thats it.. they done nothing else back on 3DO roadrash)

as you see on Burnout the jag can do much much better roads than the 3DO :-D

Because there is a huge feature and qualitative difference between 2D scanline road (ala Outrun) and 3D polygonal road (ala NFS). The 2D road cannot adjust perspective and angle with the change in 3D camera.

 

Why on earth would I be wasting time on creating 37th version of a 2D scanline road, that we all know jag can do very well at 200 fps ?

 

My last year's RR alpha had something in between the 2D scanline and 3D polygonal road - it was 2D scanline, but textured. Now, the road is 3D mesh and is textured accordingly.

 

I can always revert back to the last year's OP-based compromise, once performance becomes important, as that way I can gain almost 1 vblank worth of GPU time.

 

We're not there yet.

Link to comment
Share on other sites

why so complicated?

 

look at WIP: Not Outrun

 

there the basic roadrash engine is already done !!

Just add you "textured" houses and hills on bouth sides of the road and you got your 3do roadrash engine (or better) on the Jag ;-)

(maybe you find a way to align the textures to the old fashioned simple roadengine, thats it.. they done nothing else back on 3DO roadrash)

as you see on Burnout the jag can do much much better roads than the 3DO :-D

 

Your favorit Chairman has spoken

Surely that's too much of a ridiculously sensible suggestion!

 

Seriously though it may be something you should consider if you've been at this for three years already.

 

Maybe the developers of not outrun or gem racer would allow you to test your theorys on something much further along than what you currently have. Surely this would save you some time and maybe make some new friends at the same time!

Link to comment
Share on other sites

why so complicated?

One more thing. 2D approach does not allow for change in resolution.

 

While working on RR alpha, I'm creating all core 3D engine functionality that can then be very simply reused for any other game or demo.

 

Most importantly, I'm building the engine generic enough, so that it can handle different resolutions. I'm not using any hardcoded constants for resolution. All computations and clipping are based on resolution variables, so changing resolution should be very simple.

 

Example - flatshading at 640x200 should be doable at 20-30 fps. Wouldn't you like to see higher-resolution 3D on jag ?

 

Well, maybe you don't, but I'm personally curious. Hell, it's my free time I'm burning here...

  • Like 1
Link to comment
Share on other sites

Because there is a huge feature and qualitative difference between 2D scanline road (ala Outrun) and 3D polygonal road (ala NFS). The 2D road cannot adjust perspective and angle with the change in 3D camera.

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 .. :-o (see link below)

 

The 2D road cannot adjust perspective and angle with the change in 3D camera.

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 :-o

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

Link to comment
Share on other sites

Seriously though it may be something you should consider if you've been at this for three years already.

Three years ? What are you talking about ? I spent less than 2 weeks on the previous RR prototype (a year ago in December). Didn't touch it since then till now.

 

 

Maybe the developers of not outrun or gem racer would allow you to test your theorys on something much further along than what you currently have. Surely this would save you some time and maybe make some new friends at the same time!

Let's entertain this idea for a bit. Please clarify what exactly do you mean, as I don't think you thought it through - let me explain:

1. Neither of them has a 3D engine, so they can't really "test my theories", even if they wanted (which I 100% presume they for sure don't want)

2. Even IF they had their own 3D engine, that test you propose would only test the efficiency of their 3D engine, so it really would not prove much in general, as a 3D engine can be endlessly optimized and rearchitectured.

 

Question 1: How exactly would the above save my time ? Please elaborate.

Question 2: When did I say I want to save my time ?

Question 3: What makes you think I would stop working on my own 3D engine for jag just because someone else played with a racing genre ?

 

Just curious, that's all.

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...