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

[Wreck]

I had tried comparing, but I don't think GoldenEye has any 64x64 4-bit colour images normally? I think Zoinkity was the first to utilize them in Labyrinth. So I don't have any real reference to follow. Size 40 x 40, Mipmap Levels 06, is what I have guessed. But the other flags, I'm not sure. I either get a really screwed up colour palette, or even crashing when the screen comes into view.

[Trevor]

To use 64x64x4 in GE you need no mip-mapping.

Remember that CI images use 2KB for TLUT, that leaves 2KB for Tile(s)

64x64x4 = 2KB so you an only have 1 tile in TMEM.

Since 4bit CI has 15 TLUTs I had thought about moving the TLUT to the end allowing the Tile(s) to overflow into the second 2KB but I have not experimented yet.
It should be possible since there are some games that use 64x64 and seem to have mip-mapping.


More Info

Trev
_________________

[Wreck]

This is great information, but it still doesn't help me with the monitor screens, haha.
I will poke some more today.

I reduced one image to 32x32 4-bit colour, and it works fine. But the quality has taken a nosedive, and the other image I was going to use is even worse when shrunk down.

[Wreck]

By the way, I think something is happening with the monitor animations. If you make edits to any screens, by deleting anything, if you reload the ROM in, it uses the current table size as the maximum, rather than the original size. Say you delete a whole bunch of stuff, then save, if you then try to add things in, you are told you will exceed it, when there should be room leftover.

[Carnivorous]

SubDrag wrote:

Updated

Thank you, another error I spotted was description for GE sub-action CC. Please fix with the corrected info

Code:

<CC> CC.XXXX.AAAA Vehicle Set Speed [X] And [A]cceleration. 03E8 (1000 decimal) units = 1 meter per second travel speed. Acceleration time is number of game ticks to reach set speed - 3C ticks (60 decimal) per second.

[RyanDwyer]

I see you guys were looking into PD's sound IDs earlier. Well, I've been looking into them recently too. Here's what I've found:

Mask the ID with 0x8000. If this bit is set, the ID needs to be replaced via the Russ sound bank (offset 0x3e04 in the 39850 segment). To do this, mask the ID with 0x01ff then use it as an index into the Russ sound bank. Each entry is 4 bytes long and is composed of two u16s. The first u16 is the new sound ID. The second u16 is a number in range 0-63 and is an index into a config array which follows the Russ sound bank (offset 0x44f8). The configs likely contain settings like speed and pitch, and I know the "contains swearing" flag is in there too. But what you're interested in is the first u16. That's the replacement ID.

So now you are either using the original ID (if masking with 0x8000 was 0) or the Russ replaced ID (if masking with 0x8000 matched). Whichever it is, mask it with 0x1000 (edit: actually 0x1800) to determine whether it's an mp3 from the file table or an instrument number from the first ctl/tbl file. If masking with 0x1000 matches, mask it again with 0x07ff and use that as an index into the file table. If masking with 0x1000 was 0, mask it again with 0x07ff, subtract 1, then use it as an index into the instruments list.

I also did some testing of the flags to try and determine what they do. I don't think there's anything new here.

