Car racing game concept, idea, want, worth a try?

[Kilian Hekhuis]

Mmm, that link doesn't seem to open...

[Guybrush]

Hmmm... are you a member of the Commander X16 group on facebook?

[Kilian Hekhuis]

Yup, but the link just goes to the group main page. I'll try on my pc (on phone now).

[DusanStrakl]

Interesting project. I was actually thinking about putting it on my list of possible future projects but unfortunately that list is way too big already especially considering available free time

Considering that sending data to VERA can be a bottleneck some sort of hybrid solution of tile background with hardware scrolling and bitmap road with bending by using scan line shifting might work and leave enough CPU time for manipulating animated sprites that could be used for everything else.

Keep us updated and good luck!

 

[Fenner Machine]

I’ve made some placeholder/concept art.

I’ve made it in a way to easily encode it and test effects.

Also learning pixel art and animation.

This is a scene with several elements merged.

 

Edited October 22, 2021 by Fenner Machine
Image not attached correctly.

[Fenner Machine]

Critique, comments and suggestions welcome.

[ZeroByte]

I skimmed through the thread, and what you're looking to do sounds more like F-Zero than anything else, especially with the mockup posted. Obviosly the technique used by F-Zero is totally unavailable on VERA (mode 7 with hdma-driven HBLANK DMA updates). I think the way to do this would be to make a buncha-buncha road tiles for varying angles and scales of road edges and center lines, then consider those as "atomic pixels" of lines - i.e. draw a line of tiles showing the road edge angle.

Reading this thread, a "fast line draw" algorithm came into my mind with VERA - set the stride to be either vertical or horizontal (whichever increments more slowly in a typical basic line algorithm) - so say a line of slope 1:3 - 1 delta-Y for every 3 delta-X. Set the stride to be horizontal (1 or 2) and draw delta-X number of pixels/tiles then bump the address +/- however many bytes-per-row your display area uses.

 

[Fenner Machine]

Hi ZeroByte. You did an impressive Sonic demo using lots of scrolling.

 

My original idea is probably a bit ambitious and doesn’t take advantage of the X16 strengths.

Instead, I’m planning on a pseudo 3D driving game, a bit like OutRun or Pole Position, but I don’t want to do a clone. So I’m going to try a new style and slightly different perspective.

A slightly more zoomed out look, trying to reduce the amount of ‘scaling’ required, as ‘scaling’ would just be different sized sprites. That should free up VRAM for more variety.

It might work, and if not at least I will have experience programming and making graphics.

I’ll use that experience to make a decent driving game for the X16 eventually.

 

320×240, 4bpp tiles and sprites, custom colour palette and make use of palette offsets, tile flips etc.

Background layer 128×32 tilemap, 8×8 tiles. Over 3 times the viewable screen width, so could maybe simulate 360 degree rotation.

Road layer 64×32 tilemap, 8×8 tiles. Use line scrolling for bends. Maybe palette swaps for road movement, but maybe just vertically scrolling centre tiles. Is that even possible, and if so would it save CPU cycles verses palette swaps?

Sprites, whatever combination of sizes for optimum VRAM use and number of sprites per line.

[Kalvan]

You make it sound less like Out Run and more like Turbo.

That's not necessarily a bad thing.

Also, using sprites for the centerline and shoulders means that 1. they won't be available for things like trees billboards, clouds, or cars, and 2 how do you plan for them to not overlap the cars on the road?

[Ed Minchau]

On 10/25/2021 at 7:46 PM, Kalvan said:

You make it sound less like Out Run and more like Turbo.

That's not necessarily a bad thing.

Also, using sprites for the centerline and shoulders means that 1. they won't be available for things like trees billboards, clouds, or cars, and 2 how do you plan for them to not overlap the cars on the road?

Sprites can be placed between layer 0 and 1, behind layer 0, or on top of layer 1. They are also drawn with lower-number sprites drawn on top of higher-number sprites (within the sprite attribute table).

[Fenner Machine]

Thanks you for your replies.

The road including centre lines would be part of the tile layer.

Sprites used for things like cars, track side detail (trees, houses etc) and random encounters with obstacles like potholes and animals running across the road.

Edited October 26, 2021 by Fenner Machine

[BruceMcF]

On 7/31/2020 at 11:12 AM, StephenHorn said:

.. but I figure a person could reduce the necessary draw surface further through strategic placement of HUD elements in a tile layer and, if it really comes down to knocking out a few last columns or rows of pixels in order to free up CPU time, you could always reduce the size of the display area with DC_VSTART, DC_VSTOP, DC_HSTART, and DC_HSTOP, and I wouldn't be surprised if a lot of folks just don't notice if you're actually running 300x240, or the like, especially on a VGA display. (Just make sure to leave enough VRAM for a double-buffered display of that bitmap layer... you almost certainly can't do 60Hz so you'll want to draw to a backbuffer and only flip between the two during hblank.)

Yes, you can put plenty of "active" decoration in a tile layer along the side or edges which is very "cheap" to manipulate, and trim off whole rows or columns of pixels from the bitmap layer underneath. You say around 33% of the pixels if you have ~10 pixels of decoration on the top and bottom and ~30 on the bottom and each side with a ~240x200 active display.

[ZeroByte]

You could draw your road border tiles and lane line tiles using color palettes intended for palette rotation so you don't have to scroll anything at all (except for the raster line effect used to create bends in the road)

If you wanted to get really fancy, you could do 8 colors for border cycle and 8 colors for centerline cycle, make both tiles use the same palette, and then just rotate the one palette every frame. You could do it fairly speedily as well using the two VERA data ports - point both at the first entry of the palette. Read 2 bytes from data1 and cache those in X and Y as the "new last color" now alternate "read data1, write data0, read data1, write data0... do 14 such pairs (inline - don't make a loop) and then lastly STX data0 STY data0.

[ZeroByte]

On 10/25/2021 at 4:41 PM, Fenner Machine said:

Hi ZeroByte. You did an impressive Sonic demo using lots of scrolling.

By the way, thanks!