STUNT CAR RACER?

[Gunstar]

So Commodore's just went with external ram expansions like the 600XL, while Atari's went with mostly internal in the 800 through XE with 800 ram cards or XL/XE internal dram. Until recent years anyway with the external PBI ram expansions released a few years back or like the Syscheck 512K I have plugged in my PBI port. Too bad the Commodore community doesn't support it better these days as the Atari community does.

[Level42]

TT030, Amiga, and Falcon030, anything less is close to a felony ... well sort of... a modded STe avoids being a misdemeanor ... all stf fm and mega's needed the memory upped and the sound mods as well as the graphics updates...

 

You forget the Mega STE...... for me the best Of the ST series.

[EnderDude]

Such a great port! How about we try to make a mod of this to make Accolade's Test Drive?

[Level42]

Yugh.

 

Worst "racing" game ever.

 

Why did that game ever get such great following is beyond me.

 

The speed of the graphics.....man you could write it in Turbo Basic on the A8......

Edited October 5, 2018 by Level42

[Mclaneinc]

Same here, saw it and thought "racing game?", its so clunky...

 

Nice idea at the time but hardly an Adrenalin thrill ride

 

Didn't realise it had a following, all the folks I knew thought the same sort of thing, sure when it hit a console in later life but the initial versions were er over taken by a granny with a walker...

[flashjazzcat]

The speed of the graphics.....man you could write it in Turbo Basic on the A8......

Not sure how the graphics actually work, but I fancy that flood-filling an arbitrary region of a colour bit-mapped graphics display with green pixels ten or twenty times a second might present some challenges even for Turbo BASIC.

[Mclaneinc]

I can't imagine it would have been a mega optimised specially written fill routine, they probably spent more time on just getting the car and what physics there were used right..

 

Still a 'plodder' though...

[Rybags]

You can cheat a bit with fill on the C64 by using attributes, though they only apply to foreground colours.

You can do the same thing on Atari but have to use the multicolour text mode.

[emkay]

You can cheat a bit with fill on the C64 by using attributes, though they only apply to foreground colours.

You can do the same thing on Atari but have to use the multicolour text mode.

Using the PMg shapes is faster and saves a lot of characters.

[Wrathchild]

Using the PMg shapes is faster and saves a lot of characters.

You'd only need 4 characters, 1 each filled with the colour patterns $00, $55, $AA and $FF, but you could probably get away with two, for example for the sky rock colours.

 

Writing to one memory byte in the screen's memory in Antic 4 character mode will have the effect of covering a 4*8 pixel area of the display. Therefore 2 writes cover an 8*8 area, 4 covers a 16*8 and 8 covers a 32*8 area.

 

Alternatively handling this with Player data (i.e. DMA enabled) would require the following:

 

A double-line mode player of normal, double and quadruple width needs 4 writes to fill the same vertical height.

This can handle a 4*8 area when you set half the pixels in normal width player. So this is 4 times slower.

This can then handle an 8*8 area if you set all the pixels in normal width. So this is twice as slow.

It can handle a 16*8 area when you set all the pixels in double width. So this is works out as the same.

It can also handle a 32*8 area by setting all the pixels in quadruple width. So yes, this would be twice as fast.

 

A single-line mode player of normal, double and quadruple width needs 8 writes to fill the same vertical height, so:

A 4*8 area setting half the pixels in normal width, this is 8 times slower.

An 8*8 area setting all the pixels in normal width, this is 4 times as slow.

A 16*8 area setting all the pixels in double width, this is twice as slow.

A 32*8 area setting all the pixels in quadruple width, works out as the same.

 

Of course there is the option of not using PM DMA but then you are responsible for managing the turning on the pixels at the right ypos and off again, the overheads of which I should think are again going to be more or less the same or worse when comparing with the overheads of the DMA. Especially if you consider having to also set various player's xpos over the height of the screen too.

 

You can cheat a bit with fill on the C64 by using attributes, though they only apply to foreground colours.

You can do the same thing on Atari but have to use the multicolour text mode.

 

I'd therefore suggest that this method would be a more sensible approach. As far a I can see, only the quad-width players may offer something comparable but would argue here that handling the granularity, i.e. working out if 1..8 pixels need to be set (e.g. when the wall edge gets closer to the edge of a screen) would again be a greater overhead.

 

This simplistic math may have missed something so I'm more than happy to have it demonstrated where the Player/Missile approach works better for a whole screen. Perhaps two g2f's of a captured screen with an explanation of the fill loops for the solid areas would help?

[EnderDude]

So... What about that steep hill? could we make the hill be a brown PM, like Elektra Glide did with the tunnels, that should give a believable illusion of 3d?

[emkay]

So... What about that steep hill? could we make the hill be a brown PM, like Elektra Glide did with the tunnels, that should give a believable illusion of 3d?

That's one of those relevant points.

The hills have a limited animation. You could store that in the Player. Use one or two players in single width and set another to fill the rest. Then just some commands for the x position of the players will build the hill animation for the full height. The game could be build on Antic 4 then , without any problems.

Using the PMg for filling up ranges in games to have more colors with Softwaresprites is surely "underused" ...

[emkay]

Could you imagine a "hill racing game" ? No need for 50fps. Just 14-16 fps would do well by the given resolution.

But it could run at "50fps" ...

 

 

 

Not to mention that Test Drive was intended to be a racing game within a Sportscar simulation ?

Edited October 6, 2018 by emkay

[Rybags]

The other available cheat is the hardware exploit with SIZE for PMs to make them persistent. Though for a driving game the options are probably a bit limited.

[emkay]

The other available cheat is the hardware exploit with SIZE for PMs to make them persistent. Though for a driving game the options are probably a bit limited.

You'd only need the raw shapes. You could also use some characters to do some additional "line-up" .

 

Not to miss the point that masking is easily possible.

[EnderDude]

Could we also do MCS for the cars? Also, could we implement the mirror functionality?

[Wrathchild]

Worth staring a new thread... ? this has nothing to do with SCR

[EnderDude]

Actually, I started a thread about porting Hard Drivin’ to the Atari, as it seems to be a game that’s more worth the time than working on Test Drive.

[zetastrike]

I'm trying to run this from my Uno Cart on my 130XE. I can't get past this screen. What am I doing wrong, or is it not compatible with my setup?

 

Sent from my SAMSUNG-SM-J727AZ using Tapatalk

[xxl]

you must run this game from a device connected to the Peripheral not Cartridge connector.

 

 

or look for a crack version without a save option.

 

 

Edited November 28, 2018 by xxl

[BoatofCar]

For those without access to an emulator or hardware, I made a quick gameplay video:

 

 

No quips about my playing ability!

[_The Doctor__]

Nitro stunt racing (twisted)... hard drivin... stunt track driver... stunt driver and stunt driver 2.... get's to be a jumble...

 

anybody remember stunt cycle or for a real blast of the pat stunt pilot (mechanical) ?

Edited December 1, 2018 by _The Doctor__

[pseudografx]

Did the latest two posts in this thread disappear, including mine?

[Albert]

Did the latest two posts in this thread disappear, including mine?

 

Yes, the poster who made the post you responded to asked us to remove it as he made a mistake.

[Irgendwer]

Interesting what a 2MHz DMA penalty free 6502 65SC12 can accomplish:

 

 

 

Edit: Corrected info about processor.

Edited March 17, 2019 by Irgendwer