Jump to content

Photo

Road Rash pre-alpha on Jaguar at 30 fps

Road Rash GPU 30 fps

286 replies to this topic

#276 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,707 posts
  • Busy bee!
  • Location:North, England

Posted Sat Apr 22, 2017 2:59 AM

I was hoping someone would call me out on that :)

Higher MHz but the 3DO CPU is both RISC and ARM

The 68000 takes multiple clock cycles to execute a single instruction. For example, a nop instruction takes 4 clock cycles. ARM CPUs of that era have conditional execution instructions that can be executed in a single cycle (the only exceptions being branches, memory read/write instructions and multiply). Although the  ARM lacks  the 68K's divide instruction, division can be carried out with an unrolled loop algorithm on ARM (using Newton–Raphson division). The 68K's BCD arithmetic/conversion can be replaced with double dabble BCD - note that the "C" software implementation on that wiki entry is very poor.

 

Edit: Added a link to the fast division typically used on ARM.


Edited by GroovyBee, Sat Apr 22, 2017 3:08 AM.


#277 VladR OFFLINE  

VladR

    Dragonstomper

  • Topic Starter
  • 620 posts
  • Location:New York

Posted Sat Apr 22, 2017 4:28 AM

I appreciate the research you are doing VLAD but realize you don't have the time or resources to create a game that would have taken a team of 30 and a few hundred thousand dollars to create 20 years ago.

Actually, I slightly disagree with that, let me explain, but basically, the corporate environment is incredibly non-productive for this kind of R&D work:

- I don't have to share codebase with anyone, which means

- I don't have to loose time on code merges, branching and all related source control uber-clusterfuck issues

- There's no migration from one source control system (insert any other infrastructure element here) to another every 6-12 months, when project manager reads an article in Cosmopolitan magazine during weekend

- There's nobody fucking up your code because they're learning a new source control system

- There are no daily scrums that fuck up the quality of your work because you are pressed to deliver "something". I can make a decision that I will work on a feature for 3 days, and nobody will give me the dirty look every day that "oh, it's in progress, but can you present it now (we're agile)?"

- There are no "status meetings" that come in the middle of the debugging session that kill your focus, and when you come back to your desk at 4pm, you feel like shit, absolutely not in state to continue the 2-hour debugging session you engaged before, hence you postpone for tomorrow, which will kill half day realistically, and most probably will be interrupted by any instrument of the corporate bullshittery

- so, what only needed to take additional 15-20 minutes, is suddenly spread over 2 days

 

- I have yet to meet a manager that understands that there's no such thing as "quick 10-minute meeting" when you're in the middle of coding. They're really good at pretending they do, but they don't really understand/care that we see that they don't.

 

- I don't do lunch breaks on weekends. Sometimes I have 14 hour coding sprees without eating.

 

- I've had many weekends that I produced more since Friday evening that I can realistically do in a corporate environment in 2 weeks.



#278 sirlynxalot OFFLINE  

sirlynxalot

    Moonsweeper

  • 419 posts

Posted Sat Apr 22, 2017 7:51 AM

^Good points on the programming side of things, but coming up with all the artwork, 3d models, textures etc to make a complete 3D game per 1994/1995 standards still seems like it would take a very long time in and of itself. It seems that having multiple people work on the artwork would greatly speed up the process.


Edited by sirlynxalot, Sat Apr 22, 2017 7:52 AM.


#279 VladR OFFLINE  

VladR

    Dragonstomper

  • Topic Starter
  • 620 posts
  • Location:New York

Posted Sat Apr 22, 2017 3:12 PM

^Good points on the programming side of things, but coming up with all the artwork, 3d models, textures etc to make a complete 3D game per 1994/1995 standards still seems like it would take a very long time in and of itself. It seems that having multiple people work on the artwork would greatly speed up the process.

