Quote:
The only way to have a constant mid-frame PPU write with a single mapper like CNROM or UNROM is to have a sprite-0 trigger, right ?
Not the only way, but prolly the best/easiest. You can also used timed code or something of the like though.
Quote:
Does it works if the BG is turned off via $2001 ?
You mean does the sprite 0 hit occur with BG rendering off? Of course not. The nontransparent sprite 0 pixel has nothing to "hit."
Quote:
I'll have a multidirectionnal scrooling routine, but it will be able to run on a single system and be portable and very simple, so witout calculating half attributes, etc...
So the good way is to use vertical mirroring so horizontal scrooling is no problem (no gliches). The vertical one will work also witout gliches, but a part of the screen (at the top or at the bottom) is going to have the BG redering off to hide gliches (this part should be at least 4 rows heignt, to hide one whole attribute). This part would be used to have a sprite-only status bar.
So 1-The scrooling is portable and simple; 2-There is no gliches; 3-There is a status bar. The only crap thing is the 8-sprites per line limitation for the status bar.
So then you want a scrolling routine that can be easily used with any mapper (portable)? A sprite-only status bar guess you could do if you wanted, but why?
Quote:
If the status bar is at the bottom of the screen, the PPU will spend 80% of the frame for waiting and 20% only will remain to do calculations, etc...
So have the status bar at the top like most old nes games (Mario Bross, CastleVania, etc...) will be usefull for waiting only 20% of the frame.
Yep, without an Scanline IRQ you have to constantly wait, that is unless you have some interesting timed code.
Quote:
But, this means that the BG is off, and is turned on after the sprite-0 hit. So is that possible ?
If it's not, I've the idea to put 9 sprites at the last status bar's row, and using $2002.5 trigger as explained in the parallel topic. Would it works with most emulators ?
Sprite 0 hit will not occur. Why does rendering need to be turned off during the top portion of the screen and have a sprite-based status bar instead? Since Sprite rendering is turned on I assume the sprite overflow bit will still work so I guess you could use that. I doubt any emulators authors would've ignored to add something as simple as that so it should be well emulaed.