Jump to content
IGNORED

How hard would be to convert Stunt Car Racer?


Recommended Posts

But this is on 1.79 MHz CPU that is 8-bit and you need to handle 16-bit values. You have to write two different rendering engines, sync them without glitches and on top of that write physics engine.

Why would anyone need two different rendering engines?

 

I'd really love to see the frame stats breakdown - e.g. how much % goes to physics, collision detection, world processing, Z-sorting and rendering.

It is no breakdown of fps, it's some irregular presentation of the frame content, timewise. If you look at the Amstrad part, it runs at around 4 fps, but the projection is right.

Link to comment
Share on other sites

Why would anyone need two different rendering engines?

 

 

It is no breakdown of fps, it's some irregular presentation of the frame content, timewise. If you look at the Amstrad part, it runs at around 4 fps, but the projection is right.

I'm still not sure that the horizon is not at least a partially separate codepath. Initially, I incorrectly thought that horizon is rendered as regular pixels - e.g. Gr.7.

 

But since it can rotate, you can't just switch to charset on lower scanlines. So, it's all charset, hence the horizon is charset too.

So, it's now reasonable to presume it's all using same , single, technique for both horizon and terrain.

 

As for the "breakdown of fps" - I meant benchmark profiling - e.g. something like : 32.7% (charset line drawing), 11.2% (projections), 17.3% (drawing the chars) - things like that...

 

 

I was wondering , if this is 6 fps, what is the framerate of TestDrive on C64 then ? 3 fps ?

Link to comment
Share on other sites

Up to 4 (Hill & Street) , as it seems. Moving objects move 3 steps in a second.

Well, then it's taking 15-20 vblanks per game frame. And there's no complex 3D vector-based physics (compared to, say, StuntCar), which must be taking a lot of CPU time.

 

One has to wonder then, though. If we spent 20 vblanks on A800, just to compose one game frame, how much stuff could be drawn, pixel by pixel.

 

How many cycles are available in Gr.7 in total ? I'm thinking just vanilla Gr.7 with 4 colors so that we have as much CPU time as possible. I saw a cycle table somewhere here, just can't remember which thread...

Or, perhaps, have first half of screen in charset (for static things like sky) to leave more CPU time, and only have bottom 100 scanlines in Gr.7 - for 3D environment.

 

I never really considered 3-4 fps as a release candidate, but apparently, it was happening, out there, just fine.

  • Like 1
Link to comment
Share on other sites

Well, then it's taking 15-20 vblanks per game frame. And there's no complex 3D vector-based physics (compared to, say, StuntCar), which must be taking a lot of CPU time.

 

One has to wonder then, though. If we spent 20 vblanks on A800, just to compose one game frame, how much stuff could be drawn, pixel by pixel.

 

How many cycles are available in Gr.7 in total ? I'm thinking just vanilla Gr.7 with 4 colors so that we have as much CPU time as possible. I saw a cycle table somewhere here, just can't remember which thread...

Or, perhaps, have first half of screen in charset (for static things like sky) to leave more CPU time, and only have bottom 100 scanlines in Gr.7 - for 3D environment.

I wouldn't worry about speed of drawing at all. If C64 can do it, A8 can do it even better.

Maybe I'm repeating myself but check out some recent demos for Atari. For example here is voxel terrain that is much more complex than what Stunt car racer needs to draw and it runs in really good speed.

https://youtu.be/g3u-hGxT9XE

 

My guess what SCR does with drawing is only 20-30% of time spent. Rest is all about physics and how cars move.. Who knows, maybe we could even make racing game over voxel landscape :)

  • Like 1
Link to comment
Share on other sites

Voxels are great for flying games, not car driving ones. That voxel terrain would be great for star-wars-style flying / racing, for sure. I wouldn't want to drive a vehicle there and try to discern hill from flat area in that voxel terrain.

 

Programmatically, voxel is way less complex to implement, obviously - so it would have a huge advantage in the whole implementation process.

 

Where the voxel would be great for racing however, is if you had a scanline road rasterizer (say, like Electra Glide) and put the voxel terrain right by the road - like in Need For Speed. Now that would give you best of both worlds and look awesome :)

 

Wonder why noone did that actually...

Link to comment
Share on other sites

Could be interesting to have some "racing game" that resembles the road, using voxels. Driving between hills, and so on.

But, please, in Graphics 7 and without black scanlines.

 

As that may result in an ego view game, the front of the car could be done, using PMg with overlay.

Link to comment
Share on other sites

I was rewatching the Let's compare YT video and then it hit me - we could actually use the Atari 8-bit techniques on the Atari 64-bit console :)

In short:

- separate screen into 2 parts :

- blue sky (could be a texture, but that would not artistically match with the flatshading look)

- brown "terrain background"

- rotate them (clock-wise and counter clock-wise, as the car is following the track) using ObjectProcessor

- create the 3D "polygons" only by drawing the lines, just like on the 8-bit console

- fill only those few small polygons that occasionally cross the border between sky and terrain

 

Now you're probably thinking "WTF would be the point of that ?" :)

 

But hear me out. Since we do not have to fill 95% of the screen (pixel by pixel, as would be the case in classic polygon rasterizer), we've saved enormous amount of bandwidth (which is at quite a premium on jaguar).

 

So, it follows, that this technique should run even at the highest resolution of jag, which is 1400x480, since we're basically just drawing lines (plus few small polygons above the horizon, occasionally)

This should look sharp even on 60" TV :)

 

Clearing framebuffer 1440x480 (656 KB for 256 colors, or 328 KB for 16 colors - which should be enough for this environment) would take 10 times longer than 320x200 (64 KB), so that's a problem, but still Blitter should be able to do that within 1 vblank. it would be certainly faster to just erase old frame lines and draw new ones. My last line-drawing benchmark shows that about 18,000 line pixels can be drawn on GPU within 1 vbl. There's definitely less than that in those scenes. Even if we halve that number (to account for erasing), there still should be some buffer left.

 

Worst-case scenario - 2 vblanks and 30 fps. But 1400x480 3D game on Atari - it's so crazy it just might work :)

 

These threads are so inspiring - thank you guys !

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...