at AtariAge forum (ColecoVision part) there is a thread about Pole Position - http://atariage.com/forums/topic/152019-another-reason-pole-position-shouldve-been-released-for-the-cv/ - and since i posted a test there, here is the msx version of it: https://dl.dropboxusercontent.com/u/795795/retrocoding/msx/poleposition_msx_teste.zip - so, perhaps, i think would be great having a MSX port of Pole Position, that would be better than the TI-99/4A version?

thanks! i actually used 22 frames (and yes, 11 for the rotation, instead of 23 from the original arcade version (they used 12, with x-flipped sprites) ) - i guess you moved the joystick up for seeing the car moving!

Eager to see if you have made any more Pole Position mock ups or demos?   As your player car was a software sprite, have you planned to use software sprites for other cars as well, in case if you would like to make the actual game? It will work with hardware sprites as "enemy" cars too, maybe cars might explode slightly too early though ("invisible car" problem) if player drives behind the "enemy" and hits hardware sprite enemy´s tail, as hardware sprite cannot be (easily and smoothly) hidden behind/under the frontside of player software sprite, so it would look like cars did explode without actually hitting each other at least when hitting while driving with slow speed.

I have an idea.

For that invisible car problem, one solution could be you could hide few hardware sprites behind the right edge, on the same y-coordinates as player software sprite, that would allow hardware sprite enemy car to smoothly be hidden under top pixels of player´s software sprite car, just before both cars will explode. Result is it will look like hardware sprite car will slide under software sprite! Hardware sprite is not visible through "transparent" pixels of player´s car though, but it´s not that big problem I think.

Of course that solution could cause problems when you are safely passing another car while one car is exactly in front of you, but I think you can easily overcome that problem by just swapping sprite plane numbers of enemy cars. The car which you are passing must have the highest sprite plane priority, hidden sprites will have the second highest priority and the car in front of you will have the smallest priority.

When there are two enemy cars in front of you at the same time, that routine must see which car can be passed and which car is in front of you, by comparing x-coordinates of both enemy cars and player´s car.

This might be usable for Toni Galvez´s Buggy Boy fantasies too! I would love to play that game on MSX1.

Hi!

I think that, from the theoretical point of view, this kind of games in MSX could be programmed with different approaches:

1) The underexplored approach: NAMTBL-based scenario (yes, like Hyper Rally or Antarctic/Penguin Adventure). It has potential: just see Outrun Europa (Sega Master System). It minimizes the amount of RAM-VRAM transfers and does not use any sprites (like GP World did, by example). The drawbacks are that the tileset must be carefully designed and the rendering algorithm can impact the speed of the final result.

2) The way most of the ZX Spectrum conversions did: per scanline. The main problem of this approach in the MSX is the huge amount of RAM-VRAM transfers, killing the performance, even if the CLRTBL is untouched (monochrome games). I still think that it is posible to get this working at a decent speed playing with NAMTBL, CHRTBL and CLRTBL, reducing the gameplay zone and aiming for "flat" surfaces. And, of course, lots of coding tricks to "mimick" the math formulas to calculate the road path. Maybe the best possible in MSX(2) would be something slightly behind Top Gear Pocket/Rally (Game Boy Color)...

And that for just the scenario...