Project64 Roadmap

[zilmar]

One of the things that was brought up a couple of times when I started to talk about Project64 on Pateron (http://www.patreon.com/Project64) was the road map for Project64.

here is my rough list I had down for my self, this the starting point of the road map (in no particular order).
* D3d version of glide64 (this is actually using a library Angle as a DX wrapper around OGL es)
* General Improvements to glide64
* CFB improvements to glide64
* Redo the website here
* Create test roms.
* Improve Cycle Accuracy
* Add netplay
* Low Level emulation
* Improve speed and stability on android
* Refactor/Clean up RSP
* 100% open source
* Native 64bit version


Some more detail about some of the items
* Angle (D3d) Glide.
At the moment glide goes glide->OGL wrapper or Glide->OGL es wrapper. I am looking at being able to remove the OGL wrapper, so that it is glide->ogl es->d3d. I know this puts another layer in but it removes a massive amount of duplicated code and another code path. Once this is working the next step is to strip all things related to glide out. So it will be a open gl es direct (which will work for android directly) with Angle wrapping it to d3d.
* CFB/General improvements to glide64
mostly cleaning it up more, fix bug, get CFB effects working better, the lle version will help with this
* Test Roms
These will be sort of like unit tests, making sure the emu is exact. I will be creating them so I can run and validate them on real n64 hardware. It will part research & development, part validation. Things like what is Round(0.5) on the n64, I do not know what the results are.
* Cycle Accuracy
Project64 was always designed to be cycle accurate, I just never had the time to research it on the n64 to get the correct timings, it was ignored since it worked well enough. I would like to get it to be 100% cycle accurate. (this is related to the test roms)
* Low Level emulation
I want as an option to be able to have pixel accurate gfx, while it will be to slow for general use it give great ability for testing and to make sure things are accurate. It also makes it easier to reverse some of the ucode (factor 5) that do not work correctly in hle
* The RSP plugin
It works well, but the code was written a long time ago, never well optimized for gfx lle. Does not make use of latter CPU features like SSE3, not portable to other CPUs, does not have a sync cpu, etc
* 100 % Open source
It has a video and audio plugin that are still closed source, they need to be removed. Need to make sure the open source gfx plugin is good enough and have an open source audio plugin, either create my own basic one based on the android version or look at using azimers audio plugin
* 64bit version
Project64 will compile and run now in 64bit, the problem is the recompiler will not work in 64bit, so you can only use the interpter. There are poeple I know who would love to see a 100% native 64bit version. The code did get a lot cleaner to be able to make this easier to implement with the creation of the ARM recompiler.

What else would you like to see? Is there a good template of a road map people like? Any more information?

[zilmar]

with the debugger there is more work there as well .. the question is do I do it all my self or look to work with shygoo to be able to merge his changes back in to the main product (https://github.com/shygoo/project64)

http://origami64.net/showthread.php?tid=549

[zilmar]

couple of things that theboy181 mentions that are not on my list above
http://forum.pj64-emu.com/showpost.p...33&postcount=4

* Updated zilmar spec - Happy for suggestions to change here, mostly have left it fairly stagnant to all backwards comparability.

* Cheat engine - Again not sure what needs to be changed here

* Accuracy/Timing - I guess these fall under the test roms.

[Melchior]

Nice list(s) Zilmar ^_^

seeing native 64bit does it for me.
and... seeing updated system spec requirements is needed too...

website redesign is long overdo...
separating the website from the forums is essential.. as right now I wanted to check to make sure my email is correct because I have NOT been receiving any forum notification emails...

nope I cannot even access the email/password screen at...
http://forum.pj64-emu.com/profile.php?do=editpassword
because it redirects to http://www.pj64-emu.com/ an if I can even login to the main site at all... it give the option for
http://www.pj64-emu.com/UserDetails.html
and that link does NOT even work

SOO yeah website redesign work is much NEEDED... >_> please!! lol


EDIT:
btw Zilmar, u might want to sticky this thread since its going to be so important going forward...

[zilmar]

Yes website needs work, seperating the forum is the first thing I need to do ... the forum stays .. need to make it a bit better for mobile, but the rest needs to replaced, need like a wiki there, cleaner main page, links to git hub etc.

The problem any work on the site is not work on the emulator, which is why I have not done it.

the road map here is meant to be a discussion. I need a proper place for it.

[tony971]

Why continue to daisy chain wrappers? Wouldn't it be easier to switch to GLideN64 and build a D3D backend?

https://github.com/gonetz/GLideN64/issues/1335

[RPGMaster]

I think the top 2 most important things for PJ64 right now, would be creating test ROMs to help improve accuracy for RSP and CPU, and fixing up Glide64.

On my personal wish list, some important things would be improving cpu recompiler performance (especially the Advanced Block Linking stuttering) and implementing x64 CPU recompiler.

Originally Posted by tony971

Wouldn't it be easier to switch to GLideN64 and build a D3D backend?

Highly doubt it would be easier.

[retroben]

I believe the cheat engine part was about the MIPS ASM codes not being responded to on Recompiler (or cached Interpreter) because of the issue it has on top of caching and Advanced Block Linking also halting ASM instruction mod updates from affecting the functions behind its changes.

Because even with all caching disabled on Recompiler and even ABL disabled as well,it still fails to update for most of those mods properly for correct results of the changed bytes on those instructions.

Not a problem for those constantly forced to one value,but this makes button activated codes not work right at all,some functions can be changed to various values for really fun results.

[Frank74]

Originally Posted by RPGMaster

I think the top 2 most important things for PJ64 right now, would be creating test ROMs to help improve accuracy for RSP and CPU, and fixing up Glide64.

Agreed, it may help fix the FPULocations issue with Indy and Naboo as well.
And cycle accurate timing would be the icing on the cake. Probably lots of issues are due to timing inaccuracies.

[weinerschnitzel]

I think it would be great if you worked with ShyGoo to merge his debugger changes back into Project64. I believe this is a good task where we can all see improvements and you can delegate some of the effort involved.

It would be really great to get some of the rom hacking community on newer tools other than using Nemu. This would be very beneficial for people who want to RE the Factor 5 ucodes and verify known ucodes.

I support your other goals.