Jump to content

Photo

STUNT CAR RACER?


492 replies to this topic

#476 Gunstar ONLINE  

Gunstar

    Gunstar

  • 9,541 posts
  • Location:Kellyville, Oklahoma

Posted Fri Sep 28, 2018 6:20 PM

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.



#477 Level42 OFFLINE  

Level42

    River Patroller

  • 2,543 posts
  • Location:Ridderkerk, The Netherlands

Posted Sat Sep 29, 2018 4:34 AM

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.

#478 EnderDude OFFLINE  

EnderDude

    Chopper Commander

  • 135 posts

Posted Thu Oct 4, 2018 7:56 PM

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



#479 Level42 OFFLINE  

Level42

    River Patroller

  • 2,543 posts
  • Location:Ridderkerk, The Netherlands

Posted Fri Oct 5, 2018 3:17 AM

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 by Level42, Fri Oct 5, 2018 3:18 AM.


#480 Mclaneinc OFFLINE  

Mclaneinc

    Quadrunner

  • 6,052 posts
  • Location:Northolt, UK

Posted Fri Oct 5, 2018 8:28 AM

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



#481 flashjazzcat ONLINE  

flashjazzcat

    Quadrunner

  • 13,911 posts
  • Location:United Kingdom

Posted Fri Oct 5, 2018 9:05 AM

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.

#482 Mclaneinc OFFLINE  

Mclaneinc

    Quadrunner

  • 6,052 posts
  • Location:Northolt, UK

Posted Fri Oct 5, 2018 9:12 AM

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



#483 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,850 posts
  • Location:Australia

Posted Fri Oct 5, 2018 10:36 AM

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.



#484 emkay OFFLINE  

emkay

    Quadrunner

  • 9,558 posts
  • What's up?
  • Location:Holy Grail ;)

Posted Fri Oct 5, 2018 11:34 AM

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.

#485 Wrathchild ONLINE  

Wrathchild

    River Patroller

  • 2,108 posts
  • Location:Reading, UK.

Posted Fri Oct 5, 2018 2:45 PM

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?



#486 EnderDude OFFLINE  

EnderDude

    Chopper Commander

  • 135 posts

Posted Fri Oct 5, 2018 11:45 PM

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?



#487 emkay OFFLINE  

emkay

    Quadrunner

  • 9,558 posts
  • What's up?
  • Location:Holy Grail ;)

Posted Fri Oct 5, 2018 11:53 PM

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

#488 emkay OFFLINE  

emkay

    Quadrunner

  • 9,558 posts
  • What's up?
  • Location:Holy Grail ;)

Posted Sat Oct 6, 2018 12:17 AM

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 by emkay, Sat Oct 6, 2018 12:19 AM.


#489 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,850 posts
  • Location:Australia

Posted Sat Oct 6, 2018 12:19 AM

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.



#490 emkay OFFLINE  

emkay

    Quadrunner

  • 9,558 posts
  • What's up?
  • Location:Holy Grail ;)

Posted Sat Oct 6, 2018 1:02 AM

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.

#491 EnderDude OFFLINE  

EnderDude

    Chopper Commander

  • 135 posts

Posted Sat Oct 6, 2018 10:17 AM

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

#492 Wrathchild ONLINE  

Wrathchild

    River Patroller

  • 2,108 posts
  • Location:Reading, UK.

Posted Sat Oct 6, 2018 10:44 AM

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



#493 EnderDude OFFLINE  

EnderDude

    Chopper Commander

  • 135 posts

Posted Sat Oct 6, 2018 11:54 AM

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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users