• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By wobbegong_
      I am taking an absolute beginner's game development course and we have just finished game jams in small groups. Our current assignment is to get feedback from people working in any aspect of game development. I would very much appreciate any feedback! The game is up on itchi.io (sound warning) https://wobbegong.itch.io/zombie-shooter It's essentially a very basic PvE.
      I also have some things I'm wondering about, but you don't necessarily have to answer these. 
      1. Do you have any tips on working with physics? My group wrestled a bit with Rigidbody physics not totally working the way we wanted to -- jumping ended up kind of floaty and inclines seem to mess up movement. Alternatively... how can I build terrains with depth that won't result in wonky physics?
      2. How can I keep up the level of challenge in an interesting way as the player progresses through the waves?
      3. What are some of your personal guidelines for creating title screens?
      Thank you very much in advance!
    • By ethancodes
      I'm having a weird issue with detecting a collision. I've tried everything I could find online but nothing seems to work. I have a brick object. It has a 2D Collider attached and I have also attached a 2D Rigidbody on it. I also have an EndScreen 2D Collider. The EndScreen 2D collider is tagged with "EndScreen". I am trying to detect when a brick collides with the end screen collider and simply print "game over" in the console. 
      This is my current code for this part of the program, it is attached to the bricks:
      void OnCollisionEnter (Collision2D collision) { if (collision.gameObject.tag == "EndScreen") { Debug.Log("Game over"); } } Several things have happened depending on the set up. If I have the rigidbody 2D set as static, my ball object can still collide with the bricks, but I get no Log message. If I set it to Kinematic or Dynamic, I get absolutely no interaction between the ball and the bricks, and nothing when the bricks pass through the collider. I have tried to set the collider to a trigger and use OnTriggerEnter2D, no change. I have tried to put the rigidbody on the EndScreen object and tried to set it's body type to all 3 settings, no change. The only thing I can think of that I have not done is put the script on the EndScreen object and switch the tag to the bricks. The reason I have not done this is because I will have several types of bricks, some of which will have different tags. 
       
      Please tell me somebody can see what I'm doing wrong here, because I'm losing my mind over something I feel should be ridiculously simple. Thanks.
    • By Sandman Academy
      Downloadable at:
      https://virva.itch.io/sandman-academy
      https://gamejolt.com/games/sandmanacademy/329088
      https://www.indiexpo.net/en/games/sandman-academy
      https://www.gamefront.com/@sandmanacademy
      http://www.indiedb.com/games/sandman-academy
    • By Sandman Academy
      Downloadable at:
      https://virva.itch.io/sandman-academy
      https://gamejolt.com/games/sandmanacademy/329088
      https://www.indiexpo.net/en/games/sandman-academy
      https://www.gamefront.com/@sandmanacademy
      http://www.indiedb.com/games/sandman-academy
    • By Sandman Academy
      Downloadable at:
      https://virva.itch.io/sandman-academy
      https://gamejolt.com/games/sandmanacademy/329088
      https://www.indiexpo.net/en/games/sandman-academy
      https://www.gamefront.com/@sandmanacademy
      http://www.indiedb.com/games/sandman-academy
  • Advertisement
  • Advertisement
Sign in to follow this  

Unity In-engine profiler: how to automatically mark all/most functions for profiling?

This topic is 402 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, after almost finishing the basic functionality of my 3D Game Engine, I am now starting to expand it. The first thing that I want to work on is to improve the in-engine profiler. Currently, I have quite a bit of functionality for manually marking beginning and end parts of code that should be profiled, which has been of great help.

However, I would like to have a way through which all the functions in my code (or at least most of them) would be automatically marked for compiling. Engines like Unity and Unreal seem to achieve that somehow: you can choose to see very detailed profilling of most inner functions, even if source code of the engines does not appear to include a time-stamp recorder at the beginning and end of all the functions.

 

I am trying to learn how to achieve the same, but it has been very hard to find references on such type of profiling. Could any of you give me some insights on how such a thing could be achieved, which techniques could be involved, etc? I would like to state from the start that I am very aware of external good profilers that could do this for my engine - I am specifically trying to learn how to implement such a thing in-engine.

Share this post


Link to post
Share on other sites
Advertisement

