New Project64k Core 2.2

[Zantetsu]

It just occured to me that maybe the 58 fps issue is due to the audio plugin. Be sure to disable audio sync in the audio plugin settings too. If that doesn't fix it, I guess I'll have to try it myself and see what's going on.

Edit: Just tried connecting to myself and I had 60 fps. I beat story mode and never desynced.

Okay, so my original test was flawed. I had tweaked around with Ownasaurus' build a lot before trying your file out, and I think that messed with my results, because when I downloaded a fresh build to use your .exe with, I got different results. Both disabling the audio sync in Jabos and switching to the old Azimer's plugin fixed the 58 fps issue. Neither of these options seemed to work with the original .exe, so whatever you did appears to have solved it.

I still have yet to do some sync tests, I don't have my spare PC on me to do so. I'm concerned about desyncs because Ownasaurus specifically said "to allow for full sync on kaillera, core runs at ~58 VI/sec instead of 60 VI/sec" which makes me believe he made that limit for a specific reason, and removing it might cause it to desync often. However, you claim to have tested it without any desyncs yourself. When you did test, were you using Jabos audio plugin or did you switch it to an old one like Azimer's? Being able to use Jabos audio over Azimers would be a huge incentive, since Azimers has a large amount of delay to it.

Also, I'm assuming the fullscreen issue hasn't been touched (yet?)? Going fullscreen in a netplay session by myself caused my end to be paused during the fullscreen, so I imagine it still causes a desync.

 

[Madao]

A few patches is all that's needed. Just the base functionality of the emulator to replicate what PJ64k and Mupen64K do for their netplay. Maybe creating a list of things that need to be done would be a good idea.

Good idea about creating a list. Eventually, I think it will be good to port kailera to PJ64 2.3, but for now, I can focus on important improvements. Other than the fullscreen syncing, I'm not sure what's left to do that's important.

I still have yet to do some sync tests, I don't have my spare PC on me to do so. I'm concerned about desyncs because Ownasaurus specifically said "to allow for full sync on kaillera, core runs at ~58 VI/sec instead of 60 VI/sec" which makes me believe he made that limit for a specific reason, and removing it might cause it to desync often. However, you claim to have tested it without any desyncs yourself. When you did test, were you using Jabos audio plugin or did you switch it to an old one like Azimer's? Being able to use Jabos audio over Azimers would be a huge incentive, since Azimers has a large amount of delay to it.

Also, I'm assuming the fullscreen issue hasn't been touched (yet?)? Going fullscreen in a netplay session by myself caused my end to be paused during the fullscreen, so I imagine it still causes a desync.

I basically just backported some good commits, like improved audio timing. I'm pretty sure it was doing 58 fps due to improper audio timing. The newer code isn't perfect, but it's a lot better. I used Jabo's Audio 1.7 for the testing.

I haven't touched the full screen code yet. I'll have to look and see what code is needed to sync that event.

 

[Zantetsu]

Good idea about creating a list. Eventually, I think it will be good to port kailera to PJ64 2.3, but for now, I can focus on important improvements. Other than the fullscreen syncing, I'm not sure what's left to do that's important.

I basically just backported some good commits, like improved audio timing. I'm pretty sure it was doing 58 fps due to improper audio timing. The newer code isn't perfect, but it's a lot better. I used Jabo's Audio 1.7 for the testing.

I haven't touched the full screen code yet. I'll have to look and see what code is needed to sync that event.

Personally, I feel that fullscreen without desync is the only "important" thing left to do, since it's the only necessity needed right now, because it's the only way to avoid forced vsync on modern windows OS'. That's important to be able to disable to minimize input lag as well as to maintain a consistent visual frame rate. I can't think of any other features that are "needed" and only things that would be bonuses.

It's great that your test was successful with Jabos though. Using Jabos in the standard PJ64k causes desync and people are forced to use Azimer's, which has a large amount of delay to it. Just another incentive to push for this new standard. I intend on doing some further sync testing myself with some other online players, I'll let you know if there's anything out of the ordinary.

 

[King Omega]

When you guys have an improved version finalized and ready, get in touch with the people in charge of the major Smash 64 online resources (here, onlinessb) and especially the outer heaven servers, get them on board so we can actually force people to switch. Otherwise the work is largely wasted (at least the Kaillera portion).

 

[Madao]

Good news is that Project64 2.3 is close to officially releasing. UI still needs a bit of work, but the emulator is steadily improving overall.

