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

Reply
 
Thread Tools Display Modes
  #1  
Old 21st August 2014, 06:31 PM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 687
Default Make good use of PJ64's opensourced-ness.

A lot of N64 emulators have an open source just waiting to be utilized for combining each emulator's best features into the PC equivalent of Surreal64.
Think of 1964's somewhat faster speed (in some cases) and overclocking capabilities and how they could be added into a PJ64 build.
It could be called PJ1964.

I am mainly calling out to anyone skilled enough at Android development to attempt porting parts of both 1964 and PJ64 to a version of Mupen64Plus AE.

Fact:PJ64 1.4 was partially ported to xbox with Surreal64.

The idea is to port the PJ64 Gameshark handler (should fix codes that refuse to work in Mupen) and the PJ64 core (would fix Banjo-Kazooie/Tooie and DK64) to Mupen64Plus AE so we can finally have a more functional N64 emulator for Android.

I'm stuck with only Android in gaming secrecy.
I am tired of all the force closing and glitching issues I get with Android (ARMv7) compared to the functionality of an x86/x32-x64 computer.
Also,any version of Mupen on Android runs Banjo-Kazooie/Tooie far too slowly and also randomly crashes into the menu.
Reply With Quote
  #2  
Old 21st August 2014, 08:08 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

This idea won't work if all you're concerned about is android.

Of course 1964 is faster than PJ64! No question! It's not easy to implement features from one emulator to another. It's hard enough porting things from different versions of the same product.

Tbh, the Mupen64plus team is your best bet. They've done some good things that no zilmar spec emulator has done. Idk why you think PJ64 & 1964 would be superior.

Is there any reason why you can't work on development yourself? That may be the only way it can happen. There are a lot of things I have to do myself, because no one else cares.
Reply With Quote
  #3  
Old 21st August 2014, 08:31 PM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 687
Default

I am too limited to even begin developing programs or apps because of the clunky old single-core,post-viruses PC I have temporary access to on a daily basis while I can't use it at all on Friday or Saturday.

There is one guy on Paulscode that compiled a fixed update for the Android Mupen,but it still can't run the Banjo games without freezing or crashing out of them.
It does however make the UngaBunga cave work now.

The superior PJ64 can run Banjo perfectly fine without crashing randomly and DK64 without missing collisions.

The 1964 emulator has a (rather slow and limited) port to javascript called 1964js,so it could be ported to Android if someone skilled enough (definitely not me) could somehow do it.
Reply With Quote
  #4  
Old 21st August 2014, 08:35 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Maybe? Ask mupen dev if they want mupen version of pj64.

Because not one pj64 developer on this forum even knows how to program for Linux/Android dude. "Know thy audience."
Reply With Quote
  #5  
Old 21st August 2014, 08:55 PM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 687
Default

Just figured maybe someone with experience of Windows AND also Android could read the internals of each emulator to find common code references that can be converted from PJ64 to Mupen64Plus AE.

Just someone who can look at both PJ64's and Mupen64Plus AE's Recompilers and R4300 Cores in their source codes enough to copy the differences that make the games run nearly flawlessly on PJ64.
Of course doing that would require crediting the PJ64 devs for those differences when compiled into Mupen.

I'll try asking about it again elsewhere to see if anyone can overhaul Android's pitiful state of N64 emulation.
Reply With Quote
  #6  
Old 21st August 2014, 08:58 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 HatCat View Post
Because not one pj64 developer on this forum even knows how to program for Linux/Android dude. "Know thy audience."
Agreed.
Quote:
Originally Posted by retroben View Post
I am too limited to even begin developing programs or apps because of the clunky old single-core,post-viruses PC I have temporary access to on a daily basis while I can't use it at all on Friday or Saturday.

The 1964 emulator has a (rather slow and limited) port to javascript called 1964js,so it could be ported to Android if someone skilled enough (definitely not me) could somehow do it.
Dude, there's nothing wrong with single core! You get more fps than I do, for SM64 ;/ .

I defo wouldn't bother with 1964js. I'm curious though, have you tried using interpreter for android? I'm wondering if the problem is solely the recompiler. I know you probably won't be able to run full speed, but at least see if you still have the same issues.

Quote:
Originally Posted by retroben View Post
The superior PJ64 can run Banjo perfectly fine without crashing randomly and DK64 without missing collisions.
Are you really comparing Mupen64AE to PJ64 2.1? You can't just compare software made for different architectures & OS.

Time is important, so I'll give you that. I still think if you even have a few hours to spare, programming is worth doing. You'd be surprised what fixes you can do in a small amount of time. Now that I'm really into programming, I'm a lot more productive now. It would have been great if I started programming at a young age, instead of wasting time watching mediocre cartoons. But back then I had limited access to a computer ;/ .

Look man, you can't just copy code. The recompiler will be totally different. The interpreter is another story though. Which is also why I'm curious.

Since I'm learning about interpreters and recompilers, I might as well explain why you can't just port code that was written for another architecture.
Code:
void Compile_ADDIU ( void ) {
	int Immediate = (short)RSPOpC.immediate;

	#ifndef Compile_Immediates
	Cheat_r4300iOpcode(RSP_Opcode_ADDIU,"RSP_Opcode_ADDIU"); return;
	#endif

	CPU_Message("  %X %s",CompilePC,RSPOpcodeName(RSPOpC.Hex,CompilePC));

	if (RSPOpC.rt == 0) return;

	if (RSPOpC.rt == RSPOpC.rs) {
		AddConstToVariable(Immediate, &RSP_GPR[RSPOpC.rt].UW, GPR_Name(RSPOpC.rt));
	} else if (RSPOpC.rs == 0) {
		MoveConstToVariable(Immediate, &RSP_GPR[RSPOpC.rt].UW, GPR_Name(RSPOpC.rt));
	} else {
		MoveVariableToX86reg(&RSP_GPR[RSPOpC.rs].UW, GPR_Name(RSPOpC.rs), x86_EAX);
		AddConstToX86Reg(x86_EAX, Immediate);
		MoveX86regToVariable(x86_EAX, &RSP_GPR[RSPOpC.rt].UW, GPR_Name(RSPOpC.rt));
	}
}
Please explain how I'd be able to use code like this for android?

