Jump to content
Fenner Machine

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

Recommended Posts

I have an idea for a racing game, but not sure if it’s feasible?

Car racing game like 90’s 3D arcade games, but obviously cut down to fit hardware capabilities.

Keep as much of the look and gameplay as possible but with an 8 bit aesthetic and limits of hardware.

Using a mix of 3D race track with 2D sprites.

Race track simple but full 3D or wireframe.

Cars, objects such as trees, overlays such as car info and mini map 2d sprites.

Maybe something that the 16 bit computers and games consoles would have struggled with or wouldn’t have bothered with, but nowhere near 32 bit console abilities.

Would the Commander X16 be capable of something like this?

Is it worth trying?

  • Like 1

Share this post


Link to post
Share on other sites

8MHz is certainly 8X more processor power than the C64 had, and C64 had Battlezone, Elite, and Sentinel, all of which were 3D games to a certain extent. So I think this would be well within the realm of the possible, especially if you stay with wireframe, but it will be a challenge.

  • Like 1

Share this post


Link to post
Share on other sites

You should take a look at Toy Story Racer for Gameboy Color. this video has a bit of gameplay footage and a brief explanation of the effect What you see on screen is a prerendered video of a 3d track, and a bunch of sprites put on top. Basically, making a green screen.

The Gameboy Color has similar processing and graphical capabilities to the x16, however, the x16 has much more ram attached to both.

Share this post


Link to post
Share on other sites
2 hours ago, lamb-duh said:

The Gameboy Color has similar processing and graphical capabilities to the x16, however, the x16 has much more ram attached to both.

In general, the GBC is a good yardstick for the X16 - a very similar level of graphical and processing capability. If it could be done for the GBC, chances are it could be done for the X16, and probably a little better.

Share this post


Link to post
Share on other sites
1 hour ago, lamb-duh said:

You should take a look at Toy Story Racer for Gameboy Color. this video has a bit of gameplay footage and a brief explanation of the effect What you see on screen is a prerendered video of a 3d track, and a bunch of sprites put on top. Basically, making a green screen.

The Gameboy Color has similar processing and graphical capabilities to the x16, however, the x16 has much more ram attached to both.

GBC:

  • 4K of fixed RAM
  • 28K of banked RAM (7 banks of 4K each)
  • 127 bytes of "fast" RAM present near the end of the memory map (similar to 6502's zero-page registers)
  • 16K of banked VRAM (dual 8K banks) directly exposed to CPU, character data and tilemaps have fixed locations
  • CPU has 16-bit stack pointer, meaning the stack can grow as large as the entire memory map
  • CPU has slower execution speeds than CX16, when running in double-speed 8MHz mode

CX16:

  • 40K of fixed RAM (minus 258 bytes used for bank latches and I/O page)
  • Up to 2M of banked RAM (each bank 8K)
  • 128K of VRAM separate from CPU (not quite since VERA 0.9 changed to store PSG/palette/sprites near the end of VRAM), character data and tilemaps have remappable locations
  • Also has 4K of PCM sample buffer memory and 114 bytes of NVRAM in the RTC chip.
  • CPU only has 8-bit stack pointer, meaning you only have 256 bytes to work with, and it may be problematic for complex code that relies on deeply-nested subroutine calls.
  • CPU has faster execution speeds at 8MHz

Maybe some GBC-to-X16 conversions could happen, considering the latter system is technically-superior in a lot of areas than the former.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, StinkerB06 said:

CPU has slower execution speeds than CX16, when running in double-speed 8MHz mode

Are you referring to the fact that 6502 instructions tend to run in fewer clock cycles than equivalent instructions on a z80, or something else entirely?

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, lamb-duh said:

Are you referring to the fact that 6502 instructions tend to run in fewer clock cycles than equivalent instructions on a z80, or something else entirely?

Yeah, it's because 6502 instructions are faster than equivalent GB CPU instructions. A standard 6502 takes 2 to 7 cycles, whereas the GB takes multiples of 4 cycles (known as M-cycles) into account.

Also note that the GB has neither a Z80 nor an Intel 8080, instead it has a SHARP LR35902. Its register set is identical to the 8080 except for the status register. Some of its bits were lost to make it cheaper to produce, and requires ported code to be reworked for the lack of a negative or overflow flag.

  • Like 1

Share this post


Link to post
Share on other sites

When comparing the X16 and the GBC, don't forget the rather limited 160x144 pixel screen resolution of the GBC vs the 640x480 of the X16. 

That's ultimately an advantage of the X16, but it also means that, although the X16 has more VRAM, it also has a bigger screen to have to generate with it.  Whether the increased resolution will also take up more of the X16's processing power and time, or whether that is more than made up for by the Vera, is not something I'm able to predict and might depend on the situation.

Share this post


Link to post
Share on other sites
1 hour ago, John Chow Seymour said:

Whether the increased resolution will also take up more of the X16's processing power and time, or whether that is more than made up for by the Vera, is not something I'm able to predict and might depend on the situation.

No, it'll definitely take up more of the X16's processing power and time, in particular because you can't just write directly to VRAM, you have to write through the VERA's I/O interface, so there's some preamble you have to do whenever you want to move the VERA's "cursor" into VRAM.

I would assume that someone wanting to make a raytraced 3D game would start by creating a 320-wide bitmap layer, then setting DC_HSCALE and DC_VSCALE to 64, so they're working at 320x240. That's still 3.3X more pixels than the Gameboy, mind you, 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.)

  • Like 1

