New Project64k Core 2.2

[Madao]

Can you run the program through a debugger to catch the critical error before the BSOD happens? I would but the win10 computer i have access to isn't mine, and i can't install visual studio on it.

I don't have access to a Win10 machine either, unfortunately.

@ Fireblaster - I'm sorry to say that my one test of fullscreen DID DS. But it was odd and froze my computer for like 30 seconds when I tried to go fullscreen, so that may be an atypical example.

You'll have to write code to make sure switching to fullscreen makes everyone pause and sync that. Don't forget that having different options can also cause a desync, so i recommend syncing settings after you get save files synced.

@ Timotheus - yeah sadly this happens in project64 if you turn on the option that makes it sync properly. there is extra overhead. i turn this option off for off-line play. if i don't turn it on for online play, it will not sync random cpu or random stage.... hopefully newer versions of project64 will fix this and make it more efficient.

I will put this in the OP as a core flaw of this emulator.

Actually, it's likely caused by an option called "Sync using audio". Improper audio emulation will cause it to drop below 60, but even the newer Fixed Audio Timing code isn't perfect, and never will be. If FPS is more important to you than reducing crackling (the kind caused by inaccurate Audio Emulation), then Sync using audio should be disabled by default. I only enable it when testing. I usually don't need it for any games I play.

Almost forgot to ask. Are there any issues besides the audio not working after reseting, preventing you from using the latest code base? That audio issue should be taken care of soon .

 

[Timotheus]

That's sad because with the new glide plugin the game looks more like console. For example when a character got hit by an attack the character blinks white for some frames. Also dk and samus look better now when they have a fully charged neutral-b. Pika glows also at it's up-b startup frames like on actual console. All these small things makes the emulation look much better but this is not good with less fps to play with...

 

[Uair]

That's sad because with the new glide plugin the game looks more like console. For example when a character got hit by an attack the character blinks white for some frames. Also dk and samus look better now when they have a fully charged neutral-b. Pika glows also at it's up-b startup frames like on actual console. All these small things makes the emulation look much better but this is not good with less fps to play with...

Do they play the rainbow animations for the Star and Hammer? I think I remember the GLideN64 having this covered but I'm not too sure if the pj64 team ever implemented this into Glide original. I remember the final version ended up also fixing the mario and luigi fireballs getting each others color which was sort of a big glitch for the older Glide64 plugins despite how it emulated Jabo7's invincibility frames and fire damage, and Jabo8's fixed stuff like shields and cursors.

isai once told me the emulation is wrong, because of that. I just assume one of those things like SM64's invisible cap grainy effect that's just hard to get right or something.


Edit: omg they did it

Edit2: Nope it's missing the full color pallet.

 

[Capos]

I forgot to ask before, what stages do you want modified spawn coordinates?

@ C Capos @ O Ownasaurus , you guys mind testing https://www.dropbox.com/s/wdm7idxfk6419bp/Project64 2.0.0.3.exe?dl=0 ? It's an old build for version 2.0.0.3. If this build doesn't trigger a BSOD for you guys, I'll consider taking another look at the commit that triggers it. It's a huge commit and I'm not too good with threading code, but maybe I can figure it out.

The rom didn't open, just got stuck on a black screen, but no BSOD.

Can you run the program through a debugger to catch the critical error before the BSOD happens? I would but the win10 computer i have access to isn't mine, and i can't install visual studio on it.

If you want me to test anything, just give me step by step instructions.

if can figure out code syncing, ill push this hard on server as soon as available or jan 1 (begin kicking people to force switch)

If this is the route we're going, is there any reason not to switch to mupen or whatever is best now? I think the main reason everyone is using the old pj64 is that everyone else is, so you need to stay on it to be able to play others. If we can force a switch, why not go with whatever you think is best from the start?

 

[Uair]

If this is the route we're going, is there any reason not to switch to mupen or whatever is best now? I think the main reason everyone is using the old pj64 is that everyone else is, so you need to stay on it to be able to play others. If we can force a switch, why not go with whatever you think is best from the start?