In past, I have bought several large texture packs, that are of resolution 1024x1024 (and up), and cover many different materials. I learnt few skills how to create textures in PaintShopPro from multiple layers, using various effects, blend maps and transition alpha maps, that were sufficient for roughly 2000-2005 era, so these skills are waaaay above what's realistically needed for jag, as jag barely manages simple lowres texturing, let alone resolution 1024x1024...

 

As for 3D meshes, I spent years working with 3dsmax (almost every week, on top of my coding), creating way over a hundred of mostly low-poly (as in, non-normal-mapped) meshes. Anything anorganic - from buildings, interiors, bridges, various props, trees, crates, you name it...

 

Never had patience for characters, though. That's an area I always left for artists.

 

 

Let's take Crash n Burn, for example. I counted about 10 textures (2 for road, lava, water, sand, 3xstone, skybox), which, by the way, look like they were taken from some texture library anyway (and just retouched). There could be more environments in later levels that require more textures, for sure. I noticed only 3 simple transitions between 2 materials on the road and environment.

 

Not sure how many different 3D cars are there. 8, I guess ? Now, you could spend polishing and retouching the single car mesh for a week. But a core, useable version of those low-poly cars can be absolutely done in half day. Spend first weekend experimenting with the art direction, playing with the style and then another weekend just quickly bashing them out.

I once employed a 3D artist, that whipped up a similar-quality version under an hour. It was fascinating watching him, as I never was a fast modeller myself.

 

As for the cars, since they're prerendered, you don't have to loose time fighting for those precious collapsed vertices, and can just literally take a hires cube and keep quickly extruding left&right. Same for texturing, the source texture can be as highres as needed, no need for timeconsuming UVW unwrap, just direct and quick paint with materials.

 

Would it look like AAA work ? Of course not. It's a programmer's art, after all!

 

But it would be good enough, and free, for sure.

 

Besides, who's talking about a full game with many levels and full art variety ? My goal was always about one level.

 

 

In short, you can absolutely create full 3D game of that era as a one man team. Won't win any "Best Art" awards, but it's entirely doable. Just need to pick a reasonable genre without 3D characters and with not a lot of complex graphics (like, Star Raiders, for example - simple space background and about a dozen of simple, untextured meshes).



#280 AtariORdead OFFLINE  

AtariORdead

    Chopper Commander

  • 223 posts
  • Location:Where everybody knows my name

Posted Sun Apr 23, 2017 2:20 AM

In past, I have bought several large texture packs, that are of resolution 1024x1024 (and up), and cover many different materials. I learnt few skills how to create textures in PaintShopPro from multiple layers, using various effects, blend maps and transition alpha maps, that were sufficient for roughly 2000-2005 era, so these skills are waaaay above what's realistically needed for jag, as jag barely manages simple lowres texturing, let alone resolution 1024x1024...

 

As for 3D meshes, I spent years working with 3dsmax (almost every week, on top of my coding), creating way over a hundred of mostly low-poly (as in, non-normal-mapped) meshes. Anything anorganic - from buildings, interiors, bridges, various props, trees, crates, you name it...

 

Never had patience for characters, though. That's an area I always left for artists.

 

 

Let's take Crash n Burn, for example. I counted about 10 textures (2 for road, lava, water, sand, 3xstone, skybox), which, by the way, look like they were taken from some texture library anyway (and just retouched). There could be more environments in later levels that require more textures, for sure. I noticed only 3 simple transitions between 2 materials on the road and environment.

 

Not sure how many different 3D cars are there. 8, I guess ? Now, you could spend polishing and retouching the single car mesh for a week. But a core, useable version of those low-poly cars can be absolutely done in half day. Spend first weekend experimenting with the art direction, playing with the style and then another weekend just quickly bashing them out.

I once employed a 3D artist, that whipped up a similar-quality version under an hour. It was fascinating watching him, as I never was a fast modeller myself.

 

As for the cars, since they're prerendered, you don't have to loose time fighting for those precious collapsed vertices, and can just literally take a hires cube and keep quickly extruding left&right. Same for texturing, the source texture can be as highres as needed, no need for timeconsuming UVW unwrap, just direct and quick paint with materials.

 

