What would you like to see done with Project64

[zilmar]

with Project64 being on Patreon (http://www.patreon.com/Project64). I thought I would give the user a bit more control over what I am working on in Project64.

I will describe all the items in the poll below, if you have any questions or thoughts you can add them to this thread:

The poll to select what you want:
http://www.strawpoll.me/13731585

Wiki Website:
Building/styling a wiki website for project64 to hold all the document, this includes trying to make sure most things are well documented.
Needed for: To have one central place for documentation that I and other people can add to as there is no good places for documentation for Project64 at the moment.

Forum Upgrades:
The forum works mostly, but there is some upgrades that are needed, like new captcha, new template, general bug fixes (avatar upload)
Needed for: General improve the discussion forum, work better on mobile devices

Test roms:
Peter lemon has already created some great test roms and it would be to add/change these.
Needed for: To better test and make sure the functionality is the same in the emulator as on real hardware.

Improve Cycle accuracy.
While timing works in general, it is not very accurate. It is basically going on average an OP takes this amount of time, so set the time each op takes to be the average (counter factor setting). While the average might be true that does not mean that block of code actually takes that time. It would need test roms to validate things took the same amount of time. Most likely having to look at cache for timing of cache misses, etc.

Need for: Getting emulation more accurate

Add netplay:
Look at code to allow native netplay so you can link multiple devices together to play. Something I wanted for a long time but never gave it the priority to actually get it done. Lots of the code/infrastructure was build with net play and making sure things could stay synced inside.

Needed for: To be able to multiplay on multiple devices at the same time

Low Level emulation:
There is AngryLion’s RDP plugin that has near perfect LLE emulation in software. It would be good to get a version of code that could work like this plugin inside Project64 Video. I would like to see a version of LLE that can be run in software and have very similar compatibility with AngryLions code and a hardware based LLE implementation. There is already a hardware based version implemented based on ziggy’s Z64, it just does not have very good results. While the software version should be able to produce nearly pixel perfect results. The hardware should be a lot faster and be able to scale resolutions better.

Needed for: to have a good implementation of LLE in the video plugin

Improve Project64-video:
Been busy working on removing all reference to glide/voodoo. There is a lot more to be done in making the code more accurate and cleaner. The aim is to make this the default plugin in 2.4 and going forward where it is more accurate and better than jabo’s plugin in all ways. Having a good hardware based LLE implementation should be comparable to HLE and a good refrence to improve things.

Needed for: Having a better default video plugin

making android recompiler faster:
One of the complaints about android is it is not fast enough. It does have an arm recompiler in it, but more work can be done to profile and make the slower code faster. Not all ops are well optimized.
Needed for: Faster android emulation

Refactor/Clean up RSP:
The main code based has been well cleaned up, but the RSP code barely been touched. Things like having the interpreter running at the same time as the recompiler to verify they are the same is not really possible. It could be made to be faster as well. It was not fully optimized doing LLE video emulation. At the time of writing it was just used for audio emulation so it was optimized for that. It is just running on windows, not portable.

Needed for: Have a more maintainable and improved RSP, that could also be ported to other platforms.

Create a basic open source audio plugin:
This is creating a new open source audio plugin, there is an audio plugin for android that can be used as the base. This is to replace Jabo’s Audio plugin, so that the emulator is 100% open source. There is also the possibility to use Azimer plugin or using elements in the basic audio plugin, so it is a simple good working cross platform plugin.

Need for: To have a 100% open source emulator

64bit version:
This is a feature that gets requested a lot. The RSP would need to be refactored, new audio plugin. The core it self will run in 64bit at the moment with the interpreter. So this task is mostly getting a working 64bit recompiler.

Need for: To get project64 faster

New UI for GlideN64
I will not add GlideN64 with its currently level of difficulty in building and the amount of bloat in it. This is mostly due to the config UI. With re-writing the settings UI that is just used for project64 I could look at least including it in the install package.

Need for: To be able to add GlideN64 in to the Project64 package/installer

Enhancement Build
Work has been done in finding lots of cheat code to improve games, like including the frame rate. There is also overclock functionality been added to project64. To use any of this at the moment it is manual effect. This task is about collecting all the cheats into one location that can be turned on by default as well as default overclock value.

Need for: To have golden eye 60 fps on a default install

[HatCat]

Voted for:
Test roms:, Improve Cycle accuracy., Add netplay:, 64bit version:

Fun things to do, that I didn't see as strategic enough priorities to actually vote for them:
Refactor/Clean up RSP:, making android recompiler faster:

The rest I did not really comprehend any reasons for wanting to vote for them.

Originally Posted by zilmar

Low Level emulation:
There is AngryLion's RDP plugin that has near perfect LLE emulation in software. It would be good to get a version of code that could work like this plugin inside Project64 Video. I would like to see a version of LLE that can be run in software and have very similar compatibility with AngryLions code and a hardware based LLE implementation. There is already a hardware based version implemented based on ziggy's Z64, it just does not have very good results. While the software version should be able to produce nearly pixel perfect results. The hardware should be a lot faster and be able to scale resolutions better.

Needed for: to have a good implementation of LLE in the video plugin

You've mentioned this before and I still have no idea what you're really talking about.

If angrylion's RDP does the LLE in software and z64gl/GlideN64/"PJ64Video" do the LLE in hardware then I don't really see what's missing or being requested here.

Maybe you're saying PJ64 Glide doesn't have LLE. If it doesn't then what's the point of having a software LLE implementation as accurate as angrylion's inside of PJ64 Glide64 when the two code bases are entirely inverted? If you were saying make a LLE version somehow based off PJ64 Glide's HLE code, that would make more sense. But just taking something as accurate as angrylion's RDP and putting that in for the LLE mode of PJ64 Video is just putting 2 DLLs in 1...the purpose of an LLE implementation of PJ64 Video should be to have something similar enough to the HLE one to the point where it is at least the same plugin in both cases, if anything so the HLE can be debugged using the LLE.

[zilmar]

Originally Posted by HatCat

Voted for:

You've mentioned this before and I still have no idea what you're really talking about.

If angrylion's RDP does the LLE in software and z64gl/GlideN64/"PJ64Video" do the LLE in hardware then I don't really see what's missing or being requested here.

Maybe you're saying PJ64 Glide doesn't have LLE. If it doesn't then what's the point of having a software LLE implementation as accurate as angrylion's inside of PJ64 Glide64 when the two code bases are entirely inverted? If you were saying make a LLE version somehow based off PJ64 Glide's HLE code, that would make more sense. But just taking something as accurate as angrylion's RDP and putting that in for the LLE mode of PJ64 Video is just putting 2 DLLs in 1...the purpose of an LLE implementation of PJ64 Video should be to have something similar enough to the HLE one to the point where it is at least the same plugin in both cases, if anything so the HLE can be debugged using the LLE.

Project64 video has a version of LLE processing based on z64. It does not work very well.

I am talking about two versions of LLE processing, one using hardware and one using software. The software version should be similar to angry lions version and write to the rdram. The hardware version should use OGL and be more similar to the current LLE implementation/hle version.

[HatCat]

To be pedantic (but in order to be specific), z64 is the software renderer from MAME (ported to plugin specs by ziggy) and z64gl is ziggy's OpenGL version of it.

I do like the idea of having a software-rendering LLE plugin with an option to use client-side hardware rendering (defined by the OpenGL driver) to switch between software and accelerated graphical rendering mode.

I even like the idea of that same plugin having HLE added to it. With LLE you can choose to use the hardware-accelerated client-side rendering rules over per-pixel-forced software rendering (default for accuracy) while with HLE it is just for speed, so in HLE it is the 3-D OpenGL renderer always, which is based on the implementation details of the LLE version's accuracy.

But what you're proposing sounds like the same thing going from the opposite direction. A good HLE graphical renderer should be based on the details of an LLE accurate renderer, not the other way around. So unless you can somehow convert the HLE in PJGlide64 to an LLE version for users of LLE (with some of the same flaws inherent within the HLE design's information), it sounds like the only thing you can do is use another LLE codebase entirely such as angrylion's. Again, putting 2 DLLs into one unnecessarily.

