Project64 Forums

Project64 Forums (http://forum.pj64-emu.com/index.php)
-   Project 64 - v2.x - Suggestions (http://forum.pj64-emu.com/forumdisplay.php?f=7)
-   -   Project64 as a x64 exclusive? (64 bit OS) (http://forum.pj64-emu.com/showthread.php?t=4053)

Con 13th September 2013 02:49 AM

Project64 as a x64 exclusive? (64 bit OS)
 
Hey, I was wondering if a x64 (PC architecture) CPU version of Project64 would ever be made?

If so, what benefits could come of using Project64 as a 64bit application?

uyjulian 13th September 2013 04:18 PM

nope... project64 is really outdated and buggy, you should try mupen64plus.

the_randomizer 13th September 2013 05:45 PM

Quote:

Originally Posted by uyjulian (Post 50003)
nope... project64 is really outdated and buggy, you should try mupen64plus.

With a GUI frontend. CLI-only sucks.

HatCat 14th September 2013 04:02 AM

I like to invoke the old Mupen64 in pure CLI without using the Win32 GUI made by Shadowprince. :)

</trollin>

</butalsokindaseriousXP>

the_randomizer 14th September 2013 04:30 AM

Quote:

Originally Posted by BatCat (Post 50012)
I like to invoke the old Mupen64 in pure CLI without using the Win32 GUI made by Shadowprince. :)

</trollin>

</butalsokindaseriousXP>

I see what you did there....

HatCat 14th September 2013 05:36 AM

How am I supposed to get some honiez with the GUI?

When I'm like, "Yo baby, look at mah gooey!", you know what they say to me?
They fukken laugh!

When I show them that CLI...
...ahhh...
Get ALL da honiez with dat CLI! :D

autofire372 15th September 2013 12:34 AM

Yeah, I for one will never use Mupen64Plus, as I have never been able to get any of its GUI frontends working on Windows, HATE operating from the command line, and don't want to have to boot into Linux Mint every time I want to play some N64. Even if it did have a working GUI on Windows, there remains the fact that Mupen's input plugin still lacks support for rumble on anything other than Linux. I consider its lack of transfer pak emulation (yes, I do occasionally play Pokémon Stadium) to be a deal breaker as well.

HatCat 15th September 2013 12:39 AM

If there is a working GUI for Mupen64Plus on Windows, that means you could just change the input plugin to something which does support the transfer pak, like N-Rage's DirectInput.

And there are several things you can do in CLI which you can't do using a GUI.
Like using a flexible batch commands script to invoke multiple parameters at once to a program's function, rather than clicking, dragging and typing a crap load of things in a GUI.

But, personal point of view. Not saying you're wrong.

autofire372 15th September 2013 12:48 AM

I think mupen64plus doesn't follow zilmar's plugin spec, meaning it is incompatible with N-Rage...

HatCat 15th September 2013 01:00 AM

It is still based closely on the zilmar plugin spec, so porting the plugin over would not be difficult work at all.
They omitted zilmar from the spec file credits though, even though they obviously resemble his.

the_randomizer 15th September 2013 01:13 AM

Quote:

Originally Posted by BatCat (Post 50042)
If there is a working GUI for Mupen64Plus on Windows, that means you could just change the input plugin to something which does support the transfer pak, like N-Rage's DirectInput.

And there are several things you can do in CLI which you can't do using a GUI.
Like using a flexible batch commands script to invoke multiple parameters at once to a program's function, rather than clicking, dragging and typing a crap load of things in a GUI.

But, personal point of view. Not saying you're wrong.

Not at all, to each their own. Hatax does have a GUI for Mupen64 and I aim to use that. :D Sure as hell a lot better then other GUI frontends I've used for that emulator. As for PJ64, yeah....a lot of crap has to be done to fix it, I don't even know what's wrong with it to be honest. :confused:

squall_leonhart 15th September 2013 06:51 AM

there is no benefits you can get out of making the emulator 64bit, that you can't already achieve by hand writing SSE optimisations.

V1del 16th September 2013 10:01 AM

Quote:

Originally Posted by BatCat (Post 50046)
It is still based closely on the zilmar plugin spec, so porting the plugin over would not be difficult work at all.
They omitted zilmar from the spec file credits though, even though they obviously resemble his.

https://bitbucket.org/richard42/mupe...=default#cl-23
dat not enuff? I'm not entirely familiar with how per file credits/licensing should be handled, but the specs are already different in the fact that they never assume DLLs unlike Zilmar's

Quote:

Originally Posted by autofire372
...Mupen's input plugin still lacks support for rumble on anything other than Linux...

https://bitbucket.org/richard42/mupe...777e6206948e21

https://bitbucket.org/richard42/mupe...4cf1396be8cff5

:confused:

Regarding the GUI on Win, I'm currently trying to find out what's wrong with the m64py build, in the meantime use WinMupen, works like a charm.

And again Zilmar's spec <--> Mupen64plus relatively easy, DirectInput --> SDL a different story and having all kinds of platform-bound plugins on a supposedly multiplatform emulator is kinda against the point

Not trying to convince you to switch back to mupen if you're happy with PJ64, but please don't spread FUD

OnTopic:

If you want a 64bit emulator, you can use mupen64plus. But as others have noted there are no visible benefits to doing so in terms of speed or compatibility (except for maybe being able to use large hi-res packs without bothering with large adress aware patching and similar stuff)

HatCat 16th September 2013 05:01 PM

Quote:

Originally Posted by V1del (Post 50080)
https://bitbucket.org/richard42/mupe...=default#cl-23
dat not enuff? I'm not entirely familiar with how per file credits/licensing should be handled, but the specs are already different in the fact that they never assume DLLs unlike Zilmar's

Duh, because we don't build/run DLLs on Linux. Might need Windows for that?

Does that mean that the specs are entirely different from zilmar's original, just because of what you said?
No, it makes it for a different OS, with only a few modifications.

And my point was that they omitted zilmar from the plugin spec file credits, not the original Mupen64 greets/credits that Hacktarux might have wrote beforehand, or whatever that was you linked to.

https://bitbucket.org/richard42/mupe...t=default#cl-4
No mention of zilmar anywhere in the spec file, even though it resembles zilmar's.

HatCat 16th September 2013 05:08 PM

Yeah, actually the real spec file was here.

https://bitbucket.org/richard42/mupe..._plugin.h#cl-3
(as of when they fixed zilmar's "TANSFER" typo say "TRANSFER")

Still no credit of him.

It's a conspiracy. :p

Kind of serves his right for having shitty spelling on the other hand anyway.

V1del 16th September 2013 07:24 PM

Whelp I'm not that involved, if it was me I would have kept the credit there, and no I don't really see the change from implicitly stating dlls (as in Win *.dll, because you always have to take everything so literally :p ) as that groundbreakingly different (iirc the main reason for switching was the requirement that plugins all were expected to have their own config and own ways of editing them which they wanted to harmonise to facilitate porting to other platforms)

It was simply a question if this isn't enough of a recognition already, but I see your point and don't intend to get into a giant argument if this is the right or wrong way of handling this

FYI the license file I linked to wasn't written by Hacktarux, but by the mupen64plus devs. I quickly checked the mupen source, it's not there (the GPL is, but not the recognition of who helped with everything)

HatCat 16th September 2013 08:18 PM

Then I'm guessing you meant to imply that Mupen64Plus uses statically linked objects for plugins, rather than externally/dynamically linked objects "DLL files" like the zilmar spec does.

Wouldn't know, never tried Mupen64Plus since that thread that guy made.

Even so, all I said originally is that their spec is still closely similar, not that it has no differences.

Quote:

Originally Posted by V1del (Post 50090)
FYI the license file I linked to wasn't written by Hacktarux, but by the mupen64plus devs. I quickly checked the mupen source, it's not there (the GPL is, but not the recognition of who helped with everything)

Probably not written by him, cause I'm not even sure how most of those names got on that list.

In the About selection of the emulator it just states Hacktarux as the author, with credit to various helpers and those who did the OS ports, none of which are on that list you linked.

I don't know how Dave2001, Zilmar, JttL ... what part of the Mupen64 code was originally written by them, besides plugins?

My question of course isn't entirely rhetorical, because I don't really know.
To my finite depth of reading mupen source, the only Mupen64 v0.5 code, "originally written by" zilmar, for example as they say, would be the plugin system source.

So I don't know where they get this shit from, and I'm not very concerned anyway.

V1del 17th September 2013 09:08 AM

Naw I didn't mean to say that, ofc mupen's still using dynamic libs, what I meant is that Zil's spec ultimately assumes you're running Windows, although that part isn't that hard to circumvent obviously.
It simply was an honest question if this is not enough recognition already, as I don't know how it should be handled (does Zil's spec have some clause that he HAS to be mentioned?).

In the end it doesn't really matter, you think it's a conspiracy, I think whatev it's in the LICENSE.txt included everywhere and if any of us had fucks left to give we could call out the m64plus devs to shed some light on this, but alas we don't and zilmar most likely DGAF so it will probably always remain a mistery/point of controversy :p

HatCat 17th September 2013 05:51 PM

Quote:

Originally Posted by V1del (Post 50100)
Naw I didn't mean to say that, ofc mupen's still using dynamic libs, what I meant is that Zil's spec ultimately assumes you're running Windows, although that part isn't that hard to circumvent obviously.

Well if that's all you meant then it doesn't really seem worth mentioning.
In fact I didn't have any trouble converting the Rsp_#1.1.h zilmar spec include in my RSP emulator to be purely cross-platform.

Quote:

Originally Posted by V1del (Post 50100)
It simply was an honest question if this is not enough recognition already, as I don't know how it should be handled (does Zil's spec have some clause that he HAS to be mentioned?).

