|
|
GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion GoldenEye Cheats, GoldenEye X Codes, Tips, Help, Nintendo 64 Gaming Community
|
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Sat Mar 14, 2015 12:23 am Post subject: |
|
|
Right, this wouldn't be happening if a mate hadn't of come forward with a cheap N64 that he didn't want, this one really really really is the last one and I want a little hand from the sharp brains out there.
From what I've read:
The Pal N64 has two clocks, both are set to ~17mHZ which then hits the . The RCP clock generally seems to govern the overall system speed as a follow through from the Ram clock messing with the CPU.
What I know: PD seems to get it's timings from somewhere other than the CPU, possibly RCP or ram...possibly that other clock.
Theory: Overclock the CPU using the 1.5X or 2X modifier, and then install a different crystal to try and bring down the framerate to a "stable" speed (it'll either be half, or double, in one or both positions). I might look at getting two sort of doubled or halved crystals, which should be fine according to the forum as long as it doesn't exceed 40 or go below 10, and try installing them in different slots and seeing if there is any notable difference to the general "gamespeed" not becoming faster while overclocked.
Hypothesis: Push hard, then balance it out. I figure that the increased timing on the RCP will control the clock that's reading for the timing inside PD and GE as the multiplier (overclock) is having the effect of just spitting extra frames through, if I can balance those two elements the game should have some level of normal timing with *possibly* a higher push on expected frames from the CPU.
Here's the rub: Anyone got any ideas on this as all bar a tiny bit of reasoning (possibly just me hoping with every fibre that I can play PD at 60fps on console) on the feasibility of this one? I reckon it's going to be a total failure frankly. It's a crazy-far out one that I thought of while we were trying to get latency out of the new Nvidia graphics cards due to them buffering frames to keep things smooth. _________________ 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: Sat Mar 14, 2015 7:30 am Post subject: |
|
|
Well... my suggestion would be to not overclock the CPU, but instead overclock the RCP and reduce the CPU back to syncronicity.
As this post shows, getting 3x on the cpu actually reduces all the rest of the system.
I say, tlets make the system faster and keep the CPU at 93.75MHz
So, thaking his info on the xtals, what we would like to do is increase the RCP to 93.75MHz and multiply the CPU by 1 (93.75).
However... to make the RCP get that speed we would require an X2 of 22MHz pushing 375Mhz (750MB/s) RAM, which as pictured below will crash the System unless we had ram capable of that speed.
* Note that he has listed speeds wrong, Eg, 14.7 (500MHz) should read 14.7 (250MHz/500MB/s)
[spoiler][/spoiler]
Since the image lists that 600MB/s (300MHz) RAM is available and stable in certian consols, this effectivaly allows a 75.25MHz RCP.
Unfortunatly this reduces the CPU by far too much.
The CPU will need to remain at 1.5 giving 112.875MHz.
Overall this is a 20% improvement.
It would still be better to have a 50% RCP improvement allowing graphics tasks to complete faster.
So... the end result is that the only next stable system requires much faster ram to even attempt.
Any further ideas?
Trev
Darn, I wish the image wasnt so big... sorry guys. I dont think the forums img code can specify width
Althedark, spoilers dont work _________________
Last edited by Trevor on Sun Mar 15, 2015 3:52 am; edited 2 times in total |
|
|
|
|
|
|
|
|
|
|
AL64inthedark 00 Agent
Joined: 18 Sep 2014 Posts: 548 Location: France |
Posted: Sat Mar 14, 2015 9:39 am Post subject: |
|
|
Regarding image size, a spoiler mode would be appreciable to compensate. |
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Sat Mar 14, 2015 3:53 pm Post subject: |
|
|
Man I totally forgot about the ram limitations and the nature of RDRam! Really good point there, m so use to beating the living snot out of modern equipment that I forgot things weren't always so flexible.
Ok guys. Any ideas or any idea where th slow motion multiplier in PD is stored? _________________ No Mr. Bond, I expect you to be re-coded! |
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Sat Mar 28, 2015 3:11 am Post subject: |
|
|
So for the first time in ages I decided to have a bit more of a mess around with overclocking rates and stumbled across something funny with the 1.5x overclock on Mario Kart...
It gets weird. Some tracks play faster, some play smoother. Red shells were tracking along the entire track without colliding with the sides, the blue shell kept on hitting player 2 regardless of their position. Flat out I've got nothing as far as suggestions go for why on earth this was (and kept) happening. I'm lead to think that the "overclock" is not as straightfoward as the forums would suggest.
Even weirder is that the 2x overclock ran delightfully. Smoother framerates and more "responsive" control actions.
I've tried messing around with the code in Mario Kart (as I've always wanted the bomb players to get more than one "kill" as we'd all love that!) and frankly the code base looks like a total mess, I could only put it down to that. _________________ 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: Sat Mar 28, 2015 5:08 am Post subject: |
|
|
Oh... wierd... but once again Im questioning the overclock terminology since what you literally described (at 1.5) is that at 'Normal CPU speed' some stages ran fast while some ran smoother etc etc...?
That is unless you meant the Cart Header?
Now of course, in an un-modded 64 a 3/4p multi skyscraper runs way to fast, yet in 1/2 player mode it runs normal. Also normally red shells travel in a straight line and hit walls.
So youve definatly hit something but im not sure what if the CPU is normal?
Trev _________________
|
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Sat Mar 28, 2015 6:24 pm Post subject: |
|
|
I have noticed those speed issues too - browsers castle on 4 player is the main one we try to avoid.
On "normal" speed it runs as expected. The more I look into messing around with, or modding this game, the more I'm thinking that it's a bad idea and should stick to GE! _________________ No Mr. Bond, I expect you to be re-coded! |
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Wed Apr 22, 2015 9:09 pm Post subject: |
|
|
Well I said I'd post on PD slow-mo levels and overclocking.
Sub was gracious enough to provide me with a sample of patches for various slow-motion speeds and I gave it a crack on the better cooled of the overclocked systems.
So apparently standard speed setting for Perfect Dark is a value of "8", and the closest to normal play on "2.0x" overclock (how about for simplicities sake, and also the sake of being correct in statements we call this "overclock" in future as 1.5x is "standard" in reality and 1.0x is a "underclock"). I found that a value of "7" was the closest to normal play, but was still about 25% slower than "real time" if you will.
*ahem* ok. There was one key thing to note: gameplay speed was variable depending on the amount of duress the system was under. So in complex areas the whole playspeed would slow down instead of becoming fragmented and trying to maintain a constant framerate. It resulted in a funny Johnny Woo kind of effect when there was a lot happening on screen. Some of the speeds for things like projectiles didn't feel correct either - as though the balance had been thrown off.
The system pulled a very nice and extremely attractive framerate in the levels that I tested but some of the running around did get a bit boring when forced to do it at 75% of standard game speed. I think any further development here might involve tracking down some of these factors and seeing if there's a way to mess with the tickers.
So that ends one phase of the testing with overclocking. Now pertaining to Mario Kart running too fast there is this:
http://tasvideos.org/GameResources/N64/MarioKart64/Patches.html
Which could be useful for those of us who play it frequently _________________ 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: Thu Apr 23, 2015 11:43 am Post subject: |
|
|
Hehe at least GE/PD does seem to have a dynamic Frameskip.
hmm, so with a 25% increase it only moves 1 place for slo-mo and yet still feels slow?
those places must have a 50% shift or something.
Trev _________________
|
|
|
|
|
|
|
|
|
|
|
MRKane 007
Joined: 11 Dec 2008 Posts: 1075
|
Posted: Thu Apr 23, 2015 2:55 pm Post subject: |
|
|
If not GE then defiantly PD. I suspected they were factors, but was surprised to find that game time was "elastic". I might see if I can find the ASM that handles this as it'd be typical that the factor is multiplied by 8 and divided by 5 to turn it into miles per hour and then used in the time system - there could also be a bit of slack in the timing department too (which would be the dream solution). _________________ 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
|
|
|
|