Re: Emulator Developers: Lagless VSYNC ON Algorithm
Posted: 20 Mar 2018, 15:41
Thank you, that is very impressive stability, even in this experiment-only version! Scanline-exact stability.
Obviously, you're doing it in higher-precision programming languages, which is much better for that.
QUESTION -- When do you plan to submit your (optionalized, refined, nonbreaking) patch to GroovyMAME or some other venue?
Meanwhile -- I'll also be publishing an open source raster calculator/estimator module (only needs to be fed a VSYNC heartbeat) so anybody can use it as a fallback for when RasterStatus is not available. This will bring cross-platform beam chasing, as long as the platform has a VSYNC OFF tearing compatible API + ability to listen to a VSYNC heartbeat.
The direct use of RasterStatus makes it unnecessary to know the VBI size. That said, I'm trying to make beam chasing cross-platform by avoiding the use of RasterStatus now (use platform-specific APIs only when available, but fallback to software estimated raster position) -- I will be open sourcing my raster estimator module.
So, maybe to prepare for future RasterStatus.ScanLine-free implementations, you might want to wrapper your RasterStatus call so it can fallback to software-based raster estimator formulas on MacOS or Linux. (The only caveat is that it requires the ability to listen to a VSYNC heartbeat, while in VSYNC OFF mode -- in order to guess the ScanLine value). The VSYNC OFF tearline is always raster based as a time-basis from the last VBI, and the exact scanline of the tearing can be estimated as a time-basis between two blanking intervals (minus blanking interval time, which can either be assumed/guessed/configured/detected -- or use the 45/1125 constant as an assumption (usually only a 1% raster-line misguess ratio in the vertical screen dimension) -- even a 5% mis-guess of raster position isn't the end of the world -- less than 0.5ms of lag for not knowing exact raster position -- and still workable for 10-slice beam chasing).
Also -- WinUAE -- the Amiga Emulator (Toni who I had talked to about my ideas before you posted) said he's eagerly going to implement it for the next release, though will take time. In your post a few posts ago, you had said you wanted to be first so by posting your (still experimental, platform-specific) code, you've cemented being the first (unofficial) emulator implementation. I've just fired off a small email to Toni to mention that you had wanted to be first to an actual (official) release, but no guarantees -- I had let him know about my ideas before you posted -- just wanted to give you fair notification
Obviously, you're doing it in higher-precision programming languages, which is much better for that.
QUESTION -- When do you plan to submit your (optionalized, refined, nonbreaking) patch to GroovyMAME or some other venue?
Meanwhile -- I'll also be publishing an open source raster calculator/estimator module (only needs to be fed a VSYNC heartbeat) so anybody can use it as a fallback for when RasterStatus is not available. This will bring cross-platform beam chasing, as long as the platform has a VSYNC OFF tearing compatible API + ability to listen to a VSYNC heartbeat.
The direct use of RasterStatus makes it unnecessary to know the VBI size. That said, I'm trying to make beam chasing cross-platform by avoiding the use of RasterStatus now (use platform-specific APIs only when available, but fallback to software estimated raster position) -- I will be open sourcing my raster estimator module.
So, maybe to prepare for future RasterStatus.ScanLine-free implementations, you might want to wrapper your RasterStatus call so it can fallback to software-based raster estimator formulas on MacOS or Linux. (The only caveat is that it requires the ability to listen to a VSYNC heartbeat, while in VSYNC OFF mode -- in order to guess the ScanLine value). The VSYNC OFF tearline is always raster based as a time-basis from the last VBI, and the exact scanline of the tearing can be estimated as a time-basis between two blanking intervals (minus blanking interval time, which can either be assumed/guessed/configured/detected -- or use the 45/1125 constant as an assumption (usually only a 1% raster-line misguess ratio in the vertical screen dimension) -- even a 5% mis-guess of raster position isn't the end of the world -- less than 0.5ms of lag for not knowing exact raster position -- and still workable for 10-slice beam chasing).
Also -- WinUAE -- the Amiga Emulator (Toni who I had talked to about my ideas before you posted) said he's eagerly going to implement it for the next release, though will take time. In your post a few posts ago, you had said you wanted to be first so by posting your (still experimental, platform-specific) code, you've cemented being the first (unofficial) emulator implementation. I've just fired off a small email to Toni to mention that you had wanted to be first to an actual (official) release, but no guarantees -- I had let him know about my ideas before you posted -- just wanted to give you fair notification