How hard would be to convert Stunt Car Racer?

[emkay]

Thinking more about the game makes me think it's not graphics that is important. "Engine", physics, vehicle control is what makes it a good game.

 

What ever type of graphics, rendering, drawing you make it will be fast enough.

 

That means cracking original version is a must... Loooooots of hard work...

Yeah, studying the C64 game , transcripting the content, and , if all works fine, make a fluently playable 8 Bit version with A8 features

[emkay]

Sorry, but it's still ridiculous to me that the only 8 bit that could handle 3d like games fluently, had none of the "known" mid to end 80's games. And still today it's hard to gather people, doing the missing stuff. Seems, I have to get a cloning machine, cloning myself and find the time to do all the missing stuff "myself"

 

Probably José Perreira could teach me attracting people doing wanted stuff, as he even managed to get people to do games of what I was proposing in the old days and put his name first

[José Pereira]

Sure but there are still some isometric games to port ZX and C64 but will also be a BBC&Electron surprise for the first time by the usual suspect and we talked for other names other types of games and was started, like you all saw, Total Eclipse that maybe this one even get also #2 as it's same code as #1 and I also started thinking the same way to get most of the others Incentive Freescape 3D games but decision and time is always on the coder's side. There were others types and also some 2D we though we never talked on Stunt Car Racer (I never talked but have thought in a similar way as Total Eclipse to get Starglider).

And there are always my platformers and shoot'em'ups to get into A8 and not many coders with much time to code.

Stunt Car doesn't seem 'the way of' Mariuszw and there are already so many on 'the wish list' that he has many years of work to come ...

But I promise to study this game on the game and make a proposal to someone I have in mind but I think he has a game in hands to add all the things he want onto the current version and hasn't much free-time to A8 code but maybe, maybe... him or other(s)...

Edited August 14, 2016 by José Pereira

[José Pereira]

O.K. so here we go and I'll also have to send a "Big Big Thank You" to Mr. Emkay to get me without sleeping this night ...

 

From Popmilo screen posted I don't get it and what I found from my studying of C64 is it seems that (and is only inside, on the playing area because panel and its contours can have other design and even PMGs, at least on the bottom):

-> (00) is always black;

Then the 3 bit-pairs:

-> 1.)- always white;

-> 2.)- gray / brown;

-> 3.)- sky blue / cyan / green;

 

 

If on A8 we go to Antic4 charmode in 3charlines=1charset then we can have it:

-> BAK (00): always black;

-> PF0 (01): white;

-> PF1 (10): brown;

-> PF2 (11): gray;

-> PF3 (11): blue sky/DLI/cyan panel numbers;

 

The difference between A8 and C64 on the bit-pairs would be on the PF2_gray wheel tire<->PF3 sky blue that will make just a little clash and only sometimes on some little numbers pixels when touch sky that I think wouldn't be all that bad beeing a 'speedy' game:

I am only using P0/P1 for those two yellow and dark gray small gfxs in left and right on the bottom panel to have them free to have yellow for turbo fire on the inside playing area car but more can be used at the bottom panel to have it more coloured.

 

 

Now here's the same with some little re-done pixels on the bottom panel and added 1charline on it to have the screen really centered vertically (really good would be to have even more 2charlines, this would be it really centered but probably not possible enough c.p.u./cycles like also, for sure, is impossible real all overscan 48Bytes wide screen):

 

 

Here's this and also inside the C64 game file if anyone wants to play and also some of the coders around here and familiar to their programs can study it more ...

stunt_car_racer ANTIC4.zip

 

 

Edited August 15, 2016 by José Pereira

[José Pereira]

... José Perreira ...

And I am not 'Perreira'!

I am Pereira, José Pereira!...

 

 

P.s.- But still thanks in that you used the accent ´ that almost no-one here usually use on my name ...

 

[popmilo]

Thanks for gfx José!

It will be usefull once we decode rest of the game... Around 2020

[emkay]

And I am not 'Perreira'!

I am Pereira, José Pereira!...

This was intentionally, to have the discussion alive

 

Btw: You know, Antic 4 and PMg leaves the 6502 at almost the same level as the C64 CPU. Using additional "256 char" imitation, would end in a unplayable slow slideshow. The 64's version is too slow already.

Edited August 15, 2016 by emkay

[emkay]

Have a look at the MS-DOS version.... That's something fluent

 

[Rybags]

Dosbox - so might be running at any emulated speed, likely something in the order of 25 MHz effective.

[emkay]

Dosbox - so might be running at any emulated speed, likely something in the order of 25 MHz effective.

If you're adjusting the emulation to fast, the whole thing runs to fast. The essential part is that you get the feeling of a real racing (not an independent accidental steering over some projected lines...) On the A8 you can reach that "simulation detail" , too.

[VladR]

Have a look at the MS-DOS version.... That's something fluent https://www.youtube.com/watch?v=5sDAczW7TNo

Well, we played Stunt Car on PC for years and on 80286 12 MHz it had a similar framerate as ST or Amiga. I don't remember such a good frame rate on PC even after an upgrade or two.

 