The main reason is because after we had everyone on the Mupen64K band wagon Mupen64++ got released with bugs and a lot of people had issues figuring out what to do so everyone started using PJ64k again. But the latest mupen64++ that was released which also was then open source and became Mupenplus, worked just fine and is the best emulator atm for kaillera.

Plus cheats, unlike what knitephox may believe, Mupen64++ has built in cheats for SSB64 specifically, and every other game uses the Host's save files. Although despite this making everything simpler and easier, people still use PJ64k because everyone else did as you said. But, besides that there is no reason not to be using Mupen64++.

Hopefully pj64k 2.2 can be everything in a nutshell.

 

[KnitePhox]

If this is the route we're going, is there any reason not to switch to mupen or whatever is best now? I think the main reason everyone is using the old pj64 is that everyone else is, so you need to stay on it to be able to play others. If we can force a switch, why not go with whatever you think is best from the start?

the reason is because you can't use custom cheats; as that is the entire point of cheats (IMO) in the first place

people's ability to have many more enjoyable experiences with games that they like is greatly increased by having an emulator that supports cheat use. some of us choose to use cheat codes to expand the game in whichever way we like that is available, beyond the simple vanilla type of "unlock everything" codes.

if i am going to push any emulator to users on the server i pay for as to "replace" the current widely used version, such a new emulator has to be better than (or at least as good as) the current one in each reasonable way(plugin support, cheats, kaillera, p2p, etc.) .

Plus cheats, unlike what knitephox may believe, Mupen64++ has built in cheats for SSB64 specifically, and every other game uses the Host's save files. Although despite this making everything simpler and easier, people still use PJ64k because everyone else did as you said. But, besides that there is no reason not to be using Mupen64++.

HAHAHA.

 

[THE_MAAFIA]

Some one put this in the smash index, would be really helpful!

 

[Madao]

@ O Ownasaurus The audio bug has been fixed . Are there any other issues preventing you from using the latest code base? If there are, I could take a look.

The rom didn't open, just got stuck on a black screen, but no BSOD.

Ok thanks. That's probably enough for me to at least take another look. It may be difficult for me to figure it out, but I'll probably give it another shot.

 

[caneut]

@ Madao @ O Ownasaurus @Agent 21 iXi and other people who are unimportant for me to remember

http://emulation-general.wikia.com/wiki/CEN64

thought u might be interested if you havent heard of it before.

 

[malva00]

I remember the good old days when I was trying to convert people to MUPEN.

 

[P D]

I remember the good old days when I was trying to convert people to MUPEN.

mupen sux unless you're playin mario party 2

 

[Morin0]

Can we get Dolphin's netplay system integrated here? (I just read that it's open-source.) I think it's vastly superior to what we have now.

 

[Madao]

Can we get Dolphin's netplay system integrated here? (I just read that it's open-source.) I think it's vastly superior to what we have now.

What's better about Dolphin's netplay system?

 

[nickthename]

What's better about Dolphin's netplay system?

Their P2P uses NAT traversal and gives out connect IDs, which means players don't need to port forward or share their IP.

It would be even nicer to have GGPO's rollback based netplay, but the emulator project with that uses MAME/MESS, which has pretty crappy 64 emulation.

 

[firo]

A new netplay system for 64 is in the works. It will require some patience but hopefully it'll be worth it.

Is GGPO's rollback supported for any game that has analog input? I've given this some thought in the past and I don't think it would work for a game like smash. There's also the question of whether players want rollbacks rather than guaranteed inputs.

 

[nickthename]

A new netplay system for 64 is in the works. It will require some patience but hopefully it'll be worth it.

Looking forward to it.

Is GGPO's rollback supported for any game that has analog input? I've given this some thought in the past and I don't think it would work for a game like smash. There's also the question of whether players want rollbacks rather than guaranteed inputs.