[Melchior]

Voted for:

• Wiki website
• Forum Upgrades
• Improve cycle accuracy
• Improve Project64-video
• Refactor/Clean up RSP
• 64bit version <-- My favorite
• Enhancement Build

[zilmar]

now it might not right off but the hardware lle should then feed in to the HLE.

it should be in theory able to be interchangeable with hle. The aim is basically create a back bone the hle can merge on to remove hacks and get a more accurate hle code base.

[HatCat]

What debugging can be done with the HLE using an angrylion-like LLE implementation that can't be done with the two plugins separate, that can only be done with them fused into one plugin? It's not like synchronise cores or anything where the RSP interpreter and re-compiler ideally should go into one plugin (and are based on the same template).

Now to be hypothetical, if it turned out that Glide64 was discovered to be based on some LLE codebase Gonetz never told anyone about that he used to create the HLE Glide64, then I would want to throw that in to the LLE side of the same HLE PJ64 Video plugin. Because then you have two modes of the same plugin...as you fix inaccuracies with the LLE Glide64 base using angrylion's LLE you can mirror those fixes to the HLE one. But just using angrylion's as the LLE side to PJ64 Video and PJ64 Video as the HLE side to PJ64 Video seems like 2 plugins in 1, where any debugging about inaccuracies could be done with them separate.

[zilmar]

Originally Posted by HatCat

But just using angrylion's as the LLE side to PJ64 Video and PJ64 Video as the HLE side to PJ64 Video seems like 2 plugins in 1.

I am not going to be directly using angrylion code. I want to build a LLE version from scratch making reference to everything to make sure it is accurate. Using the tests from peter lemon, to add functionality slowly and accurately. Now I need to add a software version that writes to the n64 memory to try and be pixel perfect as well as accurate to the real n64 using rdram. This mode should be similar and have the same level of compatibility as angry lions code. There should also be a hardware version developed at the same time that should work similar to the software one but more comparable/compatibile with HLE.

