Home  Search  Games  Tapes  Covers  Cheats  Maps  Software  New Stuff 
 Hall Of Fame  HVTC  Game Endings  Solutions  Remakes  Publications  Magazines  Effects  Top List 
 Members  Groups  Features  Plus/4 Encyclopedia  Hardware  Tools  Options  Forum 
Back to forumReply To This TopicGo to last reply

Posted By

on 2018-02-03
 Trail Blazer stunt racer cross over

Since driving OutRun on the arcade, I liked racing games. So now while waiting for my brain to come up with some solutions to real worlds C# problems I was drifting through some C64 demos on youTube. From there I got a plan: Use an emuator to relax.

When I switched colors on a real C16 there was the white pixel. I found a programm on this site which uses this to display a sky with stars in the border. So for trailblazer I do not want these, but I may like to switch
Extended color #1
mid scanline to get a slope into the "raster bar". Is it okay to switch any color ($FF16) which is not currently used on this pixel or is it like on VGA card, where all access locations in the palette lead to snow? Somehow the C64 can do nice raster splits..
Second thing is, I want to use hiRes to make this not look like Atari-8bit. And I want no color clash to not make this look like Specci. So I read in some on-screen texts that flexible line distance is possible on C16:
Bit 0,1,2 : Actual vertical scanning-line in a character row. R/W!.
And I hope there is no FLI bug?

Also image formates play around with changing smooth x scroll per scanline:
Bit 0,1,2 : Horizontal smooth-scrolling

So I want to use vector calculation like stunt driver. Far clipping before the road makes a u-turn so that I only have to render a left and a right side. Off-road would be fore-ground color, and road would be background or any of the extended colors. More specific: I want to split the road into a left and a rigth lane, separated at char borders.

Sky uses: Background: $FF15:
Left-lane uses extendedColor #1 $FF16
Right-lane uses extendedColor #2 $FF17
Scenery : $FF18 : Extended color #3.

I then use foreground pixel with the same color as #1 or #2 to draw wedges to get tilted raster bars. I want to use filed areas (like trail blazer) and not lines (like stunt driver).

These wedges can be constructed from chars filled up completely up to a specific line. I need static 16 chars for this. For steps in the edge I need to write dynamically to 16 more. I reuse them at every edge (by racing the beam, more or less like trail blazer does it).

Each side edge of the road needs to be rendered in software into a char. So for each line, I have two x values. Look them up for a partially filled 8x1 pixel block and write this byte to char memory.

So I also like the hills in OutRun and the jumps in stunt driver. For this the a part of the road is hidden (below) the apogee. The part of the hill off the road is aligend to the horizon. Or should I define real hills also oof road? Like in test drive.. later. With roll in the street this clipping leads to complicating my rendering. Now there may be a smal triangle of off-road color in my road. To avoid color clash here, smooth x scrolling is to be employed.

I want to use the whole 320x200 pixel. The char scrolled in needs to be rendered with a border in the middle. It needs to use extended color for off-road because I can change this on horizontal retrace. It uses foreground to draw scenery. It is very CPU costly => only one char per screen, aligned to apogee by means of flexible line distance.

I would really use
Bit 0,1,2 : Actual vertical scanning-line in a character row. R/W!
to reduce the number of bad lines and to align them to the edges to get away with full foreground chars in the raster bar near the center of the road. So does it work?

Other cars: Use the background color when drawn in front of off-road and foreground on the street. They may need to be bounded by bad lines to reduce the chance of a color clash. x-shift resolves the rest. Only two cars on screen at any time: Our car and someone to overtake.

So trailblazer runs at 50 fps ( or 60). But I think the CPU is idle most of the time. Stunt car only runs at 12 fps. I hope my design runs at 50 fps with a busy CPU.

I would like this program to be able to run online on this site. When started, it should drive automatically like Daytona USA. But you can drive with WASD. Also I would like to include a demo mode where all raster bars and x shifts and flexible line distances are presented using the automatic drive and time freeze. Naming registers on screen. Showing the inner loop of the edge renderer. How do I get this on my real C16?

What do you think? Of course later a C64 auto detect could add sprites (hires/underlay) to add details.

Posted By

on 2018-02-04
 Re: Trail Blazer stunt racer cross over

Hey there C16with64K,

That was an interesting read. I see that there are some technical questions scattered throughout your post. Sounds like you're pretty knowledgeable, so many of these you could probably answer yourself just by checking or experimenting. If you are in fact looking for specific answers, I would personally suggest to keep it simpler and shorter, perhaps even number your questions, otherwise the discussion can quickly derail.

Good luck

Posted By

on 2018-02-10
 Re: Trail Blazer stunt racer cross over

Hi Csabo,

I try to figure out the login system. Seems to me: I am a guest.
Collaboration is the entertaining thing. I figure out nasty computer stuff (windows ) all the time on my own. I guess I will set up a page on neocities and co-develop on JavaScript+canvas and 6502+TED. Or I start with WebGl.

Posted By

on 2018-02-10
 Re: Trail Blazer stunt racer cross over

Yes, you are a guest. To be honest I'm not really sure how to respond to the rest of what you wrote

Posted By

on 2018-04-08
 Re: Trail Blazer stunt racer cross over

Oh sorry: We collectively could not found the device any more and vagualy remember throwing it into the trash. In the mean time I found out that there was a version of hard drivin for C64 (before stunt racer). I also found out that the master clock of the C16 was really slower. That is no effective value, which is even more slow falling back to the 1 MHz of the C64. (Back then the wider pixels of helped making sharper image) . I also figured out that I have not enough CPU power to fiddle with anti color-clash tricks.

Back to topReply To This Topic

Copyright © Plus/4 World Team, 2001-2018