Welcome!
Final Burn Neo => FBN Development => Topic started by: Walk Cancel on October 10, 2010, 10:57:39 AM
-
FBA has issues with drawing frames evenly. This can be measured with a Fraps (http://fraps.com) frametimes benchmark. I found this program (http://www.mediafire.com/?ioxbd5jz7tigbed) (in this post (http://hardforum.com/showthread.php?t=1544139)), which analyzes these benchmarks.
I ran 60-second benchmarks with SFA3 for MAME and FBA under Windows XP. Here are the outputs of the microstutter program:
MAME
Number of frames = 3578
Processing data...
**************************************************************************
Global Average Frametime (ms): 16.769
... ie Average Framerate (fps): 59.634
Average Local Frametime Variation (ms): 0.032
*** Average Microstutter Index (%) ***: 0.190
Apparent Framerate is: 59.521
**************************************************************************
FBA
Number of frames = 3576
Processing data...
**************************************************************************
Global Average Frametime (ms): 16.781
... ie Average Framerate (fps): 59.591
Average Local Frametime Variation (ms): 1.826
*** Average Microstutter Index (%) ***: 10.874
Apparent Framerate is: 53.747
**************************************************************************
MAME is very accurate. FBA is way off.
I tried various things with FBA. Latest version/version from 2002, auto frameskip on/off, enhanced/experimental blitter, windowed/fullscreen. It makes no difference.
If you think you don't have this issue, prove it by posting your results.
I'm aware of the other thread, but I feel a fresh one that gets to the point right away is needed.
-
What blitter were you using in FBA? Settings?
-
Enhanced and experimental blitter (Fraps can't capture DirectDraw). Default settings (clean installation into an empty directory).
I also tried "Blitter options -> Disable all effects".
-
How about turning off auto frameskip?
-
I mentioned auto frameskip (and the blitters) in my original post.
Try the test on your system. I'm sure you'll get the same results.
-
I been working on the frame handling code in the burner interface of FBA and so far 'Windows XP (32-bit / 64-bit)(SP3)' is not problematic in that aspect.
Probably you have done most of this, but just to make sure you have the following information:
For better FBA experience remember these:
- Only use FB Alpha downloaded from the official website ( http://fbalpha.org/fba.php )
- Use the latest DirectX 9 Runtime for Windows XP (official releases only)
- Update your graphic card drivers constantly (visit the official manufacturer website and don't use custom driver releases or windows update generic drivers)
- When using a new FB Alpha with lot of updates involved it is strongly recommended to make a clean install (don't just copy the application executable to your old FBA directory)
- While running FBA avoid programs that may change the way Windows handle painting procedures (like Stardock's WindowBlinds for example)
FBA frame handling options:
- Use Triple Buffer - This option will synchronize the frame presentation to make it accurate (This will only affect FullScreen mode)
- Use Vsync - This option will make the frame presentation accurate and will wait for the last vertical line to be drawn on the back buffer before presenting the screen (Works on Windowed mode only)
Use the following as you prefer in combination with the previous options:
- Auto Frameskip ON - This will Automatically skip 'X' number of frames depending on your system features and specifications, you cannot expect this to show 60 FPS when your system cannot handle them (This may not apply to other applications since they use different codebase to work.
- Auto Frameskip OFF - When OFF FBA will draw every frame. FPS will depend again on your system features and specifications.
There is no reason to turn off Triple Buffer, Vsync and Auto Frameskip unless you are using a low end system, but FBA always have been recognized for its performance on slow machines, so it would be weird that it would not work well with the systems up to date.
Another thing to consider is to try different display resolutions in combination with different refresh rates (59 / 60 hz recommended)
About Windows 7 Frame handling issues
There is a current issue that have been reported many times about the 'Unwanted Frameskipping' on Windows 7 (and probably Windows Vista). I been working recently on a modification of code that will make the frame presentation almost 100% accurate on Windows 7 and even make Windows XP presentation even smother when not using Triple Buffer and Vsync.
The problems with Windows 7 seems to be the system and not the application itself. Aero Themes features and services and probably windows messages and procedures related to the newest GDI implementation on Windows 7 are without doubt making it hard for FBA to keep up.
My current goal is to investigate if there is a way to avoid unnesesary procedures like GDI painting on the screen rectangle while DirectX is handling that rectangle of the screen. Another goal is to check is there is something we could do about the Aero Style procedures as well. Im almost convinced that there may be a conflict between Windows 7 Graphic handling (DirectX 11) and FBA Graphic handling (DirectX 7 / 9).
I have done my test using the program you mentioned and it gave me similar results as MAME, no big difference on my end.
FB Alpha v0.2.97.08 system information (Tue Oct 12 19:08:30 2010).
----------------------------------------------------------------------
System information:
OS: Microsoft Windows XP Personal Service Pack 3 (build 2600)
CPU: GenuineIntel, Pentium III "Katmai"
2933 MHz, MMX, SSE, SSE2 (2 system processors)
Physical RAM: 1046956 KB (1022 MB) total, 392396 KB ( 383 MB) avail
Total RAM: 2519736 KB (2460 MB) total, 1849160 KB (1805 MB) avail
FB Alpha: 9500 KB in use (9500 KB peak, 57724 KB virtual)
Installed displays and display adapters:
Plug and Play Monitor on ATI Radeon HD 4650 (primary)
----------------------------------------------------------------------
FB Alpha information:
Built on Feb 28 2010, 19:33:46, using Visual C++ 9.0.
Optimised for i686 CPUs.
Using Unicode for all text.
Debug functionality absent.
MMX optimisations enabled.
A68K emulation core enabled for MC68000 emulation.
Musashi emulation core enabled for MC68010/MC68EC020 emulation.
I hope you can solve your FBA issues on Windows XP, soon I will be posting a Test Binary with to test a modification of the frame handling routine, so keep checking the forums for updates :smilie:.
SeeYaa!
:biggrin:
-
I knew there was something going on Windows 7, I found this while investigating...
What's Improved about Direct3D 9Ex for Windows 7
Flip Mode Presentation of Direct3D 9Ex is an improved mode of presenting images in Direct3D 9Ex that efficiently hands off rendered images to Windows 7 Desktop Window Manager (DWM) for composition. Beginning in Windows Vista, DWM composes the entire Desktop. When DWM is enabled, windowed mode applications present their contents on the Desktop by using a method called Blt Mode Present to DWM (or Blt Model). With Blt Model, DWM maintains a copy of the Direct3D 9Ex rendered surface for Desktop composition. When the application updates, the new content is copied to the DWM surface through a blt. For applications that contain Direct3D and GDI content, the GDI data is also copied onto the DWM surface.
Available in Windows 7, Flip Mode Present to DWM (or Flip Model) is a new presentation method that essentially enables passing handles of application surfaces between windowed mode applications and DWM. In addition to saving resources, Flip Model supports enhanced present statistics.
...
http://msdn.microsoft.com/en-us/library/ee890072%28VS.85%29.aspx
I will keep investigating this and see if there is a way to avoid Windows 7 Desktop Window Manager (DWM) on FBA. Probably by specifying a flag or something, I will keep my research :smilie:
When I get new results and have the Test Binary ready I will post back ASAP.
SeeYaa!
:biggrin:
-
I know this is technical but just for reference I found out this and will try it out (hope this do something) ^^...
DwmEnableComposition Function
Enables or disables Desktop Window Manager (DWM) composition.
HRESULT WINAPI DwmEnableComposition(
UINT uCompositionAction
);
http://msdn.microsoft.com/en-us/library/aa969510%28VS.85%29.aspx
SeeYaa!
:biggrin:
-
I suggest you NOT to handle manually DWM, that HRESULT will disable Aero if you do so in Windowed mode, some users will get fightened if a "new generation" app disables aero...
The second point will be CPU related, if you disable Aero, ALL the stuff relies en the CPU (Window drawing, animations, etc...) and therefore, you will get performance loss...
In the other hand, if Aero IS NOT disabled when you switch to fullscreen, then this function is for you, but only when fullscreen... Remenber that Windows 7 compensates performance by sending drawing and window routines to the GPU, so it takes care of this, and the CPU is free for everything else.
I guess that our best bet is the CPU affinity, if FBA can handle more tan 1 core when executing (like mame currently does) most of the performance loss will be fixed.
Just a suggestion though... ;D
See ya!!! :D
P.D. My system specs are different, but in my dual core systems, I have no issues using the enhaced blitter... normal draws way fast, but with vsync or triple buffer runs normally... maybe Walk Cancel needs to enable those two...
-
I suggest you NOT to handle manually DWM, that HRESULT will disable Aero if you do so in Windowed mode, some users will get fightened if a "new generation" app disables aero...
The second point will be CPU related, if you disable Aero, ALL the stuff relies en the CPU (Window drawing, animations, etc...) and therefore, you will get performance loss...
In the other hand, if Aero IS NOT disabled when you switch to fullscreen, then this function is for you, but only when fullscreen... Remenber that Windows 7 compensates performance by sending drawing and window routines to the GPU, so it takes care of this, and the CPU is free for everything else.
I guess that our best bet is the CPU affinity, if FBA can handle more tan 1 core when executing (like mame currently does) most of the performance loss will be fixed.
Just a suggestion though... ;D
See ya!!! :D
P.D. My system specs are different, but in my dual core systems, I have no issues using the enhaced blitter... normal draws way fast, but with vsync or triple buffer runs normally... maybe Walk Cancel needs to enable those two...
Yeah, I basically created a LoadLibrary module to access all the DWMAPI stuff, and noticed that the previous function will just temporary disable the DWM and since Aero Themes and its services depend on it, it gets disabled as well.
This is not a FBA issue btw, or CPU issue, I thought it was as well since I have a multi-core processor, but after investigating more and more, I found out that this is a OS problem of managing the frames presented on screen. There are many multimedia projects (video players mostly) that are discussing this on many forums, and they found a solution to the so famous "Stutter" caused by the DWM on Windows 7. I was reading somewhere that bsnes emulator had this problem and the author seems to have fixed it.
I am now investigating the DWM API and I think I will be able to finally fix this for FBA. :smilie:
Tomorrow I will post more details if I get some good results.
SeeYaa!
:biggrin:
-
Here you have two samples of the problem with two applications, a Mediaportal and Bsnes. The following links will take you to the threads were they discuss the DWM problems, and conclusion that is indeed a Windows 7 problem.
MediaPortal thread at their forums:
http://forum.team-mediaportal.com/watch-edit-videos-104/stutter-after-refresh-rate-change-71311/index15.html
Bsnes thread at Byuu's forum:
http://board.byuu.org/viewtopic.php?f=3&t=487&sid=6aa157b75e3658a8058029d4f757a214&start=255
I hope I can find out what they did to solve the stuttering problems on Windows 7 :smilie:
SeeYaa!
:biggrin:
-
Yeah after working on this for so long, I finally nailed it!! :biggrin:
ZERO problems with frame stuttering, it disappeared, I don't even have VSYNC activated xD, AutoFrameskip ON and OFF works 100% smooth!!!. 60FPS
BTW, Fraps does not handle the DWM API so well in its Benchmarks, it will give accurate FPS but not a good Apparent FPS value.
Anyway, the only issues now is that the main window menu is not being drawn well, its black, but everything is responding well, I bet is a CreateWindowEx() flag or something, as soon as I get the menu drawn well I will organize the code and post it, and a test binary so everyone can check it out :smilie:.
SeeYaa!
:biggrin:
-
...Maybe something to do with the vectors... (Vista/7 drayws windows as vectors... at least it was like that on the first betas of Vista...) Pretty weird stuff here... Maybe I'll ask in some Seven forums I visit... that pople may know how 7 hadles this stuff...
Yeah after working on this for so long, I finally nailed it!! :biggrin:
ZERO problems with frame stuttering, it disappeared, I don't even have VSYNC activated xD, AutoFrameskip ON and OFF works 100% smooth!!!. 60FPS
BTW, Fraps does not handle the DWM API so well in its Benchmarks, it will give accurate FPS but not a good Apparent FPS value.
Anyway, the only issues now is that the main window menu is not being drawn well, its black, but everything is responding well, I bet is a CreateWindowEx() flag or something, as soon as I get the menu drawn well I will organize the code and post it, and a test binary so everyone can check it out :smilie:.
SeeYaa!
:biggrin:
I guess that you will handle that according to the version of windows... pretty cool!
Offtopic: Por cierto, puse un par de conceptos en el foro DEV para cambiar la imagen del emulador, hace tiempo IQ queria algo asi segun lei en el foro, pero creo que nadie ha tenido chace de verlos, ahi checalos y me dices que te parecen, incluye un par de cambios al dialogo de seleccion de juego, haber como lo ves y los demas...
See ya!!!! :D
-
There is a current issue that have been reported many times about the 'Unwanted Frameskipping' on Windows 7 (and probably Windows Vista). I been working recently on a modification of code that will make the frame presentation almost 100% accurate on Windows 7 and even make Windows XP presentation even smother when not using Triple Buffer and Vsync.
can't wait for that fix, maybe then can i finally play jojo's without having to boot in XP ^^
-
can't wait for that fix, maybe then can i finally play jojo's without having to boot in XP ^^
Don't worry it is already implemented with the huge load of new stuff for the next upcoming version of FBA :), everything that has to do with the Frame Stuttering has been fixed.
[Offtopic]
There hasn't been many FBA news lately because we all are kinda busy with real life, I do post a few things when I can in my free time, :)
I dont even connect to MSN, but not because I dont want, is because if I start connecting again like I did before Imma get addicted and my time will be messed up xD haha. I remember my old MSN with like 500 contacts O___O, crazy stuff xD LOL.
SeeYaa!
:biggrin:
-
glad to hear a new version is coming.. the win7 fix will rock!
-
Windows 7 x64
MAME .152
Number of frames = 3580
Processing data...
**************************************************************************
Global Average Frametime (ms): 16.764
... ie Average Framerate (fps): 59.650
Average Local Frametime Variation (ms): 0.034
*** Average Microstutter Index (%) ***: 0.201
Apparent Framerate is: 59.530
**************************************************************************
FBA 0.2.97.29, DWM Fix enabled
Number of frames = 3576
Processing data...
**************************************************************************
Global Average Frametime (ms): 16.780
... ie Average Framerate (fps): 59.596
Average Local Frametime Variation (ms): 4.243
*** Average Microstutter Index (%) ***: 25.379
Apparent Framerate is: 47.533
**************************************************************************
Is anybody having more luck than me?
-
It seems that the reported "micro-stutter" issues unfortunately aren't really fixed by the Win7 DWM toggle. I've always wondered if the stuttering is just an inevitable side effect of imperfect emulation taken by FBA when compared to say, MAME.
Another possibly related issue is of input lag - has anyone ever looked into input latency with FBA? I'm just curious because there are builds of MAME (e.g. ShmupMAME, GroovyMAME) that deliver greatly reduced input latency, presumably by re-writing parts of the input handling in the core engine with the goal of minimising latency. Is such an effort possible with FBA at all? How difficult would it be to modify the code to further reduce input lag? I ask because we have been using FBA for fighting game netplay for years and any benefits in this area would be extremely welcome.
-
Try using Xaudio2 instead of DX for sound, that might help a bit. Gab75 tells me he gets a near perfect 60fps (on games that are 60fps) using XAudio2. Most games hover between 58 and 60fps for me, but I have an ancient pc.
So I can look into it deeper, where can I get this tool to measure microstutter? The link for this is long gone, it seems :( http://www.5group.com/wordpress/2012/07/14/gpu-mist-pre-release-1-0-rc1/ Archive.org brings it up, but not the file to dl.
-
There is a way to reduce input latency to essentially nothing. However, that will require each and every driver to be individually modified.
As to the micro-stutter, I suspect Dink is right in that it has to do with the synchronisation of the emulation with the audio stream. The X-Audio module handles that differently. The same thing can actually be done with DirectSound, too, and it will be in FBA. The only potential problem is that some bad sound drivers might not work with it.
-
Try using Xaudio2 instead of DX for sound, that might help a bit. Gab75 tells me he gets a near perfect 60fps (on games that are 60fps) using XAudio2. Most games hover between 58 and 60fps for me, but I have an ancient pc.
Yes, the XAudio2 plugin allows a more stable emulation than the DirectSound plugin... almost always all frames are rendered (100%)... :)
PS: I use a quite old intel I5 laptop (about 5 years old).
-
I just tried out the XAudio2 plugin, and it definitely seems to make a difference! I have no objective way to measure input lag, but it certainly subjectively feels like perhaps a 1 or even 2 frame reduction in input latency. Quite confident that it's not a placebo. I also noticed an improvement in the visual smoothness and reduction in frame "stutter". It's great that FBA has the option of using a faster/more low level sound API as it really does make a difference in gameplay!
There is a way to reduce input latency to essentially nothing. However, that will require each and every driver to be individually modified.
I know next to nothing about emulation - can you elaborate a bit on what modifications to each driver would entail? Just wanting to understand what is theoretically possible (separate from whether it's actually feasible or not).
-
I just tried out the XAudio2 plugin, and it definitely seems to make a difference! I have no objective way to measure input lag, but it certainly subjectively feels like perhaps a 1 or even 2 frame reduction in input latency. Quite confident that it's not a placebo. I also noticed an improvement in the visual smoothness and reduction in frame "stutter". It's great that FBA has the option of using a faster/more low level sound API as it really does make a difference in gameplay!
I know next to nothing about emulation - can you elaborate a bit on what modifications to each driver would entail? Just wanting to understand what is theoretically possible (separate from whether it's actually feasible or not).
Generally the inputs are compiled at the start of each frame. The cpu then reads the compiled inputs. If, in the time the cpu is doing work, the input changes, the cpu won't get that information until the next frame (generally 1/60th of a second).
You an reduce latency by compiling the inputs as they are read by the cpu. However, I'm not entirely sure fba polls the actual hardware inputs more than once a frame, so the whole point may be moot.
-
Generally the inputs are compiled at the start of each frame. The cpu then reads the compiled inputs. If, in the time the cpu is doing work, the input changes, the cpu won't get that information until the next frame (generally 1/60th of a second).
You an reduce latency by compiling the inputs as they are read by the cpu. However, I'm not entirely sure fba polls the actual hardware inputs more than once a frame, so the whole point may be moot.
It might be possible to have the driver re-poll the inputs in cases like this. I wouldn't attempt it myself, but it can be done :)
best regards,
- dink
-
I find it really interesting what was done in the case of ShmupMAME:
From https://shmupmame.wordpress.com/about/:
A few months after making the MAME shmups input delay list. Pulsewidth pointed out that Raine could emulate most of the laggier games in mame with less delay, after investigation and clarification by PsikyoFan it turns out that mame emulates a frame/sprite buffer for most arcade hardware. What I found out is that this buffer can ?safely? be removed on most hardware with very little consequences. So after messing around with the mame drivers for a few days I got a first version ready for release.
Is anything similar applicable to FBA?
A few years ago some input lag tests were done to compare an old build of FBA from 2008 against ShmupMAME (I assume using Windows XP as the OS):
http://forums.shoryuken.com/discussion/comment/8133809/#Comment_8133809
The conclusion from the above tests was that FBA has an additional 2 frame latency compared to ShmupMAME.
So in the case of MAME it was a combination of the core engine having frame/sprite buffers (introducing lag), plus additional per-driver optimisations that resulted in the greatly reduced latency. In the case of Super Street Fighter 2 Turbo (SSF2T), the base input delay of the game itself as measured on arcade is 4 frames. Now I'm really curious as to what optimisations might be possible at the driver level to get the input polling to be truly "next frame". I'm really only concerned with CPS2 emulation, so I took a quick look at cps_run.cpp, especially the Cps2Frame() function, but being unfamiliar with the source I have no idea if this is the right place to be looking at...
One thing that I haven't tried yet is to toggle the "Max frames to render ahead" setting (nVidia) from its default of 3 to 1. Presumably this also helps further reduce input lag and gets us that bit closer to the holy grail of arcade input latency. :biggrin:
-
You an reduce latency by compiling the inputs as they are read by the cpu. However, I'm not entirely sure fba polls the actual hardware inputs more than once a frame, so the whole point may be moot.
I was thinking of something way simpler. Most (if not all) games will poll inputs in the vblank interrupt code. So, instead of starting each frame of the emulation at the 1st scanline of the frame, start at the point where the vblank interrupt is triggered (whereever that is). Then continue until the next vblank interrupt and draw the frame. There you go, input lag is gone.
It's certainly possible in theory to update inputs in real-time, but also pointless -- the emulation happens in, say, 10% of real time...
-
As a bit of an update, the nVidia driver setting "Max frames render ahead" to 1 (default is 3) seems to have made by far the largest difference of anything I've tried so far. Running fullscreen (to bypass DWM), experimental blitter and XAudio2 all helped a bit, but this simple fix really takes the cake in terms of making everything that much more responsive.
It makes sense if what has actually happened is a linear reduction of -2 frames (32ms) of input lag basically for free! I'll start evangelizing the virtues of setting this value (or ATi equivalent) to all FBA users. :biggrin:
-
So I can look into it deeper, where can I get this tool to measure microstutter?
Try Frafs Bench Viewer. (https://encodingtalk.com/threads/frafs-bench-viewer-tool-for-viewing-fraps-benchmark-files.2121/)