PDA

View Full Version : Project64 2.0 is now available and open source!


Pages : 1 [2]

RPGMaster
17th January 2014, 02:36 AM
Lol I've never even heard of GLFW, but after reading about it today, I think I will use that if I decide to do OpenGL. GLFW seems to be better suited for what I want, compared to SDL. If I were to do OpenGL and GLFW, I should use Open AL for sound right? I tend to disregard difficultly level (unless the time required is absolutely too much) and prefer to go for the best quality. Plus I like taking on challenges. The only time I ever really give up on something is if I feel I don't have enough time, or if I lose interest.

It seems like the hard things are generally not much more time consuming, once you get used to it. I don't get why people pick "easier" languages and claim that it saves them a lot of time. I used to make GUI's in C#, until I learned that making GUI's in C wasn't as hard or as time consuming as people made it out to be...

I'm pretty excited to start learning OpenGL too :) . I've been trying to learn a lot these days, so it's hard to keep up with all my goals lol.

juniel_katarn
17th January 2014, 03:34 AM
Sigh, I'm struggling to compile a bunch of stuff.

I had found building the whole project a very painful task (using Visual Studio/MSBuild).

I worked on refactoring the VS project files and published a branch here:
github.com / JunielKatarn / Project64
All binaries compile out of the box with a single command and no tweaks.

If you are interested, please take a look and give some feedback. I'd like to contribute this change that is not invasive to the actual source code but makes compiling/testing a breeze for emulation noobs like me.

HatCat
17th January 2014, 04:33 AM
Yeah everyone complains about C being too hard or painful or w/e, but to me, at makes at least as much sense as anything else.

About compiling Project64: zilmar does a lot of non-ANSI-strict compliant things sometimes, so compilers may gave very many warnings at times (it may even amount to errors in the absence of strict compiler/IDE settings like in a Visual Studio makefile of sorts).

Lol I've never even heard of GLFW, but after reading about it today, I think I will use that if I decide to do OpenGL. GLFW seems to be better suited for what I want, compared to SDL. If I were to do OpenGL and GLFW, I should use Open AL for sound right?

I personally would go with OpenAL.
I'm not sure if there are other portable solutions besides SDL. (OpenSL/ES or w/e is something else Khronos did.)
waveOut is probably more portable than DirectX is but is still specific to Microsoft Windows (and besides lacks many audio enhancements of the extra Windows-specific DirectX audio stuff). A similar principle can be applied to the use of the Windows GDI (gdi32) for software rendering instead of DirectDraw, but for any basic/demonstration plugin I'd probably still do GDI anyway since it'd work on more computers than zilmar's basic cfb would. :)

You could still use SDL for input if you wanted.
Unlike audio and video, SDL doesn't use indirection or just targeting some sub-API to do the work for it, when it comes to joystick/controller, as SDL and GLFW are [some of?] the only cross-platform options when it comes to joystick anyway. I'm tied on which one to use though...GLFW is probably much more backwards compatible and organized than SDL, but SDL has so many convenient little functions written for you to take care of special subsystem things that it replaces having to depend upon too many additional dependencies. (I hate that they renamed the updated DLL from "SDL.DLL" to "SDL2.DLL" tho...that really is not backward-compatible.)

Either way, we have one SDL plugin anyway and that's blight's input originally written for Linux. We do lack a GLFW input plugin, so you'd be the first!

RPGMaster
17th January 2014, 05:05 AM
I personally would go with OpenAL.
I'm not sure if there are other portable solutions besides SDL. (OpenSL/ES or w/e is something else Khronos did.)

Either way, we have one SDL plugin anyway and that's blight's input originally written for Linux. We do lack a GLFW input plugin, so you'd be the first!
Alright, OpenAL it is then :) . I probably won't learn input anytime soon, unless I end up learning everything at a faster pace than I anticipated. Plus I'd need to learn how to make cross platform gui's, unless I decide to limit the plugin to just windows users. I considered learning how to use QT but idk lol... People say it generates bloated files. I like using lightweight stuff.