Once I have a LLE hardware render that is comparable to the software one I can take individual tasks from hle and emulate it using the lle hardware render and the rsp code. If all the tasks use RSP/LLE render as HLE, then it should be the same as LLE with RSP plugin. Once that version is working I can switch each task/command individually with the HLE implementation and it should still work.

[SuperTurboTurkeyStuffer]

I know I'm prone to hyperbole and looking at the glass as half empty, but here's my thoughts.

Wiki Website: This is a good idea insomuch that PJ64 and N64 emulation in general really needs more documentation of discoveries and gathered data. Having game compatibility on said wiki is... not such a great idea. Because if you'll forgive my bluntless it will be hundreds of pages of:

Problem: Game shits itself in some way.

Solution: Use GLideN64 or Angrylion's.

Test roms: This is a really, really good idea.

Improve Cycle accuracy: Also a really good idea, and one that would allow certain hacks to be removed, and for general game behavior to be much closer to the console. I don't think stuff like Rayman 2 will ever behave correctly until cycle timing is better.


Add netplay: I am curious about the issue of random number generation and netplay. Firstly, PJ64's RNG needs fixing. Secondly, is it actually possible to have working RNG while also having working netplay? That seems like something that might require quite a bit of thought. I don't think the existing methods of netplay are good enough. You need a tighter, core-level sync.

Improve Project64-video: Your refactor work has been quite good. But I'm sceptical about the realism of making PJ64-Video more accurate. As an example, how are you going to fix mipmapping? I'm not being condescending here. One of the reasons why GLideN64 uses GL3.3 as a baseline is because PC GPUs can't natively mimic N64 mipmapping. It has to be done in shaders. PJ64-Video's method is inherently flawed, and that's why Turok/Conker/PD/and some other games are broken. Improving PJ64-Video isn't necessarily a bad idea, but it's an incredibly ambitious task that doesn't really have a clear route. Still, if you're confident you can get the job done, then I defer to your judgement.

Create a basic open source audio plugin: This is a good idea, but the bigger problem is that Jabo's is broken and it needs replacing ASAP.

New UI for GlideN64: It is a pity Gonetz used QT because it has caused a lot of headaches. The Zilmar version is a nightmare to build.

Enhancement Build: Way I see it, you should split the cheat menu into two sections. One section is for stuff like 60fps hacks, the other for cheats. Bear in mind you're really not going to see that many 60fps hacks that aren't unstable and therefore not recommendable.

I would also like to point out that PJ64 would greatly benefit from an extension to the plugin spec where a plugin like GLideN64 can inform PJ64 that it is running in forced widescreen mode. Then PJ64 consults a database of widescreen hacks and applies them if suitable. This is mainly scissoring/culling hacks that are written as standard cheats.

[zilmar]

Originally Posted by SuperTurboTurkeyStuffer

Add netplay: I am curious about the issue of random number generation and netplay. Firstly, PJ64's RNG needs fixing. Secondly, is it actually possible to have working RNG while also having working netplay? That seems like something that might require quite a bit of thought. I don't think the existing methods of netplay are good enough. You need a tighter, core-level sync.

The only problem I know about PJ64's RNG issue is that things do not seem random. Unless there is some other issue that I am not aware of. I did a lot of work before on making the core perform consistently the same. This is why the sync core works, the interpreter and recompiler can run at the same time and stay in perfect sync. The isses with the RNG not seeming random is that the core is very consistent in how it works so it keep producing the same result.

Staying in sync should be doable.

Originally Posted by SuperTurboTurkeyStuffer

Improve Project64-video: Your refactor work has been quite good. But I'm sceptical about the realism of making PJ64-Video more accurate. As an example, how are you going to fix mipmapping? I'm not being condescending here. One of the reasons why GLideN64 uses GL3.3 as a baseline is because PC GPUs can't natively mimic N64 mipmapping. It has to be done in shaders. PJ64-Video's method is inherently flawed, and that's why Turok/Conker/PD/and some other games are broken. Improving PJ64-Video isn't necessarily a bad idea, but it's an incredibly ambitious task that doesn't really have a clear route. Still, if you're confident you can get the job done, then I defer to your judgement.

No Idea, might be impossible. Mostly code clean up so far. My desire to get good LLE and see where it goes from that. the software version is understandable and will work correctly. Now a hardware version of it I am going to face that problem. Is it solvable, I have no idea. I might end up at the same problem and come to the same solution. I am not there yet, when I do get there I can see what happens.

Originally Posted by SuperTurboTurkeyStuffer

New UI for GlideN64: It is a pity Gonetz used QT because it has caused a lot of headaches. The Zilmar version is a nightmare to build.
.

If I do a new UI in part it would be to make it easier to build.

Originally Posted by SuperTurboTurkeyStuffer

Enhancement Build: Way I see it, you should split the cheat menu into two sections. One section is for stuff like 60fps hacks, the other for cheats. Bear in mind you're really not going to see that many 60fps hacks that aren't unstable and therefore not recommendable.

I do have a branch where I started this work, yes enhancements and cheats will be separate. Does not have to be every game, does not even have to be many. Even if it is just Golden Eye it is probably enough.