I don't know, really depends on whether people like the feel or not. Unfortunately, that's hard to test without a prototype. It'd definitely possible that rollback based netplay wouldn't work for smash at all, but I don't know enough about the theory to say. It feels great in traditional fighters though, and considering how much people complain about input delay as it is, might be worth looking into.

I don't know how difficult it would be to transplant GGPO to a 64 emulator that wasn't written for it. Needs good savestate support, to start.

 

[Fireblaster]

This emulator is a broken mess in its current state. Using a windows 10 computer with a GTX 970 and two different plugins, the default jabo one and the new glide plugin that was crowd funded and works perfectly with pj64k 0.13 (http://gliden64.blogspot.ru/2015/05/public-release-1-update-1.html):

GLIDE

• Launches and runs just fine offline with automatic fullscreen enabled. With vsync forced off through nvidia control panel, this is the most input-lagless the game has ever felt playing it offline on an emulator.
• Literally crashes and BSOD's my computer in any other way. Offline windowed, Kaillera fullscreen, kaillera windowed.

JABO

• Doesn't crash. Graphics are the most broken I've ever seen them on emulation. Fullscreen is seizure inducing and playing on kaillera forces 58 FPS which is awful. DWM issue is super apparent here because when the emulator constantly runs at 58 FPS, it looks like it's barely reaching 30 FPS.

It's unplayable at this point. Once again I'd like to emphasize that there is a very real framerate issue that will plague anyone using windows 8 and up from this point on (or anyone using aero on 7/Vista). DWM (Desktop Windows Management) is enabled when aero is on and it's FORCED on no matter what on windows 8/10. DWM forces vsync on any windowed application. I won't go too much into details of how vsync works but for non PC savy people, vsync forces the graphics card to only send frames to the monitor at a maximum of 60 FPS. It does this by forcing the graphics card to wait every 16.6666 ms to send the next frame to the monitor (This also causes input lag). This is not a problem if a game is rendering at a framerate higher than 60 fps. However, if a game is rendering at a framerate lower than 60 fps, it means that each frame takes longer than 16.666 ms to render. This means that every other frame the game will take too long to render a frame and has to wait for the NEXT 16.666 ms cycle for vsync to update the monitor. This will happen every other frame and only half the frames will get displayed. The result is that a game that isn't above 60 fps with vsync will drop down to 30 fps instantly or lower.

SSB64 is a 60 FPS game so theoretically it should run perfectly fine with vsync. However, due to tiny miscalculations in frame rendering and emulation, pj64k cannot constantly render ssb64 at a perfect 60 fps so it must eventually drop below 60 (even if by a fraction of a frame), which causes pj64k to display ssb64 in 30 fps in bursts. This is why playing with PJ64 2.2 on kaillera makes this really obvious, since running at 58 FPS with DWM will literally make the game display at around 30 fps constantly. Many people who play online with DWM do not notice these 30 fps bursts for whatever reasons, though I think one of these reasons is that when they see something odd with the game visually it's easier to blame it on online lag instead of identifying it as a very specific vsync issue, which is something that only dedicated PC gamers would know about and most ssb64 players are not PC gamers. Either way, these 30 fps bursts really disrupt the gameplay, not to mention that it adds input lag and overall makes the game feel different.

This problem has already been addressed by the online melee/brawl/P:M scene. Dolphin's most recent netplay build update included an exclusive fullscreen feature. When a game runs in fullscreen on windows, it skips DWM and can therefore turn vsync off, meaning that it runs with the least amount of input lag possible and zero framerate issues from windows. Obviously this is not possible with pj64k 0.13 since going into fullscreen desyncs the game. As you read above, 2.2 is not a stable alternative to 0.13. The other day I was able to play with nickthename for over an hour in fullscreen using Mupen64++ Beta 0.1.3.12. There were zero desyncs and zero framerate issues caused by windows or the emulator. Knitephox doesn't want to force his server to switch to mupen because of gameshark codes, aka playing in kirby beta 2 once in a blue moon is more important than people being able to play properly on any OS. I tried asking several people why they don't want to switch to another emulator and they responded with "We don't gain anything from switching". Sure, I guess laziness definitely an important factor towards keeping pj64k 0.13 and we should just tell any new/incoming player to downgrade to a 6+ year old windows operating system if they want good emulation.

TL;DR - SSB64 online is getting outdated and unplayable unless this community stops being stupid and switches to an emulator that wasn't made more than 10 years ago. I refuse to play on PJ64k 0.13 anymore

 

[Madao]

I can say from experience that Project 64 2.2 is probably the best overall N64 emulator. It has the best game compatibility, supports the best plugins, good performance, good audio support, open source, etc.

As of today, the BSOD issue has reportedly been solved . O Ownasaurus should update his code base now.

On my machine, GlideN64 is completely broken, so it's definitely not universally good for everyone. I'm better off using Jabo's D3D, Glide64 Final, or even 1964 Video. Good thing there's several decent options for graphics plugins, although it's unfortunate that Windows 10 has some problems with these plugins.

 

[Wieners]

This version of PJ64k does ****ed up things to my rom. Don't have any of these problems on 1.4. Someone save me.

 

[Uair]

This version of PJ64k does ****ed up things to my rom. Don't have any of these problems on 1.4. Someone save me.

Change graphic dlls or restore the default settings? Jabo 1.6.1 would be ideal for this but theres no point in using this emulator over Mupen64++ besides gs codes.

 

[Madao]

Jabo 1.7.0.56 is actually the best version of Jabo's for SSB. If ownasaurus never comes back anytime soon, I could port his code to the last code. That way, BSOD would be fixed, along with improved audio and other improvements.

 

[Uair]

Jabo 1.7.0.56 is actually the best version of Jabo's for SSB. If ownasaurus never comes back anytime soon, I could port his code to the last code. That way, BSOD would be fixed, along with improved audio and other improvements.

1.7 plugins are extremely more demanding than 1.6 plugins. Thus why I mentioned using 1.6.1

 

[Rey_del_Copo]

If ownasaurus never comes back anytime soon, I could port his code to the last code. That way, BSOD would be fixed, along with improved audio and other improvements.

It depends, if you're going to port the Kaillera code to the current version of the emulator I would say that don't bother yourself, it's time wasted. The emulator requires some fixes such as the FPS limit when it's on netplay mode.

Otherwise, if you're interested in take over the project I would say that go ahead. I'd recommend to create a account on GitHub, create a branch and keep the emulator updated every certain time (for example, merge a new build every 2 or 3 months).

With luck, if we get a stable build based on the latest version of the emulator the people will start to switching from the old version of 2003 to the new version.

 

[Uair]

It depends, if you're going to port the Kaillera code to the current version of the emulator I would say that don't bother yourself, it's time wasted. The emulator requires some fixes such as the FPS limit when it's on netplay mode.

Otherwise, if you're interested in take over the project I would say that go ahead. I'd recommend to create a account on GitHub, create a branch and keep the emulator updated every certain time (for example, merge a new build every 2 or 3 months).

With luck, if we get a stable build based on the latest version of the emulator the people will start to switching from the old version of 2003 to the new version.

There is too much work to be done to make it as good or better than PJ64k let alone Mupen64++. I've already tried, I doubt anyone else has more motivation than me let alone the ability to do anything with the emulator. Better off inventing a new netplay client all together like AQZ rather than focus on kaillera emulation.

 

[Rey_del_Copo]

There is too much work to be done to make it as good or better than PJ64k let alone Mupen64++. I've already tried, I doubt anyone else has more motivation than me let alone the ability to do anything with the emulator. Better off inventing a new netplay client all together like AQZ rather than focus on kaillera emulation.

I agree with you, we need something like Kaillera (easy to implement in any emulator) but open-source.

These were the features expected to see in the Open Kaillera project:

* Basic abilities
o Ability to play games
o Ability to connect to each other by ip address/port
o Supporting 3+ players

* Feature to prevent inputs from being ignored at times of lag
* better matchmaking system requirements
o look for people with ping < XX and auto-challenge
o udp for matchmaking communication - sctp
o central server anyone can host
o One-port server
o ggpo/2df style
o NAT punchthrough helper for clients
* Must include "ad-hoc" mode so it can be more easily ported to wl devices such as PSP
* interfaces
o Interface for delay masking with game states
o Kaillera interface backward compatibility

Source: https://svn.code.sf.net/p/okai/code/trunk/docs/features-informal.txt

The problem is that even if you make all those improvements to the current Kaillera client and you don't depend of servers to play, do you still need to use the kaillera netcode to make it working (and officially is closed source software), so the developers refuses to add something like that on their emulators.

---

In overview, we need a centralized place where all the people can host their games.

- Ad-hoc network support (so emulators that uses this system can work: PSP, etc.)
- GUI with a chat/lobby feature (kinda like the FightCade platform, maybe sort the categories by consoles)
- P2P for more than 2 players
- Other features such as the ability of recording games (like the current Kaillera client does) and more...

But again, who's the person that have knowledge about the C++ programming language and is interested in start a project like this? It seems like nowadays nobody is interested in netplay.

 

[Madao]

1.7 plugins are extremely more demanding than 1.6 plugins. Thus why I mentioned using 1.6.1

Anyone who can't run Jabo D3D8 1.7.0.56 at constant full speed is better off using Rice Video then.

It depends, if you're going to port the Kaillera code to the current version of the emulator I would say that don't bother yourself, it's time wasted. The emulator requires some fixes such as the FPS limit when it's on netplay mode.

I only think it would be a waste of time if nobody uses it. Ownasaurus already did the work, so all I have to do is port it. Only reason I haven't done it is because there's no demand for it. People insist on using a desync prone emulator, for reasons I do not fully understand. Surely not everyone uses gameshark codes that need to be turned on and off mid-game.

Not sure what you are talking about, because I can't imagine Project64 1.4 having a better implementation for FPS limit.

Otherwise, if you're interested in take over the project I would say that go ahead. I'd recommend to create a account on GitHub, create a branch and keep the emulator updated every certain time (for example, merge a new build every 2 or 3 months).

With luck, if we get a stable build based on the latest version of the emulator the people will start to switching from the old version of 2003 to the new version.

The only real issue right now is that there's a massive amount of refactoring going on, so there's some regressions. Assuming I ever port the kailera code, I can either wait until it's stable, or use an older version and cherry pick important improvements.

Not sure if I will bother, since no one seems interested in using a newer version of Project64.

There is too much work to be done to make it as good or better than PJ64k let alone Mupen64++. I've already tried, I doubt anyone else has more motivation than me let alone the ability to do anything with the emulator. Better off inventing a new netplay client all together like AQZ rather than focus on kaillera emulation.

What's good about Mupen64++, aside from less desync and save syncing?

 

[Rey_del_Copo]

I only think it would be a waste of time if nobody uses it. Ownasaurus already did the work, so all I have to do is port it. Only reason I haven't done it is because there's no demand for it. People insist on using a desync prone emulator, for reasons I do not fully understand. Surely not everyone uses gameshark codes that need to be turned on and off mid-game.

Not sure what you are talking about, because I can't imagine Project64 1.4 having a better implementation for FPS limit.

Regarding to the FPS limit, I was referring to the current build of Project64k Core 2.2.

About the fact that almost nobody uses this version it can be due to certain things:

1. People doesn't know about this new build (I can talk for myself and say that when I discovered this new version it was thanks to a website about emulation).
2. It can be because it's kinda unstable (as I mentioned, the FPS limit doesn't work well when the emulator it's in netplay mode).
3. People is too lazy to change or upgrade their emulator. "Because if something works, why change?" (I mean people that mostly only plays Mario Kart 64 and/or Super Smash Bros).

The first point have a "easy" solution, like for example, announce the emulator in the description of the Kaillera servers.

The only real issue right now is that there's a massive amount of refactoring going on, so there's some regressions. Assuming I ever port the kailera code, I can either wait until it's stable, or use an older version and cherry pick important improvements.

You're right, it seems like lately they're changing a lot of internal things in the core of the emulator.

But this is like everything, I don't think there will be a "stable" version soon, there's always room for improvement.

 

[Uair]

Anyone who can't run Jabo D3D8 1.7.0.56 at constant full speed is better off using Rice Video then.

What's good about Mupen64++, aside from less desync and save syncing?

Jabo 1.7 builds are much more demanding than previous 1.6 builds, why would someone use a much inferior plugin like Rice because their computer can't handle Jabo's unoptimized plugins? Need I remind you Jabo plugins have lost support from their original owner and all zilmar did was make additional edits jabo's last release was using his original build for 1.6 with basic common fixes for things like Mario kart 64 stages with the bigscreen character cam. My laptop which was an Athylon apu could not run Jabo 1.7 at 100% speed due to it's poor optimization. Even Glide64 Finale version ran better than Jabo 1.7.

And Mupen64++ can actually play more games than sm64 rom hacks, ssb64 and mk64. That's the main reason why people use it. Not to mention it uses a lot less bandwidth and it's a better core emulator than Project64 1.4. Plus you can configure your input while emulating over kaillera, and you can even change the settings while on kaillera. and The most recent broken version of mupen64++ had a non-functioning gameshark support feature that was never finished, so everyone went back to the beta version.

Mupen64++ could of been "that" emulator but sadly the developer was literally incompetent and didn't save his previous work then said **** it.

 

[nickthename]

I only think it would be a waste of time if nobody uses it. Ownasaurus already did the work, so all I have to do is port it. Only reason I haven't done it is because there's no demand for it. People insist on using a desync prone emulator, for reasons I do not fully understand. Surely not everyone uses gameshark codes that need to be turned on and off mid-game.

We'd love a better emulator, but it can't be locked at 58 FPS on netplay, that's unusable.

 

[Madao]

Jabo 1.7 builds are much more demanding than previous 1.6 builds, why would someone use a much inferior plugin like Rice because their computer can't handle Jabo's unoptimized plugins? Need I remind you Jabo plugins have lost support from their original owner and all zilmar did was make additional edits jabo's last release was using his original build for 1.6 with basic common fixes for things like Mario kart 64 stages with the bigscreen character cam. My laptop which was an Athylon apu could not run Jabo 1.7 at 100% speed due to it's poor optimization. Even Glide64 Finale version ran better than Jabo 1.7.

Jabo 1.7 has some legit improvements. It emulates more effects than 1.6. That's why I like Jabo 1.7.0.56. It shows things like invincibility and team colors. I know Glide64 also shows these things but on my computer, Jabo's is significantly faster. I know Jabo 1.6 is faster, but it's less accurate for SSB. Rice does certain effects better while worse at others, so I wouldn't call it totally inferior to Jabo 1.6, especially since it's much faster.

And Mupen64++ can actually play more games than sm64 rom hacks, ssb64 and mk64. That's the main reason why people use it. Not to mention it uses a lot less bandwidth and it's a better core emulator than Project64 1.4.

I wonder why PJ64 1.4 would use more bandwidth. Sounds odd to me, but I never bothered to check.

We'd love a better emulator, but it can't be locked at 58 FPS on netplay, that's unusable.

As I said before, it's probably due to the option called "Sync using audio". Try disabling it and see if it still has that problem. The audio may be bad, but the newer version of PJ64 has improved Fixed Audio Timing (although it's still not perfect for SSB). All someone has to do is pick the right version to use as a base and port the kailera code. Assuming Ownasaurus fixed the full screen issue, I'm guessing the only thing missing is save syncing and setting sync (so that it can prevent desync caused by using different settings).

 