I'm curious though. Lets say I end up working on a graphics plugin, how would I make it more accurate? I hardly have any knowledge about n64 hardware, so the best I could do is maybe optimize an existing open source plugin for better performance.

I had found building the whole project a very painful task (using Visual Studio/MSBuild).

I worked on refactoring the VS project files and published a branch here:
github.com / JunielKatarn / Project64
All binaries compile out of the box with a single command and no tweaks.

If you are interested, please take a look and give some feedback. I'd like to contribute this change that is not invasive to the actual source code but makes compiling/testing a breeze for emulation noobs like me.
What version of pj64 is this? I'm checking it out right now though.

juniel_katarn
17th January 2014, 05:33 AM
2.1 a fork from the 'official' repository at www . pj64-emu . com : 8090 / project64.development

Looking forward to any comments.

juniel_katarn
17th January 2014, 05:34 AM
By the way, every time I put links in a comment, I get the following message:
"Thank you for posting! Your post will not be visible until a moderator has approved it for posting." but after many hours, the comment doesn't get approved.

What do I need to do to earn the forum's "trust" and be able to post hyperlinks?

HatCat
17th January 2014, 05:40 AM
I'm curious though. Lets say I end up working on a graphics plugin, how would I make it more accurate? I hardly have any knowledge about n64 hardware, so the best I could do is maybe optimize an existing open source plugin for better performance.

Accuracy is a matter of implementation.

To make an emulator accurate you need to know about the hardware, and the RDP is probably the most undocumented damn thing, either in source or English form, in any archive I've ever seen.

In HLE however, the graphics RSP ucodes have been fairly documented.

Maybe I don't know the full extent of your question, but I like LLE gfx.

RPGMaster
17th January 2014, 06:11 AM
Accuracy is a matter of implementation.

To make an emulator accurate you need to know about the hardware, and the RDP is probably the most undocumented damn thing, either in source or English form, in any archive I've ever seen.

In HLE however, the graphics RSP ucodes have been fairly documented.

Maybe I don't know the full extent of your question, but I like LLE gfx.
Well, I was under the impression that there's still work to do on the accuracy of graphics plugins. So I was wondering how I'd be able to improve the accuracy, but as you confirmed, I will need hardware knowledge to do so. Also what are the flaws of HLE? I know that it doesn't perfectly emulate things, but is the accuracy of HLE limited, or can it still be very accurate?

2.1 a fork from the 'official' repository at www . pj64-emu . com : 8090 / project64.development
Oh ok. I'm still a little confused on the setup process. Do I just extract that whole zip file and it should work? I tried running each project separately and had no luck getting it to work. I'm a noob with github lol. When I clicked on the .sln file, it had all the projects together. I'd prefer compiling each part separately because it just takes too long to compile everything at once.

juniel_katarn
17th January 2014, 09:46 AM
Oh ok. I'm still a little confused on the setup process. Do I just extract that whole zip file and it should work?

I guess I need a place to put some documentation of my changes. (I might move that fork to BitBucket, which is better than GitHub).

Requirements

Visual Studio 2010 and OPTIONALLY, 2012 or 2013 (the project builds with the 2010 compiler stack, but 2012/13 can be used as an editor and for debugging, profiling).
Moreover, if you don't have a licence for 2010, you can still install it side by side with the newer version. You won't be able to use vs2010 IDE beyond the trial period, but you can still use the compilers from the newer version.
git (GitHub has a nice windows client)
Windows XP SP3 or later (dah!)


Setup

Get the source code

