What's new

What do you want in Project64 ?

god0fgod

Banned
1.A reset to default ROM settings button just in case you bugger up the ROM settings.

2.Allow to play GB and S/NES games on the same emulator.

3.More compatibility with drivers and more efficient use of graphic cards and RAM.

4.A fix in mario party 1/2/3.
 

Agozer

16-bit Corpse | Moderator
2.Allow to play GB and S/NES games on the same emulator.
Was the original N64 able to play GB, NES, or SNES games? No. Project 64 is a Nintendo 64 emulator. The purpose of the emulator is to emulate a single console, not not every single pre-GameCube console.

Use a Gameboy, NES and SNES emulators to play Gameboy, NES, and SNES games. Or, if you really want an emulator that can emulate many consoles at once, use MESS.
 
Last edited:

Doomulation

?????????????????????????
3.More compatibility with drivers and more efficient use of graphic cards and RAM.
More compability with drivers? Are you implying you are seeing graphics bugs in the emulation? Or do you want more graphics card compability (ie more cards should work)?
Emulation can be a memory hog; I don't think this will change.

4.A fix in mario party 1/2/3.
Perhaps you should be more specific.
 

SubDrag

New member
I don't know if this has been mentioned, because I haven't read through all the posts, but one of the things PJ64 is seriously lacking is debugging. Breakpointing, stepping through the code, registry viewer at that time, memory viewer, ram searcher (similar to GameShark Pro's code searching) would be extremely nice. Also, it would be nice if after code searching you could turn codes on straight from the results (for testing), and be able to search certain ranges, have flags to ignore values in a certain range, ignore pointers.

One thing I've noticed is that if you turn on gameshark codes that affect the assembly code (mid-game) for certain games , for example Donkey Kong 64, it doesn't take effect until the ROM is restarted by pressing F1. Does this have to do with how PJ64 handles TLB or something along those lines?
 
Last edited:

Iconoclast

New member
Mentioned it several times in this thread, SubDrag. ;) One thing Nemu64 has that PJ doesn't.
Actually, there are several things that Nemu64 has that Project64 1.6 doesn't have:
  1. NetPlay
  2. Debugging
  3. VRML Geometry Logging (in video plugin that cannot be used with Project64)
  4. Different core emulation method that does not involve the specification of Counter Factor settings and such.
  5. Probably the best goddamn audio plugin out there, a combination of the abilities of Azimer's Audio HLE, Jabo's DirectSound, and zilmar's No Sound plugin, made by LaC. The audio plugin is better than all three of these audio plugins combined. It's only flaw is its perversive sound emulation of GoldenEye 007.
 

Iconoclast

New member
I agree, LaC's audio is amazing.
Yeah. It sucks that you can't use it with any other emulator. You can, however, use Nemu64's graphics plugin with all other emulators (except for Project64, for some odd reason). Just copy GS_DLL.DLL from Nemu64.exe's directory to EmulatorName.exe's directory, copy LemD3D8.dll to the Plugin folder of that emulator, and there you go. A shame you can't do the same with the audio plugin. The graphics plugin, however, isn't so good...it is only good at emulating a couple games like Aidyn Chronicles and Star Wars Rogue Squadron. Had Project64 not had a core issue with loading this plugin, that game would have been playable today.

As for the input plugin, Idk who made that, Lemmy or LaC, but it's about the same level as Jabo's DirectInput...there are better, and there are worse.

But enough of my spamming. Back to PJ64 suggestions.
 

SubDrag

New member
Oh, just thinking, it'd be nice if in PJ64 you had an option to ignore the messagebox that displays when you have noncritical microcode errors (like graphical/audio errors).

And an option to ignore ROM CRCs.
 

squall_leonhart

The Great Gunblade Wielder
More compability with drivers? Are you implying you are seeing graphics bugs in the emulation? Or do you want more graphics card compability (ie more cards should work)?
Emulation can be a memory hog; I don't think this will change.


Perhaps you should be more specific.

i think hes referring to the broken framebuffer issues on NV40+ that causes the link display in OoT to appear as a white rectangle
 

X-Fi6

New member
Oh, this is one for Jabo:

OpenGL

Jabo's Direct3d is a pretty good plugin but has some emulation issues. It's the fastest and most compatible, and if the plugin is going to support retexturing in PJ64 1.7 I'm gonna want to use it. OpenGL please.
 

Iconoclast

New member
Jabo had an Opengl plugin but support has been dropped for it,... not sure why..
I'm estimating it's because DirectX plugins are faster than OpenGL, and while plugins like Glide64 work best using the OpenGL rendering engine, many are too ignorant to realize that plugins like Rice's Video 6.1.1 and Jabo's graphics, when using OpenGL, just don't work very well with graphics or speed.

The user is also saying, he wants to use a plugin that actually works. Obviously, this user's system specifications are so low (or at least DirectX version and/or video card), if he can't even get DirectX plugins working, OpenGL isn't even worth trying.
 

Doomulation

?????????????????????????
Not quite. DirectX vs OpenGL is pretty much equal in soeed. It all depends on HOW you use the API. It's just that some prefer DirectX and some OpenGL. OpenGL is also portable which DirectX isn't.
Jabo, may have for example, chosen DirectX because Jabo knows it better than OpenGL. Similarly, Hacktarux would use OpenGL since DirectX isn't available on non-Windows platforms.
There are games out there with great speed with OpenGL and there are games with DirectX. It's just a matter of preference. Well, almost always.
 

gandalf

Member ready to help
well, most low end cards are more compatible with direct x than open GL, maybe that was the reason to drop it
 

squall_leonhart

The Great Gunblade Wielder
actually low end geforce cards run faster in opengl then in Direct3D

Opengl is always faster on nvidia cards as they define almost the entire Opengl spec...

this was more likely because Jabo knows DirectX better then opengl

or possibly Opengl didn't have the features he wanted at the time?
 

Top