I'll be more organized next time . Although I'm not sure when the next time I'll even submit anything. It depends how much zilmar cares about optimizing his RSP recompiler. Since I'm still going through my own code, I'm focusing mostly on accuracy atm, as well as studying RSP code in games a bit. One thing I'd like to fix is Rogue Squadron though.

Well w/e, doesn't really matter if I'm just trying to get/build the EXE anyway since I lost the emulator.
To be honest I have never tried building before...I hope it's not hard and/or full of warnings.

[Edit] Nope, fails to load all the files in VS2010. Only the VS2008 makefile works. Guess I stick to the beta downloads page.

I think zilmar actually removed the ads from source, but I guess he didn't remove the binary stuff ;/ . Good reminder though as I recently had the same issue. I think I couldn't download with chrome browser.

It's a pain to compile, but like you, I found that v2008 makefile works. I was able to convert it to 2010 and compile with that. I can't compile the exe with 2013 though. The RSP is able to compile with 2013. I'm glad I kept 2010 . Idk why, but the exe is configured to have glide64 as a dependency. I think it's better to remove the dependency.

"Idk why, but the exe is configured to have glide64 as a dependency. I think it's better to remove the dependency."

Hard to tell if as it turns out, I can't even compile the thing. The VS2008 makefile didn't compile successfully either, and there are too many warnings flooding the compiler output for me to analyze why it failed. The VS2010 makefile like you said...didn't work for you too??

So what, nobody cares if newer versions of Visual Studio can be used? Why?
Because older MSVC builds had faster run-time performance?
Because of CRT linkage/version of MSVCRT required?
Because of build file size?
Because of memory usage within the newer releases of the Visual Studio IDE?
All of those problems are amenable.

This is what I meant when I was arguing about portability with you earlier--it's not just Windows/Macintosh/Linux; it's other things like this--not being able to use the available versions of Visual Studio from Microsoft to compile the project, without converting some old makefile like from MSVC 2008. Things like inline asm aside--if something requires compiling in older versions of a compiler, and not newer versions, it is a hindrance to portability.

Ya it's been kinda frustrating at times. There are quite a few emulators/plugins that I've never managed to compile ;/ .

I think zilmar never updated his MSVC version.

Sorry, I guess it's been a while since I've had to set up Pj64 exe's project settings. I cannot remember if I even solved these ATL/WTL problems on my own, or if I had to use someone else's fork. I'll try and review some of the forks & version's I've tried.

Would be nice if a lot of these n64 emulator/plugin projects were easier to compile . I noticed the default compiler settings are sub-optimal.

It's my first time trying to compile any N64 emulator really, unless you count RCP/plugins (which I think are still emulators ).
The only other emulator I remember compiling was Mupen64 to help some other folk with patches / modernization.

Normally I'd say, try to contribute changes to fix these hundreds of compiler warnings I've been getting, but I'm not really in a position to do a pull request for something I cannot get to compile so that I can test my changes before pushing them. Nothing to make haste for though, got other stuff on my mind, other things to work on. Hope you guys have fun with this project though.

It might also have helped if the "project64" account had more than just one repository ("project64") on it--split up into a repository for the main CPU, for the RSP plugin, for Glide64, for N-Rage ... instead of associating one GitHub account with a all-in-one colossal repository. Individual repositories for each component of Project64 would make building easier...if someone failed to compile the RSP, they could still compile the core.

It's alright. I don't really pay attention to the ads. Wasn't complaining about ads, just that I can't pull from his repository without MSE auto-deleting files from the repository I just pulled. Just kinda makes it a bit weird, that's all.

But I do the former because I'm a masochist and can't even remember whether the second one was correct/necessarily works every time anyway. You do need to use the latter git pull method however, if you've made one or more commits, and zilmar pushes something to the repo that conflicts with one of the commits you just made. Otherwise you'd have to delete your commit, git clone start over again, whatever.

Quote:

Originally Posted by RPGMaster

Waiting wouldn't be a bad idea for you, but I hope you do contribute in the future . Would be nice to support more compilers and get rid of warnings. I'm still struggling with mingw for general use.

It's not so much that I'm waiting since i'm already contributing to other things, but I'm mostly just attempting to help see some life going on here. I don't mean me contributing necessarily, just setting up a social circle to help out with this external thing which does not really relate to me, aside from me being registered on the site.

I managed to compile the exe with 2010 after compiling WTL, 7zip, Zlib, Common. I think the reason I struggled to even compile with 2010 was because I had it on 2013 for WTL. Newer versions of MSVC are a pain to compile WTL with I guess. Just from googling, I see many people having some of the same issues. I'm not even sure if any fork I've tried, was even able to compile PJ64.exe with 2013, but I haven't gotten around to re-testing forks I've used before. I still recommend removing Glide64 as a dependency because that thing is a pain to compile (I never managed to successfully compile it). Plus why force it to compile Glide64, when you only want to compile/debug PJ64.exe !

I agree with you that it's best to not have an all-in-one colossal repository. It was especially tricky when I first attempted compiling like a year ago. It's confusing because there are project settings inside of the RSP folder, for instance. Yet compiling won't work because it has other dependencies.

I think zilmar actually removed the ads from source, but I guess he didn't remove the binary stuff ;/ . Good reminder though as I recently had the same issue. I think I couldn't download with chrome browser.

Yes removed the old ad code but did not remove the binary, sorry.

Quote:

Originally Posted by RPGMaster

It's a pain to compile, but like you, I found that v2008 makefile works. I was able to convert it to 2010 and compile with that. I can't compile the exe with 2013 though. The RSP is able to compile with 2013. I'm glad I kept 2010 . Idk why, but the exe is configured to have glide64 as a dependency. I think it's better to remove the dependency.

the dependency was just if I updated the plugin and then run the binary I wanted it to build those libraries. So it is just to force the compiler to build it.

I have access to Visual studio 2013, so I should see if I can see why it breaks. I use visual studio 2008 for compiling project64.

Quote:

Originally Posted by RPGMaster

It depends how much zilmar cares about optimizing his RSP recompiler.

well technically it is jabo's compiler, I did the interrupter and the re compiler was partly based off my r4300 compiler, but most of the compiler in the RSP is jabo's work.

I mostly just focused on making the RSP interrupter as accurate as possible.

Since at the time we mostly just focused on audio though the rsp it was maybe not the most efficient re compiler. I am sure there is lots of things to make it even faster.

Sorry, I guess it's been a while since I've had to set up Pj64 exe's project settings. I cannot remember if I even solved these ATL/WTL problems on my own, or if I had to use someone else's fork. I'll try and review some of the forks & version's I've tried.

Looks like WTL should be upgraded to version 9 for proper support in Visual studio 2013