Menu
▾
▴
#835 [Feature] Adjustable artificial delay of image
I'd like to have this debug feature, to be able to develop Zapper games using new technique, that allows to play them on modern TVs, which in common have different image lag.
I'd like to see delay option in ms or in tenth of frame, with additional random error span on reset.
Random error span is not going to happen.
Controllable delay, maybe. More than one frame--harder, but possible.
This is not useful to anyone besides you and it's a big mess in parts of the emulator already a mess, so it should be done in a fork.
Good luck finding someone to do it.
You should probably invest in a nes debugging board/cart.
Forgot to mention, that it must be adjustable to delay more than one frame. TV lag could be up to 8 frames. =)
Is it too hard to queue few frames and show it line by line?
Probably I could do a fork, someday.
I think, that Zapper games could be reinvented in some new projects, not mine, and this feature would be useful for every enthusiast on this path.
I'm doing this http://neslcdmod.com if you're curious
I don't understand "show it line by line"
It is not too hard to queue few frames. I said it's harder, but possible.
We would not show anything line by line (that doesn't make sense to me under any circumstances). Rather, we would schedule the swap of the previous frame at a specific scanline, instead of whatever scanline=0 or vsync time it happens at now.
I am skeptical that the sub-frame timing will be useful to you. There are additional considerations from your gpu scan-out to worry about. What does it matter if we swap at scanline 200 if the small window is at the top of your screen? You won't see it until later anyway. What does it mean if we swap at scanline 100 if the window is full screen? You'll see a tear and you can barely react that fast. The multiple frames delay could be helpful though, and if sub-frames are meaningless, then it would be easier to just have individual whole frames delay. That, actually, might be really easy, just a few minutes of work.
It was my wrong assumption out of how mouse-zapper works.
Somehow it gives different in-frame timing depending on Y coordinate. In PAL mode at the bottom of screen it reacts to the white screen almost at the end of frame (0.8), thereby emulating real Zapper behavior, so it could give average Y coordinate from this timing. Although different combination of Zapper and TV could give different delay between top and down edge of the screen.
Maybe I should to wish adjustable mouse-zapper options instead of sub-frame delay.
OK, I really don't know what youre talking about now, but it sounds like nonsense. There's only one zapper. If different zappers are different, they wouldn't be compatible with games and nobody would buy them. If they were compatible with games despite differences, then you wouldn't care about the differences. And none of that sounds like it has anything to do with a possible 8 frames TV delay. I'll just stop paying attention to this until you figure out what you're doing.
There is what to do even with 8 frames.
Just have a look https://www.youtube.com/watch?v=Vbc0-827IIg
In first comment there are timecodes to navigate.
This video is proof of work of LCDMOD on two different LCD TVs.
Good case (LG Smart TV 42", Screen mode: Game, Delay=3):
Worst case (Samsung Smart TV ~28", Screen mode: Dynamic, Delay=8):
For now auto calibration deals with subframe delay, which is a solution for those, who had problems with whole frames delay.
OK i see you deal with whole frames delay by slowing down the detection routine.
The zapper in the oldppu seems to work by a timestamp
See this line in zapper.cpp
ZD[w].zaphit=((uint64)linets+(xs+16)*(PAL?15:16))/48+timestampbase;
If you add to that timestamp there, I think it will achieve what you want with a small delay. you should be able to figure out what the time units are there. probably cpu clocks or something