GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[SubDrag]

I just wanted to share how good this thing is, especially with the old 640 x 480i patches that were made.
https://github.com/jombo23/N64-Tools/tree/master/Game%20Patches

https://www.youtube.com/watch?v=O1lFn2rqn1w
https://www.youtube.com/watch?v=acbH3Wx6JSs
https://www.youtube.com/watch?v=vZ3wfla__wk
https://www.youtube.com/watch?v=thxNKPUZnBI

Also this is my request to Ryan Dwyer or anyone who can recraft PD - please make a 640 x 480i and scrunch the 8 meg to fit it. This is desperately needed. My attempts to make this years ago failed and I also thought I needed 12 meg of RAM which is not possible (or at least....no one in the universe has done it yet on a retail N64).

I hope my videos here spawn a gold rush to make console compatible 640 x 480i patches (not by me...retired on this, I think).

[zoinkity]

Haha, could try redoing Pokémon Snap so it uses the super-hi-res photo-only pokémon in the normal game. Those actually require the expansion pak!

Not sure how the HDMI works on the back-end, but there's at least a chance that single-frame output modes won't be washed out. So long as two 320 framebuffers are in-series can be combined into 640 output.
If Status is set to the correct divisor in overclock mode would even be able to detect this and support both platforms.

[SubDrag]

I'm thinking also you can basically just disable fog and make large draw distances/avoid object popup too.

I did make a Pokemon Snap 640 x 480i hi res mode that crawled before and surely is good now - but I don't know how to change to the hi polygon Pokemon. That would be great though!

[RyanDwyer]

I've created two 640x480 patches:

* pd-640x480-gcc-nopaging.xdelta - My maths says that memory over budget so it may crash. Built with GCC to save memory but it's not enough.
* pd-640x480-gcc-paging.xdelta - This one enables the virtual memory paging system, just like how GE works and how PD works without the expansion pak. This frees up enough memory so that it shouldn't crash, at the cost of performance.

Get them here: https://gitlab.com/ryandwyer/game-patches

I recommend trying the nopaging one first, and if you encounter crashes or things not loading properly then switch to the paging one.

I also recommend disabling hi-res in the video settings. It will do 640x480 regardless of this setting, but the hi-res option applies an X scale to the menus and HUD which causes it to stretch. With the hi-res setting off the menus and HUD are tiny but to scale.

[Wreck]

I know this about the higher resolution modding, but I have to ask...

Is that 30 level multiplayer select menu fully functional? So you could actually use up every slot for a different map? I would be massively interested, if it's not just an aesthetic thing. If you don't want to reply in this thread, please direct message me about it. Thanks.

[SubDrag]

RyanDwyer wrote:

I've created two 640x480 patches: * pd-640x480-gcc-nopaging.xdelta - My maths says that memory over budget so it may crash. Built with GCC to save memory but it's not enough. * pd-640x480-gcc-paging.xdelta - This one enables the virtual memory paging system, just like how GE works and how PD works without the expansion pak. This frees up enough memory so that it shouldn't crash, at the cost of performance. Get them here: https://gitlab.com/ryandwyer/game-patches I recommend trying the nopaging one first, and if you encounter crashes or things not loading properly then switch to the paging one. I also recommend disabling hi-res in the video settings. It will do 640x480 regardless of this setting, but the hi-res option applies an X scale to the menus and HUD which causes it to stretch. With the hi-res setting off the menus and HUD are tiny but to scale.

@Ryan - Thanks for doing this - let's get this thing working properly, it's close!! Going to look amazing when done. Paging hangs on the first screen. No paging boots totally fine - but 640 x 480i isn't done right. I think it's something with lines, and the alternating buffer was offset improperly. GoldenEye actually had a bug on this (not sure if same thing or not), I had to force fix it. I don't know if it's the same thing, but it was modify a 0x500 -> 0xA00, GE was ROM 0x441C to 0x00187880 (actual bug in the game for the higher resolution, had to extend shift by 1 more). Looking in Nemu, your frame buffer is alternating between 006A0580 and 0060A580, that doesn't seem right, you're missing the interlace.

My GE Hi Res goes between at A4400004
006D4500
006D4A00 (interlaced)
0076A500
0076AA00 (interlaced)

I expect yours should be similar. Also the intro menus are not 640 x 480 and a little off, but lets get main gameplay going first.

See this screenshot:
https://imgur.com/zBdwnNc

These are VI settings I use for my hi res patches:
unsigned char rawDataHAN1[76] =
{
0x00, 0x00, 0x30, 0x5E, 0x00, 0x00, 0x05, 0x00, 0x03, 0xE5, 0x22, 0x39, 0x00, 0x00, 0x02, 0x0C,
0x00, 0x00, 0x0C, 0x15, 0x0C, 0x15, 0x0C, 0x15, 0x00, 0x6C, 0x02, 0xEC, 0x00, 0x00, 0x04, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x23, 0x01, 0xFD,
0x00, 0x0E, 0x02, 0x04, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x0A, 0x00, 0x00, 0x00, 0x04, 0x00,
0x00, 0x25, 0x01, 0xFF, 0x00, 0x0E, 0x02, 0x04, 0x00, 0x00, 0x00, 0x02,
};

Last edited by SubDrag on Sat Dec 06, 2025 9:46 am; edited 1 time in total

[zoinkity]

About the MP menu...

The stage list hasn't been modified in any way, but the menu was written so up to 30 stages can be indexed and displayed if it were.

Code:

.: Multiplayer Stage Select :.   If select image resolution doesn't change...   If width is reduced from 0x58 -> 0x55 can fit 6 across each row (ulx+1 to lrx-1 = 0x1FE)   Can easily fit 5 rows.  This affords 30 MP stages per page, up from 12.   Does require a bit of a rewrite of the interface... 48904   7F013DD4   menu 12 interface: multiplayer stage select    @7F013E70  489A0   determine row       24030005   ADDIU   V1,R0,0005       24080186   ADDIU   T0,R0,0186   # 110 + (5 - 1) * 70 = 460       0048082A   SLT   AT,V0,T0       10200003   BEQ   AT,R0,+3       2463FFFF   ADDIU   V1,V1,FFFF       1460FFFC   BNE   V1,R0,-4       2508FFBA   ADDIU   T0,T0,FFBA       24080006   ADDIU   T0,R0,0006   # stages per row       00680019   MULTU   V1,T0       00000000   NOP    @7F013EA0  489D0   get result       0000C812   MFLO   T9    @7F013EB0  489E0   determine stage in row       240301DB   ADDIU   V1,R0,01DB   # 55 + (6 - 1) * 84 = 475       0043082A   SLT   AT,V0,V1       10200003   BEQ   AT,R0,+3       2508FFFF   ADDIU   T0,T0,FFFF       1500FFFC   BNE   T0,R0,-4       2463FFAC   ADDIU   V1,V1,FFAC       01001025   OR   V0,T0,R0

It's also hacked so A & Z walk forward and back through options on the main page.

Not sure how usable on a normal, retail console it would be if the menus were at 640 and everything else left at original resolution. It might be fine? A lot of sports titles have high resolution menus.

[RyanDwyer]

441C in GE is this line in PD: https://github.com/n64decomp/perfect_dark/blob/169ed48bdcbfb3b568b028bd5bebb27680073514/src/lib/vi.c#L356

You are effectively changing the multiply by 2 to be a multiply by 4. When I do the same in PD I don't notice any difference.

Note that in PD, the structure of this function is:

Code:

