You're game uses cpu for drawing so how can you say a faster vdp would be useless.!
A vdp with more vram and doing everything with blits should be your wet dream
Sure, a Vdp with 256KB of VRAM can help a lot, by example, we can store everything in vram and just order the bitblit.
In the firsts stages of the develop, I did test using single screen buffer, and storing sprite patterns on VRAM, the result also prof that z80 is not fast enought.
Again, bigger ass vdp is not the solution, but "smart" one is the solution.
The second problem that actual vdp has, is that it can't do horizontal/vertical flip on VRAM to VRAM blitting, forcing to the game developer having several copies of the same pattern in different flip states, or using it directly from RAM.
Having to store different versions of the same pattern in VRAM, made impossible to store all patterns required, then, if that isn't possible, you ends with a logic to store patterns temporally on demand (Is what I called a pattern's VRAM buffer), well, z80 is not fast enough to run that logic, including using the best code imaginable, simply it can't do it.
But I tested all the ways.
If just VDP were SMART enough to have X/Y wrapping, and bitbliting flip capabilities. Include if it is only 128KB, well, we can work with something in screen 8 doing single screen buffer, and tolerate it without frame Vsyncing, so some flickering no problem. But , it was a no no path, with so many patterns required.
IMO, better VDP should have an option to map VRAM pages to RAM address space, so no more a lot of I/O VRAM access which is way slower (i do understand that mapped VRAM could have been used by video renderer at the same time but i bet it would be faster anyway, and good software would take care of it and access VRAM in idle time slot)
This has been proven not useful in a pratic way. Z80 access memory linearly, and blitters need to consider both coordinates to be useful. So, the only gain on this is to fill up VRAM when reading from RAM (or ROM), but you won't be able to use Z80 code to "help VDP perform tasks" anyway...
You're game uses cpu for drawing so how can you say a faster vdp would be useless.!
A vdp with more vram and doing everything with blits should be your wet dream
I insist that "blitting everything" sounds more AMIGA than MSX.
Sure, a Vdp with 256KB of VRAM can help a lot, by example, we can store everything in vram and just order the bitblit.
In the firsts stages of the develop, I did test using single screen buffer, and storing sprite patterns on VRAM, the result also prof that z80 is not fast enought.
Again, bigger ass vdp is not the solution, but "smart" one is the solution.
The second problem that actual vdp has, is that it can't do horizontal/vertical flip on VRAM to VRAM blitting, forcing to the game developer having several copies of the same pattern in different flip states, or using it directly from RAM.
Having to store different versions of the same pattern in VRAM, made impossible to store all patterns required, then, if that isn't possible, you ends with a logic to store patterns temporally on demand (Is what I called a pattern's VRAM buffer), well, z80 is not fast enough to run that logic, including using the best code imaginable, simply it can't do it.
But I tested all the ways.
If just VDP were SMART enough to have X/Y wrapping, and bitbliting flip capabilities. Include if it is only 128KB, well, we can work with something in screen 8 doing single screen buffer, and tolerate it without frame Vsyncing, so some flickering no problem. But , it was a no no path, with so many patterns required.
Yes, with small optimizations we could do a lot more things on V99x8 and a lot more easier. H/V flips sounds like something that should be easy to implement and yet Yamaha let them out. It's a bit tricky, but with current knowledge on VDP-VRAM access it can be implemented. Same goes to VRAM bankswitching (to allow more GFX to be stored on VRAM). Dual plane GFX otherwise would need another VDP, and you would still have to deal with sprite/background priority on main program (Z80). And other optimizations would not be possible (like the max sprites per scanline limitation, altough something could be done if you have two VDPs).
apart from an external VDP superimposed to the internal VDP, nothing of this could be easily installed on average joe's MSX, because it would require to dessolder VRAM chips and place some airwires that could disrupt MSX's proper operation, so only tech experts should try to install it. That's why a V9990 superimposed over internal MSX VDP sounds a lot more promissing (and this is already emulated on OpenMSX as Video9000 add-on card).
Of course that's not @fzanoto's intention, as he looks for something that could replace MSX's VDP to display higher resolution graphics and compatible with standard VGA monitors.
Again, bigger ass vdp is not the solution, but "smart" one is the solution.
IMHO, in order to overcome the CPU throughput problem, we can drop the idea of the CPU detailed drawing in the video memory all together (no matter how it is done).
BIG VDP can be a solution if it can draw/render via the graphic language (like OpenGL). Then Z80 will be capable of instructing the BIG VDP about what to do, including the motion vectors, skeleton models and after effects (very high level).
Once the MSX<->VIDEO graphic language is standardized, the SW only VDP or the HW only or the mixed emulation can be implemented.
Otherwise, the reach tiled graphics works quite well with a relatiely small CPU overhead (no 3D games of course), but do we want to develop and code another NEO-GEO?
Again, bigger ass vdp is not the solution, but "smart" one is the solution.
IMHO, in order to overcome the CPU throughput problem, we can drop the idea of the CPU detailed drawing in the video memory all together (no matter how it is done).
BIG VDP can be a solution if it can draw/render via the graphic language (like OpenGL). Then Z80 will be capable of instructing the BIG VDP about what to do, including the motion vectors, skeleton models and after effects (very high level).
Once the MSX<->VIDEO graphic language is standardized, the SW only VDP or the HW only or the mixed emulation can be implemented.
Otherwise, the reach tiled graphics works quite well with a relatiely small CPU overhead (no 3D games of course), but do we want to develop and code another NEO-GEO?
Ofcourse NEO-GEO like graphics on MSX sounds like a wet dream, but even for this goal we can't have it in a way that we should learn how to code for it from scratch. If it could be done in a way MSX coders find intuitive, it will be a killer HW.
nono no , again, don't dream with big ass vdps, without you being one of the happier owners of TR.
If the vdp is capable of dual bitplane screen, the only that helps, in about sprite software render, is that the background restoration can be just order a BLACK box render, that is just one command. If we are wasting the forefront bitplane for just software sprite. This is an advantage, but again, it maybe can save 30% of the work. There is no issue in this about sprite priority. Because it follow a order, ERASE ALL SPRITE first + print all characters after doing them AI, and take note of where them are rendered, so the next time this screen buffer needs to erase them all, it run that list.
Ofcourse, one thing is to erase all to just black, or erase all to scene background, the first do faster.
VDP is capable of XY FLIP, but just from RAM -> VRAM, not from VRAM/VRAM, where is really most needed, because in the first one we can flip from the point of view of the cpu sending the data backward.
Include if the VDP were smart enough to cycle only the X axis.... so if X = 256 it means X = 0 same row, it will help a lot, not testing for X split, and don't needs to divide the render in vertical halfs, which make the render MORE complicated, because one thing is to take the sprite pattern as a whole, and output it to the vdp, and other thing is to output it partially on demand.
The vertical Y axis wrap, well, it is the same than X, if it just wrap on Y = 256 means = 0 same column, but not, it goes to the second screen page, not help there either.
so, the render routine is basically more large, by this stupideness, or lack of knowledge about the real actual "needs" from software developers at that time, but hey, maybe at that time, software developer sure didn't know that it was a problem not doing X/Y wrapping, so didn't comunicate to the yamahaa team. Not to say, it must be custom per screen mode.
And you thinks it will have a cost?, no, it is just and AND logic without any extra speed cost, the AND logic is just don't connect the X bit 9 in screen 8, and when ensambling the vram address, it is just a direct wiring for Y in MSB and X om LSB, it will force them to plus the screen page number, which actually doesn't, but it can be done with XORs in the higher bits with no extra cost. But it wasn't in the mind of engineers at that time, them wire a simple but costly Y * 256 + X (because it is a sum which require wait a tick for stabilization), ofcourse implemented the formula work for all screen modes IIRC because the 512x mode is 16bits.
nono no , again, don't dream with big ass vdps, without you being one of the happier owners of TR.
If the vdp is capable of dual bitplane screen, the only that helps, in about sprite software render, (...)
(I'm breaking your sentence in the middle because I couldn't wait to reach the end to say this)
A big ass vdp should at least have DECENT hardware sprites so we don't need to mess with software sprites. PERIOD! Please, think out of the box! (not just @flyguille, ok?)
(...) is that the background restoration can be just order a BLACK box render, that is just one command. If we are wasting the forefront bitplane for just software sprite. This is an advantage, but again, it maybe can save 30% of the work. There is no issue in this about sprite priority. Because it follow a order, ERASE ALL SPRITE first + print all characters after doing them AI, and take note of where them are rendered, so the next time this screen buffer needs to erase them all, it run that list.
Ofcourse, one thing is to erase all to just black, or erase all to scene background, the first do faster.
Well, this is true when you're dealing with software sprites. But, again, think out of the box: If you have a "big ass" brand new VDP, you could have a brand new hardware sprite engine. If you have a good hardware sprite engine, you can save all this Z80 time.
nono no , again, don't dream with big ass vdps, without you being one of the happier owners of TR.
If the vdp is capable of dual bitplane screen, the only that helps, in about sprite software render, (...)
(I'm breaking your sentence in the middle because I couldn't wait to reach the end to say this)
A big ass vdp should at least have DECENT hardware sprites so we don't need to mess with software sprites. PERIOD! Please, think out of the box! (not just @flyguille, ok?)
(...) is that the background restoration can be just order a BLACK box render, that is just one command. If we are wasting the forefront bitplane for just software sprite. This is an advantage, but again, it maybe can save 30% of the work. There is no issue in this about sprite priority. Because it follow a order, ERASE ALL SPRITE first + print all characters after doing them AI, and take note of where them are rendered, so the next time this screen buffer needs to erase them all, it run that list.
Ofcourse, one thing is to erase all to just black, or erase all to scene background, the first do faster.
Well, this is true when you're dealing with software sprites. But, again, think out of the box: If you have a "big ass" brand new VDP, you could have a brand new hardware sprite engine. If you have a good hardware sprite engine, you can save all this Z80 time.
Yes, you are correct about it.
Oh, sorry if you felt offended about me interrupting your sentence on the middle. I felt that I was rude after doing that. Sorry.
Yes, you are correct about it.
And that's one of the main advantages I see on coding for V9990. There's a 256x212x16 dual layer pattern mode with 125 16x16x16 sprites. (each layer can use two palletes, and each sprites can use one of the four palletes) If you use this screen mode, you won't need to do too many things on Z80.
I wish you could pick any of the four palettes freely for each tile though. Nevertheless, V9990 is a pretty strong proposition. Only downside is availability and the pattern modes being 15 kHz-only (how hard is it to make a scandoubler).
I recently wrote some V99x8 code for softsprites; worst case, save-draw-restore softsprites take 12 draw calls in stead of 3, it costs a lot of VDP time to draw.
And as for V99x8 sprites, y=216 is such a useless and annoying function, why aren’t sprite colours looked up by sprite attribute number in stead of the pattern number, and who on earth thought it was a good idea to specify early clock (EC) per-line in stead of per-sprite (16 outs to change EC!). Sorry, had to vent some frustration on the design 
.