How hard would be to convert Stunt Car Racer?

[emkay]

Or Gr. 7 , fast line drawing, and build the car graphics on byte boundaries....

The Atari is fast enough to update the car in full 50 or 60 fps then ... and, well , filled polygons look better than just lines

[Rybags]

The bitmap which coincides with the car would only come to a couple of hundred bytes.

I'd change the car graphics to be on byte boundaries moreso than it already is. Then use brute force copy. There's stuff like wheels and parts of the exhaust where diagonals and curves exist, doing a few dozen bytes of mask/merge would be OK.

 

PMGs could be used within the car graphics to enhance colour.

[emkay]

PMGs could be used within the car graphics to enhance colour.

... and details....

[emkay]

btw. the "3d" seems to work between 6 and 10 fps, while the wheels get updated at 25fps.

Is there a statement of the coder, which fps have been actually reached?

Edited June 18, 2015 by emkay

[Rybags]

I imagine the FPS would be highly variable - the wheels actually move up/down too and for whatever reason the flames from the exhaust seem to move from one side to the other. Wheels are sprites like the remainder of the car so a minimal of processing power would be lost in their animation.

[landgraf]

and for whatever reason the flames from the exhaust seem to move from one side to the other.

To save sprites would be my guess Unlike in the video they switch sides every frame though - looks like the video shows almost every second frame but every now and then a single frame gets lost so the flames are captured when on the other side after that, until it happens again.

[Lost Dragon]

Clearing out my collection of Gamestm magazines, I found an interview with Geoff Crammond.

 

 

He talks of creating the C64 version 1st,then creating ST/Amiga versions.

 

Pete Cooke creating ZX Spectrum version by converting it from C64 code.

 

Tim Angell creating PC version by converting the C64 code.

[Flojomojo]

That's very cool, and reminds me of how San Francisco Rush was planned for the GameBoy Color. The developer said it had similar specs to the C64 which could run simple polygonal games, like Stunt Car Racer.

[Grevle]

So why is there a limitation of 4 colours?

 

Well depends on what you mean. Some modes are 4 colors and even 5 colors and then 4 more colors for the players. Also when players ovelap 2 extra colors for each player is produced then you are at 13 colors and still not using mixed modes or DLI.

 

With some mixed mode tricks and DLI then i beleive there can be many more colors.

Edited July 28, 2016 by Grevle

[emkay]

Well depends on what you mean. Some modes are 4 colors and even 5 colors and then 4 more colors for the players. Also when players ovelap 2 extra colors for each player is produced then you are at 13 colors and still not using mixed modes or DLI.

 

With some mixed mode tricks and DLI then i beleive there can be many more colors.

Stop! If we're talking about fluent "3d", any colour enhancing tech isn't useful. The restriction to 4 colours is based on the clean linear graphics modes. Overlaying the PMg is a different thing. As it could enhance the whole screen, but the calculations have to be restricted to the linear graphics itself.

[Lost Dragon]

@Flojomojo:Thought i'd post up the 'find' as i hadn't forgotten folks were putting the idea out of converting the ZX Spectrum code rather than the C64 code, seemed worth a shot mentioning ZX Spectrum code itself was converted from C64 code.

 

No idea if it helps anyone plan a possible A8 version, but at least it shows how others used the 'base' C64 code.

[Synthpopalooza]

Here's an idea:

 

Antic 4/5 in 128 byte mode. Change the char set with a DLI every 4 char lines. This gets you a 5 color bitmap screen, write directly to the character font memory. The bitmap graphics in this mode will be laid out exactly like on C=64 so the code will be easier to port.

[Rybags]

The mapping will be different. The problem with emulating the C= bitmapping method is you get those pesky 1K boundaries which means you can't get 1:1 mapping beyond a couple of character lines.

 

For one particular proposal, I even considered doing that method and using brute force "blits" to move the data that was affected by the boundary. But even for a part screen window it gets to the point where it costs way too much CPU time.

[emkay]

 

 

The mapping will be different. The problem with emulating the C= bitmapping method is you get those pesky 1K boundaries which means you can't get 1:1 mapping beyond a couple of character lines.

Using mode 5 will equal the 1K boundaries... and the game would run smooth, smoother , smoothest... 3D screens should always use any "double scanline" mode. If people want more details, they could overlay the PMg!