Share this post


Link to post
Share on other sites

The GBC game paks could have up to 8MB of ROM and even add up to 128k of additional RAM if so equipped.

  • Like 3

Share this post


Link to post
Share on other sites
1 hour ago, SlithyMatt said:

The GBC game paks could have up to 8MB of ROM and even add up to 128k of additional RAM if so equipped.

I didn't realize gbc games got that big! the toy story racer rom is only 2mb, even the pokemon games are only 1-2mb. The biggest gbc rom I have is donkey kong country (at 4mb, which used a lot of prerendered assets). Do you know which games used 8mb carts?

Share this post


Link to post
Share on other sites

Some interesting and inventive suggestions and ideas of limits and capabilities.

A pre rendered environment would not achieve what I envision.

 

I am thinking of a 360 degree environment.

The track, “representations” of cars and other interactive elements can be “simple” 3D for game engine purposes, such as screen placement and collision detection.

The track would be calculated and displayed as vectors and curved shapes.

Cars and other item positions would be calculated in 3D space but displayed as 2D sprites.

 

I don’t know if it would make a difference to the maths, or if optimisations can be used, but no full 3D shapes or rotation would be required.

“y” and “z” would be directly related to each other, as in how far from the screen/camera. Like a flat plane projected into the screen at an incline.

So maybe only two coordinates such as "x" and "z" would need to be calculated in real time, or "y" could be more easily calculated?

Imagine a weird mix between Starglider, Mario Kart and Sega Rally.

 

I would like 640×480 resolution if possible for the increased imaged fidelity and 2D quality.

Screen split top and bottom half.

Bottom half track and playfield.

Top half backgrounds and sky.

 

Does this sound doable?

If the game engine works, it could be modified for other games.

Share this post


Link to post
Share on other sites

Strictly my opinion, but 640x480 sounds ambitious, even considering that you're limiting your 3D to the bottom 320x480. It's a fill rate issue, your 8MHz CPU can only write so quickly, even if we're just talking wireframes. Just keep in mind that 320x480 is 4x as much work as 160x240. Also, I'm assuming you plan to draw to something like a 1bpp bitmap, so your memory requirements are 19KB and you can draw to a bankbuffer and flip between the two. 2bpp is also theoretically possible, costing a reasonable 37.5KB but requiring twice as many writes to the VERA. 4bpp will be untenable, that's 75KB and thus more than half of your VRAM -- this will severely limit your pixel drawing, because you won't be able to fit a backbuffer and will have to either live with seeing the draw process happen over multiple frames or you'll have limit your drawing exclusively to the vblank.

  • Like 1

Share this post


Link to post
Share on other sites

I agree that this will be ambitious in  640x480, especially in bitmap modes. Although - with a bit of trickery and strategically optimized tile definitions you could do this in 16x16 tile mode with 256 colors. You would only have to render the borders of the track. So instead of rendering the full lower half you could arrange the tiles just where the track is. This way memory requirements could be lowered substantially. 60-80 tiles of 16x16 in 8bpp require 15 to 20kB of VRAM for tile definitions. Let it be 100, then it's 25kB. Because the most part of the track (asphalt) and surroundings (grass etc.)  would be the same tiles all the time. You would also have to update much less VRAM. Page switching would also be easier, as the pages require a lot less memory.

Of course this might require slightly more CPU power (not sure actually) - but we do have that in the X16.

