Project64 2.2

[RPGMaster]

Originally Posted by Ambient_Malice

Jabo's LLE is worse than Ziggy's LLE in almost every way. It has poor framebuffer support and widespread geometry tearing issues. (Plus it really sucks at handling Factor 5 games in LLE.)

I know Jabo's LLE is not the best, but I wouldn't go as far as to say it's worse than Ziggy's in almost every way. If Ziggy's was way better than Jabo's, I'd be using it . Generally the graphics are better in Ziggy's but in my experience it's less stable than Jabo's. Many games I play freeze / crash or have really weird bugs. + I have hardware specific issues with Ziggy's plugin unfortunately. I usually use Jabo's LLE when testing performance of the RSP. Ideally in normal gameplay, I use pixel accurate plugin, if the game is not too heavy on the RDP. For instance in Last Legion, I maintain 60 VI/s with the pixel accurate plugin. If I just want to test a game and don't care about gfx as much, I'll use Jabo's when I need LLE since that's usually the fastest LLE gfx plugin on my hardware.

Originally Posted by Ambient_Malice

Glide64 was the first N64 plugin to have effective and cheap framebuffer support, so far as I know. Wanna play RE2? You need Glide64. (GLideN64 will hopefully shake things up. Looks as though it'll handle Vigilante 8's textures in HLE, which hasn't been successful before now.)

I know there are games that work well with Glide64(Quest 64, Star Wars Ep 1 Racer, etc), but I just feel that Glide64 is overrated. I see certain users recommend Glide64, for games they don't even play and ironically it's not the best choice for the game they recommended.

[Ambient_Malice]

In my experience, games that work better with Jabo are rare. (Toy Story 2 comes to mind.) It has extremely limited frame/depth buffer support, which causes no end of problems. (Mind you, Glide64's per-frame support is rather expensive.)

Also, the resolution detection problems. Traditionally, Jabo sucks for PAL games.

All that said, Jabo was a brilliant coder, and his plugin is much better than, say, Rice.

[naimadekar]

I have BSOD when run any game with this PJ64 v2.2.0.3, try other plugins but have same BSOD screen, Only can fix this when use compatibility mode Windows 7, but my OS is "windows 7x64sp1 ultimate."

I have same BSOD problems in two different PCs, same os and cpu, but other gfx cards. one have 760g Amd, and other Amd 4850HD

PJ64 1.7.0.49v work fine!

I leave my main PC dxdiag txt info in attachments, maybe can fix this in next versions. regards

[RPGMaster]

Originally Posted by Ambient_Malice

In my experience, games that work better with Jabo are rare. (Toy Story 2 comes to mind.) It has extremely limited frame/depth buffer support, which causes no end of problems. (Mind you, Glide64's per-frame support is rather expensive.)

Also, the resolution detection problems. Traditionally, Jabo sucks for PAL games.

All that said, Jabo was a brilliant coder, and his plugin is much better than, say, Rice.

I know my opinion is somewhat based off my own experiences, but pretty sure some of these issues with z64gl happen to everyone (like F-Zero). I'm only able to play that game on mupen for some reason ;/ .

I have somewhat better luck with z64gl on Linux. Here's an example of what I have to deal with on windows .



Even in games where Z64gl has better graphics, the performance is usually significantly worse on my end and more likely to crash / freeze. Maybe it's just the particular games I play, idk ;/. If I were to play games like SM64, I'd have a field day with z64gl cause even that game looks better and has better performance on my end with z64gl.

What kind of hardware do you have btw?

The resolution detection problem is annoying I will say. As for Glide64, my main 2 issues are stability and performance. I generally don't use Glide64, if a game hardly looks any different on other plugins.

Originally Posted by naimadekar

I have BSOD when run any game with this PJ64 v2.2.0.3, try other plugins but have same BSOD screen, Only can fix this when use compatibility mode Windows 7, but my OS is "windows 7x64sp1 ultimate."

I have same BSOD problems in two different PCs, same os and cpu, but other gfx cards. one have 760g Amd, and other Amd 4850HD

PJ64 1.7.0.49v work fine!

I leave my main PC dxdiag txt info in attachments, maybe can fix this in next versions. regards

Interesting. Some people will suggest installing updates, but I think this might be a good opportunity to track down bugs in the source code. I will try examining older versions of PJ64. If I or someone else is able to compile working versions of many revisions, I'd like for you to test them so that we can track down this issue.

[magmarock64]

Originally Posted by zilmar

Celebrating 10 year anniversary of 1.6, releasing 2.2.

Download:
http://www.pj64-emu.com/downloads/project64/binaries/

Source, issue tracker at:
https://github.com/project64

lots of bug fixes, make nrage the default controller plugin now, etc

Awesome can't wait to try it out.

[Ambient_Malice]

Originally Posted by RPGMaster

I have somewhat better luck with z64gl on Linux. Here's an example of what I have to deal with on windows .



Even in games where Z64gl has better graphics, the performance is usually significantly worse on my end and more likely to crash / freeze. Maybe it's just the particular games I play, idk ;/. If I were to play games like SM64, I'd have a field day with z64gl cause even that game looks better and has better performance on my end with z64gl.

What kind of hardware do you have btw?

Nvidia hardware. I suspect there's something wrong with Ziggy's LLE on AMD hardware. But it's also worth noting that Ziggy's LLE needs configuring via its .ini file. The wrong settings can cut framerates in half. Ziggy's LLE is not all that accurate. It's primarily useful for playing games with unknown ucodes - in fact, that's why Ziggy made it, AFAIK.

Originally Posted by RPGMaster

As for Glide64, my main 2 issues are stability and performance. I generally don't use Glide64, if a game hardly looks any different on other plugins.

The problems with Jabo are often not all that obvious. But half-working graphics emulation has been N64 emulation's curse for years. Just look at all those people playing Perfect Dark using Jabo despite the fact Jabo doesn't support the game's lighting system. (It possibly supports it in LLE, but then it still doesn't have correct depth buffer\framebuffer emulation needed for coronas, skyboxes, etc.)

Not as bad as PCSX2 culling visual effects left and right with its hardware renderer, mind you.

[chevbe2403]

Hi all. I am a long-time user of Project64 and have been very happy with it. I stuck to version 1.6 for a long time, and with the 1.6.1 patch have had almost no problems at all. I had issues with timing, A/V glitches, crashes, etc. with the early 2.x releases so was a bit reluctant to try 2.2. After a brief bit of testing many of those issues seem to be gone however there are a few things I would appreciate input on...

a) Several plugins are missing out of the box e.g. Jabo's DirectInput plugin, D3D6 Graphics plugin (1.5.2), the No Sound plugin, zilmar's audio, and the (outdated) RSP emulation plugin, possibly more. Is there a reason for excluding these? It's simple enough to copy them from a 1.6 install, so no prob.

b) How come the installer is no longer extractable using 7-zip? Never mind. I reckon it's so users will have to go through the motions and possibly install the "madware" (my terminology for bundled malware/adware). I cautiously avoided it, but can see how one could easily make the mistake of clicking next instead of skip. Anyway, an easy way to make 2.2 portable for later is to install it to Program Files or wherever, then copy all the files except unins000.dat and unins000.exe to a new folder somewhere. Done! Feel free to uninstall after that and start using the portable. I was contemplating zipping it up and attaching it to a post for whoever wants it, but that would probably piss off the admins/devs. Correct me if I'm wrong? My instructions are dead easy in any case.

