PDA

View Full Version : What would you like to see done with Project64


zilmar
18th August 2017, 04:44 AM
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
18th August 2017, 05:20 AM
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.


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
18th August 2017, 05:44 AM
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
18th August 2017, 06:01 AM
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
18th August 2017, 06:08 AM
Voted for:

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

zilmar
18th August 2017, 06:08 AM
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
18th August 2017, 06:15 AM
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
18th August 2017, 06:25 AM
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
18th August 2017, 11:42 AM
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
18th August 2017, 12:20 PM
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.


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.


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.


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.

RPGMaster
18th August 2017, 06:17 PM
In order of importance, my list of the most important things to work on are Wiki, test roms, LLE/Improve Project64 Video, 64-bit, and Create basic open source audio plugin.

Problem: Game shits itself in some way.
Solution: Use GLideN64 or Angrylion's.

Secondly, is it actually possible to have working RNG while also having working netplay?

But I'm sceptical about the realism of making PJ64-Video more accurate.It sounds like you're oversimplifying the current issues with N64 emulation. It's not as simple as "use GLideN64 or Angrylion's". Having a wiki would be great for keeping track of the current status of N64 emulation.

It's not possible to have accurate RNG while using netplay. They intentionally made it non-deterministic (which makes sense).

It would not be difficult to make PJ64-Video more accurate than it currently is :D .

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.I'm very glad you are giving it a try :D. There are plenty of solvable problems that don't require new hardware, to fix.

The situation is currently so bad that I resorted to using LLE software renderers to actually improve performance.. Something clearly isn't right. After working on HW renderers for a bit and figuring out how to improve performance for bottlenecks like copying frame-buffer from video memory, I realized that hardware renderers can do a lot better than what it's currently doing. I may be able to help improve the video plugin. I'm going to look into finally learning Hardware rendering for real this time :D .

SuperTurboTurkeyStuffer
19th August 2017, 12:41 AM
It sounds like you're oversimplifying the current issues with N64 emulation. It's not as simple as "use GLideN64 or Angrylion's". Having a wiki would be great for keeping track of the current status of N64 emulation.
In the case of the myriad of graphics emulation problems, it really is that simple. I'm saying that there's no point documenting that basically everything is broken in Jabo's and slightly fewer things are broken in Glide64. Core emulation issues and info about N64 emulation is much more worthy of inclusion.

The entire page for Mischief Makers would/should be a list of bugs and "use GLideN64 or Angrylions" as the solution for them all. Games like Body Harvest would read "unplayable broken -- use GLideN64 or Angrylion's".

Using the wiki for game compatibility listings is pointless. The RDB has the same problem. I overhauled it with Glide64/PJ64-Video in mind, but I didn't anticipate that it would be used indefinitely.

That said, maybe the wiki could be useful for documenting just how broken Jabo/Glide64 are currently because there's a lot of "looks fine to me" sentiment that still floats around. Demonstrating otherwise has some merit. I mean, Glide64 can't even render Mario 64 correctly. It gets the texture filtering mode wrong on the HUD. It just gets worse from there.

Sorry if that comes across as too negative.

RPGMaster
19th August 2017, 03:21 AM
My idea would be to document functionality that a game requires, like TLB, or FrameBuffer effects, and to also document recommended plugins/settings.

For instance what i would write for Smash Bros, is that it doesn't use TLB and that it needs framebuffer copying for the results screen in 1 player mode. That way, users would know that they can turn off framebuffer copying if they never play 1 player mode. They could also disable TLB to get a CPU performance boost. Then for graphics, i would say that only Angrylion's and GLideN64 get that intro effect right. Then also mention that most HLE plugins have graphical glitches and mention that Z64gl, Glide64, and Jabo 1.7.0.56 are decent alternatives for people who can't use Angrylion's or GLideN64.

It would be good to mention games that are noticeably less accurate in HLE.

I think being able to provide the next best alternatives is great. It would be good to highlight cases where other HLE plugins actually 100% work better than GLideN64, like those Culture Brain games. It would be nice to mention that SD Hiryuu, for example runs fairly decent in Glide64 and that Rice Video would be the next best alternative, if Glide64 is too slow. This way, people know what to use to get the best experience per-game.

That said, maybe the wiki could be useful for documenting just how broken Jabo/Glide64 are currently because there's a lot of "looks fine to me" sentiment that still floats around. Demonstrating otherwise has some merit. I mean, Glide64 can't even render Mario 64 correctly. It gets the texture filtering mode wrong on the HUD. It just gets worse from there.I think that would actually be good, as someone who rarely uses GLideN64 :D . For instance, in Super Smash Bros, I see no point in using GLideN64 over Glide64, except for the intro. It doesn't justify the performance gap imho. This is the first time i've seen someone say Glide64 is noticeably less accurate for Mario64. I'm pretty sure no hi-res plugin does texture filtering properly. Maybe bad settings were used, but even Super Robot Spirits looked bad last time i checked it out in GLideN64. That's one of the reasons I stick to Software Rendering in many cases. I play quite a few 2D-heavy games. HW rendering is just too inaccurate and the not-so-great performance only makes it less enticing.

ferlanga
20th August 2017, 11:18 PM
A way to play N64 FPS games with better mouse aiming would be great. i know about that injector program but would be a nice addition to have by default.

Getting games to run on a better framerate would be awesome. Even just getting some of them to a consistent 30 would be quite a step up, and 60fps would be even better.

Netplay would be mostly for those games which are exclusive to the n64, so check out if they pile up a big enough number to justify starting some work on netplay right now.

theboy181
22nd August 2017, 03:25 PM
Sounds like you need to vote for the enhanced version in the poll.

mistamontiel
30th September 2017, 12:10 AM
Man how ya'll be

I forget which if it was one of the v2.1x er v2.2x , the one when Glide essentially became PJ64's plugin and integrated I could not adjust any settings @ all nothing saved throughout the whole emulator

Also sad to see the site doesn't have any of the legacy builds either no more :confused:

Thanks for all your hard work ! Playing over AQZ input netplay plugin is a real treat !

EDIT: Brain exhausted I'm not in the right thread sorries