Then you would have enough VRAM left for a nice bitmapped sky... Or use tiles, there, too.

Share this post


Link to post
Share on other sites
11 hours ago, Fenner Machine said:

Does this sound doable?

I think this is definitely doable, but you're going to have to make a lot of compromises between things like resolution, framerate, how much stuff is on the track. It's hard to say whether there's a balance of all these things that will make the game you want.

That said, I think in terms of computation time there's two things that are going to be taking up most of your time:

(1) coordinate projection. you need to do lots of multiply-accumulates, probably with more than one byte of accuracy. It wouldn't surprise me if there are good well-optimized libraries for the 6502 that could easily be adapted, though.

(2) the way that vera's memory is accessed is not great for drawing vector graphics. I think this is going to be the most difficult challenge in porting wireframe techniques from other 6502 platforms. even drawing a line requires seeking in vram for every scanline. you might have to render the scene into system memory, then copy it into a backbuffer in vram. or maybe there's something more clever you can do.

  • Like 2

Share this post


Link to post
Share on other sites
On 8/2/2020 at 1:40 PM, Fenner Machine said:

Some interesting and inventive suggestions and ideas of limits and capabilities.

A pre rendered environment would not achieve what I envision.

 

I am thinking of a 360 degree environment.

The track, “representations” of cars and other interactive elements can be “simple” 3D for game engine purposes, such as screen placement and collision detection.

The track would be calculated and displayed as vectors and curved shapes.

Cars and other item positions would be calculated in 3D space but displayed as 2D sprites.

I think it would help if you drew some mockups of what you mean. I can sort of picture what you're describing, but I don't knmow if the picture in my head is anything like what you're thinking. 

 

Share this post


Link to post
Share on other sites

I have made a hilariously bad 3 stage image of what I have in mind.

Many aspects of it, include aspect ratios ba dum tss, are way off, but gives an idea.

Car heading toward a turn, turning, and coming out the other side.

1540746736_Examplegamelook2.thumb.jpg.6148da3a5f68d0b2180c9f891b9a0e4c.jpg

Share this post


Link to post
Share on other sites

I think I’ve found a game that looks similar to what I envision.

Enduro for Atari 2600.

Something like that but a 360 degree 3D environment/plane with road edges drawn with vectors.

I’m thinking vectors as full polygonal 3D would be implausible.

Add in better 2D graphics, such as nice backgrounds and good sprites.

Share this post


Link to post
Share on other sites

The background could be tiled on the back plane, the objects sprites and the road itself in bitmap mode on the foreground plane. You could tune down the resolution a lot to speed it up (doesn't matter if it looks crude, background and sprites will look good). But what do I know, it's a long time ago that I did any kind of game programming 😁.

Share this post


Link to post
Share on other sites

You definitely don't want to draw the road in bitmap mode. Just create a fixed tile map for the road, a central perspective of the road and make it pretty wide. In the default position (road in the center, a long straight ahead) there will be some amount of horizontal scroll. Then it's just (hehe, just! 😛) a matter of calculating the right scroll offset for each screen line, depending on the position on the track. For instance, if the road ahead is turning to the left, the top line of the road will have the smallest x scroll offset, with the scroll offset increasing each line until it reaches the default position at the bottom of the screen. If you're feeling particularly bold, you can also simulate terrain elevation. It's all just a matter of choosing the right line of the tile map with the right scroll. Also, you can simulate texturing either by modifying the palette on each line or (a simpler method) create multiple tile maps with different colored tiles and change the tile map per raster line. You can do all the calculations in vsync interrupt handler. Of course, this all requires a raster interrupt for each line where the road is drawn, but since you've already calculated the scroll, it's only a couple of LDA's and STA's per line.

As for the background (mountains, sky, etc.), you can use another layer, or you can reuse the same layer as for the road, you just need to switch tile maps on the right raster line.

Everything else (cars, signs, trees and bushes) should be done with sprites.

Edited by Guybrush
  • Like 1

Share this post


Link to post
Share on other sites

Can the VERA handle offset changes pretty scan line? You could then have a fixed offset line for every possible track line (in bitmap mode), and just select the right offset. And alternate the palette for white or red side-markings.

Share this post


Link to post
Share on other sites

There is a line IRQ feature, and you can scroll tile and text layers, which can produce the effect I believe you're describing. That said, line IRQs are broken on r37. You can build the current source code yourself, though, and get the fix.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use