Road Rash pre-alpha on Jaguar at 30 fps

[NeoGeo64]

Yeah, I just noticed I messed up your name! haha sorry

[VladR]

- I was able to squeeze a bit more performance from my current edge traversal algorithm and jump from 50.1 fps to 54.3 fps, at the cost of additional 120 Bytes, which I think is a fair deal.

- I can reach 60 fps just fine, if I slightly reduce the viewport, though

- Implementing new edge traversal should tip me over 60 fps, but for now I'm finally getting comfortable with the current performance(I have a buffer of 90% of one vblank for the 30 fps lock), so I'll leave that exercise for later

- I'll now go and finish the integration with the terrain as I still don't know how fast the terrain actually is, plus it's necessary for NFS / RR anyway

[cabear]

great work vladR, i'm curious though, i know what you're doing with the wipeout code and using the 3d stuff, but how do you think a road rash type game would run on the jaguar using the original non-3d engine?

[VladR]

great work vladR, i'm curious though, i know what you're doing with the wipeout code and using the 3d stuff, but how do you think a road rash type game would run on the jaguar using the original non-3d engine?

Thanks. Let's break it down.

 

There's 3 basic rendering components in RR:

1. 2D Scanline Road

2. 2D props (sky, bikes, road-side objects)

3. 3D Buildings OR 3D Terrain

 

Why am I breaking it down to separate components ? Because due to the unique architecture of Jaguar, if you are willing to undergo the additional coding complexity of syncing (which I am), you can have multiple different framerates.

This will enable you to have:

1. 60 fps framerate on input and 2D stuff (sky, bike, roadside objects)

2. sub-60 fps framerate on 3D stuff

 

Road:

- I have 2 versions

- 1. C-based (68000), scanline approach runs on OP : runs at the moment at 30 fps, but at the cost of additional memory can be easily upgraded to 60 fps. Does not take away fillrate texturing performance of GPU

- 2. gpu-based, texturing approach: runs at 60 fps, but costs almost full vblank, so any additional texturing (e.g. buildings) will directly reduce performance. I will use this one for NFS-based engine, as NFS road is polygonal. The generic texturing ability is not needed for RR at all. But, it's good to know its performance characteristics at this moment.

- I am obviously leaning towards version 1, as it does not directly reduce further performance, but I want to rewrite it, since I learnt quite few new things since last year when I implemented it first.

 

Props:

- OP renders them, so it's literally no reason for it to be less than 60 fps (unless you are abusing fillrate, which we do not, as this is 256 colors mode), as the performance cost associated with them is one 3D transform and update 3-4 values in OP list, which is roughly 0.5% of GPU's throughput (if, at all)

 

3D Buildings:

- My current version can texture the buildings in 60 fps, but costs full vblank, so any additional texturing (e.g. buildings) will directly reduce performance

 

3D Terrain:

- this is the wild card : performance depends directly on screen coverage

