 No.11949
Tafoid Administrator
Aug 10, 2015, 19:07
|
In Windows, there are numerous OPENGL controls which can be controlled via nVidia's Control Panel. Some of them directly influence the manner in which a game screen is presented or synced which might interfere with MAME's base settings. If you want good control, you need to either make a profile for MAME.exe or change your global nVidea settings "Vertical Sync" to off. I suspect doing this will allow your games to work better without all the issues above. |
|---|---|
 No.11950
Augusto Tester
Aug 10, 2015, 21:48
edited on: Aug 10, 2015, 22:03
|
Firstly I thanks God for your work Tafoid. Yes the opengl settings make results, but not is it. Changing any setting (FXAA, aliasing and etc) to on or off is the same issue if using OpenGL: - MAME is front of all anothers programs not being possible to use ALT+TAB. - Long time to exit of an game using ESC. Have time that not is possible exit using ESC with Rygar and I has to use CRT+ATL+DEL and use task manager to close MAME. That just happen with rygar. - Some games (rygar and any system16) has issues in video. Any other game is fine, but has the issues above. Emulation speed and sound are right, but the video has issues. Some frames are dropped even without use frameskip with tearing. For less of one second the screen is ``paused`` and after is rendered the frame ahead. Example Rygar lose an life and has the sound of losing an life and the screen is ``paused`` with him walking and after show him in the ground or other screen. - Also some times has ``flashs`` in tilemap of rygar, ctribe, drragon2 and perhaps others games. Few times sprites ``flicker`` with rygar and much more times with ctribe and ddragon2. The DETAIL is that I see now that just happen if ``multithreading`` is enabled. If is disabled all issues not happen, but the issue with sprites ``flickering`` happen much less times with ctribe and not more with ddragon2. Nothing related with Nvidia settings and not has backgrounds programs using CPU. I see that system16 and tecmo games has some method of render the video that not is same of anothers drivers because using 1080P the game has more time to show OSD menu and few times the video render is more slow to rendering than any another game even if use much cpu. If using D3D few times happen ``flashing`` in tilemaps and few slowdown to enter OSD menu with system16, but just if using multithreading enabled. Have some not syncing in the internal video render with OpenGL that also not is possible to use refreshspeed. Thanks. |
|
No.11952
Tafoid Administrator
Aug 13, 2015, 15:36
|
I'm afraid I'm not too good at diagnosing/troubleshooting video issues I cannot duplicate locally and that seems to be the case here. I try "mame64 shinobi -video opengl -mt" as per your assertion that it causes slowdown and delay when trying to navigate the TAB menu or try to use "ESC" to exit the game. Both work as expected for both rygar and shinobi in my testing. Are you also using a shader? I've heard of people having issue with GLSL filters/shaders with 1080p displays. |
|
No.11954
Augusto Tester
Aug 14, 2015, 04:17
edited on: Aug 14, 2015, 04:19
|
Not using shaders here and not has problems in system. Machine is AMD Athlon 2 X2 270 3.4 GHZ 4GB RAM Geforce GT 640 using driver 353.30 in Windows 8.1 PRO 64 bits in 192X1080P. Machine has enough cpu, gpu and memory to emulate. If multithread is disabled just has issues few times with ctribe and an few slowdown menu in rygar. I see another previous post saying about issues in video with multithread enabled see http://mametesters.org/view.php?id=5898 ``It would seem that our multithreading code has suffered over time, and is causing numerous problems; in my case, I cannot play anything properly with multithreading enabled, MAME will stutter and occasionally ``hardlock.`` temporary lockups happen here and ``It's definitely a real issue. You likely won't notice it with an automated test run as the most obvious symptoms are input lag and frozen video.`` frozen video happen much with rygar and few less with any system16 and never with starblade, tekken3 and others that using very much cpu if using opengl. D3D not has issues. Hmm is good to try record the screen using an cell phone. I will try and after I post the file. |
 No.11955
izius Tester
Aug 14, 2015, 10:09
edited on: Aug 14, 2015, 12:16
|
Augusto, maybe you could try installing older video drivers. I have a Nvidia card too, a GeForce 6200 TurboCache, running on Windows XP and using driver version 260.99. I had to install such an old version because in the past, with newer drivers, I had major slowdown issues when running MAME (not on OpenGL though, it was either on DDraw or D3D). After installing that specific driver version, I never had any problems since then. I've also read on a couple forums about rebooting issues when launching MAME, solved by installing either 258.96 or 260.99 driver versions. Of course, your case is different, but looks like the newer Nvidia drivers aren't very MAME friendly. So, unless it's a specific problem on Windows XP, it might be worth giving a try and downgrading the drivers. In some cases, the older ones work better. Anyway, I'm unable to replicate your issue, too. |
|
No.11956
Augusto Tester
Aug 15, 2015, 00:54
edited on: Aug 15, 2015, 02:49
|
Your GPU is an 6200. Is very old and before of legendary GF8800 of 2005. Using old driver with 6200 fix your issue, but the problem not is video driver. The problem happen with -mt on. See the link below http://mametesters.org/view.php?id=5397 see `` Reproduces here with -mt, not with -nomt. I hardly think that disabling multithreading is the solution to this problem, however. `` `` as previously discussed, -mt is inherently unsafe, and ends up updating the screen with badly synced palette / video data, that's why it was turned off by default.`` Just happen with some games and not with all games. Not is related with cpu emulation. |
 No.11964
NekoEd Senior Tester
Aug 18, 2015, 00:02
edited on: Aug 18, 2015, 00:07
|
This seems to be strongly related to our rotten multithreading code. I've related this to 05898, our catchall bug for -mt issues, and closed this as a duplicate. |