 |
 |
GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion GoldenEye Cheats, GoldenEye X Codes, Tips, Help, Nintendo 64 Gaming Community
|
 |
 |
 |
 |
|
 |
 |
 |
 |
 |
Fillerthefreak Secret Agent

Joined: 29 Mar 2014 Posts: 305 Location: Canada  |
Posted: Mon Jun 08, 2015 5:33 pm Post subject: Something I noticed about GE emulation. |
 |
|
Is it me, or does the PAL version of GE have less frame-rate issues when it's played on an emulator than the NTSC version?
I use Project 64 2.2.0.3 As my emulator of choice to play GE. It seems to be the only emulator that doesn't randomly crash when playing GE for me.
The NTSC version gave me tons of frame rate chugs and was generally unstable, going from 35 to 5 FPS. And it lags just by standing. But the PAL version plays at a solid 50 FPS, it only lags when the game itself is lagging, and not due to emulator issues.
Is there any reason why? Does the PAL version of GE use a different engine or something? _________________ This is a signature, why did you read this? |
|
|
|
|
|
 |
 |
 |
 |
 |
zoinkity 007


Joined: 24 Nov 2005 Posts: 1729
 |
Posted: Tue Jun 09, 2015 3:40 am Post subject: |
 |
|
The NTSC codebases include a large amount of debug info collection besides the debug menus and their features. NTSC will collect info on all the current allocations and throw it away, or in other cases jump to a function and collect some data before testing if it should even bother, or some of the short loops that no longer serve a purpose; PAL eliminated all these, streamlining the codebase, in addition to including all the bugfixes from J and additional ones such as better TLB management, reducing the frequency of DMAs. Quite simply, it's a more mature codebase with less clutter that runs faster and smoother.
Without all the debug code you don't need buffers for the two text displays, or buffers for generated tables, or pointer tables for the removed functions, or a dozen other things on the side. It frees up a remarkable amount of memory in the end. Also, struct sizes shrank when they did the PAL conversion to make even more rdram available. Static tables like skies and weapon sets are half the size.
Granted PAL framebuffers are larger, but the amount of memory freed exceeds this by quite a bit. It removes the need to copy data back and forth in memory when you have more on hand. _________________ (\_/) Beware
(O.o) ze
(> <) Hoppentruppen! |
|
|
|
|
|
 |
 |
 |
 |
 |
Trevor 007


Joined: 15 Jan 2010 Posts: 926 Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest  |
Posted: Wed Jun 10, 2015 12:27 am Post subject: |
 |
|
Isnt this what you were trying to schive in NSNA?
The Debug features have come in handy for checking new levels, but for final release sub should remove them?
Trev _________________
   |
|
|
|
|
|
 |
 |
 |
 |
 |
|
 |
 |
 |
 |
|
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
|
|
|
 |