Iirc, Andriod uses ARM, which is a RISC, so code like AddConstToVariable(Immediate, &RSP_GPR[RSPOpC.rt].UW, GPR_Name(RSPOpC.rt)); wouldn't even work. Looking at PJ64's recompiler would actually be a waste of time.

One interesting thing is, I wonder why they never added an if statement to check if Immediate == 0. Beats me tbh, but that just proves to me how much room for improvement there is in PJ64's RSP recompiler .

Last edited by RPGMaster; 21st August 2014 at 09:32 PM.
Reply With Quote
  #7  
Old 21st August 2014, 09:59 PM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 687
Default

I got higher FPS on SM64 probably because of all the tweaks and mods i've done including PCI enhancement,various registry hacks,and mild overclocking to kill the lag and boost performance after the times it got viruses and malware.

I'd figure it would only need the ARM equivalents of the x86 instructions,and if none are available,workarounds would be needed.
Sure,this would take so much more time and effort,but would get an awesome end-result like DraStic and Reicast proved with complete rewrites from x86 to ARM.

I think my PC is on the verge of dying since I got a horrible lag after
-->PJ64<-- failed to reset Goldeneye on the Jabo 1.6.1 plugin when I enabled the infinite health cheat. (don't judge me,I don' have a controller with analog)
The mouse cursor was getting a horrible framerate when PJ64 seized up.
PJ64 usually never causes that.

I'm not comparing Mupen and PJ64 by speed/performance,but by stability in the emulator cores and recompilers themselves.

The Mupen64Plus AE issues are only in Recompiler,and get resolved when Interpreter is used since DK64 has working collisions on Interpreter.
Interpreter is much too slow to test the Banjo random crashing issue without taking several hours of sluggish gameplay.
PS1 emulation is loads faster on my Fire TV compared to every variation of Mupen on the same device.
Spee-ro can even be fast-forwarded past double fps.

I really wished that Intel's ARM to x86 real-time conversion method had a reverse engineered counterpart for running x86 programming on ARM devices.
Reply With Quote
  #8  
Old 21st August 2014, 10:20 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

The recompiler is highly architecture specific you can just shit out a PJ64 variant on ARM and expect it to have the same compatibility, if such a port is at all feasible. None of the issues are present with m64p x86 dynarec but again even this one couldn't simply be ported, the ARM dynarec is something entirely new.
Reply With Quote
  #9  
Old 21st August 2014, 10:27 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Viruses must be karma . Dunno why people these days get so many viruses . You should just system restore or reformat computer ;/ .

Anyway, I think you're missing the point. Mupen64AE's problem is that the developers don't know the architecture well enough. Reading PJ64's Recompiler source is not going to help one bit. Tbqh, I think Mupen64Pluses recompiler is probably better than PJ64's anyway. It may be slower, but it's more accurate, so your solution does not work.

Like I said, the only thing you can really learn from, is code that actually works on your target architecture. Since interpreters are generally written in portable code, you could learn from that, and apply it to the recompiler. I wouldn't bother even looking at PJ64's interpreter. It's the absolute slowest one out there, besides emulators from a decade ago. Not to mention it's not even the most accurate. So again, PJ64 is not ideal.

The reason I'm studying PJ64's RSP recompiler is because all I care about atm is x86/64 architecture, and I believe I could apply some quick fixes so that I can get better performance & compatibility. It's also a good learning process for me. Eventually it will be a waste of time to even base an RSP off of PJ64's. It's only worth it to test ideas out and apply minor changes. And man was HatCat right about PJ64's RSP interpreter. Thank goodness HatCat's RSP is much more accurate, efficient, and readable, so I'm actually confident that I'll be able to either fix up PJ64's RSP, write a recompiler from scratch. It really just depends how much free time I have. After reading the source, I think I'm much better off doing a recompiler from scratch. I don't even think I'd want to use MMX, since I have SSE4 support . It's also fun experimenting with 1964 Audio's HLE code. For now I'm focusing on the simpler opcodes.

If anyone cared enough, someone would have already fixed these issues you mentioned. People don't even care enough to improve x86 emulators, what makes you think they'd care about Android? For pete's sake, PJ64 doesn't even have a test button... And the GUI is still buggy.
Reply With Quote
  #10  
Old 22nd August 2014, 01:01 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Now it makes sense why they don't check for certain things in PJ64's RSP recompiler. It's because Jabo/Zilmar probably looked at RSP code of various games. It seems as though the main focus was audio, so I'll have to check every single gfx microcode for edge cases to see if my extra checks will ever be of use.

Anyone have a list of all the gfx microcodes? All I want are just the game titles associated with them. Printing out the disassembly code and control-f is trivial . I'll also have to check the 2 Audio microcodes I haven't looked at.

Based on the 17 audio microcodes from 1964's HLE audio, I can see that PJ64 RSP recompiler left out a few optimization cases, in the recompilation process. I haven't really even looked at the vector instructions yet.

Last edited by RPGMaster; 22nd August 2014 at 04:05 AM.
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 09:08 PM.


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