Either using the GitHub client or git command line: git clone https : // github.com / JunielKatarn (recommended)
Download the zip file (not recommended. It downloads the source without the history and you can't track your changes).

Command line method

Open a Visual Studio Command Prompt: START\Visual Studio 2012\Visual Studio Tools\VS2012 x86 Native Tools Command Prompt
Move to the root directory of the source code (the one containint the .SLN files)
Compile any of the subprojects (.vcxproj) or the whole solution (.sln) with the following syntax:
msbuild /property:SolutionDir=%cd%\ <path to VCXPROJ or SLN file>
Note: setting the SolutionDir property is necessary at least for VS2010.

Visual Studio IDE method (in my case, using VS2012)

If using newer versions (2012, 2013) you might see a warning offering to update the compiler and libraries. I suggest leaving the 2010 toolchain for now (I recall having some issues compiling with the 2012 stack). Choose "Don't Update".
Select the desired project (or the solution itself), right click and choose 'Build'.



OK, I really hope this helps and saves you many configuration and crappy dependency-hunting hours I had to spend myself.

Finally, the default 'build' target is 'Debug', which doesn't enable all the compiler optimizations. You might need to change to the 'Release' target to get the release-quality binaries.

HatCat
17th January 2014, 05:06 PM
By the way, every time I put links in a comment, I get the following message:
"Thank you for posting! Your post will not be visible until a moderator has approved it for posting." but after many hours, the comment doesn't get approved.

What do I need to do to earn the forum's "trust" and be able to post hyperlinks?

zilmar put this in because of auto-spam-bots.
I think you need > 5, > 30 posts most likely to be able to put links.

I wouldn't count on him coming onto this forum to approve anyone's posts, either.

Well, I was under the impression that there's still work to do on the accuracy of graphics plugins. So I was wondering how I'd be able to improve the accuracy, but as you confirmed, I will need hardware knowledge to do so. Also what are the flaws of HLE? I know that it doesn't perfectly emulate things, but is the accuracy of HLE limited, or can it still be very accurate?

I myself am not in a position to directly contribute to accuracy of N64 graphics plugins because I don't even have my Nintendo 64 with me anymore. (I ended up having to leave it in some other hands...didn't really have a choice.) I am actually making the RDP command buffer/fifo storage more accurate since that is one of the things that did get some info out on, than the way they do it in MAME, but otherwise I'm much better off simply concentrating on the poor performance than adding in the remaining unknowns about the RDP.



About HLE in your question, it's one of those things that, somewhat falls in-between "static re-compilation" and "translators". (A translator isn't an emulator but something that takes native N64 code, outputs a Win32/Linux/x86 executable that you can just open directly to start the game.) HLE means you study the outputs/functions of hardware behavior, while LLE means you study the hardware behavior directly itself. (Imagine trying to mimic/copy someone's personality...if you only know the outputs/results then you're HLE'ing them. If you understand their psychology a little better than you're LLE'ing them.)

HLE can appear as 100% accurate as any LLE program, but you have to implement all the infinite variety of possible microcodes for it to support every N64 ROM (including those not made yet, I'm just saying, theoretically/hypothetically) to the point where it's impossible long before due to memory overrun/storage reasons.

RPGMaster
17th January 2014, 10:00 PM
Open a Visual Studio Command Prompt: START\Visual Studio 2012\Visual Studio Tools\VS2012 x86 Native Tools Command Prompt
Move to the root directory of the source code (the one containint the .SLN files)
Compile any of the subprojects (.vcxproj) or the whole solution (.sln) with the following syntax:
msbuild /property:SolutionDir=%cd%\ <path to VCXPROJ or SLN file>
Note: setting the SolutionDir property is necessary at least for VS2010.
[/LIST]
Visual Studio IDE method (in my case, using VS2012)
[LIST=1]
If using newer versions (2012, 2013) you might see a warning offering to update the compiler and libraries. I suggest leaving the 2010 toolchain for now (I recall having some issues compiling with the 2012 stack). Choose "Don't Update".
Select the desired project (or the solution itself), right click and choose 'Build'.

OK, I really hope this helps and saves you many configuration and crappy dependency-hunting hours I had to spend myself.
Ok thanks. This is what I needed to know :) .
I myself am not in a position to directly contribute to accuracy of N64 graphics plugins because I don't even have my Nintendo 64 with me anymore. I am actually making the RDP command buffer/fifo storage more accurate since that is one of the things that did get some info out on, than the way they do it in MAME, but otherwise I'm much better off simply concentrating on the poor performance than adding in the remaining unknowns about the RDP.

HLE can appear as 100% accurate as any LLE program, but you have to implement all the infinite variety of possible microcodes for it to support every N64 ROM (including those not made yet, I'm just saying, theoretically/hypothetically) to the point where it's impossible long before due to memory overrun/storage reasons.
Now I understand the difference better. I guess I won't be able to improve accuracy, since I don't have the tools for testing. I will have to find a way to improve performance though, since that is still an issue. Time for me to hit the books :) .

deathmountaindew
6th January 2015, 12:52 AM
So is this working and all that now? Last time I tried it, no games worked right.

juniel_katarn
6th January 2015, 01:06 AM
If by "working at all", you mean Project64 2.0, then yes.
If you mean building the code base and running the games within the built version, then YES.

RPGMaster
8th January 2015, 08:39 AM
If anyones interested, here my fork of Project 64, makes various changes here and there, fixes some problems with it, reintroduces plugin hotswapping.
http://github.com/death-droid/project64You should submit pull requests to http://github.com/project64/project64 :D !

Do you think you could fix PJ64 2.1's debugger? In PJ64 1.7, things like memory viewer actually work. It would be cool have that working in 2.1 so I could debug stuff. PJ64 1.7's source is fortunately available :D .

Melchior
8th January 2015, 09:13 AM
Huewayyy it looks like fresh updates are coming this year ;D ^_^
;):D:rolleyes::cool:

