Jump to content
IGNORED

Road Rash pre-alpha on Jaguar at 30 fps


VladR

Recommended Posts

 

This one is only 96kb:

 

http://www.pouet.net/prod.php?which=50467

I thought Facts was 64 KBs, but I must have remembered wrong. Thanks for the link, I'm browsing the pouet.net for more jag compos.

 

Any idea if there's some Atari demo compo in May 2017 ? SV is in November, which is far away.

 

I don't want to make any promises, but if I don't burn out next month (this current coding spree is probably the longest one I ever had in my free time), this might provide enough motivation to finally include some audio library into my engine (and it would finally shut up everybody bitching about no audio, too).

 

 

EDIT: Looks like there's outline 2017 in May 2017:

https://www.facebook.com/events/925448350887253/

 

Worth polishing the engine a bit more and start throwing in some effects and importing 3D meshes, I guess...

Edited by VladR
  • Like 1
Link to comment
Share on other sites

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

 

Cool your jets there Hoss.

 

As I said, i've been enjoying the thread and am following you developments every day.

 

My point was this: you may be getting x frames per second in your code but without user interaction, sound, opposition sprites and collision detection etc. then the headline number is speculative at best. I know some of these things may not impinge on performance, but some definately will, and every t-state counts in older hardware where memory, processing power and bandwidth are at a premium.

 

Again i'm not criticising your work, just trying to keep expectations realistic.

 

Oh and whilst my raw maths talent is not brilliant - I code business inteligence software for a living - so your assumption that I have not understood your technical descriptions is a bit condescending.

Link to comment
Share on other sites

 

Sir, I have to officially thank you for this link :)

 

I was rewatching it for 5th time, while drinking coffee, and then it hit me, how exactly Wipeout is cheating.

 

There's huge amounts of triangle set-up, line set-up and 3D transform set-up code chunks (quite a few pages of code per each vertex!) that could be entirely avoided by using the WipeOut Cheat (I just named it :) )

I've tested the idea on 2 polygons by quickly bypassing the code above (and interpolating appropriately) and it actually works!

 

 

I don't have the scene benchmark numbers, as I'd need some proper WipeOut track 3D data. I'll see about creating few rooms and chaining them together tomorrow. I also made sure it's generic enough for any type of polygon orientation, I tested it on skewed rotated polygon whose edges were shaped in all kinds of angles - so it's going to work nicely in a generic form (not just vertical or horizontal walls - like in RoadRash).

 

And while the bandwidth cost of rasterizing the wireframe can't really be avoided, this should still raise the scene complexity and vertex density significantly.

 

I wouldn't have gotten this idea today, if you didn't provide me with this link, so let me give credit where credit is due ;)

Is this going to turn into Wipeout: Jaguar edition? XD

Link to comment
Share on other sites

Is this going to turn into Wipeout: Jaguar edition? XD

Well, the Wipeout codepath is really merely a debugging/testing grounds for the flatshading (albeit pretty fun for me as I'm huge fan of Wipeout).

It's going to be used like that also for the opponent meshes. Arguably, at that point, it might finally make sense to introduce input and make it somewhat playable.

 

And, unlike RoadRash, which is a hybrid of 2D//3D, this is purely polygonal, so it's somewhat more exciting for me.

 

But really, one track is the most you could hope for, so don't expect full game or anything like that. But you know that already, don't you ;)

 

Although, if there was a volunteer 3D environment artist, I could spend a weekend creating a toolchain for him to import the 3D tracks from 3dsmax, so we shouldn't completely rule it out either...

 

Of course, having spent 1000+ of hours working in 3dsmax myself on lots of meshes, texturing and levels, I have the skills to create the 3d tracks myself, but I don't exactly fancy that kind of work - I really vastly prefer coding...

Link to comment
Share on other sites

Oh and whilst my raw maths talent is not brilliant - I code business inteligence software for a living - so your assumption that I have not understood your technical descriptions is a bit condescending.

Based on my lifelong experience, only a very small percentage (<5%) of "business coders" has any understanding about 3D engines whatsoever. Majority are actually of the idea that creating a GUI front-end (through a clicker IDE of any high-level language) is much bigger technological achievement than writing, say, 3D engine from scratch, because - quote "it's just stupid, bloody games" end-quote.

It's literally a waste of the breath...

 

 

the headline number is speculative at best.

ROFLMFAO. It's been covered few times, but clearly it did not click.

Let's break it down again, but this time, I'll try to avoid technical language, to make it easier for you:

 

For Road Rash, we need to render:

1. OP List of bitmaps (ObjectProcessor renders them at 60 fps)

2. OP List of road scanlines

3. 3D buildings (running on GPU at 50-60 fps)

 

