Project64 source code

[DaMan69]

You and your MinGW I'm going to call you FOSS Cat. The _M_IX86 stuff is indeed MS only.

#if _M_IX86 && _M_IX86_FP<2 || defined(__i386) && !defined(__SSE2__)

Is what my google-fu tells me.

[HatCat]

MinGW is merely one of infinitely many instruments to test standards compliance. It's not a very good one; it's just the closest to a good one within reach from MSVC-heavy code that Windows compilers have to offer. After a point, many other compilers become available, though yeah it's partially related to FOSS perspective I imagine. :P

The other issue with something like for example, what you pasted:

#if _M_IX86 && _M_IX86_FP<2 || defined(__i386) && defined(__SSE2__)

... is that it detects if certain compilers (like MSVC or MinGW, but not all compilers) are building 32-bit with SSE support. Theoretically the problem with this is someone can have a 32-bit machine capable of launching the Project64 executable, but their machine can be 32-bit but still lack SSE2 support. At which point, a crash occurs while running Project64.

For the most part, I believe that 64-bit CPU is plenty enough of a reasonable expectation that people will have at this time. It unconditionally guarantees that SSE2 ISA also is implemented, so you know that if the 64-bit EXE can be run, there is no way the SSE2 instructions can't be run.

[HatCat]

Really the type of solution here that I thought would be best is something like a standard math or <float.h> library call that would handle the R4300 precision manipulation in a cross-platform way.

This way, optimizing compilers would compile the standard library call to the _mm_cvtsd_si32 intrinsic with 64-bit compiles and to the 32-bit FP instructions zilmar wrote in his inline asm for 32-bit compiles. Then, we have a win-win and can remove both zilmar's inline asm AND my non-portable SSE2 (64-bit only?) intrinsics work-around.

However, I'm not good at FP stuff and didn't know what to write for that. I chose the FP intrinsics in this case as a "fast fix".

[DaMan69]

Kyle's mom was reverted! Even after 16 years she's still a bitch.
Juniel Katarn you PC, bro?

On topic JK's other commit broke building if you have added VC directories to MS.Cpp.win32/x64.props (none of the default directories are in the one's I've set).

[SmithJrBlaquaLuigi Inc.]

Hello everyone! I'm new here.

[drahsid]

I seem to be having a problem building the project in Visual Studio Community 2015.

Does anyone know how I can fix this? I would love to contribute to the project.

[RPGMaster]

Originally Posted by drahsid

I seem to be having a problem building the project in Visual Studio Community 2015.

Does anyone know how I can fix this? I would love to contribute to the project.

First, try compiling with release instead of debug

[HatCat]

And if that doesn't work, rename Release/lib/Common.lib to Release/lib/Common.exe, and then recompile the exe.

[zilmar]

the issue is the default project is common and your trying to run common, set project64 as the default project

[fery65]

Hello everybody,

Sorry I am new here, I just wanted to participated to improve this project64 which is one of the best emulator. It can be perfect over time, I have already participated years ago with 20 dollars in this site, so I am not so new.

Il only wanted to report a bug in Goldeneye which has never been solved in spite of new project64 versions. In the 6th level (frigate level) the sea, the water is very bad emulated, do you think it is possible to solve this problem?

Moreover, when you shot the gun the fire which is emited is square not so real as the original, maybe somthing it could be fixed.

Thank you everybody I am french so sorry for my english

François