[Uair]

Jabo 1.7 has some legit improvements. It emulates more effects than 1.6. That's why I like Jabo 1.7.0.56. It shows things like invincibility and team colors. I know Glide64 also shows these things but on my computer, Jabo's is significantly faster. I know Jabo 1.6 is faster, but it's less accurate for SSB. Rice does certain effects better while worse at others, so I wouldn't call it totally inferior to Jabo 1.6, especially since it's much faster.

I wonder why PJ64 1.4 would use more bandwidth. Sounds odd to me, but I never bothered to check.

Jabo 1.7 is bad edits of 1.6 with rice features and tons of game specific changes. Even if given a situation where Glide64 for PJ64 performance is worst than Jabo 1.7 (not considering texture options), the emulation speed and loading times will be heavily effected by using Jabo 1.7 rather than Glide64. And what's even more is GLideN64 which is even FASTER than Jabo 1.7 and Glide64 combined. It's obviously the most resource heavy but it's the fastest emulation wise.

This isn't to imply Glide64 is always more demanding for the computer than Jabo 1.7 because there is texture optimization options which make it run much faster than jabo 1.7 without any lack of graphics. Jabo 1.7 has a poor texture dumping/loading method, poor base algorithms, and it's just a bad plugin in general. But none of that matters when it comes to playing online what matters is having accurate emulation and full speed, in which case Glide64 will always be superior than Jabo 1.7. But both plugins will impact performance worst over kaillera than they normally would offline considering how 2.2 syncs over kaillera.

