Project64 2.0 is now available and open source!

[RPGMaster]

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]

Originally Posted by RPGMaster

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]

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).

Originally Posted by RPGMaster

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]

Originally Posted by BatCat

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.

Originally Posted by juniel_katarn

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]

2.1 a fork from the 'official' repository at www . pj64-emu . com : 8090 / project64.development

Looking forward to any comments.

[juniel_katarn]

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]

Originally Posted by RPGMaster

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]

Originally Posted by BatCat

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?

Originally Posted by juniel_katarn

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]

Originally Posted by RPGMaster

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

1. 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).
2. Command line method
   1. Open a Visual Studio Command Prompt: START\Visual Studio 2012\Visual Studio Tools\VS2012 x86 Native Tools Command Prompt
   2. Move to the root directory of the source code (the one containint the .SLN files)
   3. 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.
3. Visual Studio IDE method (in my case, using VS2012)
   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".
   2. 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]

Originally Posted by juniel_katarn

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.

Originally Posted by RPGMaster

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.