I'll be following this thread with interest. Grateful if you can post failed attempts in addition to your successes. I'll be adding these to my personal test suite when I start working on the VDC again. Hopefully I will be able to offer some insight on how to remove unwanted artifacts as I improve Z64K's VDC model.
Looks like you are doing exactly the same stuff I was doing recently! I had a vertical scrolling thing and was working on something like Spy Hunter, but I got bogged down in virtual sprites for the cars. I couldn't get horizontal scrolling to work smoothly! can you share you code for doing that? I had horrible jitter no matter what I did.
If I could go back in time and meet the guy that told Bil Herd that the VDC was a superset.... Damn that missing multi colour character mode!
I was doing fine pixel scrolling on mine. I had a nice smooth 2 colour bitmap working and had started to draw the roads and stuff for Spy Hunter, then I just got bogged down in trying to make a soft sprite routine and gave up.
I wouldn't use bitmap for such a thing. I would put the VDC into 16px high chars. Then make a double height screen. The Bitmap is bad for pumping data into it, as you have to write 2chars, move the pointer, write 2 more etc. The chars will give a much better "transfer rate" each frame. Having chars means you will know you can update N chars per VBLank. Then your code just has to and/or char data during the frame. Moving them around the screen will be faster as you need to only update the chars you need to display. With 512 chars at 16px high, you should be able to easily double buffer and have enough for "sprites". You could even use the 128K to precalc some offsets.
Character mode means only 1 colour plus background per tile. In bitmap mode you get 2 colours at least. It's not great, but better than nothing. You don't need to keep jumping around in the memory either. Pump a whole line of pixels in and use the auto increment to fill the line quickly, then jump to the attribute section and write a whole line of those, it's actually not as slow as you think. My plan was also to drop down to 40 columns wide, why? Well for one thing you can increase the frequency to get native VGA out when doing that. I already proved the concept with my Boulder Dash clone. I sort of got bored when I realised that I could just use the VIC if I was going to do 40 col graphics ;p
Incidentally, the 16pixel high chars are exactly how I did the Boulder Dash clone So yes, it's a great way to do it!
damn I forgot about "the attributes mode doesn't give you two colours, because that would make sense" .sigh..
say your item is 16x16 for arguments sake. doing a 16x16 write is setting the address 16 times and doing 32 bytes., so that is 64+32 = 96 bytes to the VDC. If you do whole lines to set it, you have 16x40 = 640 bytes to pump. Plus attributes, which on the bitmap is another 80bytes and on the 16x16 is 4 with 2 register updates, so 6 bytes. You do claw it back if you have multiple updates per line though.
With 40 col you can do 40x22 and then double buffer it in 16K, which is very handy.
Why VDC over VIC you get 2mhz, and you get 16K more RAM.
But you lose sprites and VDC access being slow offsets the 2mhz.. Swings and roundabouts I guess I wanted to do it just to prove the VDC was capable and shut up all the critics of the 128 and the VDC in particular