ShootersForever.com Forum Index

GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion
GoldenEye Cheats, GoldenEye X Codes, Tips, Help, Nintendo 64 Gaming Community


In-Game Debug Menu, In Depth (Series)
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ShootersForever.com Forum Index -> Q-Lab Hacking Department
View previous topic :: View next topic  
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Sun Feb 21, 2010 7:57 am    Post subject: In-Game Debug Menu, In Depth (Series) Reply with quote Back to top

In-Game Debug Menu, In Depth (Series)

Welcome to this thread, dedicated entirely to the in-game debugger. This series of posts will focus on different debug options, how they did work, how they work now, and on occation how they can work again.

First, if you've never heard of it, NTSC versions of GoldenEye have an in-game debug menu with a series of nifty features, sometimes called the master cheat menu. You can't normally activate it, but you can reactivate it with codes or hacks. NGEE owners can use the code:
Code:
"Debugger #4" .off
81036F6C 0000
81036F6E 0002
D0064F31 000C
80024303 0001

To activate the menu, press C-up + C-down at any time.

As can be expected, a fair number of these features have been entirely removed. The remaining features either still work as expected, have only been partially removed, or expect certain requirements be met to function. Subsequent posts will delve deeper into these.

<_>

Easiest to deal with are which options are completely and utterly removed. Everything in this list does exactly the same thing when selected: they call 7F0901B0, grabbing 80036B70, and save this value to 80036F70.

  • level
  • region
  • scale
  • select anim
  • gun pos
  • flash colour
  • hit colour
  • screen size
  • screen position
  • music
  • sfx
  • gun key pos
  • magic fog
  • fog
  • intro edit


Other features will still set flags to indicate they were selected or try to run code, but unfortunately the code has been removed. These are listed here.

  • stan region - 7F0B312C does nothing
  • stan problems - 7F0B303C does nothing
  • show patrols - never tested
  • chr num - read but unused
  • joy2 sky edit - never tested
  • joy2 hits edit - read but unused
  • room blocks - 7F03E698 does nothing
  • profile - never tested


<_>

A fair number of options are simply activators, many self-explanitory. Since little explaination is necessary, here they are listed.

  • move view - activate external camera
  • bond view - enters 1st person view
  • invincible
  • visible - toggles invisibility
  • collisions - toggles object collisions, also known as Bond Phase
  • all guns
  • max ammo
  • fast - also known as turbo mode
  • vis cvg - also known as line mode
  • background - toggles stage backgrounds on and off
  • props - toggles objects on and off
  • test man pos - displays position and rotation on-screen
  • play title - returns to menus, loading "stage" 5A
  • bond die
  • intro - replays the solo intro camera, starting from step 3
  • auto y aim - toggles auto aim y for current player, at BONDdata+128
  • auto x aim - toggles auto aim x for current player, at BONDdata+138
  • 007 - temporarily unlocks 007 mode
  • agent - temporarily unlocks stage on agent
  • all - temporarily unlocks stage on all difficulties
  • objectives - forces all objectives complete
  • gun watch pos - reposition items in the watch menu


(+_+)

All the rest will be analyzed here in subsequent posts, broken down and outlined. Some may work while others don't; some may even be restorable. As each is filled in, this table will include jumps to the specific post for convenience sake.

_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!


Last edited by zoinkity on Tue Dec 28, 2010 9:13 am; edited 13 times in total
 
View user's profile Send private message Send e-mail
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Sun Feb 21, 2010 7:58 am    Post subject: rgb/jpeg grab Reply with quote Back to top

Now for the first installment in our ongoing series of removed and N3RF3D debug features, image capture.

There are, in essence, two different image capture features in the debug menu. Each took a screenshot, basically copying a combination of the viewport buffers, and output in the selected format. The debug menu listed two, jpeg and rgb. What it doesn't mention is that it converts the output mode to 32bit colour before it does this, then switches back to normal 16bit output when its done.

Of more interest is that there are really four screenshot routines, not two. There happens to be 16bit versions of both the jpeg and rgb output. Neither of these are used at all.

