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

Reply
 
Thread Tools Display Modes
  #241  
Old 17th December 2015, 06:54 PM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 686
Default

Well whatever they are coded in,they're not in Native code like N64oid's Rice plugin.

BTW,any info for a port of PJ64 to Android,fzurita mentioned on Paulscode shoutbox that a port was being made,and it made me really curious.
An advantage would be a 64bit port for Aarch64 devices like NSTV,complete with the 64bit dynarec in a similar fashion to Dolphin Emu.

I am waiting on the day to see Banjo-Tooie run at a constant 60fps with lag fix,even at the oil rig ledge with seven Kazooie clones at the top.
When playing the game from the start,you'll need the code I made to control framerates in cutscenes to bypass moments where it softlocks until the activator is pressed.
You will also need activators to control the lag fix mode anyway because the JiggyWiggy challenges have crazy fast clocks from the demo buffer breaking the speed cap.

Last edited by retroben; 17th December 2015 at 06:56 PM.
Reply With Quote
  #242  
Old 18th December 2015, 05:16 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,029
Default

Quote:
Originally Posted by retroben View Post
Well whatever they are coded in,they're not in Native code like N64oid's Rice plugin.
How do you know?
Reply With Quote
  #243  
Old 18th December 2015, 08:11 AM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 686
Default

It was mentioned on Paulscode,from Paul knowing some details about it being in native programming.
That's why it looks so good on N64oid compared to Mupen64Plus AE's scotch print frames glitch.

Might have been mentioned in the shoutbox,meaning it would no longer be in there.
Whatever then.
Reply With Quote
  #244  
Old 18th December 2015, 05:45 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

Still doesn't change the fact that the plugins all are in native code, yongzh just has the benefit of using the improvements made by AE while not sharing any of his own code because he's an ass. So he might have optimized his port a little better.

Btw I assume you refer to this: http://www.paulscode.com/forum/index...12848#msg12848 there's no mention of native/not native, just of optimization, it might also be that he uses game specific hacks to speed it up, we wouldn't know.

Last edited by V1del; 18th December 2015 at 05:48 PM.
Reply With Quote
  #245  
Old 18th December 2015, 08:44 PM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 686
Default

One thing that really matters now to me is that Project64 may sooner or later be available on Android,and hopefully my "split-up anywhere" code that worked on a recent build still works within the Android port.
I can only hope there will be the interactive memory viewer alone or with memory search coded into the UI.

I still request that a dev would implement the dirty flag check for changed execution code values so Gameshark codes for them work better.
I may try to find that commit for Mupen64Plus to see if I can link it and the one before the change so it can be more effeciently observed.

Edit: Richard42's response on Jun 7 in Google Groups...

Quote:
I looked into this problem today and just committed a fix for it. The problem was that this particular GS code was modifying a word in memory which was not used for normal data but for executable r4300 code. For performance reasons, the Cached Interpreter and Dynarec pre-compute and store (in chunks of 4k pages) a bunch of things related to each instruction in a big data structure. When the code word was modified by the cheat code, the cheat engine did not mark the resulting code page as dirty, which forces a re-decode or re-compile of all the instructions in that page. Now it does; it was a simple fix.

Thanks for bringing this up; I'm sure this will fix a lot of codes which previously didn't work for us.

Richard
Here is the bugfix commit for cheats on the execution code addresses.

https://github.com/mupen64plus/mupen...1d585eb4bba5ea

I really hope this helps a lot.

The strong irony is that Conker re-allocates RAM when loading happens,and the 3C01 3F00 found at 0x802CD050 (Game Speed value) changes to completely different values during the loading of new areas and reverts back to that when in the next area.
On a recent build of PJ64,the value is reverted,but it doesn't respond to different speeds,making my "Game Speed" mod code not work correctly as it does on older PJ64 versions.
Succeeding in loading a savestate with the value pre-changed to 3E80,makes the game speed half the rate of normal,but with the code off and changing areas to make the value revert to 3F00 for normal speed,the actual speed doesn't update like it should and it perpetually stays at half the rate despite the changed value.

My guess is the issue is caused by how Virtual LUT works,making Gameshark codes less reliable for some reason.
Hopefully applying this change will fix a large number of codes that have trouble working correctly in realtime value changes due to being in execution code areas.

Last edited by retroben; 18th December 2015 at 09:32 PM. Reason: Many helpful details.
Reply With Quote
  #246  
Old 26th December 2015, 03:39 AM
retroben's Avatar
retroben retroben is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jul 2013
Posts: 686
Default

Since I got on Github (I am retrobenny on there) to post issues to GLideN64,I also posted an issue for the inconsistent Gameshark codes with the Mupen64Plus commit linked so devs can replicate what it does in the appropriate file.

Please find the time after Christmas to implement this feature/improvement into PJ64 so GS codes will work immensely better in realtime.
Reply With Quote
  #247  
Old 26th December 2015, 06:59 PM
shinra358 shinra358 is offline
Alpha Tester
Project Supporter
Member
 
Join Date: Jun 2011
Posts: 93
Default

The emu silent crashes when quitting the emu without first stopping emulation. Perhaps you can include stop emulation code in with the emu close code so that wouldn't happen. (aka, emulation stop first THEN the gui closes when you choose the option to close emu).

Also, a dropdown box to choose which rez to change your windows desktop rez to (not the game internal rez) when a game is activated would be nice.

Last edited by shinra358; 26th December 2015 at 07:02 PM.
Reply With Quote
  #248  
Old 27th December 2015, 03:32 AM
johnchrissy johnchrissy is offline
Junior Member
 
Join Date: Dec 2015
Posts: 7
Default

I'd like to see a fast-forward button or "limit FPS" button so I could skip the cimenatics.
Reply With Quote
  #249  
Old 27th December 2015, 08:32 AM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

@Johnchrissy F4 (you might have to untick hide advanced settings in the menu beforehand)
Reply With Quote
  #250  
Old 27th December 2015, 06:21 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,029
Talking

Quote:
Originally Posted by shinra358 View Post
The emu silent crashes when quitting the emu without first stopping emulation. Perhaps you can include stop emulation code in with the emu close code so that wouldn't happen. (aka, emulation stop first THEN the gui closes when you choose the option to close emu).
What plugins are you using? I have a feeling it might be that, although I haven't tested any recent builds (like the past month).
Reply With Quote
Reply

Tags
2.2, project64

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 04:37 PM.


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