Both No1 and No2 work right now from high-level C running on 68000 at 60 fps (I also have a GPU version that is not scanline based).For different reasons, I'm currently leaning towards limiting road scanlines to just 30 fps, as that's enough and it makes things veeeery easy while coding (if you just stick to 2 vblanks).

 

Hence 30 fps - just because I'm lazy. if I REALLY, REALLY wanted, a scanline RoadRash could be very probably optimized to 60 fps with audio effects (just no music, but who knows-perhaps CD Audio could work - but no experience there, so don't really know about CD Audio impact on performance).

 

I'm absolutely confident that on PAL, full 50 fps are doable, assuming I'd be willing to start using DSP for non-audio tasks (as sound effects do not take up full vblank on DSP) and if I spent 1 day rewriting OP List creation on GPU (it's running on 68000 now). But, I'm lazy, so I'll just stick to 2 vblanks, leaving 90% of second one for audio/bandwidth slowdown/input/gameplay.

 

That's 90% of DSP time (147,000 instructions), 90% of GPU time (another 147,000 instructions) and 90% of 68000 time (literally a shitload of instructions per frame) within one vblank.

 

Are you really so clueless coder that you're telling me that checking input, updating few arrays with new (x,y) positions and animation frame index (idxFrame) , checking player's (x,y) against those 2 AI sprites and against array of screen boundaries (collision detection), updating time counter will take more than 294,000 instructions (and there's still 68000 available) ? Seriously ?!? Jesus Christ... SMFH

Link to comment
Share on other sites

https://www.youtube.com/watch?v=T2NsTi_43g4

 

VladR, on 24 Feb 2017 - 10:25 PM, said:

Are you really so clueless coder that you're telling me that checking input, updating few arrays with new (x,y) positions and animation frame index (idxFrame) , checking player's (x,y) against those 2 AI sprites and against array of screen boundaries (collision detection), updating time counter will take more than 294,000 instructions (and there's still 68000 available) ? Seriously ?!? Jesus Christ... SMFH

 

 

Really? Necessary? He hadn't said anything to warrant that kind of reaction.

 

 

That's 90% of DSP time (147,000 instructions), 90% of GPU time (another 147,000 instructions) and 90% of 68000 time (literally a shitload of instructions per frame) within one vblank.

 

You won't get anywhere near those numbers with all 3 CPUs (plus the Blitter, plus the Object Processor) hitting the bus at the same time.

  • Like 4
Link to comment
Share on other sites

I checked the pouet again and it looks like Falcon has hundreds of demos.

 

The discrepancy against Jaguar is huge. Do you happen to know why would that be ? Considering the price of Falcon, it's quite surprising. Or is it merely because it was a workstation, so it was primarily bought by programmers ?

 

What do you think ?

Link to comment
Share on other sites

It's sad we'll never know for sure.

 

Are you really so clueless coder that you're telling me that checking input, updating few arrays with new (x,y) positions and animation frame index (idxFrame) , checking player's (x,y) against those 2 AI sprites and against array of screen boundaries (collision detection), updating time counter will take more than 294,000 instructions (and there's still 68000 available) ? Seriously ?!? Jesus Christ... SMFH

Link to comment
Share on other sites

Based on my lifelong experience, only a very small percentage (<5%) of "business coders" has any understanding about 3D engines whatsoever. Majority are actually of the idea that creating a GUI front-end (through a clicker IDE of any high-level language) is much bigger technological achievement than writing, say, 3D engine from scratch, because - quote "it's just stupid, bloody games" end-quote.

It's literally a waste of the breath...

 

 

ROFLMFAO. It's been covered few times, but clearly it did not click.

Let's break it down again, but this time, I'll try to avoid technical language, to make it easier for you:

 

For Road Rash, we need to render:

1. OP List of bitmaps (ObjectProcessor renders them at 60 fps)

2. OP List of road scanlines

3. 3D buildings (running on GPU at 50-60 fps)

 

Both No1 and No2 work right now from high-level C running on 68000 at 60 fps (I also have a GPU version that is not scanline based).For different reasons, I'm currently leaning towards limiting road scanlines to just 30 fps, as that's enough and it makes things veeeery easy while coding (if you just stick to 2 vblanks).

 

Hence 30 fps - just because I'm lazy. if I REALLY, REALLY wanted, a scanline RoadRash could be very probably optimized to 60 fps with audio effects (just no music, but who knows-perhaps CD Audio could work - but no experience there, so don't really know about CD Audio impact on performance).

 

I'm absolutely confident that on PAL, full 50 fps are doable, assuming I'd be willing to start using DSP for non-audio tasks (as sound effects do not take up full vblank on DSP) and if I spent 1 day rewriting OP List creation on GPU (it's running on 68000 now). But, I'm lazy, so I'll just stick to 2 vblanks, leaving 90% of second one for audio/bandwidth slowdown/input/gameplay.

 

That's 90% of DSP time (147,000 instructions), 90% of GPU time (another 147,000 instructions) and 90% of 68000 time (literally a shitload of instructions per frame) within one vblank.

 

Are you really so clueless coder that you're telling me that checking input, updating few arrays with new (x,y) positions and animation frame index (idxFrame) , checking player's (x,y) against those 2 AI sprites and against array of screen boundaries (collision detection), updating time counter will take more than 294,000 instructions (and there's still 68000 available) ? Seriously ?!? Jesus Christ... SMFH

 

Your right i've never coded a 3d engine - never needed one to to deal with a business that that turns over £5m a year, but I can say that that coding software for business is a damn sight more complicated than building GUI's ( ERP, CRM etc ) - and i'm faily competent at coding in z80 and arm assembler as thats another thing I have to deal with at work.

 

However, again, i'm not p***ing on your chips or trying to talk down what you've presented, it's just you can throw as many numbers about as you want, but until it translates into a controllable sprite/entity that can interact with the track/surroundings in real time with some sound then all your framerates are immaterial.

 

And the reason I say this is because ate the heart of all this is the fact the Jaguar is a GAMES console and it's sole purpose to exist is to play GAMES.

 

Like I said in my earlier post, keep plugging on, it's not something I could do cos I don't really understand the 3D math, and I am rooting for you to succeed in producing a playable demo of whatever you end up with - cos imho that needs to be the goal.

  • Like 1
Link to comment
Share on other sites

Well, the Wipeout codepath is really merely a debugging/testing grounds for the flatshading (albeit pretty fun for me as I'm huge fan of Wipeout).

It's going to be used like that also for the opponent meshes. Arguably, at that point, it might finally make sense to introduce input and make it somewhat playable.

 

And, unlike RoadRash, which is a hybrid of 2D//3D, this is purely polygonal, so it's somewhat more exciting for me.

 

But really, one track is the most you could hope for, so don't expect full game or anything like that. But you know that already, don't you ;)

 

Although, if there was a volunteer 3D environment artist, I could spend a weekend creating a toolchain for him to import the 3D tracks from 3dsmax, so we shouldn't completely rule it out either...

 

Of course, having spent 1000+ of hours working in 3dsmax myself on lots of meshes, texturing and levels, I have the skills to create the 3d tracks myself, but I don't exactly fancy that kind of work - I really vastly prefer coding...

If I could program, I'd do it :) Or if it could be done in a relatively easy way, I'd also do it, I'd love to play 'Wipeout' on Jaguar xD If you think I'd be able to do it, then I volunteer as tribute ahaha... Though I'd have to learn how to use 3DSMAX Edited by LianneJaguar64
Link to comment
Share on other sites

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

I'm not exactly sure if flatshading would go well with some detailed background - meaning if it would match together very well. Perhaps if the background wasn't a photo or a render - ideally something in the same visual style (e.g. polygonal, or only slightly shaded). That's where the proper 2D artist would come in handy for sure :)

 

Do you have any specific "driving&shooting" game in mind (for my reference) ? Only thing that comes to my mind now is Interstate'76. Surely there have been hundreds of other racing&shooting games on consoles of that era (I spent that decade playing on PC, so I'm unfortunately completely clueless on console games of that era).

 

Then again, you can also shoot in Wipeout, so I might just stay within the confines of current build ?

Link to comment
Share on other sites

If I could program, I'd do it :) Or if it could be done in a relatively easy way, I'd also do it, I'd love to play 'Wipeout' on Jaguar xD If you think I'd be able to do it, then I volunteer as tribute ahaha... Though I'd have to learn how to use 3DSMAX

Then I'm afraid you'd have to sacrifice yourself and just do bug/playtesting ;)

Link to comment
Share on other sites

I'm guessing 3DSMAX is difficult then :P But as I say, if it can be done, I'll do it! <3

While 3dsmax has a massive feature-set, the basic anorganic 3D modelling of basic objects (via subdivision, extrusion, chamfering, subobj, detach, ...) can be learnt easily in 1-2 days from tutorials. It's the Unwrap texturing that will give you 10 times more issues.

 

Now, whether you have a patience and determination to mess with vertices is a whole different question, though :) You blink twice, and half day is gone :)

Link to comment
Share on other sites

While 3dsmax has a massive feature-set, the basic anorganic 3D modelling of basic objects (via subdivision, extrusion, chamfering, subobj, detach, ...) can be learnt easily in 1-2 days from tutorials. It's the Unwrap texturing that will give you 10 times more issues.

 

Now, whether you have a patience and determination to mess with vertices is a whole different question, though :) You blink twice, and half day is gone :)