The redirect functions for each are still in memory and are annotated in the documentation. Look for:
70004758
700048D4
70004A60
70004BB4

There are three other rather important functions as well, used genericly for many removed functions. These are:
7F0D0098 Returns TRUE if an instance of string A0 is found on the PC. Used to check if an output file already exists.
7F0CFFE0 Grabs and exports a chunk of memory a given size. Likely this originally sent it straight to PC, possibly copying to the devtool region.
7F0D00E0 Handles special command-prompt-ish strings for manipulating this data, which incidentally may have originally sent the commands to the PC or devtool and not in-game.

+_+

How they worked:
When you select either option to take a screenshot from the debug menu, it sets one of two flags:
80036FFC 1- grab rgb screenshot
80037000 1- grab jpeg screenshot
The debug menu parser checks for these before parsing selected commands, whenever the flag at 80024300 is set.
If one of these is set, it starts to copy the buffer. There are two screen buffers, so it loops this twice. It then sends this to the proper capture routine, and afterward resets the screen depth to 16bit colour if it isn't already.

All the image capture routines basically operate the same. They generate a unique name for their image, along the lines of "grab.#.format". They then take the screen buffer data, and feed it into 7F0CFFE0 to create a temporary .uix image. From there, they call 7F0D00E0 with different command options to convert this image.

uix2pix -xs# filename.uix
Converts uix to pix, outputing filename.pix. Optionally, can call -xs to set the line width.

fromalias input.pix output.rgb
Either renames or converts from pix to straight rgb output.

imgcopy -fjfif input.rgb output.jpeg
Converts straight rgb output using the given function (here jfif) and stuffs the output into the given file.

rm filename ...
Removes the given list of filenames.

imgview filename
Just a guess, but probably displayed the screenshot ;*)

One last note is that when it makes a 32bit screenshot, it sets that screenbuffer to 803B5000. After all, it needs twice the room of a normal buffer.

+_+

Why they no longer work:
The reasons are twofold.

1) Selecting either of these options from the debug menu will put the game in a permanent loop. When you take a screencapture, it looks at a list of previous captures, each named "grab.#.format". Each type of output has an index number to keep track of these, falling within the 21990 compressed binary:
800232C4 70004758 jpeg 16bit grab #
800232C8 700048D4 jpeg 32bit grab #
800232CC 70004A60 rgb 16bit grab #
800232D0 70004BB4 rgb 32bit grab #

Normally, it generates the string, then checks a nonexistant list of output names for a match. If it had already been output, it increments the number and tests again, until it finally receives FALSE as a result.
Problem is, something changed. The test function will always output a pointer to BONDdata. So, regardless the number the function just keeps running and running.

There is a workaruond though. You can convince the game to forgo checking devtools. Either use the code:
8004EACB 0000
-or open the compessed 21990 binary and set offset 0x2DD3B to 0. It won't attempt to check the devtools, so these shouldn't loop endlessly.

Otherwise, if you did want to keep the routines from going in circles but don't want to set the much simpler code above, you can write this in:
700047B0 53B0 NOP
70004930 5530 NOP
70004AB8 56B8 NOP
70004C10 5810 NOP
That will increment the picture count by 1 but miss the obligatory loop. It still won't do anything useful, but it won't sit there spinning. The othr variety though is much simpler.

2) Of slightly more importance, all of the output routines have been removed! 7F0D00E0 is a general reroute, appending transfer data to a string. Although it still properly redirects to each function, those functions had their dependancies removed so they return unconditionally. The PC side of all debug tools have been removed like this.

+_+

So, long story short it no longer works, and could only be made to work by rewritting their code from scratch. Incidentally, none of this code exists in any region GE ROM, but it might exist in another of Rare's games instead. Not that any of this is really necessary to reimplement, concidering emulators screencapture and there are tools to take screenshots via GS/AR...

-Zoinkity
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Sun Feb 21, 2010 8:00 am    Post subject: grab task Reply with quote Back to top

Latest installment in debug history: taskgrab.

