Go Back   Project64 Forums > General Discussion > Site News

Reply
 
Thread Tools Display Modes
  #1  
Old 18th August 2017, 04:44 AM
zilmar zilmar is offline
Core Team
Alpha Tester
Project Supporter
Administrator
 
Join Date: Jun 2005
Posts: 987
Default What would you like to see done with Project64

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
Reply With Quote
  #2  
Old 18th August 2017, 05:20 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,245
Default

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.

Quote:
Originally Posted by zilmar View Post
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.
Reply With Quote
  #3  
Old 18th August 2017, 05:44 AM
zilmar zilmar is offline
Core Team
Alpha Tester
Project Supporter
Administrator
 
Join Date: Jun 2005
Posts: 987
Default

Quote:
Originally Posted by HatCat View Post
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.
Reply With Quote
  #4  
Old 18th August 2017, 06:01 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,245
Default

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.
Reply With Quote
  #5  
Old 18th August 2017, 06:08 AM
Melchior's Avatar
Melchior Melchior is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Apr 2007
Location: NH, USA
Posts: 195
Talking

Voted for:
  • Wiki website
  • Forum Upgrades
  • Improve cycle accuracy
  • Improve Project64-video
  • Refactor/Clean up RSP
  • 64bit version <-- My favorite
  • Enhancement Build
__________________
(PC Specs)
CPU: AMD FX-9590 4.7GHz 8-core
CPU Instructions: MMX, SSE1-4
Motherboard: Asus SABERTOOTH 990FX R2.0
GPU: nVidia GTX 750Ti SC 2GB
GFX Drivers: Nvidia v388.13
OS: Windows 7 Ultimate 64-bit SP1
RAM: 16GB Kingston 1866MHz DDR3

Favorite Emulators:
PS2 : PCSX2 (Auto-Builds)
SNES : ZSNES

My PJ64 setup:
EXE : v2.4.0.582
GFX : Project64-Video (v2.2.0.582)
SPU : AziAudioNEW (v0.70)(2017-09-14)
INPUT : NRage(v2.5.3.582)
RSP : RSP (v1.7.4.582)
Reply With Quote
  #6  
Old 18th August 2017, 06:08 AM
zilmar zilmar is offline
Core Team
Alpha Tester
Project Supporter
Administrator
 
Join Date: Jun 2005
Posts: 987
Default

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.
Reply With Quote
  #7  
Old 18th August 2017, 06:15 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,245
Default

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.
Reply With Quote
Reply
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 03:50 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.