Since I am currently working on a flatshade 3d racing engine for Atari Jaguar, I am very curious how they managed to achieve such a great framerate on C64. It looks like they manage to draw the frame in about 6 vblanks -e.g. 10 fps.

 

If it was just wireframe, it would be alright. But, no! C64 shows actual filled polygons above the horizon and proper Z-buffer-like occlusion! Obviously, there is no actual Z-buffer , but the trick is definitely cool.

 

So, there must be some kind of hybrid rasterizer that seamlessly bridges bottom part of screen which is wireframe and top that is filling those few polygon scanlines above the horizon.

 

Was there ever any technical interview with Geoff Crammond?

[popmilo]

Hi VladR, c64 rendering was mentioned here before:

 

If I remember correctly C64 version draws sky and ground with color attributes (draws only horizon line and then fills colors above and below that). That would need to be converted to full drawing inside bitmap.

Anyway... Maybe it would be nicer to make a new game in that genre
There is a source code of remake written in c available. Physics and race engine is nicely separated from gfx part. Could be a nice and long project to make it for A8
Game:

http://stuntcarracerwin32.bravesites.com/
Source:
http://sourceforge.net/projects/stuntcarremake/

Here is one screenshot from c64 with changed color attributes:

 

I've colorized parts with those that are different bitpattern than earth or sky. C64 has three colors that can be set by attributes (01,10 and 11). So only those chars that have horizon or track line in them need to be filled pixel-by-pixel. Parts above and bellow line are filled with two different bitpatterns so sky and ground can be set where needed.

 

Ground and sky are just filled with all three attributes set to same value (sky or ground) That way no matter what the gfx is in them they just appear single color.

 

Or something like that

 

Cheers!

Vladimir

 

[emkay]

Since I am currently working on a flatshade 3d racing engine for Atari Jaguar, I am very curious how they managed to achieve such a great framerate on C64. It looks like they manage to draw the frame in about 6 vblanks -e.g. 10 fps.

Seems, they used every trick that was possible on the C64. While the calculations and related line drawing is slow, parts of the screen get updated faster, using some character "Adjustment" other parts got never drawn. At the end that means, they did 10fps with not fully changed images.

[VladR]

Hi VladR, c64 rendering was mentioned here before:

http://stuntcarracer...bravesites.com/

Source:

http://sourceforge.n...stuntcarremake/

Perhaps the C-64 algorithm is mentioned/referenced inside the source ? Because that's a PC version, and there you can just brute-force everything. The "cleverness" there means "buy faster PC"

Hell, I'm brute-forcing all triangles and pixels on Jaguar, myself

 

 

Here is one screenshot from c64 with changed color attributes:

stuntcarracer.png

 

I've colorized parts with those that are different bitpattern than earth or sky. C64 has three colors that can be set by attributes (01,10 and 11). So only those chars that have horizon or track line in them need to be filled pixel-by-pixel. Parts above and bellow line are filled with two different bitpatterns so sky and ground can be set where needed.

 

Ground and sky are just filled with all three attributes set to same value (sky or ground) That way no matter what the gfx is in them they just appear single color.

I'm sorry. I was replying to the thread on a phone yesterday, so didn't see the picture. Now I'm on PC, so I can finally see and appreciate it

 

So, it looks like there's just literally few scanlines that have to be fully filled. I swear it looked like there's way more (just from watching the video), so this is a really cool trick. I don't know how much available CPU time C-64 has after each scanline (or whether its graphics chip works the same way as on A800), but from what I remember (from quarter century ago, nonetheless) there was very little CPU time on A800 after each scanline.

Granted, if we are given 6-8 vblanks, A800 should be probably able to do the same too, but hard to say, unless someone goes and spends several weekends to do that

 

 

 

 

So only those chars that have horizon or track line in them need to be filled pixel-by-pixel.

 

Well, you make it sound like there's not much work there , but that's a whole lot of lines to rasterize into charset. That can't possibly be something simple as Bresenham or similar. He must have found a way how to "charset Drawline" - e.g. without computing line first, and then converting it into the char. Instead, just compute the charset values straight in one go.

 

This is one hell-of-a engineering achievement on C-64. I used to think Grand Prix Circuit was awesome on C64 - and that's filling what - ~35 scanlines ?

[VladR]

Seems, they used every trick that was possible on the C64. While the calculations and related line drawing is slow, parts of the screen get updated faster, using some character "Adjustment" other parts got never drawn. At the end that means, they did 10fps with not fully changed images.

Yes. I'm sure they only updated the chars around the track line (intro sequence being a special case). We can't fill the screen pixel by pixel on this platform. Not enough bandwidth.

 

 

At the end that means, they did 10fps with not fully changed images.

That's alright, as long as the illusion of refresh rate is kept. And they're doing amazing job with that illusion ! Small things like different "framerate" on the wheels make your brain think, that the whole thing runs in different framerate than it actually does

[emkay]

This vid is very nice. particular the 10 fps time... 2:42

At 10 fps it looks rather smooth.

 

[VladR]

This vid is very nice. particular the 10 fps time... 2:42

At 10 fps it looks rather smooth.

 

