Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1211  
Old 21st July 2015, 10:51 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by GPDP View Post
Turning it off makes no difference. And it doesn't make sense to me that Vsync would cap it at precisely 120 VI/s. I do see it very briefly go higher than that when just starting the game, but it rapidly stabilizes down to 120.
On most if not all HLE video plugins, it only draws new frames, so in a 30 fps game, you can run 120 VI/s max with vsync. Are you using Mupen64Plus-libretro on Windows?

If you're playing a 60fps game and 120 VI/s is the limit, then I have no clue what's going on.
Reply With Quote
  #1212  
Old 22nd July 2015, 01:15 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 147
Default

Upon further testing, it gets even weirder. With the frame limiter off, a game like OoT that internally runs at 20fps goes all the way up to 180 VI/s. Meanwhile, F-Zero X, which runs at 60fps, doesn't go faster in the slightest, and stays right at 60 VI/s.

OoT is a very good test case overall, because the Select File screen runs at 60fps, and the in-game Start submenu runs at 30, and as such, the title screen runs at 60 VI/s and the subcreen runs at 120.

So yeah, for whatever reason, the lower the in-game framerate, the faster the game goes with the frame limiter turned off. Vsync being on or off makes no difference. Mupen64Plus-libretro, meanwhile, just runs the game as fast as your CPU can handle.

EDIT: I think I understand what you are saying regarding the cap, since as you said, with Vsync on, it only ought to cap at however many VI/s it takes to get the game up to 60fps. The problem is, turning Vsync off does nothing on either Glide64 or GLideN64.

Windows Vsync is not the problem, either, because I run Project64 with desktop compositing off.

Last edited by GPDP; 22nd July 2015 at 01:19 AM.
Reply With Quote
  #1213  
Old 22nd July 2015, 02:49 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

yeah as stated, nothing to do with vsync.

It has to do with the framework windows uses for messages and WGL/GDI, for the context. Every so often most plugins swap buffers--mine is a single-buffered context so never needs to call wglSwapBuffers or risk ghost processes of project64.exe refusing to automatically terminate.
Reply With Quote
  #1214  
Old 22nd July 2015, 04:16 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 147
Default

Hmm, so perhaps that's why Jabo's plugin is the only one that does allow uncapped framerate, yes? Since it runs on DirectX, and all.

Still, how odd that Mupen64plus-libretro also doesn't suffer from this, even though it also uses OpenGL.
Reply With Quote
  #1215  
Old 24th July 2015, 01:04 AM
GPDP GPDP is offline
Senior Member
 
Join Date: May 2013
Posts: 147
Default

Ok, so in the quest to determine if there are performance regressions (and the extent thereof) in between older and newer builds of Mupen64Plus, I've been trying to get this RSP plugin working on Linux. I've managed to build it, but it crashes Mupen64Plus 1.5 64-bit.

Any reason for this? Does it only work on 32-bit as it stands?
Reply With Quote
  #1216  
Old 24th July 2015, 02:11 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

The RCP registers are broken in the 64-bit build of Mupen64Plus, outside of RetroArch. I could tell because it was spewing out completely absurd values for the SP program counter register, which never updated in the way that it should have.

I remember trying to investigate it but the best case scenario is that I would get away with just having to change the 32-bit pointers to 64-bit pointers, even though the RSP registers are only 32-bit. So I would rather not do that...it warrants a fork of Mupen64 or an improved, more portable Mupen64Plus.

Quote:
Originally Posted by GPDP View Post
Still, how odd that Mupen64plus-libretro also doesn't suffer from this, even though it also uses OpenGL.
It's a complicated issue to debug and very difficult/impossible to fix within the plugins' end (since it's Project64's fault) in the emulator-plugin model. Since the RetroArch frontend has that stuff centralized outside the emulation cores the OpenGL support for avoiding that window refresh delay issue (60, 120, 180, 240 VI/s ...) doesn't happen.

Last edited by HatCat; 24th July 2015 at 02:13 AM.
Reply With Quote
  #1217  
Old 24th July 2015, 04:41 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

I remember enabling a setting in the past that made double buffered OGL plugins lock at 60 fps. I looked for the option on my computer and found it again .



I just leave it on application settings.
Reply With Quote
  #1218  
Old 14th October 2015, 09:17 AM
DaMan69 DaMan69 is offline
Member
 
Join Date: Feb 2015
Posts: 77
Post

Here's an --omg-optimized version. Requires VC15 runtime.
Code:
https://www.microsoft.com/en-us/download/details.aspx?id=48145
Below is a mirror for lurkers.
Code:
https://truck.it/p/8_M0_piCZJ
Attached Files
File Type: 7z RSP.7z (115.9 KB, 34 views)
Reply With Quote
  #1219  
Old 14th October 2015, 04:03 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

Haven't installed VC2015 yet. Is it doing better than VC2013 is, do you think?

Everything from VC6 to VC2013 was doing terrible things with the RSP plugin and never seemed to vectorize more than 20% of what other compilers did, so I needed to drop MSVC. Unless you find VC2015 is different, I suggest you attempt these guilds with GCC instead.

Quote:
Originally Posted by DaMan69 View Post
Requires VC15 runtime.
Just set /NOENTRY in the Linker settings, so it requires no C run-time DLL at all.
Reply With Quote
  #1220  
Old 15th October 2015, 08:50 AM
DaMan69 DaMan69 is offline
Member
 
Join Date: Feb 2015
Posts: 77
Post

These are ICC (trial but yay for VMs). VC15 is better but still slow AF. Results using last Mupen bench version & public release 6 (my GCC build crashed) on an i5 Ivy.
  • VC13 15.611s
  • VC15 13.837s
  • HatCat 6.797s
  • ICC16 3.215s
Module.c has some AVX2 & 512 usage so Haswell & the fabled Skylake Xeon should be a bit faster. The AVX 3 operand encoding got put to good use to, but that's mostly new features I can uze them (thanks for crippling Pentiums Intel; no one will ever be able to ship AVX only binaries).
Reply With Quote
Reply

Thread Tools
Display Modes

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. The time now is 08:25 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.