Possible Project64 Port to The Homebrew Channel?

[wildgoosespeeder]

I recently started using The Homebrew Channel (http://www.wiibrew.org/wiki/Homebrew_Channel) for Wii and came across Wii64 (http://www.wiibrew.org/wiki/Wii64). It is a Mupen64 port for The Homebrew Channel. It got me thinking that Project64 should be ported to The Homebrew Channel because it is far superior to Mupen64.

[rswedlow]

Why is Project64 superior?

[wildgoosespeeder]

Compared to the other N64 emulators I've tried, Project64 v1.6 has the least amount of errors when playing games.

[rswedlow]

What errors should I be on the watch for if I decide to use Mupen64?

[Zeth Alkar]

What errors should I be on the watch for if I decide to use Mupen64?

Graphical issues, framerate problems, choppy sound, etc....

I would think it would be a great idea, would prevent a lot of people bricking their wii cause they try doing a .wad install for the VC.

[rswedlow]

Graphical issues, framerate problems, choppy sound, etc....

Though those are all tied to the plug-ins that could be used with it, unless you mean external/emulated frame rate (VI/s).

I'm impressed with the first answer. The default GPU for Mupen64 is Glide64, which is widely supported by more experienced users. I could never get it to work, so I honestly actually don't know that much about it, but I haven't read much about graphics emulation issues with Glide64. Lately Glide64 dev has been fixing a lot that other plug-ins don't support (things like microcode relations or blender tricks going on with Ogre Battle 64).
If this appeals for you someone wrote a list that tested plug-ins.
http://bmgcl.emuxhaven.net/n64mgcl/N64ConfigList.htm

Choppy sound the default sound-processing main plug-in for that is Azimer's, which is HLE as opposed to Jabo's and should have Emulate/Simulate AI compatibility disabled for better sound.

But what I mean is permanent to Mupen64?
What is it that surpasses Project64 so far?

[Squall_Leonhart]

Though those are all tied to the plug-ins that could be used with it, unless you mean external/emulated frame rate (VI/s).

I'm impressed with the first answer. The default GPU for Mupen64 is Glide64, which is widely supported by more experienced users. I could never get it to work, so I honestly actually don't know that much about it, but I haven't read much about graphics emulation issues with Glide64. Lately Glide64 dev has been fixing a lot that other plug-ins don't support (things like microcode relations or blender tricks going on with Ogre Battle 64).
If this appeals for you someone wrote a list that tested plug-ins.
http://bmgcl.emuxhaven.net/n64mgcl/N64ConfigList.htm

Choppy sound the default sound-processing main plug-in for that is Azimer's, which is HLE as opposed to Jabo's and should have Emulate/Simulate AI compatibility disabled for better sound.

But what I mean is permanent to Mupen64?
What is it that surpasses Project64 so far?

your computer should be capable of running glide 64...

exactly what is the problem?

[rswedlow]

If somebody actually tried they could have the reference to be able to relate Mupen64.
For the sake of others, I haven't so used Mupen64. I have used Project64 99% of my leisure play.

Everyone, including zilmar, relied on the fact that Project64 is simply more popular. They don't really know anything about Mupen64; they just see a different interface and then leave to what already makes them happy.
Otherwise after four years I would have gotten a description by now. The best case scenario, answer is a couple games reported by someone else to not work on Mupen64. Statistically, there are more of those in areas with Project64.
Pathetic optimism is one reason this scene is dying. It's nothing new.

your computer should be capable of running glide 64...

exactly what is the problem?

Unfortunately I can't really answer that.

If I need to test I can usually get Glide64 to work.
Actually I should have said through the many systems I've used, something about it was always really sensitive to Glide64.
On my old FX5200 was the worst case when my screen was always black, yet I could tell things were being rendered. The only exception I tested was Zelda OOT or games with flickering issues as I intentionally had set up for, in which where a plug-in flickers the screen to black, Glide64 flickers it to display for me. But generally screen always showed black.
This was after I did a driver update from Microsoft's default drivers, back then where I got a bunch of wrapper failure messages.

Today with my current specs it's just I need to be really careful about the configurations. The new software depth buffer rendering I can get to work and shows objects nicely, but any time I make changes to config while a game is running the screen is never again updated until restart. If I use certain combinations, the screen is always black, once again.
With over half of the games I have tested, Glide64 results in well below full speed (even if the screen is black). These games I could see were full speed back with WinXP and my worse drivers complex.

There's also randomization, e.g. this just in, now I can't get the screen to display no matter what settings I use. :cool: Basically, long ago, I've just given up seriously trying to study with Glide64, because all of my systems have been so sensitive to it, coincidentally I guess.

[Emmett]

Rswedlow,

So are you saying that instead of asking to port pj64 to the wii we should attempt to target plugin developers to port their plugins to the wii? Because deep down we don't know if the base pj64 is any better or worse than mupen, so it's up to the plugins to make everything better?

Sorry if I got it wrong, I'm just trying to summarize what you said.

[emu_kidid]

I've had a look at the PJ64 1.4 source which is publically available and it just wouldn't be possible for the Wii to have PJ64 ported to it. I'm speaking out of experience as I am one of the coders responsible for the port of Mupen64 (aka Wii64) to the Wii. The two main showstoppers for us not porting it are: 1. It requires more memory than the Wii has to offer. 2. There's a lot of x86 code we didn't want to have to sift through.

The reason we chose Mupen64 is that it had a lighter memory footprint than PJ64 which we've been able to even further reduce. Albeit Mupen64 doesn't have certain game specific hacks like PJ64 has (for increased compatibility/speed), it's pretty good in general and we hope to maximize compatibility in the upcoming versions.

[rswedlow]

Mupen64 has also for years been ported between several operating systems and is already more compatible than Project64. I am not thinking about the game-specific investigations mentioned there, but inclusively in main memory, the re-compiler, interpreter, and "pure interpreter" options in Mupen64 offer more than the dynarec or interpreter in Project64.

Emmett,

Porting the plug-ins to the Wii console would mean a complete redesign, although not completely re-conducting engineering research while the target system is constant. The later is a specific factor behind which the developers took priority in their work, but they are not as likely to have interest in redesigning everything else for the Wii console.

The value of pj64 is the same as the value of its plug-ins: Each of those plug-ins are emulators of their own. Project64 emulates main memory, GFX emulates video memory, SND emulates audio memory, input emulates controller interactions, with additional RSP emulation for sound and vector processing. To port the team project that is "Project64", all five of these components must be ported or recreated.

More reliably, someone who is familiar with the Wii console should have access to the source behind those plug-ins that work well with Project64 or those that in the future will after being ported.


Thinking back to before when this thread was active, I see your summary. You are correct that a large portion of Project64's recognition is from the success in its "plugins", beyond which is Project64 the mask disillusionment. This deception is earned well by he who made the current plug-in system, but unfortunately for the coward, popularity is not a device for success.
It is through popularity that the "donations system" has betrayed its foolish creator.
It is through popularity that the human focus upon the channels of progress and knowledge are distracted by one source to learn from the others.
It is through popularity that the source here will emerge from its original fame and swerve through its counterpart, infamy, such that memory does not die, in such a way unfortunate for those who would hide in their selfish lives.

In the case that I have an audience. Do not be afraid to question me.
Your challenge is quite generous. You are a much better learner than zilmar was.