Hmm... Well I can always give the program a look and see, I suppose :)

Link to comment
Share on other sites

I checked the pouet again and it looks like Falcon has hundreds of demos.

 

The discrepancy against Jaguar is huge. Do you happen to know why would that be ? Considering the price of Falcon, it's quite surprising. Or is it merely because it was a workstation, so it was primarily bought by programmers ?

 

What do you think ?

 

I don't think it's the least bit surprising. Computers generally have been the target platforms for the demoscene, and consoles typically haven't. Combine that with not needing extra hardware just to code for the Falcon, and there you go.

  • Like 1
Link to comment
Share on other sites

 

I don't think it's the least bit surprising. Computers generally have been the target platforms for the demoscene, and consoles typically haven't. Combine that with not needing extra hardware just to code for the Falcon, and there you go.

Thanks a lot for confirming that theory. While my region was a strong Atari bastion, never really heard of anybody obtaining a Falcon. I guess it's still not exactly a commonplace HW these days either.

Link to comment
Share on other sites

Quick technical update:

- Since I recently fit terrain+flatshading into 4 KB, I was curious about the wipeout codepath's memory footprint

- Turns out it was 3,040 Bytes, so over 1 KB is still available for additional functionality (be it gameplay, effects, whatever)

- After some additional refactoring on Saturday, I reduced it further to 2,820 Bytes

