What would you like to see in Project64 2.2?

[the_randomizer]

Originally Posted by RPGMaster

We must play totally different games ! I'll be honest that I've only done a decent amount of audio testing in a few games. Shunyuan's generally was worse on PJ64 2.1 than Azimer's, for me. What games do you normally play?

I'm curious to know which games you've played where Jabo's output looked better than Glide64. Keep in mind, I usually use Jabo's, since it's a good balance of speed and accuracy (compared to other HLE). I don't use Glide64 often, but for the games I've tried, it was usually equal if not better than Jabo, for accuracy / video quality.

Hope so too .
I'm not too sure how audio timing works, but even Azimer's will run those games at a bad framerate when you enable force old audio sync. If you try Jabo's audio on Mupen64 0.5, you'll hear good quality audio without having to enable audio sync. In fact, i think audio sync doesn't work on Mupen64 0.5 (at least for some audio plugins), probably due to the way the emulator handles audio. I imagine the audio sync would be 60 VI/s if the emulator had better audio timing.

If I have to resort to ABX testing on Shunyuan's versus Azimer's (not using the old sync method), to prove et wrong, then I just might have to. Shunyuan's plugin isn't all it's cracked up to be. Not sure where he gets those silly opinions from lol.
Now, with old sync, why would someone use that? I get perfect VI/s when I use Azimer's audio with XAudio2 and default sync, not that old sync crap; I use the same games with Jabo's and they drop to 45 VI/s. I'd be more than happy to show a video of the VI/s count perfect with Azimers. Why enable "force old audio sync"?

[RPGMaster]

Originally Posted by HatCat

not just you man, like every time et posts here I have no idea where he gets these opinions from.

Sincerely causes me to wonder whether he's like trying to be wrong on purpose on things sometimes. Or maybe Azimer audio sounded worse because he started deprecating DirectSound and streaming the AI register handling through XAudio differently if you're not at a full 60 VI/s, which does have some different type of crackling yeah.

Rofl, well that clears things up . Ya honestly, one of the only good things about Shunyuan's plugin is how it handles audio when you're not running full speed.

Originally Posted by the_randomizer

If I have to resort to ABX testing on Shunyuan's versus Azimer's (not using the old sync method), to prove et wrong, then I just might have to. Shunyuan's plugin isn't all it's cracked up to be. Not sure where he gets those silly opinions from lol.
Now, with old sync, why would someone use that? I get perfect VI/s when I use Azimer's audio with XAudio2 and default sync, not that old sync crap; I use the same games with Jabo's and they drop to 45 VI/s. I'd be more than happy to show a video of the VI/s count perfect with Azimers. Why enable "force old audio sync"?

Dude.. The point was that audio sync has timing issues, regardless of audio plugin. The "default" sync you're refering to, does not sync audio as well as old sync or Jabo's. Aside from better audio quality, force old audio sync lets me use AQZ netplay on emulators like 1964 . Although it's still not as stable as simply using Mupen64 0.5 or Pj64 2.1 (with fixed audio timing enabled).

Again, for some odd reason, Jabo's audio seems to be worse in PJ64, compared to 1964. In 1964, Jabo's audio generally seems to sound better than Azimers. For games with audio timing problems, like the ones you mentioned, Azimer's is definitely better, even in 1964.

[Xcodeplus]

Simple requests:
Change text in title bar to Project64 2̶.̶1̶ 2.2.
Fix MANIFEST so visual styles work.

Long-shots:
Kaillera support.
TAS and input recording support.

[et500]

I am just reporting the result of extensive testing for me on my PC, on another PC you might get different results. But my results are that Shunyuan runs and sounds best on 1.7.0.50 LLE Audio setting (any game, for example Super Mario 64 and Wave Race) and Azimer (old 0.56WIP2 version, did not test the newer builds) 2nd best (sometimes stuttering). My RDB: Project64 v1.7 UnOfficial RDB by >>> Henryxs87 <<< / Based On Project64 Official RDB v1.6.0.16 & UnOfficial RDB by Nekokabu & MASA

Another result is that glide64 always looks blurry in 1080p as if there is some kind of fullscreen smoothing applied (none is set), which is only visible if you directly compare the sharpness and image quality to Jabo video.

But we should go back to the topic which is Project64 2.2.

[Ambient_Malice]

The fixed audio timing business needs to be worked out because presently lots of games need fixed audio timing but it causes bad juddering.

Games that use Factor 5's voice codec need FAT, for example.

[RPGMaster]

I'd like to see Killer Instinct fixed . Problem is, I'm totally inexperienced with debugging the r4300i ;/ . There's no Cheat_r4300iOpcode . I'll still give it another shot.

Originally Posted by HatCat

Sincerely causes me to wonder whether he's like trying to be wrong on purpose on things sometimes.

Yup, I'm convinced .

[TheLegend]

TAS/input record needs to happen ASAP. I won't mind if it will eventually get you desynced every time at first.

[Ambient_Malice]

Assuming GLideN64 lives up to the hype, do you suppose it might become the "official" video plugin for PJ64? Or at least replace the Glide64 for PJ64 plugin?

[retroben]

Just grabbed the most recent EmuCR build of PJ64 and it has that damn Banjo-Tooie audio issue!

I just can't win because it is either working debugger on 1.7.0.50 ver23/b23 with proper sound but slow,or working debugger on 2.x(2.2) with re-broken sound but faster.

I really want to see the Banjo-Tooie audio timing fixed again when using unlimited fps to fast forward it or if it ever gets slow and audio gets unsynced.
The "fixed audio timing" and "sync game to audio" options do nothing now.

It originally happens in 1.6 but got fixed in 1.7 versions like 0.50 ver23/b23,only to get re-broken with the 2.x update.

[HatCat]

Please either:
a) Install Git and Microsoft Visual Studio and simply build yourself through each commit to isolate it.
b) Post enough information for other people like me to tell how to reproduce this Banjo-Tooie audio issue. Saved state etc. could help a lot, or you can just post on GitHub and file a issue report.