deathdroid
8th January 2015, 10:44 AM
You should submit pull requests to http://github.com/project64/project64 (http:// github.com /project64/project64) :D !

Do you think you could fix PJ64 2.1's debugger? In PJ64 1.7, things like memory viewer actually work. It would be cool have that working in 2.1 so I could debug stuff. PJ64 1.7's source is fortunately available :D .

Hmm ill have a shot at it, but unfortunately Zilmar rewrote alot of the memory stuff within the last few months which did leave some of the more uneeded functions completely broken

deathdroid
8th January 2015, 01:41 PM
Weird my posts seem to of dissapeared from this topic :S
Trouble with repairing alot of those debugging options is that the way memory is handled is completely different from what was being done in 1.7

the_randomizer
9th January 2015, 01:39 AM
You should submit pull requests to http://github.com/project64/project64 :D !

Do you think you could fix PJ64 2.1's debugger? In PJ64 1.7, things like memory viewer actually work. It would be cool have that working in 2.1 so I could debug stuff. PJ64 1.7's source is fortunately available :D .

Call me stupid but I don't seen an actual pj64.exe in that zip file, all I can download is the source, but no compiled executable.

RPGMaster
9th January 2015, 02:21 AM
Weird my posts seem to of dissapeared from this topic :S
Trouble with repairing alot of those debugging options is that the way memory is handled is completely different from what was being done in 1.7Lol I thought that was weird how it said you were the last poster, yet your post wasn't there :D .

Oh well, I guess it makes sense why 2.1's debugger is broken/incomplete. I'll just have to use alternative methods for debugging.
Call me stupid but I don't seen an actual pj64.exe in that zip file, all I can download is the source, but no compiled executable.Nothing significant has happened yet. I just linked him source, so he can send pull requests if he wants.

RPGMaster
13th January 2015, 10:42 AM
Huewayyy it looks like fresh updates are coming this year ;D ^_^2015's a good year :p !

Hmm ill have a shot at it, but unfortunately Zilmar rewrote alot of the memory stuff within the last few months which did leave some of the more uneeded functions completely brokenOo your post reappeared :D ! I gave it a shot and saw that there's way too much code that needs to be changed. I give up since it would take zilmar much less time to fix it himself.

I also tried compiling 1.7, but most of the versions I tried, couldn't even compile :( . Now I'm kinda bored :confused: .

Franco_95
2nd September 2016, 11:00 PM
$ git clone http://www.pj64-emu.com:8090/project64.development
Cloning into 'project64.development'...
fatal: unable to access 'http://www.pj64-emu.com:8090/project64.development/': Failed to connect to www.pj64-emu.com port 8090: Timed out

:(

Martinitalf
13th August 2017, 12:26 AM
nevermind this...

Melchior
13th August 2017, 12:29 AM
nevermind this...

???? SPAMER?? if you are!
its STRAIGHT TO BAN! lol :p
so now kinda prove you are NOT AN EVIL SPAMMER!