Patai Gergely 
I implemented animated road stripes that have pixel-correct perspective applied, and are perfectly in sync with the props (but at double the frame rate). These are done via timer-triggered NMIs, not raster interrupts, because I'll be needing those for the less time-critical sprite multiplexing logic to render the cars. Since the NMIs always take precedence, sprites won't interfere with the road animation. #c64 #gamedev
Felix Palmen 📯@cobbpg Sounds pretty awesome, but won't the opposite happen then (visible glitches in the sprites for updating them too late)? 🤔
@zirias It could be a problem with a general multiplexer, but I have a fixed state machine with predictable scheduling and enough margin to be able to work around it. Even in the tightest case I should be able to have a window of 4-5 raster lines before seeing glitches.
@zirias There are two problems in my case. First, raster IRQs are fixed to the start of the scanline, so the timing is sensitive to the presence of sprites, and badlines need to be pre-empted by triggering earlier and wasting time. I set up my timers so they fire in the middle of the line right after the road, so they always have time to do their thing, even on badlines. Second, I have a cartridge mapped in, so I have to use the slow KERNAL codepath. That's too much overhead for IRQs.
@zirias Also, the restore key doesn't seem to be a problem in practice. I could check for it, but I can't even see any visual disturbances when pressing it, because the animation is so fast, and the rest of the logic doesn't depend on timers in any way. They get reprogrammed from scratch during every frame.
@cobbpg as long as you properly check the NMI source (so you can just ignore RESTORE), all it does is waste some cycles. You need a lot of bad luck, but it *can* happen at the most "inconvenient" screen position 😉 (and if you're completely on the edge regarding rastertime, it *could* theoretically completely mess the screen).
No, it's not at all likely. What's always itching me is why hardware was designed hardwiring a keyboard key to the CPU's NMI pin (so, NO way whatsoever to prevent the signal, all you can do is this nasty trick of keeping the line low forever...)
@cobbpg Needing more *precise* timing than the jittering scanline start of course is a reason to need NMI. I just wondered because your original post read like it was "just" a priority thing 😉
I don't understand your second point though, or do you mean a cartridge you don't control (IOW not part of your game project)?
@zirias No, it's my cartridge. Just saying that I need to have it active during the period where the interrupts happen to be able to stream content for the next frame. I'm not aware of any memory configuration that would allow me to do that and not have the KERNAL mapped in at the same time, apart from Ultimax mode, which is not exactly useful for my purposes.
@cobbpg Ah, you mean no bankswitching allowed/possible? Sure, that's though then ... many cartridge games only bank it in while otherwise "inactive" (vblank, or even only level switch ...)
(edit: doesn't RUN/STOP+RESTORE inevitably trigger a warmstart-jump when the kernal is banked in? maybe I don't remember correctly here ...)
@zirias I'm playing with some ideas that could require a lot of sprite data to be refreshed during a frame, and vblank is just not enough for that. I'm hoping to push some boundaries with this experiment.
@cobbpg That goal is already kind of obvious, given the hardware is more or less optimized for tiled 2d graphics plus sprites ... a racing game with 3d display is kind of the worst fit 😎 good luck with that, would be great to see success 😉