Go Back   Project64 Forums > Public Version > Project 64 - v2.x - Suggestions

Reply
 
Thread Tools Display Modes
  #21  
Old 17th November 2014, 04:57 PM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 687
Default

PJ64 could always be ported to Android (x86) first,then eventually cross-compiled to ARM bit-by-bit.

Part of that is how DK64 now runs near flawlessly (if not perfect)
on Mupen64Plus AE since they tested things in x86 before converting the data to the ARM version.

If only PJ64 would expand like Dolphin with thousands of revisions.
(not comparing emulators,just the amount of opensource devs)
Reply With Quote
  #22  
Old 17th November 2014, 07:31 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by retroben View Post
Gotta bring this up again since porting just became a lot less difficult if I understand correctly.
PJ64 primarily uses .NET Framework,right?
Lol, PJ64 does not use .net (thank goodness!)
Quote:
Originally Posted by retroben View Post
At least there already is so much progress with Mupen64Plus AE since DK64 collision has been completely fixed and Banjo-Tooie is now crashless for me after play-testing it for twelve hours straight! (got to just before fighting Weldar)
Do i have to keep repeating myself, when I say that the problem is their knowledge of assembly? First of all, PJ64's recompiler is not even that stable. I wouldn't even use it as a base. It's best to start with an accurate recompiler and slowly optimize it over-time.

Once it's accurate, then it would be a good idea to learn techniques from these other recompilers that seem to prioritize performance (1964 and PJ64).
Quote:
Originally Posted by retroben View Post
I wonder if PCSX2 is now more capable of being ported,even if it is incredibly slow.
(Dolphin Emulator for Gamecube AND Wii got ported to Android)
Like V1del said, you can't compare these different emulators.

Quote:
Originally Posted by retroben View Post
PJ64 could always be ported to Android (x86) first,then eventually cross-compiled to ARM bit-by-bit.

Part of that is how DK64 now runs near flawlessly (if not perfect)
on Mupen64Plus AE since they tested things in x86 before converting the data to the ARM version.

If only PJ64 would expand like Dolphin with thousands of revisions.
(not comparing emulators,just the amount of opensource devs)
Lol dude.. I don't think you understand how it works. If it was this simple, why aren't developers doing this? Either everyone's brain dead, or your idea just doesn't work. It's true that there are cases where I believe the devs are to blame, but I don't think this is one of them. The idea of "cross compiling to andriod bit-by-bit", is not a good one.

And I'll say it again. Knowledge of x86 will not do you much good, when making a recompiler for ARM. The best way to make a good recompiler is to first fully understand the interpreter. This has been true for me, in my experience. I don't see any real point in testing in x86 first. The concept doesn't even make sense to me. If you make a recompiler that works as similar to the interpreter as possible, then you're in good hands.

If you have a proper debugger for ARM or w/e, then there's no need to test in x86 first.

Again there are only 2 real things needed for a recompiler. 1, a good interpreter base and 2, a good amount of knowledge in the target architecture. Pretty sure #1 is covered, as even the original mupen64 had a good interpreter, so #2 is likely the issue.

I don't understand the mentality of doing nothing while hoping other people do all the work. Ideally sure it's nice, but it's also unrealistic!
Reply With Quote
  #23  
Old 17th November 2014, 08:17 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

Quote:
Originally Posted by retroben View Post
Part of that is how DK64 now runs near flawlessly (if not perfect)
on Mupen64Plus AE since they tested things in x86 before converting the data to the ARM version.
And thats also a big reason, mupen is already there! Why would anyone go through the shitton of work required to get PJ64 to a portable state when all of that has already happened with mupen? What benefits are you expecting from that? The compatibility? Would probably go down the drain because you'd need a new recompiler/core anyway. The speed? Will most definitely go down the drain because of a new recompiler and the non portability of x86 assembler which would have to be rewritten in higher level languages or an equivalent in arm assembly (with most likely different results in speed).

I don't mean to discourage you, it's cool that you'd like to see some development happen, but you have to understand that porting PJ64 would come akin to making a complete rewrite, it wouldn't be PJ64 anymore and I doubt that anyone wants to do this monumental task, especially as there already exists a working solution that can use help to get it to a better state
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 01:45 PM.


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