Telemetry's API allows you to pause and resume capture dynamically, allowing you to pick and choose when data is acquired*. This is particularly helpful if you're running sessions for a long period of time and don't want to capture data continuously.
When reviewing your data you'll want to spot paused areas of the capture. With Telemetry 1.x this was handled automatically since pauses were latched to the end of frame boundaries, so 'empty' frames were drawn differently. However since Telemetry 2 supports multiple frame sets this can get complex, so instead of rendering frames as paused or not, it makes more sense to mark a region of time as paused.
A simple mechanism for this is to use the tmSetTimelineSectionName API. The name 'paused' is recognized by Telemetry and it will use a bright red background for those timeline sections.
tmSetTimelineSectionName( cx, "paused" );
tmPause( cx, 1 );
...
tmPause( cx, 0 );
tmSetTimelineSectionName( cx, current_state_name );
This gives you capture somewhat like this:
* Note that a more flexible method of managing event capture in real time is available, but requires a bit more application setup.
Thursday, August 29, 2013
Tuesday, August 27, 2013
Telemetry Power Tips #1: Managing Real-time Event Volume
One of the most common questions that comes up from Telemetry users is "What if I don't want all this data all the time?" or, put another way, "What if I only want to collect some types of data, some of the time?"
While you can use the tmPause API to turn off events, it's a heavyweight solution since it shuts down almost all data collection. A finer grain solution that provides precise control of detail or specific coverage is often desired.
Simple Telemetry integrations have a single global HTELEMETRY context which is passed into Telemetry markup, and if NULL then the function is not called. (Technically they're passed into Telemetry macros which dispatch after the check, saving a little performance in the NULL case).
We can leverage this property by keeping a set of HTELEMETRY variables that alternate between NULL and the real Telemetry context.
For example, let's say you have separate markup for your rendering, game logic, physics, and audio, and you want to enable/disable profiling for each of those categories independently.
HTELEMETRY telemetry_context;
enum { TCAT_AUDIO, TCAT_RENDERING, TCAT_PHYSICS, TCAT_GAME, NUM_TCATS };
HTELEMETRY telemetry_categories[ NUM_TCATS ];
Your markup can then use the appropriate category:
void playSound( char const *kpSoundName )
{
tmZone( telemetry_categories[ TCAT_AUDIO ], TMZF_NONE, "playSound %s", kpSoundName );
// ... play audio
}
In the above code, if telemetry_categories[ TCAT_AUDIO ] is NULL then the zone is never created and sent.
Now you just hook up some method to control the categories (console command, hot keys, controller input, etc.) which sets those array entries appropriately:
void enableTelemetryCategory( int which, bool enable )
{
telemetry_categories[ which ] = enable ? telemetry_context : NULL;
}
You can obviously extend this to other things like markup 'levels', with the default being very light markup that has low overhead and going all the way up to a dense markup setting that generates tens of thousands of events per frame.
Just remember to avoid dangling (and invalid) references by clearing your arrays before you shut everything down!
While you can use the tmPause API to turn off events, it's a heavyweight solution since it shuts down almost all data collection. A finer grain solution that provides precise control of detail or specific coverage is often desired.
Simple Telemetry integrations have a single global HTELEMETRY context which is passed into Telemetry markup, and if NULL then the function is not called. (Technically they're passed into Telemetry macros which dispatch after the check, saving a little performance in the NULL case).
We can leverage this property by keeping a set of HTELEMETRY variables that alternate between NULL and the real Telemetry context.
For example, let's say you have separate markup for your rendering, game logic, physics, and audio, and you want to enable/disable profiling for each of those categories independently.
HTELEMETRY telemetry_context;
enum { TCAT_AUDIO, TCAT_RENDERING, TCAT_PHYSICS, TCAT_GAME, NUM_TCATS };
HTELEMETRY telemetry_categories[ NUM_TCATS ];
Your markup can then use the appropriate category:
void playSound( char const *kpSoundName )
{
tmZone( telemetry_categories[ TCAT_AUDIO ], TMZF_NONE, "playSound %s", kpSoundName );
// ... play audio
}
In the above code, if telemetry_categories[ TCAT_AUDIO ] is NULL then the zone is never created and sent.
Now you just hook up some method to control the categories (console command, hot keys, controller input, etc.) which sets those array entries appropriately:
void enableTelemetryCategory( int which, bool enable )
{
telemetry_categories[ which ] = enable ? telemetry_context : NULL;
}
You can obviously extend this to other things like markup 'levels', with the default being very light markup that has low overhead and going all the way up to a dense markup setting that generates tens of thousands of events per frame.
Just remember to avoid dangling (and invalid) references by clearing your arrays before you shut everything down!
Monday, August 26, 2013
RAD Telemetry 2.0b released!
Hot on the heels of the 2.0a release we now have 2.0b out the door. Lots of little bug fixes and official platform support for Android and QNX are the highlights.
- ENHANCEMENT: updated Android support, including support for TMCT_FILE
- ENHANCEMENT: support for QNX 6.5 on ARM
- ENHANCEMENT: support for Linux on ARM
- BUGFIX: endianess bug regression from 2.0a
- BUGFIX: zone view tooltips for out of range frametime plots now fixed
- BUGFIX: zooming in beyond 100 clock width would result in white screen
- CHANGE: visualizer uses term 'clocks' instead of 'cycles'
- BUGFIX: zero-length zones are handled properly now
- BUGFIX: events that were too closely spaced were being discarded
- CHANGE: documentation updates
Tuesday, August 20, 2013
Telemetry now available for QNX!
Telemetry has become a vital tool for game developers looking to squeeze as much performance out of their code as possible, especially when running on game consoles such as 360, PS3, and WiiU. Given that those platforms are just special cases of embedded systems, it's not surprising that we've had a lot of inquiries from non-gaming embedded software developers.
While Telemetry runs great on some operating systems that happen to exist in the embedded space, such as Android or Linux/ARM, for us to become really relevant we needed to support dedicated embedded operating systems. With that in mind we've added support for one of the most popular embedded platforms out there, the QNX operating system. We now have support for QNX 6.5 on x86 and ARM processors!
If you're interested in trying it out, email us at sales3@radgametools.com!
While Telemetry runs great on some operating systems that happen to exist in the embedded space, such as Android or Linux/ARM, for us to become really relevant we needed to support dedicated embedded operating systems. With that in mind we've added support for one of the most popular embedded platforms out there, the QNX operating system. We now have support for QNX 6.5 on x86 and ARM processors!
If you're interested in trying it out, email us at sales3@radgametools.com!
Thursday, August 15, 2013
Telemetry now supports Android!
Just a quick mention that Telemetry now supports Android OS, so if you're interested in performance visualization on Android, let us know!
Tuesday, August 13, 2013
RAD Telemetry 2.0a/1.1t shipped!
Man, it's so easy to just keep plugging away at something and thinking "we'll just release next week". We've been doing that with Telemetry 2 for months now because there's always one more platform or feature to add, but we finally locked things down and have made our release official as of today!
So as of now Telemetry 2.0a is available, and so is the incremental run-time update to 1.1t (the Telemetry run-time is 1.1t for both Telemetry 2 and Telemetry 1.x, which is kind of confusing right now but that's the nature of having dual version support).
Telemetry 1.1t will (hopefully) be the last release of 1.1 and going forward all releases will be 2.x+ versions.
If you're looking to evaluate again or upgrade, please contact our sales guys at sales3@radgametools.com so we can hook you up!
So as of now Telemetry 2.0a is available, and so is the incremental run-time update to 1.1t (the Telemetry run-time is 1.1t for both Telemetry 2 and Telemetry 1.x, which is kind of confusing right now but that's the nature of having dual version support).
Telemetry 1.1t will (hopefully) be the last release of 1.1 and going forward all releases will be 2.x+ versions.
If you're looking to evaluate again or upgrade, please contact our sales guys at sales3@radgametools.com so we can hook you up!
Subscribe to:
Posts (Atom)