Thanks for the infos MarathonMan.
MarathonMan wrote:Nope; the console just calls os_render_frame, which just copies the frame to-be-rendered to a buffer and signals the events/rendering thread. I was thinking about deferring the VI filtering to the second rendering thread as well, but I'm not even sure how something seemingly promising like that would work if the VI registers are updated halfway through a frame.
After some checks I realize the last CPU step is to transfer FB from memory to the VI. The VI then transfer this "digital datas" to the Video DAC that convert the given digital datas to analog signal for TV. This mean VI is still a fully digital process (I was thinking it was an analog process). So you get a point: VI registers could be updated during the VI process. But a pragmatic question here:
- If so what would be the impact on the final image? I don't know the VI rendering pattern but you would have a weird image with half of it generated with some VI options and others generated with other VI options.I guess modify VI registers during VI process is more a side effect than a true motivated rendering feature. I guess in real games, VI registers are not modified in game but at some special step (entering menus, entering loading, game start, etc...). I just suppose, I have never debug VI use on real N64 myself.
- Is there a way to get the VI output back for CPU/RDP modifications. I guess no. If we have the guaranty this output datas will never been reuse in any way (except horrible Video DAC we don't want) I wonder if there is any impact on the "cycle accurate" stuff. I really wonder what would be the point to emulate the "change the VI registers during renderer".
- Does the VI send any digital event once it terminate it transfers to the Video DAC? What are the purpose of such event? Are they uploaded to the CPU loop? (does the games known about "VI to DAC is over"? I guess no one (neither os or game) is aware of the relation between VI and DAC (but this have to be confirmed).
TL;DR: What would be the side effect of changing the VI registers during VI processing on real hardware? If it's just screen blink during two changing game states without any internal modifications (except the registers themself of course) we could consider to do not emulate the "change VI registers during VI processing" (so our "VI processing" would not have such "atomic" behavior) and have a monolithic VI filter emulation in another thread.
TBH, the only reason I could accurately get around using another thread to render frames is because CEN64 doesn't have to worry about scanlines. If I had to emulate scanlines, using a separate rendering thread might have negatively affected performance due to all the locking to maintain synchronization.
Why would CEN64 have to emulate scanline? You mean "emulate Video DAC" (which is part of N64 hardware)? lol if there is no reason to keep this part leave it out, we really don't want it.
