[mdrejhon]

Originally Posted by ReadOnlyCat

you may not have noticed but you have a tendency to repeat yourself several times in your posts which makes them very difficult to read. I really recommend that you take your time eliminating redundant information and jargon and simplifying.

I'm actually aware, but I am unnecessarily long sometimes. Noted.
Sometimes my long writing style works better in other contexts (e.g. my 480Hz tests and the animated 1000Hz Journey articles) but in these forum contexts I need to remember to adjust, especially since forum posts are not proofread/diagrammed/animated like my articles. It's my style, but I'll work to reply shorter to your quotes now.

Originally Posted by ReadOnlyCat

Since the display refresh rate is 4x that of the emulated machine's and the emulator can also emulate 4x faster, we emulate the current frame in 1/240s, and we immediately present the resulting frame buffer to the 240Hz display, then we keep that frame constant for 3/240s. Essentially what this does is compress the Amiga frame execution time to 1/4th of its duration and then idle until the next frame needs to be executed. All while keeping the rate of visual frames output at a steady non jittering 60Hz.

Yes, yes. You are correct here.

Originally Posted by ReadOnlyCat

That is not correct.

I spent 20 minutes carefully analyzing your words, redoing math formulas on paper, and:
- We might be thinking or lag stopwatching differently. Different lag stopwatch start/stop.
- For my lag stopwatch, there's no such thing as "1/4" except in a 4-frameslice situation.
- For my lag stopwatch, it is not a function of Emulator:Realworld scanout velocity difference.

As long as input-read is done anywhere later in refresh cycle, and emulator scanout velocity is faster, there's a lag reduction versus original machine under the specific lag stopwatch criteria:

Originally Posted by ReadOnlyCat

In order to claim that this benefits you must assume that most inputs occur in the top 1/4th of the screen of an Amiga frame which is frankly dubious given that inputs are equally likely to occur at any moment during a frame.

Under my lag stopwatch criteria for this case, there's no such thing as "1/4", nor "first 1/4", nor "after first 1/4". And biggest difference occurs near bottom edge of screen. It is proportional to scan line number, regardless of scanout velocity. So the bigger emu-ahead-of-real difference occurs the closer the input read is done to bottom edge.

Setting specific math variables to avoid confusion:
-- Stopwatch start for this one, is beginning of visual refresh cycle (moment scanline #1 begins)
-- Stopwatch stop for this one, is input read & visual action
-- Original 8-bit machines can react during (or below) the scanline the input read occured. e.g. doing input read in scanline right above pinball flipper sprites.
-- Real time input reads mid-scanout, with real raster racing tightly behind emulator raster
-- For math simplicity, temporarily ignore display lag (instant GtG) and frameslice granularity (e.g. theoretical 1-scanline-tall frameslices or frontbuffer beam racing)

For realtime input read in exact middle of a emulator refresh cycle (1/2 of 1/60sec):
-- Original on 60Hz has already displayed half of the refresh cycle to human eyes in 1/120sec (halftime of 60Hz scan)
-- Emulator on 240Hz has already displayed half of the refresh cycle to human eyes in 1/480sec (halftime of 240Hz scan)
-- Assuming (A) beam racing, and (B) real time input reads during beam racing
-- Your lag savings is the mathematic difference between 1/480sec and 1/120sec. That means 3/480sec less lag than original machine under this lag stopwatching criteria.

Our confusion may be simply merely different lag stopwatching criteria (start/end) and there are many ways (audio stimuli, visual stimuli, lag differential of concurrently executing machines, etc). If you do theoretical high speed video of two concurrent machines running at exactly same software at exactly the same time (1 real device, 1 emulator) at the same refresh-begin intervals -- then the input read occurs much sooner on the emulated machine for bottom-edge scanout. If you were thinking about a different lag stopwatching criteria, then you might be very well correct, then our confusion is resolved. Indeed, due to the way emulator audio is necessarily buffered during fast-scanout, lag-stopwatching via audio is necessarily different from visual stimuli. I am a deafie, so I'm a visual-stimuli guy myself... And even isolating to visuals -- there's even more than one legitimate way to lag-stopwatch visual stimuli. Such as scanline of screen reaction, rather than scanline #1. Screen reaction (e.g. player action) can occur in a vertically different part of screen than the trigger (e.g. danger/obstacle you react). So they can benefit or handicap depending on whether they're above or below each other. So some lag stopwatching criteria only show lag advantages in certain games, while other lag stopwatching criteria show lag advantages in yet different games or apps (e.g. drawing programs -- drawing lag). There are specific cases where a faster scanout may handicap, e.g. giving you less time to react. But that's not universal; depending on layout of onscreen activity and input reads. Unfortunately, not a single lag-stopwatching measurement method fits all.

Have I explained better? Or have I made an error? (unlikely)... I should have posted a diagram instead of writing so many words, eh? Some old Blur Busters scan diagrams include 144fps at 144Hz GSYNC versus 100fps at 144Hz GSYNC demonstrating the behaviour of two different frame rates on the same 144 Hz GSYNC monitor. Upon request, I can create new diagrams demonstrating the lag-savings if preferred. People like my diagrams and TestUFO animations that I make, more than my words sometimes!

Originally Posted by ReadOnlyCat

If that system works, it is by definition not realistic in any way since the original machine did not behave like that.

Indeed unnatural, but regardless, lower lag than any other possible emulator lag-reducing method (input delay, hard GPU sync, VRR-only benefit, etc). Many tricks are combineable -- beam racing VRR refresh cycles apparently works!

Originally Posted by ReadOnlyCat

(*) in the analog domain, there is some evidence that they can at least detect (as opposed to respond to) very fine lag (millisecond) but this is likely an indirect detection made possible by the easier predictability of the response to analog movements.

<offtopic but interesting>
Quite possible indeed! Another factor: Even when a human cannot feel the millisecond, there's also the "cross-the-finish-line" effect. The "see each other, react at same time, frag each other at same time". With near-identical human reaction times, the input lag of equipment can be the deciding factor of a specific reaction-time win. The "It seems like my reaction time seems better with this lower-lag setup" is a powerful effect even if one can't always feel the millisecond or few directly. When competing in professional leagues, the reaction time spread is tighter, so tiny lag differences matter more. This affects statisticals wins in their favour.
</offtopic but interesting>