c) After installing 2.2 I copied all my saved games (not states) from 1.6 to 2.2's save folder. After trying to play [game] the saves were not being read. I opened up the save folder and saw a new save for [game] had been created, called [game]_Cont_1.mpk, so I deleted the _Cont_1 mpk and appended that name to the save I had copied and it worked fine. This happened with both N-rage and Jabo's DInput plugins. What is the purpose of _Cont_1 anyway?

d) There's a lot of cracking in the audio in the games I've tested so far (just the Zelda titles) and with all the different audio plugins. I enabled the Sync game to audio option in Jabo's DSound and it has gone away (so far). I am using the (E) version for playing with a texture pack and am getting a steady 50 VI/second, so no performance hit to speak of. How come this option is disabled on games that experience this issue? Am I correct in assuming it is because it degrades performance in some cases? Is there a patch or something to enable it for the affected games versus doing so manually?

e) Dammit, my train of thought has derailed. I will repost/edit when I remember what else I was gonna say

Phew, sorry about the long-ass post. Thanks for any help.

P.S. Happy Easter, and congratulations Project64 team for 10 years developing such an awesome emulator

[Frank74]

(a) Not sure the reason why.

(b) Extractable with "innounp".

(c) Mempak handling has changed from Jabo's format to NRage. Cont_1 means control pad 1.

(d) Incomplete RDB, what games need the Jabo DSound sync setting? I currently use Azimer's 0.60 WIP2 with Dynamic Audio Sync enabled in the plugin. Sync game to audio off in PJ64. Audio HLE on.

I've edited Azimer 0.60 with Dynamic Audio Sync enabled by default. Here is my edited version. Good for GoldenEye.

https://dl.dropboxusercontent.com/u/...dio0.60DAS.dll

[Frank74]

Originally Posted by Ambient_Malice

Just look at all those people playing Perfect Dark using Jabo despite the fact Jabo doesn't support the game's lighting system. (It possibly supports it in LLE, but then it still doesn't have correct depth buffer\framebuffer emulation needed for coronas, skyboxes, etc.)

In-game, select Use Software Rendering, look at light coronas, and then switch off Use Software Rendering. The light coronas stay in HLE after selecting Software Rendering first. So Jabo's can do the coronas, with some option hacking.

[Oliver2015]

Hi friends!

Pls, is not "VI/s counter" stable. This is the case some games and runs very slow: "VI/s 20" or "VI/s 35" ...
to change much from "VI/s" to "VI/s" (?)

However, Super Mario 64, Super Smash Bros, Rayman 2... are going well, perfect "VI/s 60" (stably).
But I cannot say the same about other games.

I would appreciate some clarification or any help.

Kind regards.