This little marvel does a full 4MB RAM dump and sends it out for sushi. In fact, it is the sole reason 7F0CFFE0 is suspected of sending to a PC devtool.
Interestingly, it requires selecting the option by pressing A+B on controller 1 to trigger the effect. Selecting the option using any other button combos will not work.

+_+

How it works:
When you select the taskgrab feature from the debug menu, it sets a flag at 80036FC4. Within the main loop, around 700067D8, 7F09106C reads if this is set.
Then, it tests if A+B are pressed on controller 1. Both must be pressed simultaneously without any other keys when you select the option for debug in order to trigger the effect.
Much like the image capture routines, it uses a count kept at 80024324 and concocts a string of the sort "u64.taskgrab.#.core", checking if the name is unique and looping until it can make a good one.
When it finally comes up with one, it takes a snapshot of rdram from 80000000 to 80400000 and sends it with 7F0CFFE0 to the devtools.

+_+

Why it doesn't work:
Well, in theory, it might is the funny part. There just isn't anything to receive the data ;*)
As an interesting note, the devtool range starts at 0xF00000. Supposing you extend your ROM as the editor has been doing and happen to use, say, an eeprom cartridge or some other writable media, it would (probably) dump your RAM copy to this location properly since it would be valid, writable memory!

However, the same looping issue occurs here as with the image capture. Infinite looping can be stopped by setting the command below, but it obviously won't reactivate the feature.
7000683C 743C NOP
Likewise, you can use the general devtool disconnected cheat from before:
8004EACB 0000
-or open the compessed 21990 binary and set offset 0x2DD3B to 0.

+_+

Next session: ramrom recording, playing, and saving. You really don't want to miss that ;*)

-Zoinkity
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Sun Feb 21, 2010 8:02 am    Post subject: record/replay/save/load ramrom Reply with quote Back to top

Figured out why we can't use the demo save/replay features from debug. They are rigged to use the development tools hardware address range, from 0xF00000 - 0x1000000. Replays from there, saves to there. If you happen to use an eeprom cartridge or anything else that is writable in this region, you could record sessions straight from an uneditted debug menu!

Original usage for recording is:

  1. Select a "record ramrom" option on the mission objectives pages in the main folder and start a stage. Does nothing until the stage# changes. 8008C5F0 is your record slot#, which is the set number (0-3), 80048488 nonzero flags next loaded stage to start recording.
  2. Play for a bit. It takes periodic packets of controller data and saves them to the devtool temporary addresses.
  3. Press c-up + c-down to stop recording. Note you need the debug menu active for it to read this. Otherwise, it stops when the stage ends.
  4. Select "save ramrom". This sends whatever ramrom file is at F00000 to the PC, setting an entry name and whatnot.


Stipulations:

  1. You must not plug in or remove controllers during a recording session.
  2. Fewer controllers means smaller file. Unused but connected controllers are still read.
  3. Demos force solo, so no multiplayer demos can be captured.
  4. The debug menu must be activated to stop recording unless you end the stage.
  5. Intro data sets already have to be written for each file you're catching if you want to use something other than set 0. Set 0 is normal stage start, sets 1-3 different start/equipment options. Write this in the setup first.
  6. Demos "stop" one second before the end of the demo, to allow time for "intro camera A" to black out.


+_+

So, what works and what doesn't?

  • "Record ramrom" and its three counterparts work fine. They set the set number used and trigger a request to catch a new replay. The issue comes later. When a new stage starts, certain game settings and the current eeprom file are copied, and then controller state packets are written to the F00000 device. Assuimg this memory is valid and can be written to the feature works swimmingly. If it can't be written, well, that's bad.
  • "Replay ramrom" does sorta work. It replays the file at F00000, although you will want to do this from the title and not gameplay. Incidentally, it redirects to the same function used to run the normal replays in the game intro, but with a forced address.
  • "Load ramrom" is a mixed bag. Only issue here is with looking up the filename, since it reads from the PC list. Otherwise, by default it does load the file to the temporary location, basically allowing a replay of the previous file. In other words, it doesn't work right.
  • "Save ramrom" is doubly lethal. It tries to look up a generated filename on PC ad-infinum, and then proceeds to save a new entry to the non-existant list. From the looks of it, the request may be a pif write to an unknown device, but this is only a guess.


Newly-written ramrom files will work, regardless their size, on any ROM capable of reading them. What does that mean? It means a capture can be as long as you still have ROM to stuff it in, and implies that somebody's already made a valid capture to test the point ;*)

+_+

How to get capture working:
Not much of a tease I know. The only thing keeping capture from working on every copy of the game is a valid place to record the controller input and a way to suck it back out.

Basically, most people will not have eeprom carts, but they probably will have a 8MB expansion pak or can make it seem like they do. Instead of writing to hardware F00000, ramrom can be written and read to a different, unused address, such as 80400000. So, the trick here is to redirect a PI write request so it becomes a simple memcpy(). That involves a tedious and nasty ASM hack, which thankfully somebody else has done for you ;*)

Ramrom recording works fine from 80400000, but requires you to be able to retrieve the file. The size of the file isn't an issue; this is given at 80400080 (ramrom+0x80). On hardware grabbing memory is easy enough--even a GS can do it.
Emultors are more dicey. Nemu is kind enough to have a memory dump feature, but other emulators will require you using other programs to strip it out. I expect the editor may do this in the future.

Injecting them into a ROM requires entering the ROM addresses for each demo into a table. Ramrom may be at any ROM address, due to the unique file structure. It pulls each packet of controller input as it needs it, so no endpoint is required.

As for recording multiplayer, well, that's rather interesting. It works. Originally, the system forced solo. Interestingly though, ramrom files have a set of MP settings and even save what mode was selected. In fact, getting it to record and replay MP demos is as simple as telling it to read the mode from the file.

Why did they rig it like that then? Well, you can get a memory error after recording an MP demo, for an obscure and probably annoying reason. More likely though, they just didn't feel like it.

Oh, PAL demos and NTSC demos are incompatible, for some rather obvious reasons when you concider the intricate millisecond timers and clock counter...

+_+

The inevitable:
Naturally, the feature has been reactivated!
http://www.mediafire.com/?b0vhak0n14cr7c2

There are two patches here. One allows you record and playback, but is probably terribly unstable. The other simply allows playback of MP demos generated by other people. That one should be safe...

Record patch:
This patch is brand new and does some rather trippy stuff. I doubt it is stable. Apply it only to a backup copy of a ROM, not your favorite and final, just to be safe. Otherwise, you can apply it to any non-NSNA ROM as far as I know.

MPplayback patch:
Shouldn't cause any issues. Simply allows reading the mode from the ramrom file. Should be safe on any ROM. This is required to play back MP videos.

The readme lists how to record, grab your file, and reinsert it.

For console users, you too can experience the awesome power of ramrom recording:
http://www.mediafire.com/?f13bv8vb34xhrbv
Follow the readme. It's somewhat unstable, even for a GS application.

+_+

One last digression:
Related is that replays could be locked until you've completed Egypt! If you haven't finished Egypt, all the ramrom files after one that's locked are inaccessible. Needless to say, this feature wasn't used but does still work fine.

The ramrom table at 800483F0 is set up like this:
Code:

0x0   4   ROM address
0x4   4   lock

If the lock is set to 1, then this demo and any following will not play until after Egypt is locked. Setting it higher will shorten the list, which can be handy if you want to test if a single file will run.

-Zoinkity
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!


Last edited by zoinkity on Sat Sep 25, 2010 8:48 am; edited 1 time in total
 
View user's profile Send private message Send e-mail
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Sun Feb 21, 2010 8:03 am    Post subject: show mem bars Reply with quote Back to top

Latest installment: Show Mem Bars

There's two memory display features in the debug menu, "show mem bars" and "show mem use". They really are quite different--really! For now, let's deal with the bars.

Show mem bars no longer works, or at least no longer works right. Originally, it displayed the percentage of geometry memory in use, using two methods. First, it displays the total #opcodes used in the current display list buffer. Then, it displays the percentage of geometry memory used.

Unlike show mem use which has a clever display, show mem bars displays a string. It could use any string, but happens to use the one at 80048320. That's 25 "=" marks, each denoting 4% of the total geo. memory.

When the flag at 800241B8 is set, 7F0BD810 attempts to draw the display. It feeds values into 7F0BD7CC, which computes the string length and the percentage of memory used. Originally, this would have been displayed.

[+_+]

So, what's wrong? The problem lies in 7F0BD7CC. Right now, it determines the string length and the percentage of memory used, but immediately stops afterward. Nothing is displayed or saved.

Good news is that hacking a display into the routine would reactivate the debug tool. It wouldn't requre much additional code. Simply multiply the strlen by the percentage of memory used, then use a normal print output. Granted, this wouldn't allow seeing if overruns occur, but that would be a rather fatal situation anyway ;*)

-Zoinkity
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Sun Feb 21, 2010 8:04 am    Post subject: show mem use Reply with quote Back to top

Today, one of the more interesting debug features, "show mem use".

Unlike "show mem bars", this feature displayed a list of all the memory use in the game. Also unlike its counterpart, it happens to be quite gutted ;*)

+_+

What does it do? It sifts through the table of allocated memory blocks at 80063C28 for starters. It displayed debug information to tell how efficient merging memory allocation entries was. It likely also displayed the allocated totals for each of the eight memory banks as well, but this is only speculation.

This is a single-shot triggered feature, setting a flag at 800241B4 when you select it and reseting the flag afterward. Most likely this means the debug info was piped to the devtools and not displayed on-screen.

What did output look like, you ask? Firstly, it listed each entry in decending order. It also listed the number of 0x400 memory segments each entry took, not total memory. These are the same numbers used in the memory allocation strings, wink wink.
To write up the list, it uses three strings:
Code:
800291E0   "%d "   size entry
800291E4   "..."   if more than 200 entries
800291E8   "[%d]"   #entries, if over 200


So the output would look sorta like this, heavily truncated from 200 entries of course ;*)
"400 250 ...[201]"

As far as what shows up, this would be anything loaded to memory dynamically. Images, models, rooms, etc. are all listed. Note though that anything in a continuous line, such as room geometry, will probably be merged into one larger memory chunk.

+_+

How much of it still functions:
7000A100 is a problem. This generates a string listing the 200 largest blocks of memory in decending order, as well as the total entries in case more exist. However, this string is not printed from this function, and the string pointer invalidates after you return from the function. So, in other words, you don't ever get to see this list.
That makes 7000A29C rather useless, since it generates lists before and after merging memory. Sadly, you can't debug merging memory allocation as a result, but the plus side is that you really don't have to since it obviously works fine.

700098F0 is sadly nerfed. It loops eight times, doing nothing. Potentially this may have listed all eight memory allocation bank sizes, but now it does nothing.

7F0BD774 is a major problem. It accepted a pointer to the current display list, so it either drew something to screen or used it a reference point within geometry memory. Either way, the routine has been completely removed.

+_+

Judgement!
Not much can be done about the deleted routines, but it is feasible to display the memory use information. As it stands now, though, this function is too badly excised.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Sun Feb 21, 2010 8:04 am    Post subject: load weapon Reply with quote Back to top

Debug feature of the day: load weapon

Finally, a debug feature that actually works! Load weapon does not magically load a single weapon into inventory. Oh no. It reads a list of weapon model IDs and loads each into memory. Basically, this tests memory consumption with various weapon sets in mind.

The list of weapon models can be found at 8002A23C. These eight entries are copied and each is loaded in sequence. The block ends with an entry of -1, but it is also important to note that it can't be larger than 8 entries without hacking.

Incidentally, you can give it any model ID. It doesn't load 1st person models, just 3rd person model IDs. Unfortunately though, there isn't any way to tell that the model load didn't work short of the game locking up or using some other memory viewing tool.

Still, the feature does work entirely as expected and can be used by an enterprising hacker to test memory restrictions.

-Zoinkity
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Sun Feb 21, 2010 8:05 am    Post subject: load object Reply with quote Back to top

Easily the most misleading debug feature, "load object".

Load object does not load a single object, or a list of objects. It zips though the current stage's action blocks looking for model-loading commands. It then loads each and every one of them into memory, so that way you know if you need to allocate more memory for the stage.

Only action blocks for the stage are parsed, not any generic ones. The commands searched for are:

  • 1B - drop item
  • BD - spawn actor
  • BE - respawn actor
  • BF - spawn item
  • C0 - spawn hat

It does skip over random heads, but it doesn't catch random bodies. Also, despite the model for pickups, it will also load the default model for that item's pickup if applicable.

Granted, there aren't any bells and whistles to let you know that you exceeded available memory; for that you'd need to read the memory debug display or watch for errors. However, it saves quite a bit of time and effort simply loading all the possible models for a stage at once.

-Zoinkity
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Sun Feb 21, 2010 8:07 am    Post subject: Print Room Loads Reply with quote Back to top

"Pr room loads", obviously, printed a list of all loaded rooms. It was one gigantic, crazy string listing every possible stage and whether it was loaded, a bit like this but much longer:
"1..45..8901..."

That lists an amazing 14 rooms. Scary enough, the real thing prints out every possible room, which for unhacked ROMs would be 150, or 0x96, rooms. Unloaded rooms appear as ".", loaded ones as a single-digit. Room 0, which is invalid anyway, is skipped.

+_+

State of things:

7F0B5ED8 tests for the feature when activated and generates the string. Unfortuantely, this string is never output and invalidates on return.

However, some simple hacking could set the string someplace where it can be recovered easily. It could also, theoretically, be printed to the screen, but 150 entries would need to be text wrapped, and you'd have about 6-7 lines of text on screen at all times.

-Zoinkity
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Sun Feb 21, 2010 8:08 am    Post subject: Print Man Pos Reply with quote Back to top

Not to be confused with "test man pos" which works, "print man pos" was a tile debugger, operative word "was". You would feed it the current tile, player's x and z positions, and it would print something using the tile's colour.
What that is is speculative, but all things concidered it probably would have been either your position or a "hit/miss" sort of test. After all, we've managed to write all sorts of clipping files where you can walk out of the stage.

+_+

What's left of it?
7F0B2C2C handles the process. When the "print man pos" flag is set, it calls this routine. The x and z positions are not used. However, it does grab the tile colour and save it as a 24bit rgb value. Unfortunately, this is all that happens.

Without a clear idea what was being tested it would be difficult to restore this function. It doesn't seem as though it would merely output your position, as there is a much better routine for this. It isn't even obvious if it was printed to screen or devtool. Quite honestly, there is too little code to know.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
SubDrag
Administrator
Administrator


Joined: 16 Aug 2006
Posts: 6118

 PostPosted: Sun Feb 21, 2010 5:35 pm    Post subject: Reply with quote Back to top

I kinda of didn't want to post to ruin the continuity, but that's just pure brilliance, and extremely fascinating, and I can't wait to hear more installments.
 
View user's profile Send private message
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Thu Feb 25, 2010 10:24 am    Post subject: Reply with quote Back to top

See, there's the brilliance of the first post - links to the rest!

Working on the last couple now, between everything else. Preliminary looks like there was a tile thingy that output colour-coded side or connection values to debug. Each line was a different primary colour, like red, blue, green, etc.

On reflection, a fair number of these can be rewritten to output to stderr, otherwise known as the debug menu display. Any sound useful? Could salvage them if you'd like ;*)
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Tue Dec 28, 2010 9:11 am    Post subject: Reply with quote Back to top

Debug feature of the day: joy2 detail edit

Had to revise the front page thanks to this one. It does work after all. Who knew?
When you select joy2 detail edit, it allocates a block of memory large enough for every image. Every time you shoot a non-player object, wall, or other textured surface, the image ID of the texture struck is secretted away.

Now, here's the interesting part. Whenever you expand one of the special C0- texture ID commands it tests to see if you're using the detail edit. So, if you've activated joy2 detail edit, you've happened to have shot that exact texture ID previously, and you use the correct C0- command, then detail edit kicks in.

"Detail" is short for level of detail, usually abreviated LOD. LOD ensures textures are applied only at certain distances, usually to replace a less detailed texture with a more detailed one. Granted, you can also use it like in Mario 64 to swap out Toadstool's face with Bowser's. Here, they use LOD to partially swap images instead of full swapping. The end result is to give a more detailed stone or woodgrain when close to the object without the issues of visual redundancy you get from afar. Both GE and PD use this, and emulators don't recognise their method. That's why Grid and the trees on Surface and Bunker simply don't look right. The wrong texture is visible all the time and swapping never occurs. Unlike some other games, they set the diffuse level byte in the RSP command Set Primary Color.

I'll provide a more detailed post on C0- image calls, but the basics that apply here are this. C0- is a special fake command Rare used to save space, and they load images using a 3-nibble ID. There's 5 different types, and three are of interest here.
Types 0 and 2 are the ones that will directly function with the detail editor. As mentioned before, when you start detail edit it makes entries for every single image. Until you set values for an image nothing special will happen. You can, of course, set them by hand with a hex editor. The real way they were set though was by passing a type 0 command for the given image. The format is like so:
Code:
C0.FFFF.00 LL.000.III
FFFF   flags for ST mirror/clamp, ST edge offset, and ST shifts
LL   diffuse level, or distance at which LOD replacement occurs
III   3-nibble image ID

Type 0 normally sets an image with a certain diffuse level (to borrow a term from telemetric storage docs). However, when using detail edit and you happen to load a type 0 image for the first time it sets the S/T shifts and diffuse level for every subsequent type 2 image load. So, after the detail level and shifts are set, images loaded with type 2 commands will reload the last used values and apply them--but only when a surface has just been hit! Yeah, this is a real bugger.

The end result is this: you shoot a surface, then make up a type 0 command for that image. When you reload a room or whatnot and it loads the image as a type 2 command--the most common command by far--it will apply the LOD values. This can be used to test different values for surfaces to find the appropriate one for the effect you're looking for. Incidentally, the values they did use range from F8-FD, which is roughly camera-8 to camera-3. In other words, you'd have to nose up on it pretty close.

+_+

This may seem, well, pointless to most of you. It is essentially an aid to write two commands, type 0 and type 1. LOD isn't especially important to type 0 in fact, but type 1 depends entirely on the LOD values. Type 1 loads two images simultaneously, one swapping the other at a given distance. The command is used exclusively to do close-up detail work and is the little guy who buggers up the above mentioned stages. An enterprising hacker could, given enough time and effort, use this to test various LOD and shift values on textures. However, given the state of the editor and that hex editors provide a much faster method to do this the point has become somewhat academic. Why fuss with this when the process has been automated?

-Zoinkity
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
SubDrag
Administrator
Administrator


Joined: 16 Aug 2006
Posts: 6118

 PostPosted: Tue Dec 28, 2010 2:27 pm    Post subject: Reply with quote Back to top

They've really been fascinating, it's so interesting to see behind the scenes. Man Rare wrote a lot of tools/extra stuff!
 
View user's profile Send private message
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1684

 PostPosted: Thu Dec 30, 2010 9:11 am    Post subject: Reply with quote Back to top

I should add that LOD is used extensively in GE. The Rare logo, for instance, loads an image tile with both a near and far image. On console, only the close one is used yet on emulators the large guy is all you see. This has to be the only game I've tinkered with with an LOD debugger.

Have a lead on the hit edit now as well. Will try to get to it among other projects.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ShootersForever.com Forum Index -> Q-Lab Hacking Department All times are GMT - 8 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Cobalt 2.0 BB theme/template by Jakob Persson.
Copyright © 2002-2004 Jakob Persson


Powered by BB © 01, 02 BB Group

 


Please Visit My Other Sites: GoldenEyeForever.com | GrandTheftAutoForever.com

Got kids? Check out my Dora The Explorer site with games and coloring pages!

Our forums feature Nintendo 64 games, GoldenEye 007 N64 New Maps and Missions, GoldenEye Cheats, N64 Emulator, Gameshark, GoldenEye Multiplayer and more!

[ Privacy Policy ]