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

[zoinkity]

https://mega.nz/file/IqgigCSL#7HgleKyR03vxohTHHnZWlMU6D74djV4RY00HmhpbJq4

With the beta release late April came a neat feature to add and remove the label tables in setup files. In "Edit Setup > Edit Presets/Pads" are two new options, (currently named) "Extra Pointer 8 Data" and "Extra Pointer 9 Data" (setup +20 & +24, respectively). They're optional fields only two stages included, and they were filled with unused string labels for development stuff.

Useless, in other words.

The patches linked above give a use to the second table in a completely backward compatible way. It allows you to embed a sky table, just like the built-in ones, that overrides the original settings (if any exist). This way you can provide skies for a stage without editing the "game settings" page.
New skies are tested first, then old ones. Both the "long" and "short" (fogless) type can be used. This patch also allows multiplayers to use the short type and automatically falls back to the solo stage's sky if no MP-only ones are present.

The format is identical to the built-in tables. An example is provided. PAL skies use a different label, so you can provide NTSC & PAL sky tables in the same setup file.

The readme explains this, but...
First it assembles a list of sky IDs to check.

• If a cutscene, checks stageID + 900 first.
  
• If a multiplayer, checks stageID + (#players * 100).
  
• Checks for original stageID.
  
• Checks for default (-1).

Next it assembles a list of all the tables it will check.

• If it exists, it searches the second table for data that starts with a "E1SK" or "P1SK" label. If found, the table is added to the list. Up to six tables of the same type can be present (not that you need that).
  
• The built-in table for "long" skies is checked after that.
  
• If it exists, the second table is checked again for a "E2SK" label. That's added to the list.
  
• The built-in "short" skies are checked after that.
  

The general idea is that the second table will be used for weird global stuff like this (maybe a future music patch?), and the first table can be reserved for user stuff. This gives an editor-safe place to embed things in a way you can find them again. For instance, you could embed ASM using an entry, then execute it with a specialized action block type. (Since it's user-only, you can make the presumption the user won't give a bad index...though you could also assume they know the table already exist and strike that branch. Anyway...)
The code portion of that action would be rather simple:

Code:

(NGEE only, obviously) if (p := @80065D20+0):   call @p+(cmd[1] << 2)() LUI   AT,8006 LW   V0,5D20 (AT) BEQ   V0,R0,+6 LBU   AT,0001 (S0) SLL   AT,AT,0x2 ADDU   V0,V0,AT LW   AT,0000 (V0) JALR   RA,AT NOP

Doesn't have to be code though. Anything stage-specific you want to embed can use these "label" banks.

[Wreck]

I've tested the setup file skies for the Tournament Edition multiplayer mod, and it works great. As I have about 70 different level IDs currently in use (59 + 11 mirrored variants), it means I will run out of sky entries at some point. This removed that concern completely. It also means that you could potentially rely on this method almost entirely, perhaps only keeping default skies inside the 21990 file (and a terminator entry, that might now be just 0x4 of zeroes), which would give the user nearly 0x1000 space to repurpose for other things. Nice chunk.

[StupidMarioBros1Fan]

So...technically this isn't a result of this patch (and I'm glad I discovered this before finalizing my testing and making this post, would've been really confusing & embarrassing ) but because I discovered it while testing this patch I'm still going to post this hear since it would be useful info. Plus you have already messed around with the Sky data as well as so much of GE's coding over the years along with Carnivorous no longer being an active member in the community.

This patch can be combined with Carnivorous' Footsteps and utilize the ability to endlessly swap between the 1P & 1P-Alt skies, there are issues though which actually opens the door to making the 1P-Alt Skies fully work as originally intended especially because this works for both the built-in Sky table and the new embedded ones.

The initial usage of the E9 or FB commands in the Action Blocks work like normal (like Cloud colors not changing for example) but a second usage actually changes the Cloud colors...but for the wrong Sky Ids. For example: Egypt's 1P will get 1P-Alt's clouds but 1P-Alt will continue to use 1P's clouds. Cloud Height also has the same effect where it'll work after the second usage but is swapped between the two Skies.
So for Egypt, the 1P Sky will become Blue with Purple (partially visible Red) Clouds that are at Cloud Height 7500 while 1P-Alt Sky will still be Black with White Clouds that are at Cloud Height 5000.



The following switch properly every time:
- Blend Mult [0x04]
- Far Fog [0x08]
- Near Fog [0x0C] (Presumably, couldn't figure out a difference)
- Intensity Diff [0x1C] (Presumably, couldn't figure out a difference)
- Far Intensity [0x20]
- Near Intensity [0x24]
- Sky Color [0x28]

The following don't switch until the second usage which then are used for the wrong one but do switch every time:
- Max Obj Vis [0x10]
- Far Obj Obfusc Dist [0x14]
- Near Obj Obfusc Dist [0x18] (Presumably, couldn't figure out a difference)
- Cloud Height [0x2C]
- Offset Sky Img [0x30]
- Cloud Colors [0x34-0x3C]
- Water Enable [0x40]
- Water Height [0x44]
- Water Img Offset [0x48]
- Water Colors [0x4C-0x54]
- Concavity [0x58]

Would you be able to look into improving upon what's in the Footsteps Patch? I'm assuming that Carnivorous just changed the ability to switch repeatedly and left the actual Sky data alone, but definitely do not take my word for it. If I am correct that the stuff related to the actual Sky is unchanged, then any improvements could be contained within this patch.



On a side note: The Sky Color has 2 bytes that seem to just be a toggle for the Clouds. Most levels use 01 while 00 is used for indoor levels like Facility and Control. Setting it to 02 or higher doesn't seem to do anything but that's based on in-game testing, I don't know if the actual code does anything else.

Cloud Transparency/Alpha seems to be based on the actual color where the darker the color, the less visible/blended the color is with the Sky. Black Clouds results in NO Clouds. This also results in bright colors appearing either almost white or pretty blended. For example, set Egypt 1P's clouds to 255,0,0 and you get Dark Pink Clouds rather than Red because the texture is still see through.

If I'm correct on those last two bytes being just a toggle, maybe they could be converted into a proper Alpha channel for the Cloud texture? Then instead of visibility being determined by color, it can be handled separately and then any colors can be used for Clouds including Black. An example would be the glitched colors in the XBLA version where levels like Cradle have vibrant colors that match the internal data but look wrong because the Clouds aren't as transparent as they should be. While it would require manually adjusting every sky to have the right transparency, it would also improve the color system for the Clouds.

Again, don't know the specifics or practicality of this idea but wanted to throw it out there.


Anyways, this is an amazing patch and have been enjoying it.
One last question: Is the "None" Sky crucial to keep? The one that is literally a block of 00s at the end of the Normal Sky section right before the Small Sky section? It's a full slot yet doesn't feel like it's simply unused when the original game had multiple sets of MP skies that went unused, so I want to know if it's like a failsafe or something like the Default sky (ID -1) or if it really is just an nulled out slot that could be utilized.[/img]
_________________
Stupid Mario Brothers is a YouTube series, get asked about my username a lot.

[zoinkity]

Being retired from GE myself no, tearing apart somebody else's patch doesn't sound terribly thrilling. This project only came about because Wreck asked for something kinda mundane and instead of doing what he asked for thought it a better idea to over-engineer an extension to insert anything.


Clouds are basically three-channel additive light where the image provides the alpha channel. That's a large part of why the cloud color (not sky) are stored as floats. It's supposed to be a highlight caused by a light source, like the additive "soft light" option you see in image editors.
Doing otherwise would require a significant change to the generated display lists. Not suggested.
Maybe if the image was used twice, once for colorization and again as a mask layer...but it wouldn't look natural or blend properly because it's no longer an additive highlight effect.


It's a single byte boolean if clouds exist, not two. There's another if water exists. A cursory check shows at least some tests are just nonzero but didn't trace every usage or anything. There are maybe seven unused bytes (padding or whatnot).


The NULL sky entries are how the lookup loop ends. If they don't exist you're relying on dumb luck that the lookup actually ends or that you don't pull random garbage data. They don't need to be a complete entry though. It ends on an invalid ID so only need those four bytes. In the original game reclaiming that space requires changing some hardcoded pointers though.


Switching skies back? That's not supposed to be a thing.

Command E9 switches skies by calling 7F0BACA8 with a blend multiplier of 1.0. It's crossfaded more than copied, using a preset copy of the current and alternate as a base. It's not a direct copy.
Besides the averaging, the sky RGB are reduced to a 15bit color range.
The code isn't too long, so here's a breakdown.

Code:

7F0BACA8  0xEF7D8   crossfade to secondary sky using blend modifer F12    accepts: F12=blend    p = @800825EC+0    800825F8[0:5C] = p[0:5C]    q = @800825F0+0    800825F8+4 = @p+4 + (F12 * (@q+4 - @p+4))   # blend    800825F8+8 = @p+8 + (F12 * (@q+8 - @p+8))   # far fog    800825F8+20 = @p+20 + (F12 * (@q+20 - @p+20))   # near light (fog's proximity to player)    800825F8+24 = @p+24 + (F12 * (@q+24 - @p+24))   # far ambient light    v = p[28]    if p[28] < 0:  v += 4294967296.0    k = q[28]    if q[28] < 0:  k += 4294967296.0    v = (int) v + (F12 * (k - v))    if v < 0:  v = -1    800825F8[28] = v & 0xF8   # sky red component    v = p[29]    if p[29] < 0:  v += 4294967296.0    k = q[29]    if q[29] < 0:  k += 4294967296.0    v = (int) v + (F12 * (k - v))    if v < 0:  v = -1    800825F8[29] = v & 0xF8   # sky green component    v = p[2A]    if p[2A] < 0:  v += 4294967296.0    k = q[2A]    if q[2A] < 0:  k += 4294967296.0    v = (int) v + (F12 * (k - v))    if v < 0:  v = -1    800825F8[2A] = v & 0xF8   # sky blue component    call 7F0BA758(800825F8)   # copy table 1 enviroment to current

Command FB triggers gas and, by extension, triggers a sky change. Egypt (0x20) has a hardcoded exception to the gas going off (though the gas timer still activates). The action triggers the exact same code called when a gas can is shot. The sky switcheroo isn't even a direct consequence, it's handled by the gas stuff.

[StupidMarioBros1Fan]

Fair enough, also I didn't know you were retired. Thanks for all the work you've done over the years.

In regards to the Sky switching, it's an intended feature in the Footsteps Patch, with a breakdown of the code included in the asmhacks.tar file IF you feel like checking it out but it's ok if you don't. Again, didn't know you were taking a less active role, so I don't want to trouble you with anything. That said, from the notes I'm seeing and what you specified, I think Carnivorous might've just adjusted when the gas leak is triggered rather than anything directly with the actual Skies and Fog features, along with the ability to toggle it so possibly the issues are part of the base game that went unnoticed.

Anyways, thanks for the response along with the clarifications about the clouds. I hadn't considered the color aspect to be an intentional design of simulating the sunlight passing through. Clever if that was what the original devs intended. Also, thanks for specifying the NULL bank is important, figured as much but great to know for sure.
_________________
Stupid Mario Brothers is a YouTube series, get asked about my username a lot.

[zoinkity]

Where exactly is that tarball at?
Was eventually able to find an archived copy of the hack itself.
(In case anyone else is looking, it's at https://web.archive.org/web/20220318150800/https://carnivoroussociety.github.io/)

Could make assumptions from the behaviour described but that would only cause confusion.


Will be emailing SubDrag about this in a moment but just noticed something...
You'll see in the code above there's a few addresses used for skies. Unless mistaken, they are:

Code:

800825E8   p->selected env1 sky 800825EC   p->selected env1 sky (used for blend/crossfade) 800825F0   p->selected NEXT env1 sky

First takeaway is that the shorter, fogless env2 doesn't set these pointers. 800825E8 is NULL and the other two remain whatever they were to begin with.

The second is how the alt sky is set.
The "next" sky is literally the next in the list. This is the one used as the secondary sky when the actions or gas are involved ("q" in the code from before). The problem is the sky ID is not used to select it! They use pointer math: current sky + 0x5C.

Here's the original lookup routine and you can see how that's set. (Note this routine is completely rewritten in the patch but behaves the same.)

Code:

7F0BAA64   locate and copy enviroment values    accepts: A0=stageID, A1=cutscene sky flag    k = 0    q = call 7F09A464()   # V0 = #players    if q == 1:  q = 0   # solo sky has no multipler    80044DC4+0 = @80058D70+0    80044DC8+0 = 0.0    if A1:   # 7F0BAAB8: cutscene skies (stageID + 900)       p = 80044E10       while @p+0:   # 7F0BAAD8          if @p+0 == (A0 + 900):             800825E8+0 = p             800825EC+0 = p   # cur. sky             800825F0+0 = p + 0x5C   # next sky (alt sky)             call 7F0BA758(p)   # copy table 1 enviroment to current             return          # 7F0BAB0C          p += 0x5C    # 7F0BAB1C    p = 80044E10    v = A0 + q * 100   # stageID + (#players * 100)    while @p+0:   # 7F0BAB54: check for a normal sky       if @p+0 == v:          800825E8+0 = p          800825EC+0 = p   # cur. sky          800825F0+0 = p + 0x5C   # next sky (alt sky)          call 7F0BA758(p)   # copy table 1 enviroment to current          return       # 7F0BAB88       p += 0x5C    if q >= 2:   # 7F0BAB98: MP duplicate of above; probably a bug, and this was supposed to test original stageID       p = 80044E10       v = A0 + q * 100   # stageID + (#players * 100)       while @p+0:   # 7F0BABCC: check for a normal sky          if @p+0 == v:             800825E8+0 = p             800825EC+0 = p   # cur. sky             800825F0+0 = p + 0x5C   # next sky (alt sky)             call 7F0BA758(p)   # copy table 1 enviroment to current             return          # 7F0BAC00          p += 0x5C    # 7F0BAC14: shorter, env2 skies w/o fog    call 70004650(F12=15.0, F14=10000.0)   # set page height    800825C0+0 = False   # True if fog enabled    p = 80045F50    while @p+0:   # 7F0BAC5C       if @p+0 == A0:  k = p       p += 0x38    if not k:  k = 80045F50   # default (stageID -1)    call 7F0BA9D0(k)   # copy table 2 enviroment to current    800825E8+0 = None 7F0BA758

The takeaway is there were rules we didn't conform to:

• Alt skies can only be used with env1 skies (those using fog).
  
• Alt skies (stageID+100) must immediately follow the normal sky. The ID doesn't even matter.

[edit]
One advantage to how this works lets you set MP alternate skies. Just set the alt (the next sky in the list) to some silly skyID like 10000. No stage will hit on that, but it will be a nice, valid alt for your stage. With a little injected code could catch the "one more minute" or "one point away" events and switch skies or something. Obviously each player count (2P, 3P, 4P) needs their own alt so yes, it's a bit bloated.