Hey, just a friendly notice that this video doesn't seem to be included in the playlist! Also thanks for all the videos. I've learned quite a good amount from just this series alone.
Hey everyone, timer##__LINE__ didn't work for me, so you can use the following instead: #define CONCAT(x, y) x ## y #define C(x, y) CONCAT(x, y) #define HZ_PROFILE_SCOPE(name) ::Hazel::InstrumentationTimer C(timer, __LINE__)(name)
Thank u soooooooooooo much for the series i am learning so much from ur videos , keep it up !!! i hope u teach us implementing 3D after u finish 2D. note : UR THE BEST !!!!!
Where's the instanced batch rendering tutorials? The OpenGL series ends before getting into instancing even though it's being promised for a long time. All I can find are deprecated stuff from the previous game engine series.
On macOS you have to convert thread id from hexadecimal to decimal. Apparently JSON doesn't like hexadecimals. EDIT: Or you can remove all characters that are not numbers from the string like I ended up doing.
I found the solution.. To anyone else stuck with same problem, use the following macro instead #define LEVEL2(x,y) x ## y #define LEVEL1(x,y) LEVEL2(x,y) #define HZ_PROFILE_SCOPE(name) LEVEL1(::Hazel::InstrumentationTimer timer, __LINE__) (name);
Trace has option to do code search where u click on the little search icon next to function name... have u had a look at how this can be linked to file/line to jump to source? that would be supa cool o.o, has any1 look in to it?
Great video as always! I know I'm a bit late to the party, but can someone explain to me why I get this error message, when I exit the program: "Stack cookie instrumentation code detected a stack-based buffer overrun." This seems to only happen when in the Debug Configuration.
So I've gone and tried out this method of profiling but ran into an issue almost immediately. My applications tend to reuse a lot of code and so most functionality has been placed into a dll library to which my applications link. I was wondering what sort of changes would be required to allow this instrumentor class to be compiled inside my dll and used both inside the dll and my applications without having multiple instances of the Instrumentor object.
all right, I have figured out that. Basicly, it's totally because the Instrumentation file is a pure head file, so you need to spilt to .cpp and add YOURS_API to the class declaration. So the Sandbox will use the same Instrumentation as dll do.
What about thread-safety? You might use the same ofstream from different threads so you might get unexpected results. As far as I know, none of the streams in c++ are thread-safe by default so you might need some sync here (or use thread_local variables, but this way you clearly cannot write to the same file).
If you build up the json by sending sending everything to a local stringstream first, and then send the stringstream to the output file stream in one go at the end of WriteProfile(), then there is no need for a mutex. A single call to operator
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
Hey, just a friendly notice that this video doesn't seem to be included in the playlist!
Also thanks for all the videos. I've learned quite a good amount from just this series alone.
Great videos just became a Patreon i'm building a engine in my spare time with Java and LWJGL3 and these videos have been very helpful. Keep it up.
Very nice! I also planned to do something like that if i had time for it
If you have seen the visual benchmarking video of the C++ series and are just interested in the implementation in Hazel, the video starts at 8:20
Hey everyone, timer##__LINE__ didn't work for me, so you can use the following instead:
#define CONCAT(x, y) x ## y
#define C(x, y) CONCAT(x, y)
#define HZ_PROFILE_SCOPE(name) ::Hazel::InstrumentationTimer C(timer, __LINE__)(name)
Thank u soooooooooooo much for the series i am learning so much from ur videos , keep it up !!!
i hope u teach us implementing 3D after u finish 2D.
note : UR THE BEST !!!!!
Where's the instanced batch rendering tutorials?
The OpenGL series ends before getting into instancing even though it's being promised for a long time.
All I can find are deprecated stuff from the previous game engine series.
@22:53 you logged startup twice instead of defining shutdown. The perils of copy paste.
Feel free to make a PR in the Github repository (otherwise I can do it if you prefer). Good catch though!
@@Puddlestomps I don't have a github account, you're welcome to do it I was just hoping Yan reads comments
On macOS you have to convert thread id from hexadecimal to decimal. Apparently JSON doesn't like hexadecimals.
EDIT:
Or you can remove all characters that are not numbers from the string like I ended up doing.
Thanks for the video, man!
It wasn't easy but I ported this profiling library to the D programming language
thanks!!
thank!
Nice one Cherno
nice. thanks for the content bro.
For some reason on the first "Renderer Draw" it is taking 2 full seconds. Does anybody know what could be causing this?
Seconding Dev Pratap. Can you you give us an ETA about when would this series completed ?
Also great thanks for your efforts Cherno. You are the best.
for me, the __LINE__ resulted in an error, so i had to switch to use some COMBINE macros
Can you explain how you fixed this issue? I am stuck with the same problem
I found the solution.. To anyone else stuck with same problem, use the following macro instead
#define LEVEL2(x,y) x ## y
#define LEVEL1(x,y) LEVEL2(x,y)
#define HZ_PROFILE_SCOPE(name) LEVEL1(::Hazel::InstrumentationTimer timer, __LINE__) (name);
Trace has option to do code search where u click on the little search icon next to function name... have u had a look at how this can be linked to file/line to jump to source? that would be supa cool o.o, has any1 look in to it?
Great video as always! I know I'm a bit late to the party, but can someone explain to me why I get this error message, when I exit the program: "Stack cookie instrumentation code detected a stack-based buffer overrun."
This seems to only happen when in the Debug Configuration.
So I've gone and tried out this method of profiling but ran into an issue almost immediately. My applications tend to reuse a lot of code and so most functionality has been placed into a dll library to which my applications link. I was wondering what sort of changes would be required to allow this instrumentor class to be compiled inside my dll and used both inside the dll and my applications without having multiple instances of the Instrumentor object.
Bro, did u find the solution? I encounter the same question, which has waste my whole afternoon.
all right, I have figured out that. Basicly, it's totally because the Instrumentation file is a pure head file, so you need to spilt to .cpp and add YOURS_API to the class declaration. So the Sandbox will use the same Instrumentation as dll do.
But i really dont be clear about where the dll couldn't use the Instrumentation at first. Maybe it's because it is a pure head file.
👌
As a police officer I approve of this video
What about thread-safety? You might use the same ofstream from different threads so you might get unexpected results. As far as I know, none of the streams in c++ are thread-safe by default so you might need some sync here (or use thread_local variables, but this way you clearly cannot write to the same file).
Add a mutex to the WriteProfile function, and that's it 👍
If you build up the json by sending sending everything to a local stringstream first, and then send the stringstream to the output file stream in one go at the end of WriteProfile(), then there is no need for a mutex. A single call to operator