|
|
GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion GoldenEye Cheats, GoldenEye X Codes, Tips, Help, Nintendo 64 Gaming Community
|
|
|
|
|
|
|
|
|
|
|
pavarini 00 Agent
Joined: 07 May 2015 Posts: 479
|
Posted: Mon Jan 15, 2018 4:41 am Post subject: |
|
|
eb1560 wrote: | pavarini wrote: | Could you try Perfect Dark (USA 1.1) using this code? 8138CEB6 0008 8138CECE F0D0 |
After I applied this code, the game’s pace slowed down, 1:00 of the mission timer equates to 1:30 on my cell phone’s stopwatch. The game locked up in one instance when a combat simulator match was starting up (vs 8 meatsims).
I also tested your code using a jumper pack and no enable codes, in this scenario, the game’s pace seems to be the same as 3.0x. However, the game would always lock-up within a couple of minutes in a combat simulator match with 8 meatsims – though the music would continue to play in the background.
So far, the only games that have crashed/locked up with this CPU setup are GE and PD, the latter game only while using your GS code. Crashes happen infrequently and randomly. In one instance on Streets I tried driving the tank through a narrow alleyway, right as I collided with the alleyway’s walls, the game froze – after repeated attempts, I was unable to replicate the crash. Interestingly, a reset is enough to the restart GE, it didn’t require the console to be powered off – to me this suggests the overclock (hardware) is very stable, the game may be running into some issues with the faster processor speed. |
Thank you for testing. The code itself is changing lines 7F16CEB4/7F16CECC which is the master clock of the game (2FAF0, the gs code will set to 8F0D0). This is TLB'd at 8038CEB4/8038CECC during runtime. It is probably allocated to a different region in 4MB mode, which is why it didn't work.
I'd like to know, was there any noticeable FPS improvement with the code? And if you can try again, use this code 8138CEB6 0006 8138CECE B49C |
|
|
|
|
|
|
|
|
|
|
eb1560 Agent
Joined: 10 Sep 2016 Posts: 23 Location: North America |
Posted: Mon Jan 15, 2018 8:20 pm Post subject: |
|
|
pavarini wrote: |
Thank you for testing. The code itself is changing lines 7F16CEB4/7F16CECC which is the master clock of the game (2FAF0, the gs code will set to 8F0D0). This is TLB'd at 8038CEB4/8038CECC during runtime. It is probably allocated to a different region in 4MB mode, which is why it didn't work.
I'd like to know, was there any noticeable FPS improvement with the code? And if you can try again, use this code 8138CEB6 0006 8138CECE B49C |
I uploaded a video on your second code (hi-res mode activated), the game is faster paced than before, approximately 88.88% of normalized pace. I cannot tell if there are any major performance improvements – subjectively, I think not.
DataDyne Defection (88.88% Normalization): https://youtu.be/jA49B4SzI90
Game timer = Cell phone stopwatch
80 sec = 90 sec
120 sec = 135 sec
160 sec = 180 sec |
|
|
|
|
|
|
|
|
|
|
pavarini 00 Agent
Joined: 07 May 2015 Posts: 479
|
Posted: Mon Jan 15, 2018 9:18 pm Post subject: |
|
|
It appears to be bottlenecked by the RDP |
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Tue Jan 16, 2018 1:13 am Post subject: |
|
|
pavarini wrote: | It appears to be bottlenecked by the RDP |
Sadly it really does seem as such. I was hoping so hard that something like this would forcibly push through extra frames (say a dynamic framework) but potentially these games are just too well programmed. _________________ No Mr. Bond, I expect you to be re-coded! |
|
|
|
|
|
|
|
|
|
|
Trevor 007
Joined: 15 Jan 2010 Posts: 926 Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest |
Posted: Tue Jan 16, 2018 5:29 pm Post subject: |
|
|
But didn't we already know it was the RCP that was the bottleneck?
That's why I was hoping for the RCP overclock rather than the CPU.
All those games that don't suffer from CPU overclock don't nessesarelly run higher FPS since they too suffer from RDP Fillrate, but they are timed by VI (which is why PAL is slower for them) which was never a good practice for games.
What the benefit of CPU overclock brings (provided the code can handle it and not go crazy like SOTE) is better AI since they can work out their next event faster and have more bullet tragectories calculated after the CPU has sent its Display List to the RCP.
But otherwise, to get better FPS we need the make the RDP side of the RCP running faster.
If I remember correctly, increasing RCP clock also increases CPU (since CPU is 1.5x RCP) so it does everything we want.
Even if the RAM slows down.
Trev _________________
|
|
|
|
|
|
|
|
|
|
|
AL64inthedark 00 Agent
Joined: 18 Sep 2014 Posts: 548 Location: France |
Posted: Wed Jan 17, 2018 1:13 am Post subject: |
|
|
Quote: | What the benefit of CPU overclock brings (provided the code can handle it and not go crazy like SOTE) is better AI since they can work out their next event faster and have more bullet tragectories calculated after the CPU has sent its Display List to the RCP. |
Then wouldn't there be less framedrop when there is ? Especially when the game really slow down, like shooting very close to the wall or something. _________________ Listen to me
https://youtu.be/BzZ3k3NmhLM?t=25m51s |
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Wed Jan 17, 2018 1:27 pm Post subject: |
|
|
Trevor wrote: | But didn't we already know it was the RCP that was the bottleneck?
|
Pretty much - I know many members of the community (myself included) have messed around with different clocks and essentially we've all ended up with the same result. The "magic sauce" would be getting an uncorrupted image out of the other end after upping the crystal - my gut says that the cause is a mixture of issues with a bit of a "magic timing ratio" that the N64 was built around. _________________ No Mr. Bond, I expect you to be re-coded! |
|
|
|
|
|
|
|
|
|
|
Trevor 007
Joined: 15 Jan 2010 Posts: 926 Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest |
Posted: Wed Jan 17, 2018 1:30 pm Post subject: |
|
|
AL64inthedark wrote: | Quote: | What the benefit of CPU overclock brings (provided the code can handle it and not go crazy like SOTE) is better AI since they can work out their next event faster and have more bullet tragectories calculated after the CPU has sent its Display List to the RCP. |
Then wouldn't there be less framedrop when there is ? Especially when the game really slow down, like shooting very close to the wall or something. |
Nope, its still RDP that's causing that problem, not CPU.
If you stand next to a wall and fire without BG or Props being displayed then there is no problem, you get 30fps (gun still draws and tracers and muzzleflash are alpha composits requiring lots of ram re-writes othewise would be 60fps)
Guards can hear you and even fire at you and it will still not slow down.
Turn BG and props back on and suddenly it crawls again because the RDP is drawing and the CPU has to wait on it finishing.
Trev _________________
|
|
|
|
|
|
|
|
|
|
|
eb1560 Agent
Joined: 10 Sep 2016 Posts: 23 Location: North America |
Posted: Sat Feb 03, 2018 9:32 pm Post subject: |
|
|
I tampered with Perfect Dark’s game clock settings using my GS while performing a Xtal overclock on my non-3x CPU console. The game’s framerate does improve noticeably once the overclocked CPU is normalized – there is still lag in places that have lag, though noticeably less.
Normalized Perfect Dark 30% Xtal Overclock: https://www.youtube.com/watch?v=3r7DNfM3zV0
I used a 19.19 MHz Xtal (in place of 14.7 MHz): RDRAM clocks at 326 MHz, RCP 81.5 MHz, and CPU 122.3 MHz (1.5x). A 30% overclock across the board, most N64 games lose their video outputs (audio stays fine) with a 18.9 MHz and higher Xtal. Although the VI artifacts are horrendous when deactivating in-game Hi-Res, the framerate increases dramatically as shown briefly in the laser beam corridor in DataDyne Investigation. The game seems to lock up just before combat simulator gameplay as well as in several other levels – seems to be the GS normalization code I used. |
|
|
|
|
|
|
|
|
|
|
Trevor 007
Joined: 15 Jan 2010 Posts: 926 Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest |
Posted: Sun May 06, 2018 2:29 am Post subject: |
|
|
Just seen this and remembered about this topic.
this is what the rom header does.
By default osClockRate is defined as Code: | u64 osClockRate = 62500000LL; |
but during initialization it re-assigns to rom header (useful for region specific tweeks eg, 93.75 v 94.whatever)
Code: | /* Get clock rate from rom hader */
osPiRawReadIo((u32)RAMROM_CLOCKRATE_OFFSET, (u32 *)&clock);
clock = clock & RAMROM_CLOCKRATE_MASK;
if (clock)
osClockRate = (u64) clock;
osClockRate = (osClockRate * 3) / 4;
|
Code: | #define RAMROM_CLOCKRATE_OFFSET 0x4
#define RAMROM_CLOCKRATE_MASK 0xfffffff0 |
so, rom offset of 4 we knew and its 7bytes (0x4-0xC) long which we assumed it was only 4 (0x4-0x8)
Trev _________________
|
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Sun May 06, 2018 3:06 am Post subject: |
|
|
I'll have to have a play with that with my new PS2 to N64 converter!
Once I've stopped the epic face palm as I should have noticed that earlier... _________________ No Mr. Bond, I expect you to be re-coded! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|