Mupen64 1.5 was not written by zilmar, Dave2001, or anyone else on that list besides Hacktarux, to my knowledge.
They could maybe have included the names of all the people who helped port MUPEN to each OS, but they didn't even do that instead.

So your question of "Is that enough credit?" seems maybe like not the right question.
Giving too much credit in the wrong places and no credit at all in the right places is just a matter of disorganization.

It's not my concern, and I mostly called it a conspiracy for trolling purposes. :p

Quote:

Originally Posted by V1del (Post 50100)
In the end it doesn't really matter, you think it's a conspiracy, I think whatev it's in the LICENSE.txt included everywhere and if any of us had fucks left to give we could call out the m64plus devs to shed some light on this, but alas we don't and zilmar most likely DGAF so it will probably always remain a mistery/point of controversy :p

It beats me why zilmar refused to just make the plugin specs portable and multi-OS to begin with.
So like I said, if anything it serves him right.

I'm only a few baby steps above his DGAF viewpoint you are describing. :D
It's not my problem, and I only pointed it out of confusion XD.

Part of me doesn't even want them to fix it.
I'm sure they've at least organized something right there.

retroben 27th August 2014 09:58 PM

I REVIVE YOU! :eek:

Better than making a new topic. :D

Since open sourced 2.x is available now,I would like to see a 64bit version of PJ64 get made.

When I use the 64bit branch of Chrome,it runs a bit faster than the original 32bit Chrome.

HatCat 27th August 2014 10:06 PM

When you used 64-bit Chrome, your ass got molested 64 times.
They come and drug you in your sleep so that you wake up and your senses are all dulled down, therefore 64-bit version of their product seems eve faster than 32-bit version. In fact it is, so that you can hurry up and get infected faster.

Anyway for once I agree with you. There should be a 64-bit version of this emulator so that complex RCP emulation (even in HLE) can take advantage of x86 64-bit instruction set. That, and main r4k on n64 has 64-bit instructions. I'm mostly just in for the plugins tho.

RPGMaster 27th August 2014 10:41 PM

Quote:

Originally Posted by retroben (Post 56777)
Since open sourced 2.x is available now,I would like to see a 64bit version of PJ64 get made.

When I use the 64bit branch of Chrome,it runs a bit faster than the original 32bit Chrome.

Too bad no one has done anything with PJ64 2.1's source, aside from that fruity edition nonsense.

I do wonder how much faster LLE video plugins would be with 64 bit. Emulators would be a bit easier to write too.


All times are GMT. The time now is 02:49 AM.

Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.