Would it look like AAA work ? Of course not. It's a programmer's art, after all!

 

But it would be good enough, and free, for sure.

 

Besides, who's talking about a full game with many levels and full art variety ? My goal was always about one level.

 

 

In short, you can absolutely create full 3D game of that era as a one man team. Won't win any "Best Art" awards, but it's entirely doable. Just need to pick a reasonable genre without 3D characters and with not a lot of complex graphics (like, Star Raiders, for example - simple space background and about a dozen of simple, untextured meshes).

 

Says a guy you has never followed through on anything, despite it apparently being so easy for one person to do.



#281 VladR OFFLINE  

VladR

    Dragonstomper

  • Topic Starter
  • 620 posts
  • Location:New York

Posted Sun Apr 23, 2017 5:07 AM

 

Says a guy you has never followed through on anything, despite it apparently being so easy for one person to do.

:)

 

You're wrong, btw. I have 2 full released PC boxed games under my belt (coded from scratch, with lots of production art (both 2D and 3D) done by me). I just lost interest in PC game coding upon transitioning to US from Europe, so didn't hire artists to do levels to my last Steam game, that's all. With coder's salary in U.S., there's little financial motivation in coding games for money, really.

Say, it takes me 2 years to finish a game, and then my cut is $0.5 Mil. Absolutely not worth the risk and actual time you spent on it, as it's never 40hrs a week. Back when I was in Europe ? Sure. But not really in U.S.

 

 

Also, I don't know how many times I've mentioned that I need to spend a bit of time coding importing/rasterizing arbitrary 3D meshes to my jag engine.

 

Like, 15-30 times by now ?

 

 

Apparently, it's a complex concept to grasp [that it does not make sense to create 3D meshes if there's no way to import them]. I apologize, I did not know.

 

 

 

But if your goal is to make sure I reconsider releasing public binaries of my work here once it's done, as they might be played by people like you, then you're doing a great job!

 

What have you created on Atari Jaguar that gives you right to bitch about my research&development work, that I do [in my free time for zero profit] ?

You haven't contributed anything to this thread. And you don't have to be coder. Just linking YT videos of various games by various people has helped tremendously.



#282 Sauron OFFLINE  

Sauron

    Quadrunner

  • 5,054 posts
  • In the land of Mordor.
  • Location:North of the Black Sea

Posted Sun Apr 23, 2017 6:30 AM

Just banned AtariORdead from the thread. Anyone else who feels the need to jump on VladR will receive the same treatment.



#283 VladR OFFLINE  

VladR

    Dragonstomper

  • Topic Starter
  • 620 posts
  • Location:New York

Posted Sun Apr 23, 2017 9:29 AM

Yesterday, I've implemented terrain coloring by reading color value from a texture, but as expected, it does not give a huge visual boost, as it's determined primarily by vertex density of terrain, so the visual effect is minimal (and probably not even worth the video).

 

Today, I implemented a quick and dirty texturing that has glitches(as it's unfinished), but the most important bandwidth performance impact of texturing (reading texture for each and every single pixel of terrain and interpolating UV values across the scanline), is there.

 

Here are the benchmark numbers (from rendering 2000 frames of the flythrough):

10.8 fps: Textured

15.1 fps: Flatshaded

 

I'll post video later this evening, got an errand to run now.

 

 

So, now everybody who told me "I told you so - jag can't do it", can jump in and start posting the Simpsons animated GIFs :)

 

And of course, there's no input, audio, AI. Yes, I know.

 

But, I'm not giving up! All this means is, that my triangle rasterization routine needs more improvement, because, quite frankly, the difference between flatshading and texturing is much smaller than I expected. Right now it's what - 39 %?



#284 CyranoJ ONLINE  

CyranoJ

    River Patroller

  • 4,418 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Sun Apr 23, 2017 3:27 PM