[popmilo]

Forget about cars "sprite-mask". It's nice but not very much important. Once 3d game engine works it's easy to make that part best it can be (mix of 4 color bitmap over 3d and PM details).

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/

[emkay]

Anyway... Maybe it would be nicer to make a new game in that genre

Yeah, it would be easier to have a look at the speccy version. Either recreate the 320x192 screen or build a colourful graphics 7 screen with additional PM overlay, than to use the C64 version for a conversion ...

[popmilo]

Deleted

Double click...

Edited August 12, 2016 by popmilo

[popmilo]

Managed to find some time and rip out bitmap screen while playing c64 version.

With all color attributes set to same values (rgb for three bitpair combos) it looks like this:

Black is used for lines.

'red' bitpair is used for edges of track.

Second bitpair (green) is used for 'area with details between sky and land'.

Third (blue) is used for sky+ground.

Most important - bottom "Car graphics" is also drawn into bitmap.

Imho it wouldn't be hard to make it work on Atari... Either in bitmap 4 color mode or character mode with 5th color.

Edited August 12, 2016 by popmilo

[emkay]

Forget using charactermode for that! Using "Gr.7" would result in a playable Stunt Car Racer on an 8 Bit Computer. ... C64 Spectrum or Amstrad... they are all too slow, to handle eneough frames and proper controls at the same time.

[pirx]

but it would need more serious rewrite of the code to allow for different aspect ratio. it could be as simple as one asr, but not necessarily.

[popmilo]

Char mode is not the enemy

If it let's us use one more color per character that can be set by changing 1 bit per char then all the cycles we could save by using bitmap mode are not that important.

It's much much faster to just change hundreds of bytes in "sky part" of screen to make it blue instead of changing couple thousand bytes in bitmap.

 

On the other hand, using '2 scanline high' modes is a good idea. That for sure saves a lot of cpu time. Using double height character mode sounds like a winner imho.

Maybe it could be made into option you could select "double or single scanline mode". Player maybe wants it pretty maybe wants it fast.

 

Needs more investigation. As time allows it we'll maybe figure more out...

[Irgendwer]

It's much much faster to just change hundreds of bytes in "sky part" of screen to make it blue instead of changing couple thousand bytes in bitmap.

 

 

Wouldn't a DLI at the horizon with a single colour register change have the same effect?

[Rybags]

The enemy is also how the thing is rendered (thanks to earlier post from Popmilo and getting behind the scenes with the ICU64 utliity with WinVice).

 

Rather than the time-consuming process of filling solid areas like the sky and track, the C64 only draws the lines and fills the cell corresponding to where transitions are occurring. For the filled areas it's just using attributes to do the heavy lifting. An obvious time saving since it's a single write rather than 8.

The filled areas use non-zero pixels which are assigned attributes, so the sky and track are the same. Where clash is possible another foreground colour is used.

Whether this would translate easily to Atari... hard to say.

 

 

ed - also, there is good reasoning for the fixed area with practically no changing graphics. The game double-buffers the main screen which means most of the 16K is used. The bottom part isn't double-buffered which leaves that Ram free to hold the sprites and atrribute Ram.

Edited August 13, 2016 by Rybags

[emkay]

since it's a single write rather than 8.

 

The filled areas use non-zero pixels which are assigned attributes, so the sky and track are the same. Where clash is possible another foreground colour is used.

Whether this would translate easily to Atari... hard to say.

They did that to have some additional colour for the Car. No need to use that fuss on the Atari. The "3D" Scene could be set with 4 colours. Then , have a look at the "Car" . there is a range where never any 3D appears. Then there is a range of "4"? chars height. putting that part to byte boundaries and overlay some PM , gives additional colours. Then , the rest of the car can be adjusted by a DLI. Well, "Gr. 7" means to have "4 times" more bytes to fill , but one can drop every filter routines to adjust charmode clashes and non linear handling.

The most important part is to have additional cycles available for the "3D" calculations.

Edited August 13, 2016 by emkay

[popmilo]

Wouldn't a DLI at the horizon with a single colour register change have the same effect?

Problem is that horizon is not horizontal all the time.

 

 

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