And Pj64 1.4 isn't the reason why it uses more bandwidth it uses more bandwidth because it's doing a **** ton of extra work like applying gameshark data, rom compression data, and just so many features involved in PJ64k by Hotquik in 2003 that it's hard to imagine there ever being another better emulator aside from Mupen64++ which in every regard is superior.

 

[Deleted member]

is this more stable now? i always found it kind of janky, compared to 2.2.

 

[Rey_del_Copo]

is this more stable now? i always found it kind of janky, compared to 2.2.

No, sadly the emulator didn't received any improvement since then.

 

[Deleted member]

No, sadly the emulator didn't received any improvement since then.

ownasaurus was working on it right?

 

[Madao]

When I had tested on Kaillera, I had hosted and started the game by myself and still received a max of 58fps. I don't think the disable audio sync effects Kaillera games at all.

And yes I'm talking about the ds that happens when you full screen on netplay. Seems that emulation on the full screener's end pauses briefly while nobody else does, causing the ds.

However, I do recall the thread mentions the 58fps lock was put in place to avoid ds, so I'm not sure if just removing it will make the emulator playable. Either way, if it desyncs less than pj64k and still has the full screen fix, it'll already be miles better.

Might as well continue the conversation here.

I just finished changing some code. Here's a link to the exe. I guess fullscreen isn't fixed, based on previous comments. Try it out and let me know if the 58fps issue is gone at least. The BSOD issue should also be fixed.

 

