grinvader wrote:What do you intend to do about the 2 ppus ?
A very good question. I'm not 100% sure just yet.
All of our current scanline renderers have no problems interleaving their function, so I'd like to keep both of them inside the same class. They may be two chips, but unlike the CPU and SMP/DSP ... they really cannot do anything useful alone.
I will separate all of their variables into separate blocks, and try and comment on what chip is doing what to make their separation clear.
The biggest problem I foresee is if there are hardware communication delays between the two chips. Eg let's say a write is recognized by PPU1 at time=n, and by PPU2 at time=n+4. I'd have to keep a 4-cycle history for that register.
But I think most of the communication will be internal and minimal, so it should be okay.
If it turns out I absolutely have to split them to two separate threads ... that should be doable with a similar model to this. I'd just need two ring buffers. The context switches for each PPU1/PPU2 tick would be brutal. I'd be absolutely forced to use state machines at that point.
One of my biggest fears at the moment is whether or not the BG mode register can be changed in the middle of a scanline. If not, it should be easy to streamline and cache a lot of these variables (eg have the MMIO register write functions update the temp variables inside the renderer as well.) But if so, we'll be doing a ridiculous number of register checks for every single pixel.
Geez ... can you even imagine having to switch from mode0 to mode7 right in the middle of a scanline ...?
All in all, I don't expect to be able to get this cycle renderer anywhere near perfect. I'd just like the mid-scanline effects to at least be seen. It'd be very helpful for the hobbyist coders.
And if we're lucky, we'll figure out how to back-port fixes to games like Megalomania, Adv. of Dr. Franken and Uniracers to the scanline renderers that are otherwise more than adequate.