Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - retroben

Pages: [1]
1
Support / Distorted sounds from things offscreen.
« on: December 01, 2014, 02:07:41 PM »
It caught me off guard the first time it happenned.

It happens in Super Smash Bros. and Banjo-Kazooie mostly.
This is only on xperia64's build and Gillou's build while the stable version's sound is very different and lacks the issue.

Here is a savestate of Banjo-Kazooie (U) (V1.0) with the issue in TTC near a treasure chest enemy.

http://www.2shared.com/file/K1gO6S_n/Banjo_Kazzzrt.html

To your left,you will hear a dying treasure chest,looking at it makes it feel okay.  ;D

2
Support / Needed fixes before the new plugin.
« on: September 28, 2014, 02:42:11 AM »
Just listing some stuff I hope to see fixed in updates.

Ordinary:
Loading a savestate multiple times gradually bogs down performance,forcing the user to restart the game and load the savestate again.

Convenient:
Improved performance with intense stuff like Banjo-Tooie while using my "no frameskip" code.

Important:
Certain games randomly exiting to menu or freezing out of nowhere. (Banjo-Kazooie/Tooie)
Collissions in DK64 on Recompiler. (game otherwise runs perfectly,even with real system based slowdown physics)

Others may reply with their own globally caused issues to help even further.

Wanted really badly:
Better Gameshark logic,I can't get my 81120000 Banjo-Tooie codes to work with activators like they do in PJ64.

These codes work...

master code
81092BE0 0804
81092BE2 8000
81120200 03E0
81120202 0008
Required for 8112000x codes.

Never Slide On Slopes
81120000 3C0E
81120002 0000
81120004 AC8E
81120006 07C8
Requires the master code.
Try climbing up the Honey B.'s giant beehive in the Plateau.

Camera Type (example code)
81120000 3C0E
81120002 xx00
81120004 AC8E
81120006 02DC
Requires the master code.
Camera C-buttons are stuck as a side-effect,but can still go into 1st person with C-up.
00=Normal
01=Frozen
02=Cull?
03=Fly Camera
04=1st person (weird)
05=Follow Cam
06/07=Frozen
08=Swim Camera
09=Frozen
0A=Close-up (door camera)
0B=Frozen
0C=Map Center
0D-11=Frozen
12=Centered Follow
13=Far View
14=Klungo Battles?
15=Rotate-to-focus
16=Analog-less Cull
17=Kazooie's Glide
18=Lower Cam (R lowers)
19=Another Camera

Not working with camera code plus activators...

Camera Type
81120000 3C0E
81120004 AC8E
81120006 02DC
For the code below.

Camera Types (D-pad up and down)
D0081084 0008
81120002 0500
D0081084 0004
81120002 0A00
Used with code just above,not working on Android for me,but should work on PJ64.
Up for Follow Cam and down for Close-up (door camera)
Remember to go in 1st person with C-up to refresh the camera after switching to desired camera type.

3
General Discussion / How was Mupen64Plus AE made?
« on: September 21, 2014, 01:16:55 PM »
To speculate what I mean,was it ported as is or was it heavily tweaked and customized before porting it to Android?

I am asking this because I have an idea for improving it by making a really strong MOD of the original Mupen64Plus with major performance boosts,fixed stability issues for DK64/Banjo-Kazooie/Banjo-Tooie plus other games,and the best idea that just came to mind...

Port various parts of PJ64 into the original Mupen64Plus and then port that to Android!
Unless this is too complicated because of architecture changes.

The idea is to make all the best enhancements and fixes on Linux BEFORE porting it to Android,then tweak some more.
Or I guess you could merge part of the current latest source to get all of the Android bits on it.

Just brainstorming with geniusy ideas.

Edit:I know that Mupen64Plus AE is actually way slower than first anticipated since setting the cycles per operation to 1 for the smoothest framerates causes horrendous slowdown.
Doing so causes massive slowdown while 2 is a mix of both 0 (automatic) and 1 cycle.
I wished it ran faster.

4
Support / Make use of 1964's and PJ64's opensource-edness.
« on: August 21, 2014, 09:56:22 PM »
Mupen64Plus AE could really use PJ64's Recompiler stability and maybe 1964's overclocking feature.
Someone with both x86/x32-x64 and Android knowledge could read PJ64's and Mupen64Plus AE's source codes and implement stuff from PJ64's source into Mupen64Plus AE to fix its short-comings.

I think it might be possible to convert PJ64's x86 RSP instructions to the ARM equivalent instructions so they can be used to make Banjo-Tooie stop crashing randomly as often and give DK64 proper collisions plus many other fixes.

Are there any Android devs out there with ASM knowledge that can attempt to greatly improve Mupen64Plus AE as a whole?

Again,maybe someone could add a PJ64-like function of "Sync Cores" so that it can use both Interpreter and Recompiler simultaneously for faster performance of decently more accurate emulation.
If this can be achieved,DK64 could run at a more decent speed with collisions intact,and maybe Banjo-Tooie could stop crashing so often.

I just really want to see an improvement of N64 emulation on the Android platform.
Somebody should try to make dualcore/quadcore enhancements work with Mupen64Plus AE.
Since an actual N64 uses two 32bit engines,why can't an emulator split their emulated forms into dual-cored multi-threading to majorly boost performance?

5
Support / Gameshark issues.
« on: August 21, 2014, 12:25:22 AM »
A Gameshark code that is proved to be a working code does not work in Mupen64Plus AE.
(there is an old GSCentral video on YouTube from 2011 showcasing it)
Just Google "Super Mario 64 robot sound" without the quotes to find the video.

Super Mario 64 (U)

Mario sounds like robot from jedi
A032CCDD 00FF
(name shortened)

The Fastest Game code works in Mupen64Plus AE,and it also uses A0 instead of 80.
I also have a "strange sounds" code working on M64+AE,so it's not failing on every audio-related code.

I've used these codes on PJ64 and they worked,but Mupen64 fails to comply.
This is really making me furious since I wanted to use these codes again without needing my PC.

How can this be fixed?
Can the Gameshark engine from the open-source PJ64 2.x be ported so the other codes would work?

6
General Discussion / Wii64/Not64 Android port?
« on: August 03, 2014, 02:02:25 PM »
This is an excellent idea since DK64 has proper collisions on Wii64 and also has decent performance,even in its limited RAM access.
I made it mostly through Angry Aztec with the wonky camera caused by GlN64.

If Wii64/Not64 is ported to Android,it can benefit from Rice and Glide64 since they both fix the camera glitch.
The main reason to port Wii64 to Android is because the Recompiler can run DK64 with the collisions intact,and with amazing performance in the limited RAM.

Maybe DK64 could also save correctly instead of not saving at all.

In PJ64,the camera issue in DK64 is caused by the Virtual Lookup Table,and fixing the issue only requires you to switch it to the Physical Lookup Table.

If I remember correctly,the Unga Bunga cave also worked on Wii64.

Anyone capable of this feat,please make this Wii64/Not64 port to Android (AND64) happen.

Pages: [1]