English Amiga Board


Go Back   English Amiga Board > Support > support.FS-UAE

 
 
Thread Tools
Old 26 October 2013, 13:48   #1
apanloco
 
Posts: n/a
Keyboard lag

I have started playing Pinball Dreams on FS-UAE 2.2.3 on Mac OS X. Except from very apparent euphoria from my part, there is pretty often noticeable input lag on the paddles (shift keys). I wonder if anyone else has noticed keyboard input lag on FS-UAE for OS X. Or if anyone knows anything about it.

I have a MacbookPro10,1, Kickstart 1.3.

BR/apan
 
Old 26 October 2013, 16:01   #2
s2325
Zone Friend

s2325's Avatar
 
Join Date: Jun 2006
Location: Gargore
Age: 39
Posts: 17,789
I think older WinUAE versions had same problem which was minimized later. Maybe just wait some time for update.
s2325 is offline  
Old 26 October 2013, 17:00   #3
bcripon
Registered User

 
Join Date: Jul 2012
Location: Chicago, USA
Posts: 68
Quote:
Originally Posted by apanloco View Post
I have started playing Pinball Dreams on FS-UAE 2.2.3 on Mac OS X. Except from very apparent euphoria from my part, there is pretty often noticeable input lag on the paddles (shift keys). I wonder if anyone else has noticed keyboard input lag on FS-UAE for OS X. Or if anyone knows anything about it.

I have a MacbookPro10,1, Kickstart 1.3.

BR/apan
After seeing this, I downloaded Pinball Dreams and tried it on my iMac. I simply used the setup (Amiga 500) in the OAGD database. I would assume that would use Kickstart 1.3. I have not noticed any keyboard lag. I did notice that I am really bad at this game.

However, I am using the development version of FS-UAE (2.3.8dev) and my iMac identifier is iMac 14,1 (late 2013 iMac with integrated graphics). If you are comfortable using the development version, you may want to try that to see if it works better for you.


Bob C

Last edited by bcripon; 26 October 2013 at 17:03. Reason: misspelled word
bcripon is offline  
Old 11 November 2013, 18:50   #4
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 38
Posts: 3,602
Hi, I have written a page about latency in FS-UAE, which includes information about:
  • FS-UAE options which influence latency
  • some things outside the control of FS-UAE which you can check / tune
  • Limitations in FS-UAE and the plans to resolve them

See http://fs-uae.net/latency - hope it's useful
FrodeSolheim is offline  
Old 12 November 2013, 11:36   #5
yesplease
Registered User

yesplease's Avatar
 
Join Date: May 2012
Location: germany
Posts: 147
Quote:
Originally Posted by FrodeSolheim View Post
Hi, I have written a page about latency in FS-UAE, which includes information about:
  • FS-UAE options which influence latency
  • some things outside the control of FS-UAE which you can check / tune
  • Limitations in FS-UAE and the plans to resolve them

See http://fs-uae.net/latency - hope it's useful

nice article frode, i am always interested in such details. When you plan the separation of the input thread and display thread in sdl2.0, will it have then a large impact on the underlying winuae-code in terms of modifications to be made? Does WinUAE have this separation ?
yesplease is offline  
Old 12 November 2013, 12:10   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,573
WinUAE checks for waiting input events every 20 or so emulated scanlines but reading input every frame or multiple times/frame won't make much difference, most programs read joysticks and mouse only once/frame anyway.

Input lag in Pinball games is the usual problem with frame buffering and very fast action games, they are playable only if there is max 1 buffered frame and it can be even worse if triple buffering is (internally) used.

Also it is most likely input lag that makes it difficult to play, even if it appears to be not caused by input lag. Ball can move 100+ pixels in single frame!
Toni Wilen is online now  
Old 12 November 2013, 20:42   #7
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 38
Posts: 3,602
Indeed, whether a having input and rendering in separate threads helps is quite game-specific. If the emulator reads input right before starting the emulation of a new frame for example, and the game checks for input early in the emulation of the frame, there is little to gain. Examples here are Superfrog (reads joystick movement at vpos 5 - vpos 18) and Project-X (vpos 1 - vpos 4).

On the other hand, games such as Lotus 2 (vpos 253 - vpos 266) and Battle Squadron (around vpos 217) reads input later in the frame, and if it takes 5 ms to emulate to this position, then 25% (5.0 ms / 20.0 ms) of input events will be applied one frame later then necessary.

