I hope you're still working on v9938 version too...
I hope you're still working on v9938 version too...
Yes I do.
I have merged both versions at source level, using conditional assembly.
Someone is doing a good race game for Commodore264 series (C16 and CPlus4) too...
Wow, that looks quite amazing, what a detailed and colourful graphics!
Indeed, that Vespertino game inspired a lot of coders to do their best...
Metalion, any updates? Its such a good project!
Metalion, any updates? Its such a good project!
Well, I stopped development since february, because I had other projects besides MSX.
But I slowly started again last week.
The V9938 version development runs into a lot of limitations... For example, I need at least 72 sprite patterns just for the main car, much more than the 64 the VDP allows. Even with a pattern table address change, I'll be strongly limited for incoming cars and decor. I'm trying to find solutions, but it's difficult. Tried software sprite yesterday, but it does not work out with the road rendering engine.
The V9990 version is halted at the moment, because for some reason I still have not understood, it works on OpenMSX but not on real hardware. I bought a V9990 cartridge at Nijmegen in february, just so I could test. But all it gives on screen is garbage... I've not yet been able to take time to understand what is happening, but I'm guessing it's a relatively easy fix (might have to do with how the VRAM is initialized).
In my project, for little particle sprites I have all the patterns in the pattern table, however the player animations are too many and I don’t pre-load them into the pattern table. Rather I use a VDP copy command to animate the pattern data in groups of 8 patterns.
In my project, for little particle sprites I have all the patterns in the pattern table, however the player animations are too many and I don’t pre-load them into the pattern table. Rather I use a VDP copy command to animate the pattern data in groups of 8 patterns.
Yes I know that solution, it's actually the last one that I can use. But I already applied it for tests on the sideroad sprites, and loading the pattern and the colors on the fly does introduce some visible latencies on screen.
EDIT : I can, of course, put them on VBLANK, but that implies that I have to protect every VDP command (and there's a lot of them) fully with di/ei (instead of only the write to the sequential register). And that means that I can miss some HBLANK interruptions (already tested).
I have double buffered the sprite pattern table, so do the copy whenever, toggle the "active pattern table" flag, and update the pattern table base address in the interrupt handler.