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

[SubDrag]

Carnivorous wrote:

Quote: Has anyone used the end of the image table before (that was nullified by image table from 8 to 4 bytes)? It's beyond FFF * 4 for max images. Like 2D900-2D9D0...maybe I can write the custom ASM inplace there? Not that I know of, I've never used that part. Maybe Wreck has?

Unlikely. We didn't know about it, as far as I know. I will start investigating tomorrow rewriting the ASM/table and updating editor to support. May take some time given my limited free time. I'll report when I have something.

If someone wants to figure out how those values actually work it'd be helpful for new detail mapping too...

[Wreck]

I'll look to see if I used either of the spots in 21990. I don't think I used any area after the image table, as I wasn't sure what might go there. It was most likely going to be the character setup table, but I may not need more entries than what I extended it to elsewhere.

As for any custom ASM, I typically only mess with cheats, myself. And it is within their original space. However, I have had Carnivorous add some stuff for the Tournament Edition. I can't recall any thing custom, other than Footsteps patch related, in the compilation pack.

[Carnivorous]

For the standard footsteps patch the last update from a few days ago now entirely fills the empty zx jump table in 21990 before the ucode binary (0x3B3A0-0x3BA8F). The unused indy image dump functions should be fine, as well as the end of the image table.

As a request - when the asm table update has been finished please add a check to confirm if the area is unmodified or not, and warn the user that the area will be overwritten on next save.

[Wreck]

What was added / altered from the Footsteps patch, and where can I find the download link?

[Carnivorous]

A few things. As always extract asmhacks.tar archive within the ROM file listing for full code

Quote:

Changelog V30 (06-05-2020): * Set anti-aliasing off by default * Updated no aa hack to invert read option * Renamed 'Disable AA' option to 'Anti-Aliasing' (preview) V29 (05-31-2020): * Improved footsteps distance calculation (before / after) * (Optional) Make guards not fade on screen unless FPS is low or guard flags are invincible/friendly fire/no auto aim * Added pointer address (8070011C) for easy access to current character's structure * Force cinema cameras to use widescreen setting * Randomly pitch down guard pain sfx (like XBLA) V28 (05-30-2020): * Improved melee example action blocks * Added numerous death checks to jump to infinite (lower AI load per tick) * Camping guards stop aiming at player if haven't been on screen for more than 5 seconds * Make 04A5 have the possibility of investigating dead bodies (25% RNG) * Fixed camping block using invalid reaction speed (127 -> 100) * Add 10 second max limit to guards investigating dead bodies V27 (04-15-2020): * Updated footsteps block to not use sound effect slots * Tweaked descriptions for tutorial

Download from https://carnivoroussociety.github.io/

[Wreck]

I looked, and I have not touched anything at 2D900-2D9D0, or 5358-5920 in 21990. It's all just zeroes in my exported file.

Seems a few things may have received updates since the last version of Footsteps I began incorporating into the compilation pack ROM. I think I may have been on v27. I did a direct comparison on the custom ASM area of 21990, and there are differences at 3B8CE and on. I'll have to refer to your notes, and see which text files have newer dates on them. Glad you updated the Anti-Aliasing setup. That's kind of what I was going for, but I had to reverse ON/OFF in the watch because I didn't know how to update the actual data that controls it.

[SubDrag]

Ah the tougher part of TLB is you can't write back to it. I think this detail portion table is static though...not sure what joy edit2 does, hopefully this works, not seeing any writes. That might be ok.

The 2 bytes appear to be 4 4-bit values (not 100% confirmed). We should try and sort out what it is, because detail mapping is very powerful, and we always thought was broken, but it was actually...the image table fault.

Quote:

As a request - when the asm table update has been finished please add a check to confirm if the area is unmodified or not, and warn the user that the area will be overwritten on next save.

How would I know this area was otherwise modified? Just check if first 4 bytes match the base GE ROM?

Last edited by SubDrag on Sun Jun 07, 2020 8:28 am; edited 1 time in total

[MultiplayerX]

Any future plans on updating Jet Force Gemini? I would love to see some of those levels working in ge multiplayer OR Perfect Dark
_________________
[img]http://imgur.com/ud785Jq[/img]

[SubDrag]

MultiplayerX wrote:

Any future plans on updating Jet Force Gemini? I would love to see some of those levels working in ge multiplayer OR Perfect Dark

