Go Back   Project64 Forums > General Discussion > Open Discussion

Thread Tools Display Modes
Old 27th July 2017, 12:42 AM
Wally123's Avatar
Wally123 Wally123 is offline
Senior Member
Join Date: Jul 2013
Location: Freedonia
Posts: 159

Originally Posted by Frank74 View Post
GLideN64 Public Release 2.0 is a lot slower than the later WIP versions with the VI refactor. Also Body Harvest is fixed in later WIP. Threaded version gave me another massive speedup, with Perfect Dark going from 40-60VI/s, to 160+ VI/s with frame limiter off. But Goldeneye is still slow.

If I set Goldeneye's counter factor to 1 with GLideN64 it becomes even slower. Not so with Jabo.
Latest PJ64 git builds have overclock option, I set it to 2 and leave counter factor at 2, for same effect. But it still struggles with GLideN64. Some games need CF=2 for correct timing.

One good example is Monaco Grand Prix, I use PJGlide64 (Project64-Video). I changed the counter factor to 1 in the rdb some time ago. Because the analog controls with CF=2 were like switched input, uncontrollable. But CF=1 makes the menu screens like a 1fps slideshow switching screens when in fullscreen. Setting it to CF=2 and overclock=2 fixes the slow menus and the controls, plus increases the frame rate.

Sync using audio has no effect with fixed audio timing off. I already turn off FAT for most games, as I use my own build of Azimer's new audio code.
I'll be sure to check it out....I am running it on a Core i7 6700k with a NVIDIA GTX970...takes quite a bit to slow me down. I will try the WIP builds of GlideN64. Keep in mind too that I used 4GB Patcher on PJ64's exe file...


@Frank74: Goldeneye seems to run fine as it did before under the same settings. Sync to Audio is not the same as Fixed Audio Timing (the latter changes pitch depending on the V/I Rate)....all so far with no change in plugins...I think it's NTCore's 4GB EXE patcher that is helping quite a bit because I was having the same results with Goldeneye as you were before I patched the exe with the RDB settings I used for Goldeneye. Since Windows Vista, all 32Bit apps requiring MVCS2008 or newer (or compiled since Windows Vista was released) will only use up to 2GB of RAM in spite of testing tools detecting 4GB. Try using that, then using GlideN64's public release 2.0 on all default seetings using Shunyuan's HLE Audio with the default packaged RSP plugin with the settings above...should work well.

"I find television very educating. Every time somebody turns on the set, I go into the other room and read a book."

~Groucho Marx

Last edited by Wally123; 27th July 2017 at 06:27 AM.
Reply With Quote
Old 28th July 2017, 01:55 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
Join Date: Dec 2013
Posts: 2,008

Originally Posted by Atsix View Post
For which games exactly do think Glide64 is more accurate? Most of the games I have are the popular ones, like Super Mario 64 and the Zelda games. I think that the most problematic game I have is Body Harvest, because the collision detection is broken with other HLE plugins, but even that has been fixed by GlideN64.
Off the top of my head, Killer Instinct, SD Hiryuu, and some other Japanese games. These days I use Rice Video when I need performance, Angrylion's for accuracy, and Glide64 if I want something in between. In rare cases I'll use GLideN64. Most of the time, I don't really see a difference in accuracy, so no point in using the slower plugin . Granted, this may just be due to the specific games I choose to play.

Originally Posted by Frank74 View Post
But Goldeneye is still slow.

If I set Goldeneye's counter factor to 1 with GLideN64 it becomes even slower.
That game doesn't run full speed for you? What part is slow?
Reply With Quote
Old 28th July 2017, 06:43 PM
Frank74's Avatar
Frank74 Frank74 is offline
Alpha Tester
Project Supporter
Senior Member
Join Date: Aug 2013
Location: UK
Posts: 828

Originally Posted by Wally123 View Post
Sync to Audio is not the same as Fixed Audio Timing
I know this...

According to what I've seen in the source code. Sync using audio option has no effect unless fixed audio timing is enabled.

Unless you mean using Sync game to Audio option in Jabo's, Prevent buffer overruns in Azimer? They'll both sync to 60ish with PJ64's frame limiter off, using audio sync.

Project64's sync using audio option only works with FAT enabled in 2.3.

I can now confirm this as a fact. Sync using audio has no effect unless Fixed audio timing is enabled.
I put debug message in the sync using audio function, and it never writes to the log unless FAT is enabled.
In a perfect world, the sync using audio option should be greyed out, until the FAT option is enabled.

There's other options that should cause other options to be greyed out. The physical vs virtual lookup should grey out the self mod methods that aren't available in virtual.

Last edited by Frank74; 30th July 2017 at 01:28 AM.
Reply With Quote

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 03:26 PM.

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