[Uair]

Might as well continue the conversation here.

I just finished changing some code. Here's a link to the exe. I guess fullscreen isn't fixed, based on previous comments. Try it out and let me know if the 58fps issue is gone at least. The BSOD issue should also be fixed.

Are you working on it now? It'd be nice to see it continued.

 

[nickthename]

Can't play netplay at the moment to test it, but if this really fixes the 58fps issue that would be awesome.

 

[Zantetsu]

Might as well continue the conversation here.

I just finished changing some code. Here's a link to the exe. I guess fullscreen isn't fixed, based on previous comments. Try it out and let me know if the 58fps issue is gone at least. The BSOD issue should also be fixed.

Okay, I'm home for a couple of days before I hit the road again. I tried this out, the 58fps issue is still there. Can't test BSOD since I'm on Windows 7 and I never had the problem to begin with.

 

[Madao]

Are you working on it now? It'd be nice to see it continued.

I'm not really going to dedicate much time, seeing as there's not much interest in it. I can do a few small patches when needed.

Okay, I'm home for a couple of days before I hit the road again. I tried this out, the 58fps issue is still there. Can't test BSOD since I'm on Windows 7 and I never had the problem to begin with.

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.

 

[Uair]

I'm not really going to dedicate much time, seeing as there's not much interest in it. I can do a few small patches when needed.

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.

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.