- these sections will have lowest framerate (which is what I've been saying since the beginning 2 yrs ago - that the city segment is best candidate on jag)

- Best-case scenario for this component is going to be 2 vblanks, e.g. 30 fps

- This is what I'm working on right now, although, admittedly, my level-of-detail approach is overkill for RR purposes

 

We obviously don't want to combine textured buildings with 3D textured road, as that's 2 vblanks gone right away, so this leaves us with scanline road and textured buildings.

 

But this approach, although more complex to implement, is playing directly to jaguar's strengths and works great for player. Why ? Because what matters most is the input and sensitivity of controls. Your eyes are directly watching the bike and road, which will have 60 fps. Same for road-side objects. So, this will be as smooth as possible.

 

Only the 3D portion will have variable framerate, directly dependent on the 3D scene complexity (be it terrain, buildings, whatever). Which is exactly the same problem as with any other HW platform on the planet - be it PC or PS4. So, some section will run at 53 fps, some at 37, and some at, say, 15 fps. Technically, it is a separate bitmap in the OP List, so we update the OP List with 3D scene once we're done rendering the 3D scene, otherwise, automatically, OP uses last frame's bitmap without any effort on coder's side.

 

But your bike, your controls, and the road will be 60 fps.

 

I'm considering building the engine in a way that the option of vsync will be on the player - so you can choose tearing vs maximum performance on 3D components, based on your personal preference. Some people are more sensitive to tearing, some just want max.performance and don't care for tearing whatsoever.

 

Of course, the above 3D numbers are for single-threaded 3D engine. If one was to engage in, say, writing a multi-threaded renderer for jag, the framerate on 3D component would go obviously up

Edited March 10, 2017 by VladR

[cabear]

excellent explanation. Thank you sir and good luck with your findings!

[phoenixdownita]

Was there any more progress?

[VladR]

Yes, 2 weeks ago I finished the integration with the terrain component,but the framerate dropped below 2 vblanks (around 25 fps). Looks like I need to tweak the distribution of the polygons, as too many are in the first LOD chunk.

 

When I was doing that, I noticed a rendering glitch, which is also contributing to the performance hit, so I gotta fix that first, but didn't get to it last 2 weeks.

 

 

I'm hoping things at work normalize and I'll be able to resume super-early morning coding (before going to work), as that's when I'm absolutely most productive, and even 60-90 minutes result in major progress.

[tschak909]

I guess the only problem I see here, is that, despite lots of talking about how awesome this engine is, I have yet to see either:

 

* An in-depth explanation of the Jaguar GPU units, or

* some code. (and this is one of those things that gets me across all these threads...why people don't post their stuff on github for peer review, etc?)

 

But hey, what do I know? Maybe some people gain advantage to keeping their cool tricks for a retro-gaming platform close to their chest?

 

-Thom

[VladR]

I guess the only problem I see here, is that, despite lots of talking about how awesome this engine is, I have yet to see either:

 

* An in-depth explanation of the Jaguar GPU units, or

* some code. (and this is one of those things that gets me across all these threads...why people don't post their stuff on github for peer review, etc?)

 

But hey, what do I know? Maybe some people gain advantage to keeping their cool tricks for a retro-gaming platform close to their chest?

 

-Thom

I understand -from your nick- you're active in the 8-bit section of these forums. That's a completely different environment.

 

If you want to know reasons, why don't you spend 2 minutes, go back few pages and read my explanation over several posts ?

 

 

Maybe some people gain advantage to keeping their cool tricks for a retro-gaming platform close to their chest?

Tricks ? You're funny There's no trickery involved, just willingness to roll up your sleeves and get down and dirty with the RISC assembler, and keep refactoring and optimizing. And again and again.

 

That is, unless you consider Software Engineering and Research&Development a Sorcery

 

I'm pretty certain you are thinking of "tricks", which are used in Atari 800 - and yes, there's really lots of actual HW tricks on 6502 (and yes, I did lots of Atari 6502 ASM coding over quarter century ago, so I know what you're talking about, plus I keep passively following recent developments there).

 

 

But what you see here, is really only a result of those 2 things above:

1. Research&Development : Coming up with 3D rasterizing algorithms that are suited for Jaguar's architecture (no, you can't google them, that's the stuff you actually gotta come up with by yourself (duh!) - if you go implement Michael Abrash's Black Book algorithms from PC architecture, you won't get above 3-5 fps on Jag's architecture, so you gotta come up with something different)

2. Software Engineering : iterative development and optimizing (e.g. having determination and motivation)

 

So, no tricks. Just Do The Shit

[tschak909]

As for "shit" .. you talk a lot of "shit" and assume way too much, of me. I am a software engineer with three decades of experience under my belt for various systems, currently doing R&D work for Ericsson.

 

(as in, you may want to revise your tone, with me, lest I embarrass you.)

I am merely asking to see code, so that I can look at it.

If you don't want to do that, I can only assume two things:

 

(a) you're wanting to keep it close to your chest, for whatever reason. I've seen many a people do that, only to have their techniques lost because they were greedy fucks.

(b) You actually are lying to us, and have nothing real to show.

 

Either way, pretty dickish of you.

 

-Thom

[JagChris]

As for "shit" .. you talk a lot of "shit" and assume way too much, of me. I am a software engineer with three decades of experience under my belt for various systems, currently doing R&D work for Ericsson.

 

(as in, you may want to revise your tone, with me, lest I embarrass you.)

I am merely asking to see code, so that I can look at it.

 

If you don't want to do that, I can only assume two things:

 

(a) you're wanting to keep it close to your chest, for whatever reason. I've seen many a people do that, only to have their techniques lost because they were greedy fucks.

(b) You actually are lying to us, and have nothing real to show.

 

Either way, pretty dickish of you.

 

-Thom

I am sorry but disagreements such as this must be settled in a code off competition between you two per the AA guidelines.

[+Stephen]

I am sorry but disagreements such as this must be settled in a code off competition between you two per the AA guidelines.

Only if the code is shared.

[Stage_1_Boss]

First person to make Road Rash playable on the Jaguar wins? (along with the rest of us)

[VladR]

As for "shit" .. you talk a lot of "shit" and assume way too much, of me. I am a software engineer with three decades of experience under my belt for various systems, currently doing R&D work for Ericsson.

 

(as in, you may want to revise your tone, with me, lest I embarrass you.)

 

I am merely asking to see code, so that I can look at it.

If you don't want to do that, I can only assume two things:

 

(a) you're wanting to keep it close to your chest, for whatever reason. I've seen many a people do that, only to have their techniques lost because they were greedy fucks.

(b) You actually are lying to us, and have nothing real to show.

 

Either way, pretty dickish of you.

 

-Thom

Uhm, what exactly did I assume about you?

 

Because I didn't really assume anything till you posted again!

 

As for my tone, I believe I was nice, yet somehow you interpreted it wrong. Cannot help with that unfortunately.

 

And if you have 3 decades of SW engineering as you claim, how could you possibly have missed the iterative progress on my engine, clearly showing gradually enhanced feature-set?

 

And I have been sharing technical info on my findings multiple times, just go back and read the thread. Yet you clearly did not do it.

 

But you clearly only wish to engage in unprovoked attacks, so there is no point in trying to reason with you.

 

 

 

 

Thank god for the Ignore button on the forums. I don't wish to engage in flamewar, so best to stop feeding the trolls...

[phoenixdownita]

News? Videos?

[JagChris]

Only if the code is shared.

There is plenty of code 'out there' in the direction this is going that is ignored from those far more experienced with the Jaguar. Until what is out there is shown to have been studied, utilized by those demanding others to share their code these demands seem to be being made just to do so.

[VladR]

News? Videos?

Well, my 60" TV broke last Sunday, so I was involuntarily forced to put a halt to a 3-week Mass Effect marathon

 

Thus, this early morning I had no excuse, but to resume jag coding

 

I am very happy to report that I found out that the rendering glitch is not due to flatshading rasterizer, but merely transformation stage (which is order of magnitude easier to debug than flatshader, so should be fixable in my next 2-hr coding session on Friday morning). So, a weekend video is highly likely.

 

More importantly, this weekend I don't have to work (unlike previous ones), so I can spend some time on this and hopefully make a bigger dent into the code again!

[Machine]

Well, my 60" TV broke last Sunday, so I was involuntarily forced to put a halt to a 3-week Mass Effect marathon

 

Was it a Sony?

 

Looking forward to another update. I like watching your progression.

[Gentlegamer]

Well, my 60" TV broke last Sunday, so I was involuntarily forced to put a halt to a 3-week Mass Effect marathon

 

 

 

It's all for the best.

[VladR]

There is plenty of code 'out there' in the direction this is going that is ignored from those far more experienced with the Jaguar. Until what is out there is shown to have been studied, utilized by those demanding others to share their code these demands seem to be being made just to do so.

Exactly my point. Has anyone ever taken all those complete source codes and at least, say, mod those games (not saying make a new game or optimize the engine) ?

 

For how long have those codes been out there ? There's like 5-10 (don't remember exact number now) complete game source codes.

 

So, I don't really see a point in throwing my source code out there, just to rot, unused.

 

 

I'm much more inclined, however, to link it with my VRBasic (that's been left untouched for few years now, but jag's not going anywhere either).

 

I'm guessing that would actually be two orders of magnitude more accessible than RISC asm (which is not exactly an easy read after you detach yourself from the code, in all honesty). Hell, it's my code, very, very heavily commented (there's more comment lines than actual code lines!), it's been about 6-8 weeks since I touched it last, but spent first hour this morning in one massive whiskey-tango-foxtrot grin expression.

 

But, if it was linked against my VRBasic lib, then it actually could be used very easily, as you could use simple VRBASIC syntax like:

Load3DMesh ("C:\jag\artassets\Spaceship.ASE", SpaceShip) ; Import 3Dsmax model

SetCameraLookFrom (0,0,0)  ; Camera Origin
SetCameraLookAt (0,0,-100)  ; Camera Destination

SetWorldPos (SpaceShip, 10,0,-180) ; Set 3D position of our SpaceShip
SetRotationZ (SpaceShip, 45) ; Z-Rotation Angle [in degrees]
SetRotationY (SpaceShip, 180) ; Y-Rotation Angle [in degrees]

; RenderWireframe (SpaceShip)

RenderFlatShade (SpaceShip)

Now, that, for sure, would give more to the coding community than, yet-another-assembler-engine...

 

 

 

Was it a Sony?

 

Looking forward to another update. I like watching your progression.

Nah, I got burnt very badly in past on ultra-expensive TVs, so now I only buy the cheapest ones - this one was Westinghouse. Hell, I literally broke 2 TVs in my last year's move.

 

This time, it was a static electricity from my carpet. I noticed recently, the screen went blank for few seconds when changing volume, each time hearing the static electricity spark (at night, you can literally see the spark). After about a year of this abuse, the TV is in a constant channel-change loop. I'll see if there's a way to do a factory reset, but I doubt that'll overcome the damaging power of static electricity...

 

In worst case, I'll just post a YT video of me&Hammer&TV on that "Break your sh*t" channel

 

 

And I'm glad to hear someone still reads this !

 

 

It's all for the best.

It actually is. My lease is up soon, so I'm gonna move in 6 weeks, and this gives me a nice excuse to buy a 4k TV and get a second PS4 that will finally support 4k. And it just so happens, that the weekend of the move is the Memorial Day weekend - hence brutal sales everywhere

 

But in all seriousness, it's better to spend the mental energy challenging your brain in RISC ASM, rather then brainlessly shooting random sh*t on playstation

[Gentlegamer]

 

 

It actually is. My lease is up soon, so I'm gonna move in 6 weeks, and this gives me a nice excuse to buy a 4k TV and get a second PS4 that will finally support 4k. And it just so happens, that the weekend of the move is the Memorial Day weekend - hence brutal sales everywhere

 

But in all seriousness, it's better to spend the mental energy challenging your brain in RISC ASM, rather then brainlessly shooting random sh*t on playstation

 

I was actually referring to the end of your Mass Effect playing. *troll face*

[VladR]

I was actually referring to the end of your Mass Effect playing. *troll face*

Certainly, there's a direct correlation between amount of time spent on ME vs jag

But, my Husky's been enjoying these last 3 days as well, we spent about 6-7 hours in the park, so it really is for the better

 

Anyway, I just fixed the glitch (so there's some semblance of progress). Turns out it wasn't a bug with either Transformation or rasterizing, merely unfinished feature of the LOD indexing - completely forgot about the state I left it at (I stepped out in the middle out coding aaaand didn't get back to it for next 6 weeks).

 

So, here's a quick screenshot (had to place camera waaay up and back to see all of them) from my TVR VideoOut SW, depicting all 4 terrain chunks at 3 LODs:

 

Gotta run to work now, video will happen during weekend...

[VladR]

When I was posting the screenshots on Thursday morning, I had no idea there was a 3.5-day weekend (a rare thing in U.S. compared to EU), so I used it for a hiking trip.

 

Just got back home, implemented the LOD transition feature (there was just a black gap between LODs until now), and was able to record a short video:

 

This, is one important step closer, to figuring out if Jag can [at least remotely] handle something like 3DO's Crash n Burn's insane drawing distance, as we discussed couple pages back with sirlynxalot.

 

Thanks to the LOD, the distant chunks (where the most of actual polygons are) take up only small portion of the frame time, as they're reduced to just 16 triangles, and each is occupying very small screen space, so its fillrate cost is minimal. Right now I have 4 chunks (1,024 triangles), but there was almost no measurable performance drop when I doubled the polygons in the scene to 2,048, as they all got reduced to lowest LOD.

 

So, the drawing distance is not really a problem in itself, as terrain chunk switching is really just few instructions on the GPU (I made sure of that).

 

The greatest, remaining, unimplemented (as of now), problem is thus performance impact of texturing - which remains to be seen (until I actually implement it, but flatshading is an obvious prerequisite for texturing). I'm already paying the performance price of edge sorting, pixel fillrate, and triangle scanline rasterizing, so arguably, adding simple texturing to the mix shouldn't really cost more than 2 vblanks.

 

So, we should still be theoretically able to hit 4 vblanks, hence 60/4 = 15 fps textured with single-threaded renderer. If I was to write a multi-threaded renderer, then there's zero doubt that 15 fps [textured] (like on 3DO), is doable.

 

We'll see. Getting closer....

 

Of course, the work above, does not translate directly towards Road Rash, but mostly towards NFS/CnB.

[VladR]

Small engine update:

- implemented run-time LOD switch based on camera distance (until now, the terrain chunks were just sorted from highest LOD to lowest LOD), so it's finally fully generic now, regardless of camera direction

- reduced code's memory footprint by ~300 Bytes doing refactoring, so right now the code takes up 3,480 Bytes, meaning I got 616 Bytes free

- looks like those 616 Bytes might be enough for texturing. I'm pretty sure texturing would fit into the wipeout codepath (as that one is just ~2,800 Bytes), but terrain handling+LOD takes up additional 0.7 KB, so up until now I didn't really believe it could be done with LOD terrain (without swapping code between RAM and cache), but now it's looking like it actually should fit

- I still want to experiment a bit with flatshading's performance before going for texturing - probably will go for a test scene (with terrain) along the lines of Checkered Flag (though CF has a fog, so I will have to implement that first)

[VladR]

Looks like I'm soon going to have another Atari to try my RISC Assembler 3D engine on

 

I was very lucky and eBayed a dirt-cheap Falcon 030 (14 MB RAM, 4 GB CF) with broken case that does not close, but it's booting up (supposedly, as per the seller's video). It was only $1,200, so -duh- it's along the lines of "if it's too good to be true, it probably is", but hell, I couldn't pass such an opportunity to get this rare beast!

 

From an [admittedly very brief] look on Falcon's DSP instruction set, it looks like porting from jag's GPU should not be a big deal. And while there's a very strong demoscene presence (+dml) on Falcon, over the next few years, I -eventually- should be able to make a dent there, too. Assuming, of course, I advance steadily on jag, as that's always going to be the baseline for my Falcon coding.

 

Wish me luck that it arrives in bootable condition this weekend