Well, I didn't listen to the audio on that YT vid, but I've done a lot of work in past of trying to make low framerate look smooth.

 

You can actually make 3 fps look smooth, as long as objects don't jump great distances on the screen. If they move (horizontally/vertically) 1-3 pixels per frame, then your eye will perceive it as very smooth (albeit slow).

 

Same thing with that guy in the YT video - majority of screen is occupied by him, but he's barely moving few pixels left/right, so the eye perceives it as very smooth (due to interpolation).

 

That's why, in racing games, even though the framerate is basically the same, it feels much smoother at the start of the game, when you are just speeding up, and the objects by the road move barely few pixels. Once you go fast, and they jump 20-40 pixels per frame, it's not smooth anymore, even though it's same framerate.

Which is why racing games and FPS games need a lot of framerate, compared to other genres.

 

This is the same trick as intros/demos use - move camera slowly, thus hide the low framerate behind the camera movement, so to an untrained eye it looks great and smooth

 

Do we actually know the real framerate in C64's StuntCarRacer ? I'm just guessing it's 10 fps, but in reality it could be 7-8 or even 11-12...

 

 

We could use this fact for our advantage, and create, for example, a bicycle racer. At 10 fps, it would feel like NeedForSpeed at 60 fps

[emkay]

It's around 6fps on the C64 . The PC version plays at around 14fps

[toddtmw]

So, 2 years in. Is anyone actually working on this? I'd love to see this. I hated it when anything on C64 was better than somehting on A8. Stupid Commode Door computers.

[emkay]

So, 2 years in. Is anyone actually working on this? I'd love to see this. I hated it when anything on C64 was better than somehting on A8. Stupid Commode Door computers.

Well, the C64 is in many aspects clearly the advanced machine. Alike if Music or sprite based games, the Atari has no chance to compete. But any ego view game on the C64, not being available on the A8 is a perversion of reality.

An example is still Rescue on Fractalus. Using real 6fps with full drawn frames, makes that game phantastic on the A8. Running the game without vertical sync would show even more ...

The C64 version runs at visual 4 fps. But the frames weren't fully drawn. A factor of 1.5 is reasonable. So the C64 shows real 3 fps. You understand ? While they used the A8's hardware just like a "slow" supercomputer, they pulled all registers, to get a playable framerate on the C64, using all upspeeding tricks.

[snicklin]

P.s.- But still thanks in that you used the accent ´ that almost no-one here usually use on my name ...

 

 

On my Australian keyboard, it is rather difficult to put an accent onto the characters.

 

There is probably an alt code that could be use, but I revert to Googling for it and then copying and pasting it.

 

I understand why so many people don't put the accent on.

 

I do feel a bit rude though if I don't use one.

[José Pereira]

Thank you very much.

[VladR]

So, 2 years in. Is anyone actually working on this? I'd love to see this.

I'm sure you would. I just don't think you understand what you're asking for here. This is like Crysis of 8-bits. Technologically, this is arguably harder than, say, Project-M.

 

Let me give you different Atari example. I'm currently getting about 55-65 fps from flatshading 3D racing engine I'm writing on Jaguar for similar scenes. I still have full power of DSP (26.59 MHz), and Motorola (13.295 MHz) available, that have not been yet used (plus Blitter).

 

it still would be a huge undertaking because of the physics and proper collision detection, as the physics of StuntCar is vastly different from regular car racing games (where you cannot fall off cliff, slide down the slope under the angle or hit road segment under an angle like in StuntCar).

Now, granted, I'm not using 10 vblanks, I'd love to do everything in just 1 vblank (e.g. keep 60 fps). DSP could probably pull the input and physics off and keep 60 fps.

 

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.

 

This is beyond crazy.

 

It's around 6fps on the C64 . The PC version plays at around 14fps

Only 6 ? I swear it felt closer to 8-10. So, they're using full 10 vblanks. Still an incredible achievement. Don't remember when I was shocked last time what C64 could pull off. To me this is stronger than Project-M 2.0 on Atari.

 

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.

[emkay]

Only 6 ? I swear it felt closer to 8-10. So, they're using full 10 vblanks.

That makes sense in a "special" way. 10vblanks using 6 fps ist modulo 60Hz. As they didn't draw always the full frame, after "6x10" caculation steps (however) they got to get in time... parts of the frames seem to be updated in real 10 fps. The PC version , for comparision, draws always the full frames. You can see it ... if you just watch it.

Edited March 5, 2017 by emkay

[VladR]

That makes sense in a "special" way. 10vblanks using 6 fps ist modulo 60Hz. As they didn't draw always the full frame, after "6x10" caculation steps (however) they got to get in time... parts of the frames seem to be updated in real 10 fps. The PC version , for comparision, draws always the full frames. You can see it ... if you just watch it.

I watched it closely, and could instantly notice speed differences when there was less amount of polygons to process (which is to be expected).

 

I still didn't notice any additional screen element (besides the wheels) that would be updated in different framerate, so I still see only 2 different framerates right now- one for wheels, another for environment.

 

Where exactly do you see another different framerate ? I'm guessing horizon would be a candidate, as it's a different rendering component...