Armchair coding Stunt Car Racer

The more I think about it the more I think someone should definitively give it a try! Are there any other MSX/Spectrum games with 3d polygonal graphics for comparison? I can only think of:
- Stunt car racer
- Hard drivin

As for implementation details, if I were to do this, I think I'd still go for Screen 2 (since we need additional tiles for the scoreboard at the bottom of the screen, etc. we would not be able to fully utilize the tile set in Screen 1 only for the game anyway). So, I think using Screen 2, using the top two banks for the game, and the bottom bank for the scoreboard could work. Then, if we want to double buffer on the VDP itself, perhaps hit9918's idea of using the first 128 patterns in each tilebank for buffer 1 and the other 128 for the buffer 2 could work. As TomH says, the graphics in Stunt Car Racer will not be complex, so it is likely that we do not need all 256 patterns to display the graphics, since there will be a lot of background!

I guess you'd probably need some empirical numbers on likely tile use per frame, though it strikes me that a close to optimal strategy for usage is a simple stack and a threshold. Suppose tiles 255 and 254 are your fixed full-tile pattern fills then:

1. at start of frame, seed the stack with 253 to 0 in reverse order, set the threshold to 0, draw your horizon;
2. when applying a tile fill to the display, any pattern names you replace that aren't 255 or 254 can be pushed to the top of the stack;
3. when plotting individual pixels, if the tile you want to touch already isn't 254 or 255 then just draw to it. Otherwise pull whatever is at the top of the stack, fill it with the same pattern as the tile it is replacing, then draw to it and update the pattern name table. If the new ID is greater than or equal to the threshold, increase the threshold;
4. to upload a frame, upload all the patterns from 0 to the threshold (or in reverse), then push the pattern name map.

You'll push up some tiles you don't need but you'll be pushing a contiguous block so the unrolling is easy. And they should be a relatively low proportion.

Separate observation: if you really believe that you'll stick within 128 tiles per third of the screen, then for a top-two-thirds update you're definitely not going to need to push more than 128*2*8 + 512 = 2560 bytes. With a hypothetical completely unrolled loop for an 18 cycles/byte transfer and the NTSC 69 lines of fast access available a frame, I make that three frames to push one frame. So if you were somehow producing the pixels quickly enough, you'd be able to display them at 20fps.

Since you are pretty-much definitely not going to get 20fps that means: if you restrict yourself to two thirds of the display and half the tile set, the VRAM interface is not the bottleneck. The unusual thing about the MSX isn't a problem, but rather whatever advantage you're getting from the tile fills adds up to an architectural advantage.

You know, for this one particular presentation.

I've written a simple 3d engine for screen 2 some years ago. The source is open, so you could use that to estimate the number of blocks being used.

https://github.com/ricbit/Oldies/tree/master/2002-05-elite

Sure, here's a compiled .COM binary. It just spins a simple 3D model, you can change the model by modifying the source code. This code is kinda bad, but my suggestion is not to reuse the code, instead just plug in a representative 3D model to check how many blocks do you need to change, from frame to frame, and then use that number to properly design the best algorithm.

Most easy way to start MSX-DOS is to use feature called "dir as disk" that can be found ie. in BlueMSX and OpenMSX. This way you don't have to learn how to put files to disk images. If you use real disk, format it first on MSX (See CALL FORMAT-command) and then use it like regular folder on PC.

To run MSX-DOS your disk needs to include files called MSXDOS.SYS and COMMAND.COM... You need to google these... then place also the .COM file to same disk and restart the emulator.

MSX-DOS should feel quite familiar if you have used MS-DOS or Windows command prompt although it is more limited. The .COM program can be started by simply writing it's name and pressing return. (No need to write extension) You can list the files on disk with command "DIR" + return. You can also exit to BASIC by writing "BASIC"+return. This already should be enough information for casual user.