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

[kholdfuzion]

Since the fiance is out of town, I've had time to sit down and actually crank some stuff out on this.

https://gitlab.com/kholdfuzion/goldeneye_src

It's an in-progress split disassembly for Goldeneye 007. Feel free to send changes.

edit:link updated

Last edited by kholdfuzion on Wed Nov 13, 2019 7:48 am; edited 1 time in total

[Trevor]

... there is nothing there...

Just has you and someone else and 3 tabs of project members with the third tab saying lots of things but all not available

Trev
_________________

[kholdfuzion]

Didn't notice it didn't switch to public properly. Try now

[pavarini]

Thanks for sharing the project.

kholdfuzion wrote:

Didn't notice it didn't switch to public properly. Try now

Yep works now

[Trevor]

Ah that's better, can see the files now

Very interesting and will help enhance PG even more than it already is.

Id suggest updating ucode05.txt although I had to split some segments out since it got quite big. All various updates are posted on these forums, I made a shortcut list here

Id love to see you de-compile back to C, I notice you have the SDK includes references, it would be awesome if the de-compiled code could be re-compiled again. It would help to find viewport objects and lights (which are soft code rather than hardware binary's like say B900031D 0C182078 which is gsSPSetOtherMode(G_SETOTHERMODE_L, G_MDSFT_RENDERMODE, SetRenderMode(c0) | (c1)) or the High Level C function gsDPSetRenderMode(c0, c1))

Trev
_________________

[AL64inthedark]

aheum...what could it brings to us, content creator for PD/GE ?

[kholdfuzion]

At Trevor:
I get a "The topic or post you requested does not exist" for that link.

Once I get enough disassembled, I will start looking into it. My first priority is just splitting and relabeling(even if just with generic labels) so code and data can be edited without having to manually update addresses. During this phase I was going to leave the library functions as a binary blob, but I'll do those now as well.

The C decompile won't be for awhile. RetDec (https://retdec.com/decompilation/) works wonders now for a lot of the code and helping understand whats going on, but it chokes on any functions using the n64 specific opcodes. Specifically mtc0 mfc0 and tlbwi come to mind.

At AL64inthedark:
It will bring a well documented disassembly that will make researching, further documenting, and modding of Goldeneye easier than ever.

At everyone:
As a parallel to this project, I will be starting a branch just focused on engine improvement at some point. It will bring in fixes from the J and P versions, along with zoinkity's 8mb patch and stuff documented in Operation Monkeywrench form the documentation.

Also once I get enough of this project done, I will probably start a PD disassembly as well.

[AL64inthedark]

If it mean no texture limitations storage on rom for PD/GE X and allowing to create bigger maps than the original, it would be awesome. Because rom corruption is a really annoying thing that discourage a lot.

Abusing of multitexture and with lots of rom space, we can go crazy with details.

[Trevor]

Texture size limitation is a hardware problem not a rom problem.
Rom can address up to fff or 4095 textures.

kholdfuzion, ah, sent pm

Trev
_________________

[AL64inthedark]

I'm talking about the number of texture you can add at the end of PD/GE:X rom, which is limited because of corruption issue.

[Wreck]

I don't think GE has much of an issue when it comes to adding more textures to the end of the ROM with the Editor. I can't recall how high you can go, but it is in the high F00 range. Perfect Dark seems to be hit or miss. Sometimes you get lucky, sometimes not so much. I think SubDrag has said it is from an address pointer, which when it becomes a value that compresses the file it's in too large for the space it occupies, will mess up the ROM. I guess you could try little by little, saving under new ROM names each time. If adding one texture screws it up, instead try two or three before saving. If Sogun has found pretty good success with it, you should be able to, as well. I still get hammered in GE-X with compression issues once in a while, myself. But with enough testing, it ends up alright.

[AL64inthedark]

I gave up on that, and sadly switched to GE right now.
I did so many tries and never managed to add enough textures to a PD/GE:x.
It took way too much time for no result at all that I needed a break because if really made me mad. Still hoping to work on those since the engine and IA is waaaay better. I'm doing multitexture of 16 or so different texture sometimes so it become a living hell to work on a PD/Ge:x rom at the moment with that issue going on.

[Wreck]

Hmm, the only idea I have, if possible, is to somehow remove (null out) something else from that file so that it can compress smaller. If that is the primary issue. It is a job for SubDrag, as he's the only one who could determine what's what, and allow the Editor to handle it (or done manually once).

[SubDrag]

There's a lot of beta textures - you should be able to at least use that for the most part, and just replace instead of add.

[Wreck]

That's certainly true for GoldenEye, but I am not as sure for Perfect Dark. There are probably a decent chunk of them, scattered throughout the image list, but finding them all could be tricky.