C64 sprites are great and all, but they really screw with your raster splits. Depending on how many sprites are over a raster, what character line we're on you may end up with virtually NO cpu cycles left at all! Looking up some timing info on the VIC (HERE) shows that BAD lines+ all sprites leaves you with less that 10 CPU cycles a scanline, and only 4 write cycles at the start.
Theres a few ways to get a cleaner split, but most use too much memory. However, I've got a reasonably stable raster for now and although it flickers a little now and then (when LOTS of sprites scross the panel raster) its mostly okay.
I guess the best way would be to count the number of sprites that cross then do some kind of variable delay depending on the count. Thats faffy stuff, and I could spent LOTS of time trying to get a clean raster split, so I'm happy enough just now with a basic flicker... I might fix it one day....
Actually.... If I lose the 1st pixel of the panel, the flicker won't be visible, thats probably the best solution.
EDIT: Well, removing the 1st pixel of the chars at the top of the panel actually works pretty well. I now have a solid raster split no matter what crosses the raster - cool.
3 comments:
Your post inspired me to write this :)
I liked the use of the timer, thats pretty cool. Its one of the features of the Plus/4 that I do miss on the C64, the horizontal raster counter... Using a timer to do the same is pretty neat.
Using timer is pretty standard demo coding method these days, although to do it with minimum cycles one would point IRQ vector to $DC02, place JMP there and have multiple routines 256 bytes apart. Juggling code to keep those code snippets at correct place didn't sound too inviting, so I went the slower route.
Post a Comment