Project64 source code

[Ambient_Malice]

Originally Posted by Petzi

The forum requires me to make 5 posts before posting a thread, so I'd like to say I'm glad Project 64 went open-source. Hopefully I'll discover that there's a way to emulate Paper Mario without all the graphical issues.

https://code.google.com/p/glidehqplu...e64_Final.zip&

[HatCat]

k so i think i'm starting to get the hang of making multiple pull requests

For anyone else who is confused on branches here's how I figured to get it to work.

Normally when we contribute a commit/fix to the repository we do something like this:

git clone https://github.com/project64/project64.git
cd project64
### This is where you change one or more files you want to improve.
git commit -m "[your commit reason message here]"
git push origin master

Now to do multiple consecutive pull requests here was how I got it working:

git clone https://github.com/cxd4/project64.git
cd project64
### again change stuff here
git commit -m "pull request A"
git push origin master

git checkout ????????
git checkout -b I_fucking_hate_making_new_branches
### change more stuff here
git commit -m "pull request B"
git push origin I_fucking_hate_making_new_branches

...
rinse and repeat, as long as you keep naming a new branch each time

You can then go to the GitHub website and drop-down select in the combo list which branch to make a pull request from...you can pretty much make all your pull requests from all of them it would seem.

The ???????? in that fetch command is the commit number you can find on the GitHub website, which would look something like 7345ecd, which points to the last commit zilmar made officially before I deviated off the main repository with any of my own pull request commits.

I suspect that there may be a shortcut to the git fetch #### method I'm using, but atm it works for me. I can edit this post if someone has a better way to say it.

[V1del]

Ahaha your branch names are godlike, lol'd hard

[HatCat]

It's pretty much all I could come up with lmao. How am I supposed to know what the hell to name these branches? IDGAF. They're just a means to an end for pull requests.

And if I run out of name space for them I can just start doing so_i_herd_u_liek_(improvement) instead of ya_(improvement)_plz_kthxbai.

[zilmar]

you can also delete old branches and reuses old names.

[DaMan69]

The version.h for the plugins say "VFT_APP" should be "VFT_DLL". The version in the manifest "needs" changed and you might want to add

  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
    </application>
  </compatibility>

[deathdroid]

[quote]The version.h for the plugins say "VFT_APP" should be "VFT_DLL".[quote]
Whoops didn't notice that, nice pickup.

[camelCaseClosed]

I opened this thread about to ask if there was a .make file included, when I remembered PJ64 is Windows only. Whoops!

I'd like to help bug test these. Before I compile, are there any external dependencies I should be aware of?

[DaMan69]

The Cat in the Hat's recent interpreter commits. Shouldn't they apply to the 32bit also? The internets says SSE2 convert instructions are faster than fisting. Something like

#if _M_IX86 && _M_IX86_FP <2

in the relevant asm sections.

[HatCat]

I believe that's fine too, and yeah intrinsics are better. SSE1 is needed for __m128 stuff while SSE2 is needed for __m128d stuff.

Unfortunately, neither the inline __asm nor the SSE intrinsics are at all portable to non-Intel architectures, such as whatever Android might be using. In that case I mostly intended to correspond as much as I could to zilmar's inline asm without too much risk of breaking the exact specification of what he was attempting.

Ideally both the inline asm & and the SSE intrinsics I added should be deleted and replaced in the future with some standard math FP library algorithm that can compile to them for Intel's case on modern compilers.

Plus the _M_IX86 stuff I think may be MSVC-only and wouldn't detect 32-bit compiles with say MinGW. Using <limits.h> or something may be best to detect 32- or 64-bit compiles in a universal way.