Personally, I feel that fullscreen without desync is the only "important" thing left to do, since it's the only necessity needed right now, because it's the only way to avoid forced vsync on modern windows OS'. That's important to be able to disable to minimize input lag as well as to maintain a consistent visual frame rate. I can't think of any other features that are "needed" and only things that would be bonuses.

I figured full screen was the last important thing needed. Anyway, I tried playing against myself in kaillera p2p and full screen worked. I switched between full screen and window mode a few times and no issues other than the transition being slow. I think it's best if you select the option in PJ64 called "Enter full screen mode when loading a ROM". That should reduce the amount of potential problems, i imagine.

When you guys have an improved version finalized and ready, get in touch with the people in charge of the major Smash 64 online resources (here, onlinessb) and especially the outer heaven servers, get them on board so we can actually force people to switch. Otherwise the work is largely wasted (at least the Kaillera portion).

Well it's already good enough to replace pj64 1.4k imo. Although perhaps there should be some more testing and feedback before forcing people to switch.

 

[caneut]

Good news is that Project64 2.3 is close to officially releasing. UI still needs a bit of work, but the emulator is steadily improving overall.
I figured full screen was the last important thing needed. Anyway, I tried playing against myself in kaillera p2p and full screen worked. I switched between full screen and window mode a few times and no issues other than the transition being slow. I think it's best if you select the option in PJ64 called "Enter full screen mode when loading a ROM". That should reduce the amount of potential problems, i imagine.

Well it's already good enough to replace pj64 1.4k imo. Although perhaps there should be some more testing and feedback before forcing people to switch.

u need testers?

 

[Deleted member]

Good news is that Project64 2.3 is close to officially releasing. UI still needs a bit of work, but the emulator is steadily improving overall.
I figured full screen was the last important thing needed. Anyway, I tried playing against myself in kaillera p2p and full screen worked. I switched between full screen and window mode a few times and no issues other than the transition being slow. I think it's best if you select the option in PJ64 called "Enter full screen mode when loading a ROM". That should reduce the amount of potential problems, i imagine.

Well it's already good enough to replace pj64 1.4k imo. Although perhaps there should be some more testing and feedback before forcing people to switch.

Awesome saucies! ^_^ Let's hope it's not an unstable version like 2.2.

Edit: Also, if you need anyone to test, I'm your girl.

 

[Madao]

u need testers?

Yea. Some feedback would be nice.

Awesome saucies! ^_^ Let's hope it's not an unstable version like 2.2.

Edit: Also, if you need anyone to test, I'm your girl.

It should be ok at least. I'd appreciate any testing.

 

[caneut]

http://forum.pj64-emu.com/showthread.php?t=5813

new 2.3 pj64 is out

 

[nickthename]

Yea. Some feedback would be nice.
It should be ok at least. I'd appreciate any testing.

I'll try to arrange some testing with cane next week when I'm back on ethernet. What's the plan now that 2.3 is out? Are you porting kaillera to that, or should we try to make 2.2 the new standard?

 

[Madao]

I'll try to arrange some testing with cane next week when I'm back on ethernet.

Alright, let me know how it goes.

What's the plan now that 2.3 is out? Are you porting kaillera to that, or should we try to make 2.2 the new standard?

I think 2.2 is fine for now. I'm not sure if / when I'll port kailera to 2.3.

 

[Zantetsu]

I've come back to this for further testing and I think I know why my results were inconsistent & why you and I have been getting different results.
Almost every test you have done has been exclusively p2p, correct? No servers?
Because after some additional testing, I've found out that I'm only achieving 60fps through offline and p2p. Servers, no matter what audio plugin I use or setting I change, always gives me the 58fps lock.

 

[Madao]

I only tested p2p. Didn't even realize that server would be any different in that regard. Maybe I'll look into it then. Nice find.

 

[Zantetsu]

Sweet! Glad that was cleared up, the inconstant results I was getting is what made me stop trying/tweaking originally lol.

 

[Uair]

I only tested p2p. Didn't even realize that server would be any different in that regard. Maybe I'll look into it then. Nice find.

Server and P2P is totally different for kaillera client. You can play some games like DK64 (U) longer (but still ds) on mupen64k with p2p.

 

[Madao]

Sweet! Glad that was cleared up, the inconstant results I was getting is what made me stop trying/tweaking originally lol.

