|
|
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: Wed Jul 08, 2015 8:19 pm Post subject: Editing the PAL version of GE? |
|
|
Does the GE setup editor support modding of the PAL version of GE? Since it's runs better in terms of performance, and it's more stable on an emulator.
Either way, I think most modders should be editing the PAL version, as I think the more-optimized game code allows more memory space on objects and such. You could probably even make the patches 8MB expansion-pak required to cram out the most space.
Or am I wrong. Does it just improve stability on an emu? _________________ This is a signature, why did you read this? |
|
|
|
|
|
|
|
|
|
|
SubDrag Administrator
Joined: 16 Aug 2006 Posts: 6124
|
Posted: Thu Jul 09, 2015 4:20 am Post subject: |
|
|
It might allow basic quick conversion if you toggle region to PAL in preferences but that's it. NTSC is the region I use and wreck and Zoinkity, and most PAL tvs at the time could play NTSC also but not vice versa. It was just too difficult to maintain two or three regions for me. NTSC also had all the great debug features. |
|
|
|
|
|
|
|
|
|
|
zoinkity 007
Joined: 24 Nov 2005 Posts: 1687
|
Posted: Fri Jul 10, 2015 5:11 am Post subject: |
|
|
There's no direct conversion of the code. You'd almost need a new editor to fully support PAL.
A lot of code and structs the editor edits vary wildly from their NTSC counterparts. For instance, skies:
Code: | NTSC
format: 0x5c per entry
0x0 4 stage ID number (or multiple thereof)
(these values are more dedicated to obscuring stage/object elements)
0x4 4 (float) odd blend multiplier. pervasiveness of fog on rendered surfaces (ie. ground) closer than near fog value. Also affects the z index for the viewport to some degree but not on PAL.
0x8 4 (float) far fog value; beyond this is complete obscurity
0xC 4 (float) near fog value; distance from player to start of fog gradient
0x10 4 (float) max obj vis. range; furthest dist standard (non-door) obj and actors are visible at
0x14 4 (float) obj obfuscation range; objs start to 'fade' at this distance
0x18 4 (float) default 0 min obj vis range; nearest stand. objs are visible at. Always set to zero!
(note: these values are more dedicated to actual ambient fog lighting effect)
0x1C 4 long default 999 All Objects: difference between near and far ambient light. Intensity, in other words
0x20 4 long default 996 BG: dif. in light. smaller # = foggier near player
0x24 4 long default 1000 far ambient light value value. used with above two values
I think this is when fog occurs, and above two are subtracted to create the near fog boundry.
0x28 1 red component 0-FF
0x29 1 green component 0-FF
0x2A 1 blue component 0-FF
0x2B 1 clouds 1-on/0-off
0x2C 4 (float) default 5000; cloud image repeat value. larger = more repetitions (pushed to DL)
0x30 2 default 0000; offset from loaded sky image (8B6) to image entry used for sky.
0x32 2 reserved (0)
0x34 4 (float) cloud Red channel (alpha->red)
0x38 4 (float) cloud Green channel
0x3C 4 (float) cloud Blue channel
0x40 1 unsigned byte Nonzero='water'; also pulls the object ambient light value...
0x41 3 reserved (0)
0x44 4 (float) default -1000; water image repeat value. larger = more repetition (pushed to DL)
0x48 2 default 0001 or 0002; offset to loaded water image entry.
0x4A 2 reserved
0x4C 4 (float) water Red channel; these three values affect water highlight near the player only
0x50 4 (float) water Green channel
0x54 4 (float) water Blue channel
0x58 4 (float) world concavity distort! positive makes world concave, negative world convex. distorts perspective
Note: stages 1A, 36, default omit fog data (0x4-0x24 above):
0x0 stage ID
0x4 fog colour
0x8 cloud repeat value
etc... |
versus :
Code: | PAL
entries 0x24 in size
0x0 2 stage ID number (or multiple thereof)
0x2 2 near pervasiveness of fog on rendered surfaces
0x4 2 far fog value; beyond this is complete obscurity
0x6 2 near fog value; distance from player to start of fog gradient
0x8 2 max obj vis. range; furthest dist standard (non-door) obj and actors are visible at
0xA 2 obj obfuscation range; objs start to 'fade' at this distance
0xC 2 default 996 BG: dif. in light. smaller # = foggier near player
0xE 2 default 1000 far ambient light value value. used with above two values
I think this is when fog occurs, and above two are subtracted to create the near fog boundry.
permillage. light/ambient=multiplier
0x10 1 red component 0-FF
0x11 1 green component 0-FF
0x12 1 blue component 0-FF
0x13 1 clouds 1-on/0-off
/*cloud-specific*/
0x14 2 default 5000; cloud image repeat value. larger = more repetitions (pushed to DL)
0x16 1 default 00; offset from loaded sky image (8B6) to image entry used for sky.
0x17 1 cloud red component 0-FF
0x18 1 cloud green component 0-FF
0x19 1 cloud blue component 0-FF
0x1A 1 unsigned byte Nonzero='water'; also pulls the object ambient light value...
0x1B 1 RESERVED
/*water-specific*/
0x1C 2 default -1000; water image repeat value. larger = more repetition (pushed to DL)
0x1E 1 default 01 or 02; offset to loaded water image entry.
0x1F 1 water highlight red component 0-FF
0x20 1 water highlight green component 0-FF
0x21 1 water highlight blue component 0-FF
0x22 1 world concavity distort! positive makes world concave, negative world convex. distorts perspective
0x23 1 RESERVED |
Same goes for MP weapon sets, some of the animation tables, intro tables, etc.
One thing the editor takes advantage of is the sheer amount of stuff that can be condensed down in size or removed. Doing so makes room for extended entries and tables. PAL has vastly less extroneous stuff, and it's rare that any of it is sequential.
As far as the quietly patched features, some already have PAL versions written. Pretty sure the image table extension doesn't though, and with how heavily the codebase differs that would be a real pain to rewrite.
Being unable to test on console is a huge disadvantage. _________________ (\_/) Beware
(O.o) ze
(> <) Hoppentruppen! |
|
|
|
|
|
|
|
|
|
|
Trevor 007
Joined: 15 Jan 2010 Posts: 926 Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest |
Posted: Fri Jul 10, 2015 11:05 am Post subject: |
|
|
Didnt NSNA basically take all the PAL bugfixes and implement them plus way more in the NTSC ROM?
I wounder how so much of the code is different though... they must have re-written loads while Nintendo were testing the NTSC ROM.
Trev _________________
|
|
|
|
|
|
|
|
|
|
|
Fillerthefreak Secret Agent
Joined: 29 Mar 2014 Posts: 305 Location: Canada |
Posted: Sun Jul 12, 2015 6:49 pm Post subject: |
|
|
Trevor wrote: | Didnt NSNA basically take all the PAL bugfixes and implement them plus way more in the NTSC ROM?
I wounder how so much of the code is different though... they must have re-written loads while Nintendo were testing the NTSC ROM.
Trev |
Has anyone thought of making it so the GE setup editor can apply that patch along with the custom setup patches into a single patch? As I only see the use of the debug tools for level testing. They just waste up space when you don't need 'em. _________________ This is a signature, why did you read this? |
|
|
|
|
|
|
|
|
|
|
zoinkity 007
Joined: 24 Nov 2005 Posts: 1687
|
Posted: Mon Jul 13, 2015 3:42 am Post subject: |
|
|
NSNA is...different. It's also buggy as snot and needs a complete rewrite.
The editor is clearing out and using portions of the debug stuff to extend tables. Most of it isn't sequential though.
Patches can't just be randomly applied in that manner. You'll get into conflicts with multiple patches changing the same code and altering the same data. _________________ (\_/) Beware
(O.o) ze
(> <) Hoppentruppen! |
|
|
|
|
|
|
|
|
|
|
Kerr Avon 007
Joined: 26 Oct 2006 Posts: 913
|
Posted: Mon Jul 13, 2015 3:55 am Post subject: Re: Editing the PAL version of GE? |
|
|
Fillerthefreak wrote: | Does the GE setup editor support modding of the PAL version of GE? Since it's runs better in terms of performance, and it's more stable on an emulator. |
Is that true? Does the PAL version run better? How? Does it have a better frame-rate, or is it smoother, or what?
And if so, then why is Goldeneye X and other mods aimed at the NTSC version? Since most people would have to play them with an emulator (since flash cartridges and CD backup units were so rare back when Goldeneye X was started, though it's much better now with the Everdrive 64 and 64Drive) then it wouldn't matter if you modded the NTSC or PAL version. |
|
|
|
|
|
|
|
|
|
|
zoinkity 007
Joined: 24 Nov 2005 Posts: 1687
|
Posted: Mon Jul 13, 2015 6:56 pm Post subject: |
|
|
Goldeneye X is a PD mod; there's less difference there.
Most PAL TVs will display NTSC signals, but NTSC TVs will rarely, if ever, display PAL. The people leading these projects have NTSC TVs, so they're making the mods for their region. It's not really possible to determine if it's running right otherwise on console when you can neither see nor hear it.
You're seriously underestimating the amount of work involved in documenting multiple versions of these games as well. PD is a bit more straight-forward, but GE? They're very, very different. _________________ (\_/) Beware
(O.o) ze
(> <) Hoppentruppen! |
|
|
|
|
|
|
|
|
|
|
mistamontiel 007
Joined: 17 Apr 2011 Posts: 843 Location: Miami, FL, CUBA |
Posted: Mon Jul 13, 2015 10:24 pm Post subject: |
|
|
I believe I has read one's brain-fart _________________
|
|
|
|
|
|
|
|
|
|
|
Kerr Avon 007
Joined: 26 Oct 2006 Posts: 913
|
Posted: Tue Jul 14, 2015 7:09 am Post subject: |
|
|
zoinkity wrote: | Goldeneye X is a PD mod; there's less difference there.
Most PAL TVs will display NTSC signals, but NTSC TVs will rarely, if ever, display PAL. The people leading these projects have NTSC TVs, so they're making the mods for their region. It's not really possible to determine if it's running right otherwise on console when you can neither see nor hear it.
You're seriously underestimating the amount of work involved in documenting multiple versions of these games as well. PD is a bit more straight-forward, but GE? They're very, very different. |
I see, thanks. I thought that since Goldeneye PAL was released after Goldeneye NTSC, that the PAL version would just be the the same as the NTSC version but with regional differences (PAL output instead of NTSC, British spelling, bug-fixes, etc). I didn't know that Rare had made alterations to the locations of data tables and such like. Why did they do this? To speed up the game, or something? |
|
|
|
|
|
|
|
|
|
|
zoinkity 007
Joined: 24 Nov 2005 Posts: 1687
|
Posted: Tue Jul 14, 2015 7:00 pm Post subject: |
|
|
They did need to make room for the larger framebuffers. Even between the Japanese and USA releases there were bugfixes applied, and PAL received several more.
Biggest change was they removed all the debug menus and some of the interface for it. They also clipped out the Spectrum emulator. Amusingly, some of the functions the debug menu used (such as the ramrom recorder) were preserved though.
The tables were probably just stripped down because they could be and there wasn't a reason not to. Nice that it only uses one type of enviroment block though (skies, water, etc.) Locations obviously change though when things move. _________________ (\_/) Beware
(O.o) ze
(> <) Hoppentruppen! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|