dvik

Thanks for feedback. Personally I always turn off music when playing any puzzle game (well I listen to the music the first time or so...) so yes, muting the music will be possible (I believe it only mutes the in-game music, not the menu and game over music. For the latter I guess muting the TV is the better option).

I documented our approach for supporting the driving module in Burn Rubber and released our source code for it. I plan to write a small standalone test program as well, but I promised Alekmaul I would publish something relatively soon. You can find the documentation and links to code at http://www.danielvik.com

Hey all, Just wanted to hear if anyone had a chance to play Burn Rubber and if you want to share some thoughts about it. -Daniel

I've been reading the criticism here and sure there may be some issues worth improving. But homebrew publishers don't grow on trees. J-F is making a huge contribution to the scene by spending time and money on this. I hope the issues can be resolved because with lack of quality the interest drops, but asking him to consider quitting publishing is just ridiculous. We (dvik&joyrex) have released several cartridges now (most of them by J-F) but without someone actually willing to produce and distribute the carts they wouldn't have been released or probably not made at all. Big thumbs up for your efforts J-F!

I guess here, he used preshifted tiles. It is why ,i think , the graphics variety is poor, it is the price to pay using this method. Indeed. The rom contains around 6900 different tiles (uses about 13kB of the 32kB rom). Every other frame 108 tiles are moved from rom to vram and then the bgmap is updated. the other frame is used for the game play and physics engine. On a 60Hz coleco, every 6th frame is used to update status bar and other lower frequency tasks like checking if the car drives backwards. On a 50Hz coleco, this is spread out over every frame. This gives a frame rate of 25fps on both. The background in the game is built up of blocks of 8x8 characters and the map itself contains 16x16 of these blocks. The most complicated parts of the game is actually not the scrolling. Making a real physics engine for four cars that can execute at around 20% of the cpu was the hardest part and took a couple of months by itself. Another surprisingly challenging part was to support two steering wheels, partly because they share a single interrupt. If people are interested I can try to make a more detailed description of how the game works. Its by far the toughest game/demo we've made. It took several thousand hours to make (if you include tools and components we brought in from earlier productions). Some I think could be pretty interesting for other developers.

Nice to see that the programmer of the game has a hard time with those high-speed, hair-pin turns as well. Great game Dvik! Just going to take a lot of practice to nail down the physics of the turns. Thanks. It really doesn't take that much practice before you start winning races. The game has a real vectorized physics engine, so it is pretty intuitive once you get used to the friction. I had btw my daughter in my lap when making the video and that adds another layer of difficulty

Here is a short preview of Burn Rubber. I made it pretty quick with no edits. I'll make a nicer video when I have a bit more time. http://www.youtube.com/watch?v=HH-OnfUuD60&feature=youtu.be

I am most likely the customer with working power supply and controllers, but I was in big need of a console because my old modded one took its last breath early this year. Yurkie helped me out really fast and after a few days I was back on track with a new console with the mod described above. I really like this mod compared to the older mod with drilled holes. This mod is really neat with just a small 1/8" mini plug. The quality is obviously a lot better with composite compared to RF and well worth the investment. Since I'm developing games I'm always a bit concerned buying consoles because I guess I got burnt by poor quality in the past, but Yurkie does pretty extensive tests on the stuff he sells and it was really worth it. This starts to sound like a sales pitch, but I really just want to show my appreciation. I'm very happy with the console I bought. Many thanks and keep up the good work Yurkie!

So it sounds like Meka and blueMSX is emulating this feature correctly then.

Sounds very good. I will do that too, but I don't have my setup easily accessible atm. If it runs correctly on a real Coleco, I'll do some more investigations to see if there are differences in the address handling.

I did some debugging and the reason why its not running properly in blueMSX (and probably Meka although I haven't really checked), is that on the TMS video chips that we based the emulation on, the VRAM address is always updating when you write to the VDP latch register (also when you write VDP registers with bit 7 set). This 'feature' is only present in the TMS video chips and not the successor V9938. Mess may have a V9938 like emulation if it shares code between these video processors, but I don't remember since its been a while since I looked at the Mess source. Did you run the game on a real ColecoVision or only in Mess? If it does run properly in a real ColecoVision it would be very interesting to get the model number of the video chip so I can look at whats different compared to the MSX VDP. Before I change the emulation it would be nice if you could check these two things. Thanks, -Daniel

As far as features goes, we're currently working on a time trial mode, which essentially is a single player mode with a ghost car that represent the fastest lap on a particular course. I have the basics working on MSX and now I'm moving the ghost car data into VRAM so it can be saved and retrieved on Coleco as well (its about 512 bytes of RLE'd data per track). After that we'll add a championship mode where the objective is to run all courses against AI cars with accumulated scoring. The other big missing part that we are working on is the sound and sfx engine and tuning inputs. But we've had some pretty good progress and I hope we can present another beta in not too long. With a little luck we may be able to finish the game this year, I guess it depends on how much tweaking and tuning we need to do to make it play smooth in all game modes.

Just curious, did anyone test the game on a real Coleco?

One option is to make a 2p mode like the one in Micro Machines. Personally I like it a lot. Another option would be something like the C64 Rally Speedway and I'm sure there are other ways too.

Some more detail about the scroll engine. The race track is made up of around 60 different tiles. Each of these tiles can be rotated 8 pixels horizontally and vertically making 64 possible combinations. All these rotations are stored in ROM. Every second frame we basically pick one rotation and update all 60 tiles, and then update the BG map. This takes most of the frame so all game logic, physics engine, input, collision detection and AI is done in the other frame. Each frame runs the sprite engine (rotating the sprites) and the music to make that part smooth. In 60 Hz we basically drop every 6th frame to get the same speed on music and game in both PAL and NTSC. This spare frame will be used to update the status bar, calculate speed, and other tasks that can be done less often. In 50Hz, we split these tasks over multiple frames.