if (g_ViBackData->mode == VIMODE_LO) {     // configure for LAN (lo-res, antialiasing, noninterlaced) } else if (g_ViBackData->mode == VIMODE_HI) {     // configure for HAF (hi-res, antialiasing, deflickered interlacing) }

The VIMODE constants were named by me and are wrong. VIMODE_LO is used during gameplay regardless of the hi-res setting. VIMODE_HI is only used on the title screens. Note that the VIMODE_HI branch already uses a multiply by 4 so they must have fixed it there. Other differences between the two branches include a different calculation of the yScale and vStart registers. I don't know how these work exactly. I don't know of any documentation that explains how these registers work.

As mentioned, if I edit the VIMODE_LO (LAN) branch so it multiplies by 4 instead of 2 then I don't notice any difference.

If I force it to take the VIMODE_HI (HAF) branch then the text rendering is perfect, but turning left/right shows obvious issues with interlacing.

If I apply your raw data then I appear to get the same results as when I force it to take the VIMODE_HI branch. The text is perfect but there are issues when turning. I've updated the xdelta patch on GitLab to this version if you want to try it yourself. I've only changed the nopaging one for now. I'll sort out the paging one once this is resolved.

[SubDrag]

Looks right now!!! I'll double check your VI settings and capture a video in a bit. I didn't have to do this fix in any game except GoldenEye for 640x480i. Is it a bug in the core libraries or the game itself? Basically it is offset improperly so it totally screws up frame alignment.

So the beginning when Joanna is typing at Carrington institute it sort of has a black box around that expands. Probably missed spot for the new size. I'll mess around more and get some video.

[RyanDwyer]

SubDrag wrote:

Looks right now!!! I'll double check your VI settings and capture a video in a bit. I didn't have to do this fix in any game except GoldenEye for 640x480i. Is it a bug in the core libraries or the game itself? Basically it is offset improperly so it totally screws up frame alignment.

I assume you're talking about the multiply fix? I suspect it's a GE/PD only thing. The runtime code copies the VI mode settings from libultra, modifies them (this is where the multiply is), then sends that to the video interface. I don't think other games have access to the underlying settings in libultra so all they can do is select a VI mode.

SubDrag wrote:

So the beginning when Joanna is typing at Carrington institute it sort of has a black box around that expands. Probably missed spot for the new size. I'll mess around more and get some video.

I've made a new patch which should fix this. It's a simple setting in a table which I didn't realise I had to adjust.

[SubDrag]

I thought PD might have used 640 x 480i for some promo shots, but maybe not...considering this bug, leftover from GE.

Here's a video in action on Analogue 3D - you can see the 640 x 480i spot you missed, the cut-scenes/intro typing. They are accidentally half height.

https://youtu.be/9uXjn6-YUQk
(no paging version

[SubDrag]

Oh you had updated the patch, missed that - that should fix both spots that were off in the video. I'll give it a longer run through tomorrow and see if anywhere is off, but looks promising, thanks!

What is the no paging one? Trying to run faster? Is that ready to try again?

[RyanDwyer]

SubDrag wrote:

What is the no paging one? Trying to run faster? Is that ready to try again?

The term paging comes from modern computing's use of virtual memory. Virtual memory is split into chunks called pages. When a virtual memory page is accessed which isn't available in physical memory, the OS loads it from swap or wherever it is. This is called paging.

GE and PD do the exact same thing. The 7F000000 range is virtual. When PD is in 4MB mode (no expansion pak) then paging is used. But when the expansion pak is present all 2MB of code is loaded upfront into memory, so a page miss will never occur and paging is effectively disabled.

The nopaging patch is the one closest to vanilla behaviour, but this is likely to run out of memory on some stages due to the increased framebuffers. So I took the 4MB paging logic and applied it in 8MB mode to create the paging patch. With the paging patch only about 1.1MB of code is in physical memory at any one time, leaving enough room for the framebuffers so it shouldn't run out of memory.

The emulator I'm using is known for not reproducing N64 behaviour properly, so it doesn't surprise me that the paging one won't boot on real hardware or in better emulators. I'll set up Ares and get the paging version working soon.