So, now everybody who told me "I told you so - jag can't do it", can jump in and start posting the Simpsons animated GIFs :)

 

Nobody told you that. They told you it couldn't be done at that speed on the 68000/ in C - which you've just proved.

 

Nice work on the GPU renderer.

 

[Edit]

 

BTW, what are those 2 PC games you've completed? I think we're all wondering what a finished Vladr Production looks like :)   [j/k]



#285 VladR OFFLINE  

VladR

    Dragonstomper

  • Topic Starter
  • 620 posts
  • Location:New York

Posted Sun Apr 23, 2017 7:58 PM

Alright, here's the glitchy video:

 

Yes, the texturing glitch sucks, but I didn't have time today to fix it, so I'd rather post it as it is, because 95% of performance impact of texturing is there.

 

I think this will force me to just bite the bullet and go for multi-threaded renderer, to get about 40-65% additional performance.

 

 

Also, this proves that the scanline method for racing games must be preferred, as it can be offloaded to OP/Blitter, freeing GPU/DSP.

 

So, a 30-60 fps Road Rash on jag is still doable at the city section, as road will be done on OP.

I always said that terrain section will be slower, but only now we know for sure how much slower it actually is.

Though, granted, this terrain is overkill for RoadRash, so perhaps I should go and simplify it for Road Rash.

 

On the other hand, I just realized, that I don't have to pay the huge fillrate cost for the road with RoadRash, so a combined renderer (e.g. 3D for terrain and 2D scanline for road) even at current form should reach 20 fps for the terrain part (but 60 for road, as it's OP-based).

 

No idea, how it will look with 2 different framerates (e.g. 60 fps for road, and ~20 fps for terrain) - but that's where this must be going to extract all power from jag (e.g. each chip working at full speed).



#286 JagChris OFFLINE  

JagChris

    River Patroller

  • 3,072 posts
  • Location:Oregon

Posted Sun Apr 23, 2017 10:52 PM

Well you're not using the blitter for any of this GPU stuff so the numbers may be different if that route was taken.

#287 VladR OFFLINE  

VladR

    Dragonstomper

  • Topic Starter
  • 620 posts
  • Location:New York

Posted Mon Apr 24, 2017 6:09 AM

Well you're not using the blitter for any of this GPU stuff so the numbers may be different if that route was taken.

For a Flatshading - Yes, there might be a threshold where a single scanline filled by Blitter would be faster than on GPU. It is actually quite high on my to-do list of experiments.

For texturing - not so sure. While in theory, once you initiate the Blitter command, your GPU can work nicely in parallel , as long as it does not touch RAM.

But GPU is touching RAM, as it's rendering scanlines.

 

You would have to interrupt rasterizing and switch to a completely different task, which involves saving and later restoring all registers, so there's really almost zero time that the GPU can do something productive, as one scanline is not a lot of GPU time (I have measured that, actually).

Plus, that time is lowered, as you have to compute all registers for Blitter.

 

 

There is, however, a completely different algorithm, I came up with on a paper, few weeks ago, that would truly unleash Blitter for Flatshading, as instead of producing single scanlines, it would rasterize whole polygons in one call. You'd have to fill the rest the old-fashioned way, but the savings should be really substantial.

I'm just not sure if it's doable during one weekend, though, as it's quite involved (definitely more complex than texturing) and it's a lot of math, so there's possibility, that by the time I compute all intersections and line equations, the performance savings have already been evaporated.

 

But, unless I try, I won't really know.

 

 

The point is, there are lots of ways how to speed things up.

 

And while the performance difference between texturing and flatshading is almost 2 full vblanks worth of GPU time, I still believe, it is possible on jag, to reach 15 fps textured, on that Crash n Burn large drawing distance terrain.

 

This is what I need to do:

- break up GPU code into smaller chunks and keep only texturing function so that I can fit a lowres texture into its small cache

- Implement multi-threaded rendering

 

So, we're not there yet...






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users