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)

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.


All times are GMT. The time now is 03:37 AM.

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