I don't have any plans right now for anything other than bugfixes/enhancements suggested to what exists already. That's about all I have (or don't have) time for but am trying to do.

[MultiplayerX]

Good things come to those that wait. Took over 20 years to get the Editor and make a gameshark UNNECESSARY. Things never thought possible! Much appreciation for the continued support sir!
_________________
[img]http://imgur.com/ud785Jq[/img]

[Carnivorous]

SubDrag wrote:

Quote: As a request - when the asm table update has been finished please add a check to confirm if the area is unmodified or not, and warn the user that the area will be overwritten on next save. How would I know this area was otherwise modified? Just check if first 4 bytes match the base GE ROM?

For example let's say you're going to write the new code at 0x5358 to 0x53E4, the editor would check the first and last 4 bytes



This would be safe to write the new code, else show a warning that detail maps will be broken until 0x5358-0x53E4 is restored.

[SubDrag]

Maybe..it wasn't as bad as it seemed. I updated beta, it now takes over 115880-117880 for the Detail Maps. It reads from TLB (not directly from ROM). There were no additional ASM jumpouts needed, just updates the value it reads from.

If you updated 115880 with anything but stock value it will warn. This will be updated for all new ROMs. Any old ROM, it will detect if first time, and if so, clear out that area, and set to base GoldenEye values (only 0x15/0x16 images with values 38D2).

You can edit them in Image Editor by right clicking and choosing Set Detail Map Values at the bottom. I'm not certain how this works, maybe some kind of multiplier. They are all zero in PD so I have not yet supported it there, maybe it's not used. But their image table is 8 bytes.

This is pretty experimental...so use care and keep your old backup editor for now.

And if some one sorts out how the values work, let me know. LOD should be 0000.

"The two nibbles in byte 4 are used as an offset correction for tmem fields. tmem value would be calculated (Line value * lower nibble) + upper nibble. So something along the lines of xoffset, yoffset.

Byte 5's upper nibble corrects mask s, lower nibble mask t. They're bitlengths (#bits to express number, ie. 7 = 3, 8 = 4, 0x1C = 5)
To generate those, they get the bitlength for the width and height [7F0CCA9C(A0)] and subtract the image's value from it to create the mask."

This is the source:
//7F0CCC70
//LUI $t9, 0x7F0E
//3C197F0E
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x1017A0, 0x3C197F0E);

//7F0CCC80
//ORI $T9, $T9, 0x0D50
//37390D50
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x1017B0, 0x37390D50);

//7F0CCC7C
//SLL $t8, $t7, 0x01
//000FC040
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x1017AC, 0x000FC040);

//7F0CCD18
//LBU $t4, 0x0000($s0)
//920C0000
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x101848, 0x920C0000);

//7F0CCD1C
// Change to LH, from LW
//LH T2, 0(S0)
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x10184C, 0x860A0000);
//SRL T3, T2, C
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x10185C, 0x000A5B02);

//7F0CCD5C
//LBU $t9, 0x0001($s0)
//92190001
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x10188C, 0x92190001);

//7F0CCD74
//LHU $t4, 0x0000($s0)
//960C0000
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x1018A4, 0x960C0000);

//7F0CCDB4
//LBU $t2, 0x0000($s0)
//920A0000
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x1018E4, 0x920A0000);

//7F0CCDD0
//LH $t0, 0x0000($s0)
// Change to LH
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x101900, 0x86080000);
//SRL T1, T0, C
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x101910, 0x00084B02);

//7F0CCE24
//LHU $t8, 0x0000($s0)
//96180000
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x101954, 0x96180000);

//7F0CCE48
//LBU $t7, 0x0001($s0)
//920F0001
imageEditorParentWindow->WriteLongToBuffer(GEROM, 0x101978, 0x920F0001);

[Carnivorous]

Tested and confirmed working, glad to have this issue finally resolved. Thank you for your work

[SubDrag]

Carnivorous wrote:

Tested and confirmed working, glad to have this issue finally resolved. Thank you for your work

Thought had it last time...but wasn't so simple. Let's just keep an eye on all the ways of editing images and make sure there aren't any editor bugs...but it's nice to at least understand the situation. And maybe open up detail mapping for real. We were a little disappointed we couldn't do it on the sand in Miami in GF64.

PD has the same 8 byte image structure. Didn't add for now, as it was all non-zero and they clearly do detail mapping. Maybe they calculate in the on the fly instead of hardcoded somehow. It doesn't really make sense by the image, since it depends on the main image size...so they probably corrected.

[CrashOveride]

I'm really confused on what's happened, do I have to edit my ROM to get it to work with newer editor versions?
_________________
Playing old, low poly games since 2003