I tried playing against myself on server and stayed at 60, although there were lag spikes (either my wifi or the server's fault). I had to run 2 exes from different folders to even play against myself. Did you try playing against yourself or someone else? I'm not sure why it would be a problem unless you're playing someone else and their settings aren't correct. Any sort of "audio sync" is bad for netplay because it can cause the fps to drop.

Server and P2P is totally different for kaillera client. You can play some games like DK64 (U) longer (but still ds) on mupen64k with p2p.

Isn't DK64 worse on mupen? Not sure why people would use mupen for that game. Good to know that there is a difference between server and p2p when it comes to desync though.

 

[Uair]

I tried playing against myself on server and stayed at 60, although there were lag spikes (either my wifi or the server's fault). I had to run 2 exes from different folders to even play against myself. Did you try playing against yourself or someone else? I'm not sure why it would be a problem unless you're playing someone else and their settings aren't correct. Any sort of "audio sync" is bad for netplay because it can cause the fps to drop.
Isn't DK64 worse on mupen? Not sure why people would use mupen for that game. Good to know that there is a difference between server and p2p when it comes to desync though.

DK64 and most games don't work on PJ64k even through P2P. LD and Williams90000000000000 or whatever knows more about this specific issue with DK64.

I remember me and LD got DK64 (U) to work over Mupen64k through P2P for about 5 minutes. The main problem with DK64 is it's so unsynced (as you may know), it wasn't until about a year ago when GLideN64 got better than DK64's intro actually synced the audio to gfx. That issue is why it syncs so poorly online.

Of course it works fine with AQZ, but it's basically impossible to play on kaillera/p2p unless you use the Japanese version which still desynces quickly but not instantly like U/E used until whatever me and LD/william did to get it to sync for 5 minutes.

 

[Zantetsu]

Madao Hey! Got some info that may help!

Chatlog:
Zantetsu: Ownasaurus where is that line in your source code that forces that? I've attempted to find it but couldn't (even though I don't have any knowledge on this stuff, just trying). However, Madeo is fixing some issues up with this emu to hopefully make it a new standard. Basically, the reason that the current emu sucks is because you can't full screen without DS, so people on Windows 8+ are forced to deal with stuttering due to the forced vsync on windowed programs. According to Madeo, the 2.2 fullscreens without DS, so that would help us a ton. Plus, the fact that it's so much smoother than 1.3.
Ownasaurus: i havent looked at the code in ages but let me take a quick peak
Ownasaurus: This was the change: https://github.com/Ownasaurus/Project64k-Core-2.2/commit/e49634be94530807fb598feb607a70265e84d261
i even left the old code commented in
thats all a coder would need to know to revert that change. it has the file name, the line number, the before, and the efter

 

[Uair]

Madao Hey! Got some info that may help!

Chatlog:
Zantetsu: Ownasaurus where is that line in your source code that forces that? I've attempted to find it but couldn't (even though I don't have any knowledge on this stuff, just trying). However, Madeo is fixing some issues up with this emu to hopefully make it a new standard. Basically, the reason that the current emu sucks is because you can't full screen without DS, so people on Windows 8+ are forced to deal with stuttering due to the forced vsync on windowed programs. According to Madeo, the 2.2 fullscreens without DS, so that would help us a ton. Plus, the fact that it's so much smoother than 1.3.
Ownasaurus: i havent looked at the code in ages but let me take a quick peak
Ownasaurus: This was the change: https://github.com/Ownasaurus/Project64k-Core-2.2/commit/e49634be94530807fb598feb607a70265e84d261
i even left the old code commented in
thats all a coder would need to know to revert that change. it has the file name, the line number, the before, and the efter

That looks like a framework issue. Bool stands for boolean, which is a true or false statement.

 

[Zantetsu]

Madao not sure if this will also help, but I actually went and tested fullscreen via p2p on the old Project64kVE by myself (over LAN, not internet) and found that fullscreen doesn't desync through this emulator either (under p2p, still does under Kaillera) like many people have thought. What I noticed is that during the full screen, the emulator doesn't pause (the sound keeps going) so perhaps the issue with fullscreen without desync is within the kaillera code and not the emulator (as it seems Kaillera is responsible for pausing the emulator which causes the desync in the first place).

 

[Madao]

I'm pretty sure my tweaked version of 2.2k is set, as far as desyncing is concerned. The only potential issue remaining afaik is fullscreen.

Perhaps this weekend, I can try testing fullscreen on server. It should be possible to ensure fullscreen gets synced, through the emulator.

 

[Zantetsu]

I tried playing against myself on server and stayed at 60, although there were lag spikes (either my wifi or the server's fault). I had to run 2 exes from different folders to even play against myself. Did you try playing against yourself or someone else? I'm not sure why it would be a problem unless you're playing someone else and their settings aren't correct. Any sort of "audio sync" is bad for netplay because it can cause the fps to drop.

I had completely missed over this when I wrote my other 2 messages, my apologies. I have actually managed to get 2.2 to work at 60fps through both server and p2p. I believe it will full screen without DS, but I'm doing some additional testing on that just to confirm.

There is an issue I'm having with p2p though, when I click "drop game" the p2p client will repeatedly send "dropping game" in the chat area before it freezes and then crashes. I was wondering if you were having the same issues during your tests?

 

[Deleted member]

Hello everyone

There plans of Project64k 2.3?

A greeting.

 

[Madao]

Sorry for the late replies

There is an issue I'm having with p2p though, when I click "drop game" the p2p client will repeatedly send "dropping game" in the chat area before it freezes and then crashes. I was wondering if you were having the same issues during your tests?

I think I have encountered that issue. Idk of an open source emulator that does not have that problem. I could never manage to compile mupen64 0.5 so idk if it works on that build. Hitting drop game is indeed an issue.

Hello everyone

There plans of Project64k 2.3?

A greeting.

Not really, since people still would rather use 1.4k.. I tried to get people to switch over to a better emulator, but was unsuccessful each time.

 

[Zantetsu]

Sorry for the late replies

I think I have encountered that issue. Idk of an open source emulator that does not have that problem. I could never manage to compile mupen64 0.5 so idk if it works on that build. Hitting drop game is indeed an issue.

Not really, since people still would rather use 1.4k.. I tried to get people to switch over to a better emulator, but was unsuccessful each time.

I haven't encountered the issue in any other emulators either, just this one, and it's a huge pain because it requires the program to be reset each time. Besides this particular issue, with all of the other fixes you have applied and some other things I have tested, I'm confident I could get this to become the primary emulator to use, but with the p2p restart issue, that's a big issue that makes it difficult. Is this something you think you could resolve?

Also, sorry to nitpick you for everything, you seem to be the only one who has the knowledge on how to do these things, and have been willing to do it. I truly appreciate the adjustments you've made to make this emulator better.

 

[y0da]

Hello.
I am very interested in your project and I can spend some time to try your stuff.
Most of my friends now work in other countries and cannot come at my house to play anymore
So, we are looking forward to play the N64 online and as far as i remembered, it was chaotic few years back.

Will both the new emulinker and your project fix most of the desync problems ?
We could also open a compatibility list on google drive in order to keep track of what is tested so far.

Have a nice day and keep up. You have my support

 

[Uair]

Hello.
I am very interested in your project and I can spend some time to try your stuff.
Most of my friends now work in other countries and cannot come at my house to play anymore
So, we are looking forward to play the N64 online and as far as i remembered, it was chaotic few years back.

Will both the new emulinker and your project fix most of the desync problems ?
We could also open a compatibility list on google drive in order to keep track of what is tested so far.

Have a nice day and keep up. You have my support

Mupen64k

Project64 AQZ

 

[Madao]

I haven't encountered the issue in any other emulators either, just this one, and it's a huge pain because it requires the program to be reset each time.

Perhaps that part works somewhat better on 1.4k, but I still remember it being buggy in 1.4k. The only emulator with truly stable kailera integration is mupen64++beta.

I haven't encountered the issue in any other emulators either, just this one, and it's a huge pain because it requires the program to be reset each time. Besides this particular issue, with all of the other fixes you have applied and some other things I have tested, I'm confident I could get this to become the primary emulator to use, but with the p2p restart issue, that's a big issue that makes it difficult. Is this something you think you could resolve?

I don't mean to downplay the issue, but why is that more important to fix than desync? Desyncing is the biggest problem imo. Out of curiosity, why do you need to drop game? It would be nice to fix the remaining issues, but I don't know how long it would take me to figure out how to fix and my free time is limited these days so i don't think I'll bother any time soon, if at all.

If someone can manage to compile mupen64 0.5 with kailera, I would consider comparing the code (assuming it works fine in mupen). I know that it works great in mupen64++beta, but it's closed source.. I'm not much of a UI coder, so this isn't something I would likely be able to easily fix on my own.

 

[Uair]

Perhaps that part works somewhat better on 1.4k, but I still remember it being buggy in 1.4k. The only emulator with truly stable kailera integration is mupen64++beta.

I don't mean to downplay the issue, but why is that more important to fix that desync? Desyncing is the biggest problem imo. Out of curiosity, why do you need to drop game? It would be nice to fix the remaining issues, but I don't know how long it would take me to figure out how to fix and my free time is limited these days so i don't think I'll bother any time soon, if at all.

If someone can manage to compile mupen64 0.5 with kailera, I would consider comparing the code (assuming it works fine in mupen). I know that it works great in mupen64++beta, but it's closed source.. I'm not much of a UI coder, so this isn't something I would likely be able to easily fix on my own.

It's not closed source, it was just lost.

Maybe someone has it on a harddrive from a decade ago.

 

[Zantetsu]

Perhaps that part works somewhat better on 1.4k, but I still remember it being buggy in 1.4k. The only emulator with truly stable kailera integration is mupen64++beta.

My first time experiencing the issue was with this 2.2 build, it had never happened to me on 1.4k or on the Mupen w/ kaillera support emus I've tried (which I think was ++beta?)

I don't mean to downplay the issue, but why is that more important to fix than desync? Desyncing is the biggest problem imo.

It's not that it's more important, I was just beginning to think that full sync support through Kaillera won't be a possibility.

Out of curiosity, why do you need to drop game? It would be nice to fix the remaining issues, but I don't know how long it would take me to figure out how to fix and my free time is limited these days so i don't think I'll bother any time soon, if at all.

Sometimes people forget to do things like forcing a specific frame delay, or recording the match for a krec file. Also, on the low chance that a DS does happen through p2p, dropping and starting is much faster than force closing the program and starting it over again. It's difficult to convince somebody to switch when a crash happens 100% of the time on something that people do frequently.

Although, I completely understand if your free time is limited, or you simply wanna use it elsewhere. Perhaps somebody can pick this up from where you have left off, and again, I really appreciate the time you have put into this already.

 

[Madao]

I recently tried testing GLideN64 for SSB and it's worse than Glide64.. Why are people suggesting to use that over Glide64???

It's not closed source, it was just lost.

Maybe someone has it on a harddrive from a decade ago.

When I said closed source, I simply meant that the author never released source.

My first time experiencing the issue was with this 2.2 build, it had never happened to me on 1.4k or on the Mupen w/ kaillera support emus I've tried (which I think was ++beta?)

It's not that it's more important, I was just beginning to think that full sync support through Kaillera won't be a possibility.

Sometimes people forget to do things like forcing a specific frame delay, or recording the match for a krec file. Also, on the low chance that a DS does happen through p2p, dropping and starting is much faster than force closing the program and starting it over again. It's difficult to convince somebody to switch when a crash happens 100% of the time on something that people do frequently.

After doing more testing, 2.2k definitely has a bigger problem with dropping game. However 1.4k is still less stable than Mupen64++beta. So if stability is the main concern, then Mupen64++beta should be default. If gameshark codes are top priority, then 2.2k should be the default because it supports activator codes.

If dropping games is such a big deal, just run a script to exit the current process and restart PJ64k. I cannot imagine anyone having to drop the game so frequently that they would rather use some buggy 16 year old emulator that desyncs easily. Tbh I recall someone making a script to exit 1.4k due to its instability as well.

 

[Uair]

I recently tried testing GLideN64 for SSB and it's worse than Glide64.. Why are people suggesting to use that over Glide64???

When I said closed source, I simply meant that the author never released source.

After doing more testing, 2.2k definitely has a bigger problem with dropping game. However 1.4k is still less stable than Mupen64++beta. So if stability is the main concern, then Mupen64++beta should be default. If gameshark codes are top priority, then 2.2k should be the default because it supports activator codes.

If dropping games is such a big deal, just run a script to exit the current process and restart PJ64k. I cannot imagine anyone having to drop the game so frequently that they would rather use some buggy 16 year old emulator that desyncs easily. Tbh I recall someone making a script to exit 1.4k due to its instability as well.

He released his source. It was public but nobody who downloaded it ever reuploaded it.

It's just a very unlucky that things happen the way they did.


Edit: Also activator codes work, By activator code you mean D0 and D1 They definitely work lol. If you mean the GS button that's a different story.

 

[ownage]

Core 2.2 fixes a lot of glitches for me, however I can't seem to use it for NetPlay because my ROM list gets screwed up.

"Super Smash Bros. (U) [!]" is rendered as "Super Smash Bros. (U)" and therefore it says I don't have the ROM, saying "Super Smash Bros. (U) [!]" is not in my list.

Also when creating a SSB room, the alphabetical grouping is screwed-- there are probably about 6 different S's to choose, all which are a different ROM starting with S rather than the correct behavior of grouping all ROMs that start with S.

Any help? I'd love to switch to Core 2.2 but this is pretty critical when I can't even play on NetPlay.

 

[Madao]

He released his source. It was public but nobody who downloaded it ever reuploaded it.

It's just a very unlucky that things happen the way they did.

Edit: Also activator codes work, By activator code you mean D0 and D1 They definitely work lol. If you mean the GS button that's a different story.

I see what you mean. I never seen anyone else acknowledge that activator codes work in PJ64 1.4k..

Core 2.2 fixes a lot of glitches for me, however I can't seem to use it for NetPlay because my ROM list gets screwed up.

"Super Smash Bros. (U) [!]" is rendered as "Super Smash Bros. (U)" and therefore it says I don't have the ROM, saying "Super Smash Bros. (U) [!]" is not in my list.

Any help? I'd love to switch to Core 2.2 but this is pretty critical when I can't even play on NetPlay.

Dunno what to say. I don't have that issue on my end. You shouldn't bother connecting to people who are using different emulators though, because you will desync if you do.

 

[ownage]

You shouldn't bother connecting to people who are using different emulators though, because you will desync if you do.

This is a good point. Do you ever foresee a new PJ64k being the new standard? I mean, it's been since 2003, and people are still claiming Mupen - though less popular - is superior.

 

[Madao]

This is a good point. Do you ever foresee a new PJ64k being the new standard? I mean, it's been since 2003, and people are still claiming Mupen - though less popular - is superior.

At this point I doubt they will switch to a newer version. I find it ironic people will switch to a newer graphics plugin that happens to be worse than Glide64, but won't upgrade emulators . I don't even care anymore. People can use whatever they want. Mupen, 1964, and PJ64 2.2k are all better than 1.4k. I'd honestly rather even use PJ64 1.7 with AQZ.

 

[Uair]

At this point I doubt they will switch to a newer version. I find it ironic people will switch to a newer graphics plugin that happens to be worse than Glide64, but won't upgrade emulators . I don't even care anymore. People can use whatever they want. Mupen, 1964, and PJ64 2.2k are all better than 1.4k. I'd honestly rather even use PJ64 1.7 with AQZ.

If you're going to complain about this forever why don't you just implement all the features from 1.4k to 2.2k.

 

[Madao]

If you're going to complain about this forever why don't you just implement all the features from 1.4k to 2.2k.

Not even complaining. I was just answering a question.. What is 2.2k missing?? I've invested far more time than I should have, trying to convince people to switch. I should have known better than to try this hard to cater to people I strongly disagreed with in the first place. People nitpick smaller issues instead of the bigger ones, so I do not care anymore.

The only drawback I see, is that dropping games does not work properly. If anyone cared that much about stuff like that, they should be using Mupen because that has the most stable kailera UI.

 

[Uair]

Not even complaining. I was just answering a question.. What is 2.2k missing?? I've invested far more time than I should have, trying to convince people to switch. I should have known better than to try this hard to cater to people I strongly disagreed with in the first place. People nitpick smaller issues instead of the bigger ones, so I do not care anymore.

The only drawback I see, is that dropping games does not work properly. If anyone cared that much about stuff like that, they should be using Mupen because that has the most stable kailera UI.

Off the top of my head there is basic things like ending emulation via X button doesn't work or closes the entire emulator.

No checks for Kaillera being open/closed. also addresses first issue.


There was a ton more major basic functions that are lacking from 2.2k which make PJ64k superior. I honestly cant remember because I haven't use 2.2k much. I see 0 reason to use it over PJ64k/Mupen64k.

 

[Jdbye]

I want this to work, but it crashes almost immediately after opening for me, and nothing I do seems to change that. It doesn't even give me a chance to change any settings. Is anyone else having the same issue?
The old PJ64k works, but the Kaillera option seems to be gone from the main menu, so it's pretty useless.
Mupen64k is the only thing that actually seems to work.