- Of those, 240 Bytes is for data, that could be easily moved into main RAM (at the cost of some minor performance (as they're mostly for outer loops))

- This means that the code is really only ~2.5 KB. Things like input/score/driving could easily fit there

- I also did some optimizations of the reference rasterizer, and improved framerate by 11.3%

- I noticed (and noted - for later) quite a few areas where performance could be improved further (potentially drastically)

- I'm getting much closer to PAL's 50 fps now, so I think I'll spend some next available time on further optimizations, to see how far I can push the HW

- If we used a cockpit window (like, with steering wheel and such) covering some bottom portion of screen, we could get to 50 fps now

 

Please note that unlike RoadRash and H.E.R.O., these are not camera axis-aligned quads (where a boatload of optimizations can be made), but generic arbitrary triangles.

  • Like 3
Link to comment
Share on other sites

- Got up at 5 am and spend 2.5 hrs with refactoring and managed to optimize the Wipeout codepath to PAL's 50 fps - I render 700 game frames in 838 vblanks.

- I believe I'm at the limit of the current edge traversal approach, so to get more performance I'll have to implement a new one

- I still have 2 substages that are shared (regardless of the edge approach), so I'll go optimize those next (though I doubt those will get me to 60 fps - 55 is my guess)

- this work will translate directly to texturing later (still have to process triangle edges, regardless of shading), so it's not wasted just for the flatshader - plus it's a great learning experience with the RISC chip

- this is still GPU-only, so both 68000 and DSP are fully available for any audio/gameplay code

- current cache footprint is 2,730 Bytes

- these optimizations mean linear increase in polygon complexity - I'm getting really curious - for games that do not need 60 fps (e.g. 3D platformers) - what scenes are now possible in 2 vblanks (30 fps) or 3 vblanks (20 fps).

- I'd hazard a guess that at least 2-3 polygonal animated characters should be now possible within one vblank, so a fully polygonal platformer at 30 fps is now completely within the reach. I have a lot of 3D character meshes that I could import for testing purposes, just gotta write a converter first

  • Like 3
Link to comment
Share on other sites

Dragonstomper, I don't know if you'll read this but I just wanna say this project of yours is fascinating and the work done is amazing! I've just started learning coding and what you're doing is what I hope I can do at some point. If you do finish your game I look forward to playing it, even buying a physical copy if it's available.

Edited by NeoGeo64
  • Like 1
Link to comment
Share on other sites

Dragonstomper, I don't know if you'll read this but I just wanna say this project of yours is fascinating and the work done is amazing! I've just started learning coding and what you're doing is what I hope I can do at some point. If you do finish your game I look forward to playing it, even buying a physical copy if it's available.

He already stated he is mostly interested in the research and prototype phase of it (to see how far it can be pushed) not on a full blown game.

Also "Dragonstomper" is the forum nick based on post count and such, he's "VladR", same way you're not "Space Invader".

Link to comment
Share on other sites

Dragonstomper, I don't know if you'll read this but I just wanna say this project of yours is fascinating and the work done is amazing! I've just started learning coding and what you're doing is what I hope I can do at some point. If you do finish your game I look forward to playing it, even buying a physical copy if it's available.

I read it alright, it just looked to me yesterday like you accidentally replied to a different thread than you intended to, but now that the Dragonstomper designation has been explained (I swear, I haven't noticed it there either), I see you meant me, and I'm really glad you enjoy reading the technical progress despite this engine being purely research-only at this point :)

 

Hopefully, it may also serve as a motivation/inspiration for you (seeing what is technically possible on the platform) - like you said, you're also coding, so the more coders here the merrier ;)

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