Suspektan
Commodore
- Registriert
- März 2021
- Beiträge
- 4.147
Die Latenz wird meist nicht durch den Emulator, sondern das OS selbst eingefügt, habe mehrere Messungen mit 240fps Aufnahmen und einem Controller durchgeführt, dessen integrierte led bei Tastendruck aufleuchtet.lowrider20 schrieb:Kein Problem mit Eingabeverzögerungen via Emulator? Wenn ich an so Spiele wie Sonic, aber selbst so manches Mario denke, werden die erst mit annähernd keiner Latenz wirklich spielbar.
In retroarch kann man sich OHNE geladenen Emulatorcore den eingegangen Befehl auch mittels eines virtuell eingeblendeten Controllers auf dem Display anzeigen lassen.
Ergebnis: auch ohne jegliche Emulation vergehen schon mal drei-vier 60fps Frames (also ca. 45ms - 60ms), die spielinterne Latenz addiert sich real dann noch hinzu.
Ob linux (batocera) oder windows 8/10/11 oder android, BT oder interne Tastatur (notebook) war nicht entscheidend.
Man kann mit runahead oder "preemptive Frames" die spielinterne Latenz etwas ausgleichen, den Lag des OS aber nicht.
der Entwickler des zyklengenauen bsnes Emulators bestätigte das:
Latency
The one area where the Super Nt will absolutely beat traditional emulators is in latency: how long it takes between when you press a button on the gamepad until you see and hear the result of said action on the screen.
The reason for this is once again not magic: the Super Nt runs without an operating system in the way. Yet when you run an emulator on your desktop, it has to share resources with a thousand other processes that also want access to your video card, your sound card, your input devices, etc. This time sharing results in added latency. A software emulator can reasonably expect to get within 30-50ms of the latency of a pure hardware approach.
But again, it's not magic: there is nothing preventing an emulator written in C from running on bare metal, without an operating system in the way. It isn't done only because the demand isn't there to produce a robust real-time kernel environment that gives software emulators direct ownership access to all hardware resources. And thus, emulator developers cannot bypass the need to share these resources. Yet.
https://misterfpga.org/viewtopic.php?p=78395&sid=09b6ea4fcef5301a54e675ea331fdcc0#p78395
Das OS ist das Problem, nicht der Emulator selbst.
Aus eigener Erfahrung kann ich sagen, dass ich im sega genesis Titel "Buster's hidden treasure"auf meinem emu handheld (rg35xx h) zuverlässig den gezielten Absprung bei Vollspeed von der Kante verfehle ohne den Lag mit der Runahead Option um min. 1 zu reduzieren. Denke mal, es würde sich mit sonic ähnlich verhalten
Also ja, ein Frame kann den entscheidenden Unterschied ausmachen
Habe mit dem analogue pocket das Verhalten verglichen, da existiert besagtes Problem in dem SPiel nicht
Ergänzung ()
retroid sind nun offiziell Lügner, das Display des retroid pocket mini verfügt nicht über die beworbene AUflösung und SIE WUSSTEN DAS!coral81 schrieb:Hoffe mal für die Käufer das sie von Display Problemen verschont werden. https://www.notebookcheck.com/Displ...-werden-Kaeufer-erhalten-Rabatt.975626.0.html
https://bitbuilt.net/forums/index.php?threads/investigating-the-retroid-pocket-minis-display.6845/
Conclusion:
- The panel used in the Retroid Pocket Mini is NOT a native 1280x960 AMOLED panel.
- It is likely a commodity 3.92" 1080x1240 AMOLED panel, with some of the vertical active area hidden behind the device bezel.
- This also corroborates the ~928p resolution observed by community members
- Kernel sources indicate a 1280 x 960 signal is sent over MIPI DSI to the panel. Presumably, the controller on the panel scales this down to 1240 x 930, which is the root cause of the scaling issues the community has observed.
- The reason Retroid cannot fix this issue is because the panel resolution is not what they advertised.
Zuletzt bearbeitet: