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 Previous  1, 2
 
Post new topic   Reply to topic    ShootersForever.com Forum Index -> Q-Lab Hacking Department
View previous topic :: View next topic  
Dragonsbrethren
Hacker
Hacker


Joined: 23 Mar 2007
Posts: 3056

 PostPosted: Sun Feb 17, 2013 2:03 pm    Post subject: Reply with quote Back to top

Hey Zoinkity, any plans to get back to these some day? I completely forgot about this thread, so rereading all of this has been great. Hope you dig into PD's menu once we get those beta ROMs, too.
 
View user's profile Send private message
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1666

 PostPosted: Sun Feb 17, 2013 8:16 pm    Post subject: Reply with quote Back to top

Sorry, forgot about it ;*)
Wow! It's been three years?

The tile debugger is interesting. That's the one mentioned a few posts ago. It basically tells you details such as the color, positions, and connectivity of the current and adjacent tiles.
I mention that since the XBox PD rehash as a full display for its tile debugger, but it's a bit more likely if PD still has the feature it will work more like this.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
Dragonsbrethren
Hacker
Hacker


Joined: 23 Mar 2007
Posts: 3056

 PostPosted: Sun Feb 17, 2013 9:24 pm    Post subject: Reply with quote Back to top

zoinkity wrote:
Wow! It's been three years?

Tell me about it. Razz

zoinkity wrote:
The tile debugger is interesting. That's the one mentioned a few posts ago. It basically tells you details such as the color, positions, and connectivity of the current and adjacent tiles.
I mention that since the XBox PD rehash as a full display for its tile debugger, but it's a bit more likely if PD still has the feature it will work more like this.

Interesting. I wouldn't have expected them to put any real effort into new debugging features in the XBLA version, not related to their additions anyway. I guess improved tile display would have been nice for making sure the tiles matched up with any minor background changes they made. I was surprised to see PD's (well, 4J's) pads display was just flat squares. I would've figured they'd at least show sizing information. Guess the editor spoiled me, hard to believe the original devs had so little to work with.
 
View user's profile Send private message
zoinkity
007
007


Joined: 24 Nov 2005
Posts: 1666

 PostPosted: Mon Feb 18, 2013 5:06 am    Post subject: Reply with quote Back to top

Well, it does sort of make sense to upgrade. The original debugging tools were designed for a different PC interface. Sure, printed text might tell you the same thing, but how exactly do you pipe it to PC? Making it more user-friendly also means less background reading for the debugging crew.

Chances are most of the debug threads' code in XBox is brand new.

Did they close off any of the known bugs? Especially interested in those MP pitfall tiles (Skedar Ruins door frame, for instance).
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!
 
View user's profile Send private message Send e-mail
Dragonsbrethren
Hacker
Hacker


Joined: 23 Mar 2007
Posts: 3056

 PostPosted: Mon Feb 18, 2013 12:05 pm    Post subject: Reply with quote Back to top

I never thought to try the door frame in Ruins. Truth be told I haven't played much multiplayer on the XBLA version; online is dead, I've already played the original game's multiplayer to death offline, and if I've actually got friends around who want to play I'd rather it be on a good map. Razz

The bug with the door on dataDyne Central's rooftop is still there, where you let the guard open it, stand on it, and walk through the wall, allowing for ridiculously short Agent times in Defection. Other than that, I don't really know of any.
 
View user's profile Send private message
Trevor
007
007


Joined: 15 Jan 2010
Posts: 884
Location: UK, Friockheim OS:Win10-Skip PerfectGold:v4.1

 PostPosted: Wed Mar 09, 2016 4:04 am    Post subject: Reply with quote Back to top

Another 3 years hahaha

Anyway, sub linked to the thread and I thought I might as well share some info and hopefully get corrections if Im wrong.

It is unfortunate that show mem use is gutted, that is a really usefull tool.

I think I know what information Display Speed provides.




The bars are "Chunked" by frames
If a bar crosses a mark then it takes another frame to complete.
If a bar is 3.2 marks long it takes 4 frames to complete etc

Code:


|====     ||       |        |        |        |        |   
||======  |        |        |        |        |        |   
|=========|===     |        |        |        |        |   

utz 99    30hz
rsp 0     2 frames
tex 1




|=========||=======|====    |        |        |        |
||        |=====   ||       |        |        |        |
|         |========|==      |        |        |        |   
utz 90    30hz   
rsp 9     2 frames(3)
tex 1



Chucking Knives into the abyse (Causing sound to stop)
|=========||||=====|========||||=====|========||||=    | 
||||====  |        ||||     |        ||||     |        |
|   ======|==      |        |        |        |        |

utz 88    10hz
rsp 3     6 frames
tex 9

First bar (red) - RSP Time, Converting DLists into DPLists.
First Bar (blue)- Audio RSP (always low, max 1/4 frame)
Second Bar (red) - RDP CMD time (without stalling)
Second Bar (blue) - Audio RSP (always low, max 1/4 frame)
Third Bar - RDP render time (always higher than bar 2)

The blue bars are always staggered. If the top starts on frame0 the second will start of frame1 and the top will restart on frame2 etc.
likewise, if the second bar starts on frame0 the top bar will start frame1.

hz = FPS
Frames = number(BNumber)
Whole frames to complete, same as marks on bar graph
Bracketed number refers to frames for graphics only with leading frame idle
eg: 2(3) is, 3 frames to complete but graphics alone was 2frames (30fps), leading frame was idle waiting for RSP.
Bracket number will be converted to actual number if that state excedes 1 frame (since its no longer able to complete within the lower number of frames)


utz xx% = RSP Utilisation, Ideally should be 100%
rsp xx% = RSP Stall, waiting on commands from CPU. Usually very low (3%)
tex xx% = TMEM - Usually low (5%) therefore must be Delay not size.

UTZ should be 100%, If the RSP has to wait on DMA transferes it is Stalled and the time (percentage per frame) is indicated as RSP or TMEM.

This explains why when a guard first appears the RSP count goes high then low again.
Same for textures. The more textures on-screen, the longer the delay waiting for DMA from RAM to TMEM.


Other Examples:

Mario
Mario uses a similar kind of speed bar (The cutting room floor)

where the audio bars are staggered accross the top 2 bars.
The third bar (the lowest and longest bar in screenshot (1 bar is missing from emu) ) is the frame marker and does not move.
Also of note is that TCRF have incorrectly called is the sound bar. it is not and instead shows the SP processing times for both Audio and Grapics as well as the DP render time.

nuDebTaskPerfBar1
Below is an Example from CCBL showing longer render time but less idle
Code:

        |frame -1     |frame 1      |frame 2      |frame 3
        ---------------------------------------------------------
(1) RSP |             |             |             |             |
(2) RSP |=============|========     |             |             |
(3) RDP |=============|=============|=====        |             |
(4) CMD |=============|=============|======       |             |
(5) PIPE|=============|=============|=======      |             |
(6) TMEM|==           |             |             |             |
         --------------------------------------------------------

(1) RSP's time processing audio task (black)
(2) RSP's time processing graphics task (yellow) (includes yield time)
(3) RDP's time drawing graphics (green)
(4) CMD counter value of RDP's internal counter
This is the process execution time. Unlike (3) it does not include the time waiting for commands from the RSP. When this bar is shorter than bar (3) it means that time is being spent waiting for commands from the RSP.
This counter is incremented once every clock cycle when the RDP has work to do. The RSP places RDP commands in a FIFO for execution. If this FIFO is not empty, the counter is incremented.
(5) RDP's PIPE counter value
This counter is incremented when the internal RDP pipeline is not stalled while waiting for memory accesses to occur.
(6) RDP's TMEM counter value
This value represents the time required for loading to texture memory. The performance is better if this value is small.



Trev
_________________
 
View user's profile Send private message Visit poster's website
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 Previous  1, 2
Page 2 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 ]