0x0800 = no noticeable effect
0x1000 = mp3
0x2000 = whisper affirm
0x4000 = normal affirm
0x8000 = determines whether to use the Russ sound bank (all replacement IDs have 0x8000 set as well - it doesn't appear to do anything else)

Here's an example: sound ID 0x8196 is Carrington's "Get up to the offices" line in Defense. 0x8000 is set, so we mask the ID with 0x1ff, leaving 0x196, and use that as an index into the Russ sound bank. The replacement ID here is 0xd313. This ID has 0x1000 set, so we mask with 0x07ff, resulting in 0x313, then use that as an index in the file table which gives Ainvcar04M. The 0xd313 ID has 0x2000 is set, so Jo affirms. 0x8000 is also set in the 0xd313 ID but this doesn't appear to do anything.

EDIT: Upon further inspection it appears the mask for determining if it's an mp3 or instrument should be 0x1800, not 0x1000.

[Carnivorous]

Some new documentation with GE command E7. Please update sub-action name and actions.ini with the following details

Sub-action name

Code:

If Guard Is Firing And Using 180 Limit Target Bit, Goto Label

action.ini

Code:

<14> 14.TTTT.####.LL Guard Fire/Aim At [T]arget, Goto [L]abel On Success. Make guard aim/fire their weapon at target, goto label if successful. Target bitfield argument is used to set the target type (preset/Bond/guard ID #). 00x1: set target to Bond (ignores target argument) 00x2: set target to front of guard 00x4: set target type to guard ID - put guard ID # in #### field 00x8: set target type to preset - put preset # in #### field 001x: set target to compass direction - put direction in #### field (hex) N: 0000 E: C000 S: 8000: W: 4000 002x: aim at target instead of firing 004x: limit target range to 180 degrees in front of guard (cannot be used with Bond target) <15> 15.TTTT.####.LL Guard Fire/Aim At [T]arget Kneel, Goto [L]abel On Success. Make guard kneel and aim/fire their weapon at target, goto label if successful. Target bitfield argument is used to set the target type (preset/Bond/guard ID #). 00x1: set target to Bond (ignores target argument) 00x2: set target to front of guard 00x4: set target type to guard ID - put guard ID # in #### field 00x8: set target type to preset - put preset # in #### field 001x: set target to compass direction - put direction in #### field (hex) N: 0000 E: C000 S: 8000: W: 4000 002x: aim at target instead of firing 004x: limit target range to 180 degrees in front of guard (cannot be used with Bond target) <16> 16.TTTT.####.LL Guard Fire/Aim At [T]arget Update, Goto [L]abel On Success. Update guard's aim/fire target, goto label if successful. This sub-action only works if guard is already aiming at a target. Target bitfield argument is used to set the target type (preset/Bond/guard ID #). 00x1: set target to Bond (ignores target argument) 00x2: set target to front of guard 00x4: set target type to guard ID - put guard ID # in #### field 00x8: set target type to preset - put preset # in #### field 001x: set target to compass direction - put direction in #### field (hex) N: 0000 E: C000 S: 8000: W: 4000 002x: aim at target instead of firing 004x: limit target range to 180 degrees in front of guard (cannot be used with Bond target) ... <E7> E7.LL If Guard Is Firing And Using 180 Limit Target Bit, Goto [L]abel. If guard is in firing state and using 180 degrees limit target range bitflag, goto label. Bitflag is set by fire at target sub-actions 14/15/16.

Found a bug with GE's action editor - with a new setup, create a action block ID 0401 and add sub-action EB. Then try to search for the string dead. The editor will say `sorry dead was not found`

[Wreck]

I just came across this the other night, and have no idea how long it may have been around for. But it seems that after you make some edits to the image bank, something is happening to texture hit types - most notably to water. My tests showed that if you either edit a hit type on an image, or you add in a new image, then save out your ROM, the hits will be incorrect.

Normal water hit...
Sparks, and splash sound.

After Editor export...
Sparks, debris, small fireball, smoke, and splash sound.


I don't know if it is affecting others, but it may be possible. I've only shot at images 05E4, 05E5 and 05E7 (water stuff), and it happens to each. I also checked multiplayer, and it is the same way.

Could this be a longstanding side-effect of reducing the table size of the image bank in 21990? Maybe some offsets to images not supported with the change?

[Carnivorous]

Clicking the flag checkboxes for characters within the object editor (GE) will not update unless I reselect the current character from the list of characters.

[SubDrag]

Updated actions ini and that one action.

So....on the "DEAD" search, search was detecting if was hex, and if so, just searching bytes...that is hex. I guess I'll just have it search as if it were text no matter what too. Originally I think I was trying to have hex digits only search the byte values, and if not hex, search the descriptions. Of course this is an unusual, it's a hex value, and it's a string.

Fixed the not updating character flags.

Water hit types...looks like another shift << 3 instead of << 2 that was missed from the beginning. This appeared to fix water, if you notice any other images exhibiting this besides water, let me know, and I will track it down. If you just open a ROM in images, and write ROM, it will be fixed.

[Carnivorous]

Thanks!

[Wreck]

Great. Glad you found it so quickly. I'll give it a look tonight.


I did just want to mention the monitor animations table again, as I am not sure if any updates affected it. But it seems that, once you delete some data out of it, that where ever the final monitor entry ends becomes the new table end. It won't let you add more back in, and it looks like the end gets padded with 0C entries. My current workaround is padding with 0B loops in one animation, to maintain full table size.

By the way, I did find success getting 64x64 4-bit colour images to work as monitors. I need to confirm on console, though. I'll post some info if it worked out.

[SubDrag]

Can you give me step by step instructions on a clean ROM? Then hopefully can figure out what's off. Not able to recreate.

[Wreck]

I should have mentioned that you need to delete some monitor data, save the ROM, reload it, and add some data back in. If you try to save, it will warn you about the size. That should trigger it. The Editor adds 0C entries after the final monitor to pad to the end (0x1170, I think?). It seems the Editor may believe it's part of the final monitor, so it recognizes the table as full.


Tested the water hit type update, and it looks good. If I happen to spot anything off, I'll make note of it.

[SubDrag]

The editor seems to read all the TLB entries, in order, and assume the last one ends at 0x11170. The others just go up to the next one. It pads with 0C to the final entry, so the final entry is always going to contain extra 0Cs and fill up to fill capacity. I'm not sure how to calculate the final spot, I guess I never did, so it has to pad. Well not really sure how any of them end, it just does the next spot, which matches.

I'm not really sure it has an end spot, it just executes infinitely? That's why the editor does that anyways. To make future edits you need to delete from final 0x33 slot.