This isn't exactly how FS-UAE works, but separating video and input will improve things (a bit). It is situational how much it will help.

The other (bigger) factor is the delay before emulating a frame and it is displayed on screen. With v-sync, the frame is emulated as early as possible to increase the chance that it can be displayed "on time" for vblank, but ideally (lag-wise) one would rather like to emulate it as late as possible. But optimistically delaying it can cause the opportunity to display the frame to be lost. This is where G-Sync can really make a difference ...

To answer to question of when I plan to separate the input and display threads... -Originally I thought I would do this after 2.4.0. But now there are cropping up some issues on OS X 10.9 which seems to be solved with SDL 2.0, so I may end up doing it sooner...

Last edited by FrodeSolheim; 14 November 2013 at 20:26.
FrodeSolheim is offline  
Old 14 November 2013, 10:35   #8
yesplease
Registered User

yesplease's Avatar
 
Join Date: May 2012
Location: germany
Posts: 147
Quote:
Originally Posted by FrodeSolheim View Post
To answer to question of when I plan to separate the input and display threads...
I didn't ask for when you plan to do it. My question was, "WHEN" you do it, will it THEN involve a great amount of changes to the winue kernel on which fsuae is based? "When" in the meaning of "if". Ups my poor english, easy to misunderstand me right ?


Quote:
Originally Posted by Toni Wilen View Post
WinUAE checks for waiting input events every 20 or so emulated scanlines but reading input every frame or multiple times/frame won't make much difference, most programs read joysticks and mouse only once/frame anyway.
I see, the reason for game developer to doublebuffer is that they need more than the time for bitmap manipulation than the time in which the vblank is in offscreen.

Can one say then that those games who do (or must do) doublebuffering for clean animation will have at least 20ms lag which of course corresponds to 50Hz PAL ?

I think from a pure emulation perspective, frodes plan to separate the threads for input and output brings the emulation closer to an real original amiga. A real amiga machine also does not serialize the input and output. Even if it does not much diffenrence in a lot of cases. Maybe if the emulation is in parallel threads, we will get in some cases only a 20ms lag where it otherwise would result in a 2x20ms = 40ms lag.

Last edited by prowler; 14 November 2013 at 23:20. Reason: Back-to-back posts merged.
yesplease is offline  
Old 14 November 2013, 21:29   #9
FrodeSolheim
FS-UAE Developer

FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 38
Posts: 3,602
Quote:
Originally Posted by yesplease View Post
I didn't ask for when you plan to do it. My question was, "WHEN" you do it, will it THEN involve a great amount of changes to the winue kernel on which fsuae is based? "When" in the meaning of "if". Ups my poor english, easy to misunderstand me right ?
Hehe, the work "do" was missing and my brain auto-inserted in your sentence, but in the wrong location ;-) -The upside is that you'll now have two answers with one question! Second try then...

No, the change I mentioned does not require any changes to the UAE core at all. But FS-UAE and WinUAE also does things slightly differently. If I recall correctly, The WinUAE emulation thread actually polls the OS (Windows) for input events every 20 scanlines or so (by handling the Windows message queue). The emulation thread in FS-UAE checks instead an internal lists of queued events - but this itself does not cause FS-UAE to check with the OS for new events. In FS-UAE/SDL, the emulation thread is not allowed to mess with the event system.

The internal event list in FS-UAE is updated with new events once every frame right now, and this is what will be changed to basically populate this list at all times, an event will be queued as soon as it is available.

While at it, the UAE core will also be changed to check for new events every scanline instead of every 20-30. This will not matter much for the average case, but a few input events may be applied to the game logic a frame earlier, and checking the internal event queue is cheap anyway, so why not...

I'd say your 20ms and 2*20ms example is more or less correct. The real Amiga will have some input lag in games too, so the goal isn't as much to remove input lag, than to ensure that it isn't worse than the real thing
FrodeSolheim is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Mouse Lag markpage support.WinUAE 7 31 May 2011 14:10
LAG is Booked. rockape News 0 25 June 2010 13:35
Vsync = Lag vrm support.WinUAE 23 17 May 2010 02:27
Joystick input lag Torkio support.WinUAE 3 06 March 2007 01:56
WinUAE keyboard lag ervin support.WinUAE 3 08 June 2004 18:59

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 17:07.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.07264 seconds with 13 queries