Personally, I would not try to do this with an intrusive profiler - there's a decent overhead to every profiling block, so adding them at a fine-grained level will destroy the data that you're trying to collect.
Perhaps those engines use a sampling profiler instead? Unreal is not closed source, so you could check :wink: These profilers periodically interrupt a thread and record the call-stack, which at a later point in time can be converted into a stack of function names using the application's debug database (e.g. PDB file on MSVC).

Share this post


Link to post
Share on other sites

UE4 has quite explicit macros in the source code that mark out the areas that get profiled. I've not seen any magic that goes further than that.

Share this post


Link to post
Share on other sites

Could any of you give me some insights on how such a thing could be achieved, which techniques could be involved, etc?

The two sets of keywords for search engines are "instrumenting profiler" and "sampling profiler".  It looks like you are trying to build your own instrumenting code.

With an instrumenting profiler, SOMETHING inserts code into your program to record the metrics.  Whatever method is chosen, the code can be added manually to the source code as stack-based profiling objects, or 1980's style ugly macros, or added through compiler flags to the function prolog/epilog processing, or if the language supports reflection can be added at run time, or by linking against a profiler library that automatically adds function prolog/epilog calls.

In the case of Unity and other systems that do some profiling for you, it is a mix of systems. Unity has code that enables instrumented profiling within certain blocks, it gets activated and deactivated so that you see all your functions using C# reflection and only Unity's interesting tidbits that are explicitly marked.

 

For code I write yourself, I personally prefer scope-based objects in the functions you care about. Every time you enter a function, you create the object right as you enter:

void foo(...) {
  Profiler::Marker marker(__PRETTY_FUNCTION__); // creates log entry when created and another when destroyed

  /* Remaining code here */
?}

You can add some optional parameters so it includes specific flags for whatever purposes you'd like, perhaps a construction signature like:

marker( const char* function_name, const char* sub_name = nullptr, uint64 flags = 0);

Share this post


Link to post
Share on other sites

I have created a in-game profiler as well. Its still not finished but i already get a good overview which part of the code is slow.

Its fully based on macros, when i want to include a function i simple just stick one word after the function body - thats it.

When i want to time sub-parts of my code, i put a BEGIN_BLOCK("some name") and END_BLOCK().

 

Internally it uses just two profiling event array´s, one to write to and one to read from + atomic index to store the event array and the current event index.

 

The overhead for recording each events is very small:

inline void RecordProfilerEvent(ProfilerType type, char* guid) {
    Assert(externProfilerMemory);
    ProfilerTable *profilerTable = (ProfilerTable *)externProfilerMemory->tableStorage;
    Assert(profilerTable);
    u64 arrayIndex_EventIndex = AtomicAddU64(&profilerTable->eventArrayIndex_EventIndex, 1);
    u32 eventIndex = arrayIndex_EventIndex & 0xFFFFFFFF;
    Assert(eventIndex < ArrayCount(profilerTable->events[0]));
    ProfilerEvent *ev = profilerTable->events[arrayIndex_EventIndex >> 32] + eventIndex;
    ev->clock = __rdtsc();
    ev->type = (u8)type;
    ev->coreIndex = 0; // @TODO: Retrieve core index from current thread or remove this field entirely
    ev->threadID = (u16)GetThreadID();
    ev->guid = guid;
}

The GUID is created like this:

#define ABCD_(a, b, c, d) a "|" #b "|" #c "|" d
#define ABCD(a, b, c, d) ABCD_(a, b, c, d)
#define PROFILER_ID(name) ABCD(__FILE__, __LINE__, __COUNTER__, name)

The only thing which is slow is to process the events, so that you can reasonably visual it:

- Snapshoting the events, so you get at least two frames worth of data.

- Each snapshot contains a single frame boundary event, so you can just look at the events between frame A and B

- Traversing the events, calculating the delta cycles and building up a tree or list

- Render the data in a list/graph whatever you want.

 

This wont affect the game code at all and i can clearly see which codes takes how much time.

Of course the entire frametime will increase with this collation process, but this is fine because all timings are just cpu cycles.

Edited by Finalspace

Share this post


Link to post
Share on other sites

Just a hint: instead of using atomic trickery to get safe indices into a shared array, consider using thread local storage and collating the results at the end. It can be faster in most circumstances and it's arguably cleaner too. (Not so good for short-lived threads, though.)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement