PDA

View Full Version : Project64 2.2


zilmar
1st April 2015, 10:18 AM
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

Mush Man
1st April 2015, 03:01 PM
Congratulations on the release and thanks to everyone who contributed.

Could you please also provide a portable archive version?

=X= Smasherx74 =X=
1st April 2015, 04:03 PM
http://i.imgur.com/gLUKNkH.png
http://i.imgur.com/CgP2zSO.png

Could you at least change the button text from next to okay? I mean come on, there isn't even a picture of the advertisement I can see why people get so pissy over this.

theboy181
1st April 2015, 04:11 PM
Great job everyone. Is there a quick description of all the wonderful changes somewhere?

HatCat
1st April 2015, 04:24 PM
You're an alpha tester, so I think you've seen the change logs in zilmar's RC threads.

zilmar
1st April 2015, 05:34 PM
Could you at least change the button text from next to okay? I mean come on, there isn't even a picture of the advertisement I can see why people get so pissy over this.

I have no control on how the ad looks likes, I just make a 3rd party call and it creates the page.
CreateBINNOPage(wpSelectTasks,'pj64emu','pj64emu') ;

you can run the installer with /noads and it will not load anything from the 3rd party ad provider.

=X= Smasherx74 =X=
1st April 2015, 05:48 PM
I have no control on how the ad looks likes, I just make a 3rd party call and it creates the page.
CreateBINNOPage(wpSelectTasks,'pj64emu','pj64emu') ;

you can run the installer with /noads and it will not load anything from the 3rd party ad provider.

How about just not having an installer to begin with? Why should I have to 'run the installer with /noads'? My concern isn't about me it's about whoever clicks through your (completely) unnecessary installer. Why not just not have the ads there to begin with :)

theboy181
1st April 2015, 06:39 PM
You're an alpha tester, so I think you've seen the change logs in zilmar's RC threads.

Been on vacation and won't get to take a full look until I return. I guess I will have to wait and see. ;)

RPGMaster
1st April 2015, 07:32 PM
How about just not having an installer to begin with? Why should I have to 'run the installer with /noads'? My concern isn't about me it's about whoever clicks through your (completely) unnecessary installer. Why not just not have the ads there to begin withWhy not just compile it to begin with :D ;) :rolleyes: :p . Obviously ads generate cash, so that's why it's there.

Been on vacation and won't get to take a full look until I return. I guess I will have to wait and see. Are you for real? Just check the threads like HatCat suggested...

Ambient_Malice
1st April 2015, 09:47 PM
Thoughts:

1: I regret not making that pull request to enable Jabo audio sync for a bunch of games to fix their crackling. Because there is a shitload of crackling. I was hesitant because it might in theory introduce input lag.

2: This adware business... If only it was just ads. This tends to be browser hijackers and stuff. The bread and butter of anti-Malware developers.

3: Happy 10th Anniversary, Zilmar.

4: Jabo, we love you. May the Father of Understanding guide you.

5: (In the absence of GLideN64) PJ64 REALLY should have Glide64 as the default video plugin and not Jabo. I'm pretty sure it defaults to Jabo. Not a good idea. (I hope I'm wrong.)

RPGMaster
1st April 2015, 10:25 PM
1: I regret not making that pull request to enable Jabo audio sync for a bunch of games to fix their crackling. Because there is a shitload of crackling. I was hesitant because it might in theory introduce input lag.I would only do that for games that run 60+ VI/s with audio sync on. For instance, Quest64 does not run 60 VI/s with audio sync on (Jabo's Audio), so I wouldn't recommend enabling it for that game. Honestly, I'd rather just take advantage of per game plugin settings.

Ambient_Malice
1st April 2015, 10:29 PM
I would only do that for games that run 60+ VI/s with audio sync on. For instance, Quest64 does not run 60 VI/s with audio sync on (Jabo's Audio), so I wouldn't recommend enabling it for that game. Honestly, I'd rather just take advantage of per game plugin settings.

I was going to add it on a per-game basis for pre-tested games. I already did it for Donkey Kong 64, since PJ64's audio sync has slight popping that Jabo's cures. I'm aware of the problems it causes for specific titles.

RPGMaster
1st April 2015, 10:52 PM
I was going to add it on a per-game basis for pre-tested games. I already did it for Donkey Kong 64, since PJ64's audio sync has slight popping that Jabo's cures. I'm aware of the problems it causes for specific titles.Ok, you have the right idea then. I knew Jabo's audio sync worked good for DK64. It also does a good job in Super Smash Bros and Last Legion. Generally if a game runs 60+ VI/s with Jabo's Audio Sync, then it's better to have it enabled. You can get a good idea of how much it affects the VI/s by enabling "Show CPU Usage". If the usage of r4300i isn't much higher with it enabled, that's a good sign.

If the usage is significantly higher but still is able to run 60 VI/s, it's still usually better to use a different plugin if there's a better one. For instance, I can't run Mario Party 1 at stable 60 VI/s with Jabo's Audio Sync, yet theboy181 could iirc, yet Azimer's 0.56 WIP2 does a better job.

the_randomizer
2nd April 2015, 07:35 PM
What I wish Jabo's plugin did was emulate alpha dithering (or dissolving pixel effect, or so I've been told). The reason this has been brought to my attention is that Nintendo actually emulates the effect on the Wii U Virtual Console now, and that's a real beotch to emulate properly:

http://i.imgur.com/Nl8CZMG.jpg

Was there any reason why Jabo's couldn't emulate that effect? The only plugins I know that do it are Glide64 and the Ziggy's plugin. So I agree with the sentiments of others, that Glide64 should be the default plugin in future builds of PJ64. :D

Zera
2nd April 2015, 08:04 PM
Seems like Jabo's audio doesn't work too well with Goldeneye, even with sync to audio enabled (still skips). Azimer's newest plugin has the same problem. Shunyuan's is the only one that has no skips, but has an annoying delay in the audio.

But hey, this release is certainly an improvement over the previous one. No more timing issues, it seems.

RPGMaster
2nd April 2015, 11:14 PM
Was there any reason why Jabo's couldn't emulate that effect?Have you tried Jabo LLE? Most plugins are simply incomplete dude.

The only plugins I know that do it are Glide64 and the Ziggy's plugin.I think you need to test more plugins :rolleyes: .
So I agree with the sentiments of others, that Glide64 should be the default plugin in future builds of PJ64. :DIdk about that. Why use an HLE plugin that's slower than an LLE plugin :rolleyes: ?
Seems like Jabo's audio doesn't work too well with Goldeneye, even with sync to audio enabled (still skips). Azimer's newest plugin has the same problem. Shunyuan's is the only one that has no skips, but has an annoying delay in the audio.Iirc, Azimer 0.56 WIP2 did a decent job in goldeneye, although probably not perfect. I honestly rarely ever use Shunyuans (mostly just for comparison/ testing). I honestly wouldn't recommend his plugin for very many games (I haven't come across a single game where his is the best). The only thing I like about his, is that I believe he implemented time stretching (probably copied from another emu source). Only time I could see his plugin being useful is maybe when FAT is enabled.

I'll do more testing on that game, and see which audio plugin is the best.

the_randomizer
2nd April 2015, 11:19 PM
Have you tried Jabo LLE? Most plugins are simply incomplete dude.
I think you need to test more plugins :rolleyes: .
Idk about that. Why use an HLE plugin that's slower than an LLE plugin :rolleyes: ?
Iirc, Azimer 0.56 WIP2 did a decent job in goldeneye, although probably not perfect. I honestly rarely ever use Shunyuans (mostly just for comparison/ testing). I honestly wouldn't recommend his plugin for very many games (I haven't come across a single game where his is the best). The only thing I like about his, is that I believe he implemented time stretching (probably copied from another emu source). Only time I could see his plugin being useful is maybe when FAT is enabled.

I'll do more testing on that game, and see which audio plugin is the best.

Does Jabo emulate alpha dithering in Super Mario 64, Mystical Ninja 64, Hybrid Heaven, Mario Kart 64, etc? Simply having transparency effects isn't accurate, but alpha dithering is, just saying. LLE RSP plugins also emulate it, yeah, as they are extremely accurate.

Some games have missing effects in Jabo, such as motion blur in Paper Mario (battle transition), etc. If Jabo LLE can emulate alpha dither, motion blur, then great. Glide 64 actually works quite well for me, so...yeah. And doesn't the first boss (Draco) in Bomberman 64 require certain settings for his level?

Zera
2nd April 2015, 11:41 PM
I honestly rarely ever use Shunyuans (mostly just for comparison/ testing). I honestly wouldn't recommend his plugin for very many games (I haven't come across a single game where his is the best). The only thing I like about his, is that I believe he implemented time stretching (probably copied from another emu source). Only time I could see his plugin being useful is maybe when FAT is enabled.
On games such as Mystical Ninja, his plugin is the only one that gives consistent audio. Azimer's works extremely well on games that have FAT enabled by default, such as TWINE (no more garbled speech!) and Rush 2049 (the plugin was designed to work with that setting on, IIRC). Unfortunately, most games don't like this setting, otherwise I'd use Azimer's for everything (best quality I've seen so far).

RPGMaster
3rd April 2015, 01:07 AM
On games such as Mystical Ninja, his plugin is the only one that gives consistent audio. Azimer's works extremely well on games that have FAT enabled by default, such as TWINE (no more garbled speech!) and Rush 2049 (the plugin was designed to work with that setting on, IIRC). Unfortunately, most games don't like this setting, otherwise I'd use Azimer's for everything (best quality I've seen so far).Azimer's 0.56 works pretty good for certain games that don't work good on other plugins. From my brief testing, it seems Azimer's 0.56 is the best plugin for Goldeneye, but haven't really tested shunyuan's for that game.

I just tested Mystical Ninja. You're right about Shun's plugin. Still not perfect though. If audio plugins were more customizable, there would be far less audio issues. But I hear too many complaints from end users about not wanting to config that stuff rofl. It's a shame really.

Ambient_Malice
3rd April 2015, 03:29 AM
Have you tried Jabo LLE? Most plugins are simply incomplete dude.

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.) 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.)

RPGMaster
3rd April 2015, 04:03 AM
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.
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
3rd April 2015, 05:05 AM
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
3rd April 2015, 05:49 AM
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
3rd April 2015, 06:07 AM
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 :( .

http://i.imgur.com/JFH3D2b.png

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.
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. regardsInteresting. 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
3rd April 2015, 07:27 AM
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
3rd April 2015, 07:30 AM
I have somewhat better luck with z64gl on Linux. Here's an example of what I have to deal with on windows :( .

http://i.imgur.com/JFH3D2b.png

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.


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
5th April 2015, 05:25 PM
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? :confused:

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 :p

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 :D

Frank74
5th April 2015, 06:44 PM
(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/9498358/AziAudio0.60DAS.dll

Frank74
5th April 2015, 07:09 PM
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
5th April 2015, 07:14 PM
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.

RPGMaster
5th April 2015, 07:43 PM
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.Can't help you, until you mention the games where you are having issues..
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.Wow that's interesting.

(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.Doesn't that setting cause the VI/s to drop though? At least for me it did in Goldeneye. I'd rather just use a different plugin :D . I'm pretty sure Azimer's 0.56 WIP 2 worked good for Goldeneye (i use LLE for audio though). Is there a particular part of goldeneye where there's a lot of crackling? Because I usually just test the intro and part of the first level. I don't really play Goldeneye much.

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.Because people have the mentality that less plugins = better. Obviously if you play a variety of games, chances are, you'll need more plugins in order to get the best experience.

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?Patching the emulator wouldn't even make sense. It just reads from a config file which you can edit and choose whatever settings you like. As for why it's not on by default, it's because it's not perfect. Some of it depends on your hardware, but there are games that cannot run at 60 VI/s with the setting on. Quest64 is a good example. Generally though, if a game cannot run 60 VI/s because of audio sync being enabled, then you're using the wrong plugin :p .

Frank74
5th April 2015, 09:16 PM
Doesn't that setting cause the VI/s to drop though? At least for me it did in Goldeneye. I'd rather just use a different plugin :D . I'm pretty sure Azimer's 0.56 WIP 2 worked good for Goldeneye (i use LLE for audio though). Is there a particular part of goldeneye where there's a lot of crackling? Because I usually just test the intro and part of the first level. I don't really play Goldeneye much.

The only stutter is when bond first walks on in the intro. Maybe because in the (U) version, bond walks on too fast. In the (E) version, there are no stutters at all, bond walks much slower. Another difference is the (E) version music is higher pitched for some reason.

With Jabo, I get constant gaps in the audio.

HatCat
5th April 2015, 09:36 PM
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.

It just gets compiled for the release, but to compile the release requires having the source to it which was not available for the older plugins which were closed-source. So it doesn't come with those other plugins.

RPGMaster
5th April 2015, 09:37 PM
The only stutter is when bond first walks on in the intro. Maybe because in the (U) version, bond walks on too fast. In the (E) version, there are no stutters at all, bond walks much slower. Another difference is the (E) version music is higher pitched for some reason.

With Jabo, I get constant gaps in the audio.Now that you mention it, I notice that stuttering now. I think it's related to the video plugin because when I use dummy video in 1964, it never happens. Dummy video doesn't seem to work in PJ64 2.2, because it doesn't appear in my plugin list ;/ .

For me Azimer's 0.56 WIP2 seems good for Goldeneye. Have you tried that version? If so, how was it for you?

Frank74
5th April 2015, 10:17 PM
For me Azimer's 0.56 WIP2 seems good for Goldeneye. Have you tried that version? If so, how was it for you?

Slight delay in audio with Azimer's 0.56 LLE, compared to Azimer's 0.60 HLE. 0.60 HLE feels better when playing. More responsive.

I have Counter Factor set to 1, and Sync using audio off.

Ambient_Malice
5th April 2015, 10:18 PM
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.
The plugins are missing because they're outdated, incompatible, or not properly portable. Portability is why 1.7 Jabo plugins are used instead of 1.6.1, despite 1.6.1 being newer. Jabo's input is redundant and lacks features. Using old RSP files is pointless. No sound is useful only for debugging. Zilmar's audio is (mostly) redundant. Plugin bloat is bad, IMO.


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?

Jabo's Sync setting indeed cures a number of games. It also causes problems in other games. But I intend to enabled it by default for all games that benefit.

HatCat
5th April 2015, 11:02 PM
There is no change in portability as the plugins still use DirectX and are closed-source. The 1.7 plugins are different from 1.6.1 chiefly in that 1.7 had some of Jabo's concessions to the newer plugin specifications, which were for Project64-centric maintenance of code and not portability. If anything, the newer plugin specs impact portability to be worse, not better.

Up until now the only reason that's been cited officially is because he wants to supply open-source plugins that he can control.

Ambient_Malice
5th April 2015, 11:13 PM
There is no change in portability as the plugins still use DirectX and are closed-source. The 1.7 plugins are different from 1.6.1 chiefly in that 1.7 had some of Jabo's concessions to the newer plugin specifications, which were for Project64-centric maintenance of code and not portability. If anything, the newer plugin specs impact portability to be worse, not better.

Up until now the only reason that's been cited officially is because he wants to supply open-source plugins that he can control.

Wrong word. I meant the 1.7 plugins apparently work better with PJ64's current model of using a centralised ini file for configuration. I could be wrong, though. My brain is fuzzy.

Oliver2015
5th April 2015, 11:23 PM
Can't help you, until you mention the games where you are having issues..


First of all, many thanks for replying, RPGMaster :)

Please note, the games is: "Mystical Ninja Starring Goemon" and "Paper Mario" (in the latter game ...some scenes, it is slow).

Pls, perhaps you could let me know a solution.

Many thanks in advance!

HatCat
6th April 2015, 12:31 AM
Well hey at least someone realizes it.

Had this one person connect once and brag about some "portable" IRC client he was using. It was non-portable (+ closed-source) in every sense of the term, yet he persisted it was portable because it came from an archive instead of an EXE installer (therefore most likely also used INI files instead of the registry) and that anyone else's definition of portability was just too philosophical or code-wise religion to him.

But anyway yeah with PJ64 it has to do with letting PJ64 control the config system instead of having the plugin do it. The upside to this is PJ64 could quickly change to use either the registry, INI files, or a single Project64 config file for all of the settings from all of the plugins using the Project64 core to go through the settings. The downside is it's less portable, because this complicates the plugin specifications with unnecessary criteria to emulation which may or may not fit in on other operating systems. So from Mupen64Plus' and zilmar's POV it's more maintainable and/or portable to have all config go through the core and not within each plugin; ultimately though it's actually less portable and also more complicated. Besides, since each plugin setting is really only specific to one exact plugin and not multiple ones, it would confuse more than help those who are more familiar with the exact plugin used across multiple emulators, than they are with one exact emulator using the plugin.

chevbe2403
6th April 2015, 03:16 AM
Not sure the reason why.
Never mind, I found the answer. Thanks anyway.


Extractable with "innounp".


That's a nifty little program, it hadn't occurred to me to use something besides 7-zip. Using it surely beats the method I used. Thanks for that.


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


I had a feeling it was something like that. Good to know.


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.


I don't know which games if any need it, since I haven't tested many games yet. I will try more games and plugins when I have the chance. Thanks for the link.


Because people have the mentality that less plugins = better. Obviously if you play a variety of games, chances are, you'll need more plugins in order to get the best experience.


Yup. Personally, I think it's best to only include what is needed on an individual basis. I don't like adding plugins that I'll only use on a single game unless I love that game and want only the best experience. If it's a so-so game I will try to get the best experience I can out of a minimal plugin setup.


Patching the emulator wouldn't even make sense. It just reads from a config file which you can edit and choose whatever settings you like. As for why it's not on by default, it's because it's not perfect. Some of it depends on your hardware, but there are games that cannot run at 60 VI/s with the setting on. Quest64 is a good example. Generally though, if a game cannot run 60 VI/s because of audio sync being enabled, then you're using the wrong plugin :p .

Thanks for the info, that makes sense to me. :)

It just gets compiled for the release, but to compile the release requires having the source to it which was not available for the older plugins which were closed-source. So it doesn't come with those other plugins.

Yep, that's what I suspected. It's a shame Jabo hasn't open-sourced his plugins. Oh well. But it sure would be nice if other plugins could fix issues not present in Jabo's plugins by having access to the source. The WinBack gray square issue for example is not present only in Jabo's D3D 1.5.2 plugin AFAIK. It would be nice to be able to play that game without having to switch plugins all the time. Thanks for your answer.

The plugins are missing because they're outdated, incompatible, or not properly portable. Portability is why 1.7 Jabo plugins are used instead of 1.6.1, despite 1.6.1 being newer. Jabo's input is redundant and lacks features. Using old RSP files is pointless. No sound is useful only for debugging. Zilmar's audio is (mostly) redundant. Plugin bloat is bad, IMO.

I see, but just because something is outdated, doesn't mean it's without purpose. For example, Jabo's D3D6 1.5.2 is the only plugin AFAIK that makes WinBack (one of my favorites) tolerable by eliminating the gray square. It does however have the drawback of the lasers not being visible among other issues, but you can see what I mean. I always used Jabo's input in the past mainly because it was the default and I had no issues with it; if it's redundant so be it, I'll just stick to what's there unless I have issues with it. I don't use old RSP for anything but sometimes the No Sound so I can play my music library while gaming, but it would be just as simple to mute the audio in the plugin config and do away with No Sound. I never really used Zilmar's audio for anything but experimentation anyway. And yes, I agree about the plugin bloat.


Jabo's Sync setting indeed cures a number of games. It also causes problems in other games. But I intend to enabled it by default for all games that benefit.

I understand, and that would be appreciated. Thanks for your reply.

Ambient_Malice
6th April 2015, 05:22 AM
You make an excellent point about Winback & Jabo's old plugin. I guess the hope is that GLideN64 will fix that irky little bug.

MELERIX
6th April 2015, 06:42 AM
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

DxDiag says that your video drivers are from 2009, so probably are totally outdated, try to update them using this: http://support.amd.com/en-us/download/auto-detect-tool

Lithium
6th April 2015, 06:35 PM
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

It's a old issue, you need install windows updates to fix this.

Skorne
7th April 2015, 02:30 AM
What about Gauntlet Legends... could anybody have repaired the flicker and the status bar?

HatCat
7th April 2015, 02:43 AM
I answered your question already the last time you asked that. It could be controlled by the graphics plugin but not by Project64.

Tasoulis
12th April 2015, 09:28 AM
Any specific game fixes with this release? Any regressions? What about the RDB? Do we need to change default settings for each and every game again, like with 2.1?

V1del
12th April 2015, 11:00 AM
There have been a lot of RDB changes to make sure this doesn't have to be done individually anymore, so no you probably don't need to switch around all that much anymore

shinra358
15th April 2015, 06:58 PM
I can't seem to get the community texture pack for zelda to load with gliden64. But it works on 1.6 and 1.7. What am I doing wrong?

Edit: nevermind. had to manually point to the location. thought it did that by default.

ferlanga
16th April 2015, 02:17 AM
How does 2.2 perform compared to 2.1?
I recall 2.1 fixing some graphical issues but at the same time lowering the framerate on some games (fighter's destiny 2 being an example) to the point where I just kept using 1.6

shinra358
17th April 2015, 03:26 PM
Works very well. Especially with gliden64.

RPGMaster
17th April 2015, 05:47 PM
How does 2.2 perform compared to 2.1?
I recall 2.1 fixing some graphical issues but at the same time lowering the framerate on some games (fighter's destiny 2 being an example) to the point where I just kept using 1.6The main difference in 2.2 compared to 2.1, is default settings + rdb changes. 2.1 itself is still good and generally better than 1.6. All you had to do was change settings...

Of course there are some fixes in 2.2 though.

JPMC
18th April 2015, 08:52 PM
When I make a save state on PJ64 2.2, and go into the .zip, my OS C: is in the zip file, and there is no usual .pj file in there, also, there is another issue but it was problably my graphics plugin, the game never started and PJ64 froze, I switched to the best plugin out there, Glide64 and it worked. Jabo really sucks actually because many problems has been detected by me. Hopefully this can be fixed in the next publication of PJ64. Thanks!

Tasoulis
26th April 2015, 12:03 PM
So far i don't see any any differences with version 2.1

The games that i had problems with are still broken. Pilotwings crashes with a weird box-like texture just like in version 2.1 (you can see this at the end of the first stage demo as it always happens there).

So, even after all these versions, i still have to keep version 1.6 for some games :(

Frank74
26th April 2015, 12:37 PM
So far i don't see any any differences with version 2.1

The games that i had problems with are still broken. Pilotwings crashes with a weird box-like texture just like in version 2.1 (you can see this at the end of the first stage demo as it always happens there).

So, even after all these versions, i still have to keep version 1.6 for some games :(

Pilot Wings crash is caused by cheat fix in RDB (shadow fix). Cheat is enabled for Jabo and Glide plugins.
You need to uncheck Use TLB and Advanced Block Linking when the cheat fix is used.

Does anyone know if GlideN64 works ok?

Tasoulis
26th April 2015, 12:45 PM
Pilot Wings crash is caused by cheat fix in RDB (shadow fix). Cheat is enabled for Jabo and Glide plugins.
You need to uncheck Use TLB and Advanced Block Linking when the cheat fix is used.
Thanks, i wasn't aware of this.

Does anyone know if GlideN64 works ok?
Tested a few early N64 games and so far it works OK with 2.2 version. Pilotwings has the shadow glitch though (needs a new cheat fix?)

Frank74
26th April 2015, 01:03 PM
You could try adding ",GLideN64" to the RDB cheat plugin setting.

CheatPlugin0=Jabo's Direct3D8,Glide64 For PJ64,GLideN64

I can't use GLideN64, don't have OpenGL 4 support.

Predator82
26th April 2015, 03:15 PM
Haven´t OpenGL 4.0 too & most works fine
only some things didn´t work right without 4.0 for example the Extreme-G-logo (experimental n64 depth needs 4.0)

Ambient_Malice
26th April 2015, 09:19 PM
I was under the impression that Gonetz was supposed to be fixing the shadows in Pilot Wings. Hasn't happened yet, though, apparently.

Did fix the shadows in Turok 3, though, which is nice.

Tasoulis
27th April 2015, 11:28 PM
After about 2-3 hours testing games and saving different plugins and settings for each one, the emulator decided to revert everything at default settings for whatever reason after i started it today...

Is there any way to get my settings back? Or do i have to start over? And how can i make it sure that the emulator won't screw me over again?

Edit: i guess backing up Project 64.cfg somewhere should be sufficient.

RPGMaster
28th April 2015, 12:12 AM
After about 2-3 hours testing games and saving different plugins and settings for each one, the emulator decided to revert everything at default settings for whatever reason after i started it today...

Is there any way to get my settings back? Or do i have to start over? And how can i make it sure that the emulator won't screw me over again?Your cfg file is possibly corrupted. I'd check in notepad. If you have win7, it may be possible to restore to a previous version of a file.

The cfg file corruption was fixed after official release, so you'll need to use a newer version. Also be sure to clean the cfg file if it is indeed corrupted.

furryfangs
20th May 2015, 03:44 PM
this is already better by a landslide the donkey kong 64 intro stays in sync for a majority of the time, so that's a S+ in my books. :D

Mantidactyle
2nd June 2015, 02:00 AM
So you embraced malwares with "Next" buttons when prompting for installation.

I'll never ever use project64 again. If that's money you want just put a friggin "donate" button during the installation and be sure I would have donated. Go to hell dear p64 devs.

Ambient_Malice
2nd June 2015, 02:43 AM
So you embraced malwares with "Next" buttons when prompting for installation.

For what it's worth, the wording of the installer is controlled by a third party. But yes, I sympathise with your disgruntlement.

dsx_
2nd June 2015, 04:15 AM
yeah its a fucking JOKE

OldGnashburg
2nd June 2015, 09:32 PM
I still think pornhub or PunishTube ads would be better.

OldGnashburg
5th June 2015, 06:47 PM
Anyways, onto another subject that would probably be more productive. From what I've seen in the GitHub repository, Project 64 is going 64-Bit, and obtaining 64DD support. People are doing all sorts of cool contributions (sadly the only contribution I managed to make is now outdated), and have also (from what I've seen) been trying to optimize the sh*t out of Project 64 and possibly make it portable. There have been all sorts of updates, such as CXD4/Iconoclast/FatCat/BatCat/HatCat's (jeez, so many names) grammar Nazi ambushes whether it's aimed at either actual writing or just code (he does a lot of good for portability and optimization too), and like I said, LuigiBlood has also contributed with the addition of 64DD support, I could go on, but I don't know any of the other developers and can't list them off the top of my head. Anyways, my conclusion? The Nintendo 64 emulation scene has taken off and progress is happening again. It's a wonderful thing.

OldGnashburg out!

HatCat
5th June 2015, 08:06 PM
There have been all sorts of updates, such as CXD4/Iconoclast/FatCat/BatCat/HatCat's (jeez, so many names) grammar Nazi ambushes whether it's aimed at either actual writing or just code (he does a lot of good for portability and optimization too),

Well nah, that was just because some contributors started falsely touching the multi-language support files for the UI text that the Project64 window shows. The English itself was so bad that I never wanted to make grammar commits to it until some furthering to the situation made it even worse. It was also an experiment to see whether I would troll zilmar or if he'd just blindly merge everything about the grammar.

As with any other type of thing I always divide into as many small micro-component and specifically named commits as I can :) as that is the only correct way to organize disputable changes into many commits. MarathonMan just chose to deliberately misinterpret the history for the purpose of presenting it as something that it's not, as like you said there have been many core & RCP changes as well. ;) All one can really do is ignore all the jealous counter-productivity in the scene--at least some of us have been moving things forward.

RPGMaster
5th June 2015, 10:02 PM
People are doing all sorts of cool contributions (sadly the only contribution I managed to make is now outdated), and have also (from what I've seen) been trying to optimize the sh*t out of Project 64What optimizations?

OldGnashburg
8th June 2015, 07:01 PM
I didn't see any optimizations, but I assumed the overall code clean up would be considered optimizations.

fabrique_bacon
5th July 2015, 02:15 PM
Where can i find the changes in the new version 2.2 ? Can't find a list of what's new despite searching. Anyway are the bugs from Donkey Kong 64 have been fixed? I mean the timer bug and also the bug that make the game crash after some playing, which makes it impossible to complete.

ExtremeDude2
5th July 2015, 02:42 PM
Project64 2.2.0.3

Language: clean up of text
RDB Changes: lots
NRage: ignore raw when mempak set
NRage: Default to mempak
Project64: code clean up
RSP: code clean up


Project64 2.2.0.2

RDB Changes: lots
Glide: fixed memory leak in config window
Glide: Stop assert on non utf8/ansi internal name
Glide: Be able to show errors when in debug mode
Project64: All language files are utf8 instead of ansi
Project64: Upgraded 7zip library to 9.2
Project64: Hacks in rdb are now applied to jabo and glide plugin only
Project64: fixed some bugs in dynamically changing plugins
Rsp: Optimize a few recompiler opcodes
Rsp: Used standard types


Project64 2.2.0.1

Input: dynamic link xinput (should work better in XP)
Update project settings for VS2013 (should work better in XP)
Upated rdb file
update glide.rdb
Updated cheat files

fabrique_bacon
5th July 2015, 02:47 PM
Thanks for the changelogs, for some reason i couldn't find it. Doesn't seem to have bug fixes for Donkey Kong 64. That's unfortunate because DK64 was a good game

V1del
5th July 2015, 10:04 PM
The RDB changes: lots imply fixes, including the timers, don't know if they were able to get past the crashing with some CF magic

Skorne
7th July 2015, 10:51 PM
and what about Vigilante 8?
a good game that i can't play in PJ64
any solutions?

shaggshroom
10th July 2015, 10:42 AM
Good to see this is still being worked on..
Enjoyed it way back when in the beta program.. then honestly forgot about it with IRL stuff.. but kudose for keeping it alive and thanks for the updates

OldGnashburg
23rd July 2015, 04:30 AM
@ Zilmar or anybody with anybody with any power on these forums.

After seeing some of the major changes in the PJ64 GitHub repo, I believe it is either time to release some Beta's in preparation for a new stable release, or at least open a suggestion thread for 2.3 (or whatever version number the next release will be).

TheTurkGamer
31st July 2015, 07:34 AM
why? IT HAVES VIRUS WAJAM AND DAILYPCCLEAN IS A VIRUS AND A FAKE ANTIVIRUS HE GONNA BLOCK ALL MY FILES

ferlanga
5th August 2015, 06:07 PM
So this virus alert I got when trying to install PJ64 2.2 was a false positive?

V1del
6th August 2015, 06:21 AM
Yes and no, PJ64 itself doesn't contain any viruses or malware, the installer installs some ads/browsertoolbars/whatev which technically aren't viruses but are usually marked by AVs because they are undesired in most cases (the name of the viruses often contain AD something which points to it being blocked due to being an advertisement) If you keep your eyes open during install you can avoid installing them (or call the installer exe with the /noads flag or extracting it with 7zip or similar)

Marcelo_20xx
11th August 2015, 11:17 PM
I have a question: How is that PJ64 2.2 is not portable? or are you referring to the type of cross-platform portability? because I can have different per game PJ64 2.2 setups without any writing to the registry.

Also I am very pleased to see the N64 scene doing improvements over the past months/years...

geniv
23rd August 2015, 04:37 AM
there are a few people here including me that actually paid for donation to PJ64 though that was along time ago. and we were giving access to download beta version before the public gets it.

anyway I don't see any new beta version but can you at least give us a installer witout that annoying ad?

or at least a portable/Zipped version instead of the exe installer?

UberAndrew
5th September 2015, 05:56 AM
When I try to go to the download page on google chrome it gives me a warning that the page contains malware and won't let me go there.

I'm assuming this is because of the installer?

ferlanga
5th September 2015, 09:34 PM
When I try to go to the download page on google chrome it gives me a warning that the page contains malware and won't let me go there.

I'm assuming this is because of the installer?

Im on firefox and i get the same result. Im not sure if its the installer because i only got the malware warnign when opening the installer.

arede
18th September 2015, 04:47 PM
every time I can level up in mário paper in the part where defeated King Goomba, the game crashes and does not return, and no matter What do I do, it keeps crashing, I know how to solve this problem

Carsomyr
21st September 2015, 05:19 PM
I'd like to know what is up with the main pj64 site? The blogs page shows a sidebar and the downloads page functions but every other page is blank? Kind of hard to look at a gamefaq I can't see :confused:

Carsomyr
22nd September 2015, 02:36 AM
While I'm at it I'm curious what compiler/libraries the emulator was written with?? I'm looking to expand my coding horizons, even if It isn't ever release quality. :)

DaMan69
22nd September 2015, 09:22 AM
Visual Studio 13 or 15 community will do. Nobody updated the WX headers for 15 yet:confused: (I guess I should make myself useful). Repo includes all the libraries needed to build. MSE complains about the installer adware you don't need it just be sure to uncheck installer from the build configuration.

HatCat
22nd September 2015, 05:09 PM
I have a question: How is that PJ64 2.2 is not portable? or are you referring to the type of cross-platform portability? because I can have different per game PJ64 2.2 setups without any writing to the registry.

Portability refers to neither of those two things.

Contrary to popular belief, cross-platform is just one key to portability. It's quite possible to write something that's multi-OS yet still have very poor availability to other systems and other conformant implementations of C as a specification.

As for the other thing (not writing to the registry, using local config files) I have no idea what idiot end user started that rumor. Because that has nothing to do with "portability"; that just means you can take the binary form of the pre-compiled Project64 and have it search for a relative directory on your hard disk instead of the infamous system registry that only Windows uses.

Marcelo_20xx
22nd September 2015, 05:18 PM
I guess they started to call "portable" because the USB era allowed many programs and games to be just copied in it and then executed on a different machine without any installation procedure...

As of know many apps developers refers to "portable" when such app doesn't require any installation (thus writes on the registry)...

Emulation as I see it should be locally configured on a per game basis because there isn't any single config that will run optimally for everygame, I am happy that since PJ 2.X you can have it this way...

HatCat
22nd September 2015, 05:50 PM
I guess they started to call "portable" because the USB era allowed many programs and games to be just copied in it and then executed on a different machine without any installation procedure...

Well that still has nothing to do with portability.

That means the configuration of the compiled software is portable.

The only way for the software itself to be portable is if it is designed that way. No amount of flashing EXE files over USB makes any difference there; it just sounds like a dumb expression end users refer for their ability to not have to re-configure software which actually isn't portable either way.

Not sure why USB should have to do with it. I'm sure when floppy disk drives were still the major thing, the Windows registry didn't even exist back then! So why wasn't this artificial context of "portability" so correct back then as it is now?

As of know many apps developers refers to "portable" when such app doesn't require any installation (thus writes on the registry)...

I wouldn't say it's surprising that these developers would willingly use wrong terminology if it's in their better interest to capitalize in their position of power over the users.

It's easy for developers to claim their closed-source works as "portable" because they only release for a single operating system where the "registry" even exists as a thing at all.

By the definition of portability you cite, any software that is available on a non-Windows operating system is automatically considered portable, because there is no system registry. I however disagree with that too, because it's not hard to make Linux- or Macintosh- or etc.-only software that isn't portable to other systems, like Windows.

Emulation as I see it should be locally configured on a per game basis because there isn't any single config that will run optimally for everygame, I am happy that since PJ 2.X you can have it this way...

It's a good idea, but there are approaches at emulation that don't need any per-ROM configuration at all and maintain complete compatibility with everything. For things like speed hacks or stuff like mixed or hybrid HLE then it sounds like a good idea to have per-game config, but I think that's a matter of personal approach.

Marcelo_20xx
22nd September 2015, 07:02 PM
I only started to read "portable app" on the USB era, since some developers advertised their apps by the slogan: "Put it on a USB and carry it with you everywhere so as not to interrupt your work" or something among those lines, I personally despise the damn Windows registry for many reasons, I was happy with the ini files back then, I don't needed the convoluted thing that the registry has become now. Because I like to have control of what an app do to my system...

It's a good idea, but there are approaches at emulation that don't need any per-ROM configuration at all and maintain complete compatibility with everything. For things like speed hacks or stuff like mixed or hybrid HLE then it sounds like a good idea to have per-game config, but I think that's a matter of personal approach.

Yes, its a very personal preference. Since I like to try various configurations, I don't want to screw up games that I already configured for the best experience possibly within my rig and it also ease the process of testing games too...

If I don't like the results of a configuration I just delete the test folder of the game I just created for that purpose and when I am happy with the results I rename the folder to the game's name and move it to another folder called "Final_dont_touch_ever_again " that I rarely ran configs tests again...

Wally123
23rd November 2015, 01:18 PM
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

System DLL files may be corrupted. Try this...

https://support.microsoft.com/en-us/kb/929833

GamingFan4Ever
16th January 2016, 04:59 PM
Thanks for this emulator. Started using it today and it's great. :)

welshstan
21st January 2016, 11:17 PM
Hi Sir.can you tell me how this site works please? I have just installed Project 64 and want to tell who made it,that it's brill. Better than retropie.Full screen,good sound and fast. :)

kick007
26th January 2017, 02:32 AM
Nintendo wii can it be add to homebrew

HatCat
28th January 2017, 04:22 AM
System DLL files may be corrupted.

http://forum.pj64-emu.com/customavatars/avatar139586_1.gif

Nintendo wii can it be add to homebrew

Are you sure you're 29?