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

[Fenner Machine]

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?

[StephenHorn]

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.

[lamb-duh]

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.

[SlithyMatt]

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.

[StinkerB06]

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.

[lamb-duh]

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?

[StinkerB06]

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.

[John Chow Seymour]

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.

[StephenHorn]

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

[Kilian Hekhuis]

What about ROM? The GBC had cartridges with ROM, what was the ROM size limit?