Project64: Document settings, etc. of current version.

[Fanatic-64]

The current "User Manual" is from Project64 1.6, and inside the document it says this:

About this file: This document only covers official Project64 releases, and was written by Smiff for the official Project64 v1.5 release. Any other versions of Project64 available may differ in any number of ways, and this help file may not apply - please refer to the documentation included with them.

Working with the current RDB, there is a lot of stuff that didn't exist back then (and also a lot of stuff that no longer exists). To cite a few:

[Microcode Identifiers] - This section of the RDB has never been explained, and currently all it's contents are commented out.
32bit= - I get this is an optimization, to not have to deal with 64-bit whatever on 32-bit computers. However I wonder what kind of effects should I expect from this, if it doesn't work will it obviously crash or can it cause obscure errors deep into the game? Also honestly, since most computers are currently 64-bit, wouldn't it be better to deal with the 64-bit stuff natively?
The whole Recompiler settings tab: Judging by CXD's struggle here: #22 , this definitely needs explaining. For example, how is TLB Unmapping supposed to be used compared to the standard TLB option? And what settings can be used in conjunction with the Interpreter, Physical/Virtual Lookup Table (and what does that option itself do?)? How do the current SMCM options work? Etc.

And also, the .h files in the Plugin Specs folder should be updated to the current plugin specs.

All of this would allow more efficient configuration of the emulator, and make it easier for me and others in the future to use and maintain it.

[cxd4]

ya, Smiff was in charge of all the user support pretty much... he wrote the CHMs and FAQs until he disappeared, so updating those files is probably easier said than done. If it could then it should use some updating to reflect new options added since pj64 1.7.

Also honestly, since most computers are currently 64-bit, wouldn't it be better to deal with the 64-bit stuff natively?

There are too many limitations to make it that simple. I would love to have a 64-bit Project64 or other emulators, but there are several hindrances. Off the top of my head:

• The VR4300 re-compiler core... The interpreter is easily enough ported to 64-bit, but the dynarec needs to generate different machine code for 32- and 64-bit x86, which could double the amount of code to maintain at compile-time.
• Frequent usage of inline assembly code...inline assembly is a non-standard, non-compliant extension use of the C language and is only supported under MSVC when not compiling for the x64 target.
• a 32-bit plugin system specifications, which uses plenty of non-portable types like DWORD which can change the calling convention (especially when not compiling under MSVC)

To have a 64-bit release of Project64 emulator, these three issues need the most addressing I think.

And also, the .h files in the Plugin Specs folder should be updated to the current plugin specs.

Those plugin specs for 1.7 were mostly to keep people from distributing Jabo's 1.7 plugins to people who didn't donate. They're even LESS portable than the existing, publicly available and officially supported (by other emulators) versions of the specification. Instead of prematurely standardizing Gfx #1.4, Audio #1.2, Controller #1.2, Rsp #1.2, we should be taking advantage of the available time to be maximizing the effectiveness and service portability of these versions of the specs, not immediately publishing them and breaking backwards compatibility.

[project64]

the main changes with the plugin spec for 1.7 was no to keep more people from using jabos plugin elsewhere. It was mostly to allow the plugin to go though the emu for settings. this basically was for the ability to reset settings and give default settings.

it was more an extension it probably did not actually need a value change.

[cxd4]

Wouldn't matter if you didn't change the value. That still broke compatibility with all non-pj64-1.7 emus.

Mupen64Plus did something similar to what you just got done saying as I recall...go through the emu for settings, not the plugin. I like to do that to keep dependencies outside of the plugin (centralize GUI/framework/connections to the main emulator, not link them within each plugin), but I also don't like to break backwards compatibility which was what both m64+ and yourself did.

[project64]

where do you think some of these support files/information should be kept? In the installer, git, website?

[oddMLan]

My vote goes to the website.

[death-droid]

Agreed, stored on the website

[oddMLan]

Maybe the Project64 site could store all the support info/game compatibility status in a wiki? Other emu projects tend to do it that way.

[cxd4]

There is a Wiki feature embedded into GitHub. You can also commit a README.md or README.markdown file and push it to GitHub, and GitHub will automatically display the readme on the home page of the repo.

Past that, I don't care where the binary files go, as long as they're off the Git.

[death-droid]

Hmmm personally im kind of wondering if theres much point in the two .chm files at all anymore. There rather out dated and it seems like most users do not look at them.

[project64]

I was actually planning on stripping the .chm files out of the installer/menu tonight, would like to see what I need to actually get to a beta version.

[oddMLan]

@Fanatic-64
Is this still actual? What else needs to be updated currently?
I feel the current "RDB Info.txt" file is good enough for technicalities, but I agree it does not replace the old user guide.

885 Attempts to adress that issue, though.

Therefore, I think this ticket should be closed.

[cxd4]

Yeah but he died passively waiting for zilmar to close any of his issues for him though, cause fanatic refused to close any himself. So the only way this would get closed is if a admin over the repo did it.

[Fanatic-64]

@cxd4 I've come back from the dead for my revenge.

Most of PJ64's settings are still undocumented. However I've already found out what most of them do. I can write a guide if someone wants me to.