Apparently All Games in Mario 3D All-Stars Are Just Emulated

[PixelPhoenix]

In regards to input latency for Mario 64, it's actually among the lowest the game has seen to date, at least when compared to previous VC releases on the Wii and Wii U. I don't know if anyone has Time Sleuth'd it yet, but it's solid.

[orange808]

... I don't know if anyone has Time Sleuth'd it yet...

How?

[ldeveraux]

... I don't know if anyone has Time Sleuth'd it yet...

How?

The dock has HDMI out, wouldn't that work?

[nmalinoski]

... I don't know if anyone has Time Sleuth'd it yet...

How?

The dock has HDMI out, wouldn't that work?

I think the confusion is due to the proposition appearing nonsensical--I don't think there's any way to loop in a Time Sleuth.

The TS is designed to output an HDMI signal, then read that signal on the target display with a light sensor. There's not really any way to loop that output into the emulator, nor would there be a way for it to calculate the lag if it's the emulator producing the output, not the TS.

The only way that something like that might work is if some form of the TS software was running in the emulator and you had a sensor connected back to the Switch, and usable by the emulator, via USB; in which case that wouldn't involve a Time Sleuth at all.

[ldeveraux]

I think the confusion is due to the proposition appearing nonsensical--I don't think there's any way to loop in a Time Sleuth.

The TS is designed to output an HDMI signal, then read that signal on the target display with a light sensor. There's not really any way to loop that output into the emulator, nor would there be a way for it to calculate the lag if it's the emulator producing the output, not the TS.

The only way that something like that might work is if some form of the TS software was running in the emulator and you had a sensor connected back to the Switch, and usable by the emulator, via USB; in which case that wouldn't involve a Time Sleuth at all.

I admittedly don't know the ts very well, but I thought he was referencing the Switch game, not the game run independently through an emulator. I think I just broke my brain...

[awe444]

The old method of capturing a (USB) gamepad with button-press-activated LED on high speed camera, and the resulting action on the display, would be a more reasonable approach here, no?

[PixelPhoenix]

... I don't know if anyone has Time Sleuth'd it yet...

How?

I don't think you can - I misunderstood. It was my understanding that you could have the input delay overlaid above the game, but the Time Sleuth actually sends the signal directly to the TV via HDMI. At that point it would come down to software, and I'm not sure how you'd be able to incorporate that into the Switch.

Instead, you could use a high speed camera to measure frames and compare. Of course you won't have it down to the fractioned millisecond in exact numbers, but I think it'd fall within one or two frames.

[nmalinoski]

The old method of capturing a (USB) gamepad with button-press-activated LED on high speed camera, and the resulting action on the display, would be a more reasonable approach here, no?

I'm not sure I would describe it as reasonable, but I think that might be the only possible approach right now. It won't be perfect, because it won't be automated; but you could take the combined input lag and display lag from the video analysis, then get subtracting the display lag values from a Time Sleuth on the display alone to get the input lag.

[orange808]

... I don't know if anyone has Time Sleuth'd it yet...

How?

I don't think you can - I misunderstood. It was my understanding that you could have the input delay overlaid above the game, but the Time Sleuth actually sends the signal directly to the TV via HDMI. At that point it would come down to software, and I'm not sure how you'd be able to incorporate that into the Switch.

Instead, you could use a high speed camera to measure frames and compare. Of course you won't have it down to the fractioned millisecond in exact numbers, but I think it'd fall within one or two frames.

With a proper high speed camera, LED modded controller, and careful controls: a highly motivated person could get results that measure in the milliseconds--and remain significant well below a frame.

That person is definitely not me.

[RIP-Felix]

With a proper high speed camera, LED modded controller, and careful controls: a highly motivated person could get results that measure in the milliseconds--and remain significant well below a frame...

The console polls controller inputs, processes the response, and outputs in discrete blocks (Frames). The best you can hope for is an input lag of one frame or less. For NTSC consoles that's 1/60th of a second (16.67ms). 120Hz = 8.3ms, 144Hz = 6.9ms, 240Hz = 4.17ms, and so on. Depending on when your input is made in the current frame and when the console draws the next frame can vary up to a frame. It can be more accurate than that, which is what you're saying, but that's an average over many presses and doesn't guarantee consistent results for any one BTN press. This means that a diligent person has to do many frame by frame counts, then average them to get the number we all want to see. But the real lag could be up to one frame shorter or longer.

[Sumez]

Input lag measurements is such an arbitrary art form.

Like, CRTs by themselves will have lag of basically 0, because whatever color is being sent to them from the source will be rendered immediately. But the standard measurement for "input lag" involves an input that changes a complete frame buffer, and then measures the time before that change is detected on the middle part of the screen. Logically that dictates that a CRT will always measure at least half a frame of "lag" (so around 8.3ms for a 60hz source). But that lag is inherent in the method, not in the display technology, which I guess is worth remembering. That also means if a LCD had 13ms measured lag on a 60hz source (which seems common on many modern consumer TVs), that's still very very good.

Obviously video games suffer the same circumstances as a lag tester. If the hardware allows a write directly to the graphics registers and the software is doing nothing but polling inputs, you can essentially have a 0ms reaction on the screen, but in order to logically process a game state, you'll want to run all the logic for a single frame before the next vertical blank, typically based on input polled one frame earlier, so there are realistically no video games that have less than one full frame of input lag (or nearly two, depending on the input timing) unless they are intentionally designed to process an entire frame in much less time than it takes to draw them (which would be a massive waste of hardware).

[xeos]

The right way to do it is to automate the measurement of lag from button press to screen change and collect the full distribution of lags. as you say it's going to depend where in the scan out the button press happens but also where in the game loop. A single sample or even an average doesn't really tell you what's going on.

OTOH I imagine the average variability is going to be no more than 1 or at most 2 frames of video.

measuring monitor input lag I've found that about 2ms of variability is pretty much standard just because the backlight flicker on almost all display. But some TVs don't sync with the input giving a rolling input lag over time (or power cycles):

https://alantechreview.blogspot.com/202 ... -dont.html

[RIP-Felix]

What I've been waiting for is something like what Nvidia uses in house for lag testing. Linus Tech Tips did a video on it. Basically it's a light sensor you place on the screen, with a mouse to trigger an action onscreen. You set a luminance value to calibrate the trigger and the software calculates the lag from click to luminance change.

I envision a mod like the TS with a trigger wire and breakout adapters (for various controllers). Instead of generating the signal itself, it just waits for a luminance change, once calibrated. Then when mario jumps (for example) it triggers, calculating the time from BTN press to luminescence change. You would get a lag measurement from input to on screen change, which includes everything in your input chain. You'd have to do it may times to get a distribution you can accurately average, but it's be a number more relevant to gamers. Seems like this would be a pretty easy project for someone to cut their teeth on.

Sorry, lag is a sure fire way to derail a thread. Back to your regularly scheduled programming.

[xeos]

What I've been waiting for is something like what Nvidia uses in house for lag testing. Linus Tech Tips did a video on it. Basically it's a light sensor you place on the screen, with a mouse to trigger an action onscreen. You set a luminance value to calibrate the trigger and the software calculates the lag from click to luminance change.

yeah that's a cool idea. Given that my low-cost display lag measurement tool didn't exactly catch the world on fire I'm not sure how much actual take-up there would be on a device like you describe though. it would definitely require some additional work for each new device you were testing since you'd need to set up whatever method you were going to use to introduce input into it.

much easier to just measure the input lag of the display itself (unless it's a switch or laptop or some other tech with no video input).