I completely support your choice for C++17! As seen in the previous link, support by the major compilers is already pretty good. Why sticking to C++14 while C++20 is already out (and already quite well supported).
And this the second time I hear about ImGui in the past weeks... Maybe I should try it ^^
Yeah, ImGui is a great library, I’ve had a lot of good experiences with it.
I honestly would choose C++20 instead, but the main thing I’m interested in is the new module system and NO one is implementing that yet... including CMake so it isn’t really an option.
EDIT: Okay that's a lie about no one implementing it yet, GCC 11 and some others have it working, but that doesn't change that CMake doesn't support it last time I checked. :P
Oh you're a bit mistaken, it's nowhere near done yet. I wouldn't consider it even at an alpha state yet, it's essentially unusable... my bad if I gave off a different impression, this series of articles is basically me putting out my thoughts as they actually happen--aside from the OpenGL specific ones which are a little more retrospective from my first few attempts.
To address your points:
It isn't actually documented yet, so if you looked through the code trying to find any comments, those are mostly comments for myself to remember in the future. I am planning on Doxygen though when I actually get around to doing documentation!
I'm not actually sure what you're referring to with this, if it has anything to do with the raw pointers I'm changing over to smart pointers today :) Other than that, a lot of the decisions so far have been at least partially due to having to work around the structure of OpenGL, which is unfortunately a C library. I'm gradually trying to make it more C++ but I am really interested in knowing what specifically you noticed. You're the first one other than me to touch it.
It's just the file I'm using to test things, it's not a real example (those will come soon once I get the main batcher fully set up). Putting it in the examples folder was just an easy to get it to build automatically with everything else.
That's for me, not really for the end user, but also see the response to your first point
I appreciate you trying it though! You're looking at what's basically a conceptual idea, hence why there's no actual documentation, no README, no anything really aside from my own testing code.
Oh sorry! There was a misunderstanding: I was talking about Dear ImGui!
But the maybe the misunderstanding will be useful for you: don't make tje same "mistakes" ;) Your comments sounds legitimate.
BTW, I have also taken a lot at your GitHub this morning (before writing my first comment). I have noticed that it is still work-in-progress. The code seems clean to me. You should maybe:
a clearer separation between your code and 3rd party library.
put all your code in the aurora namespace
add std:: in front of type like uint32_t
prefer functions starting with target_, like target_link_libraries() to link_libraries() in CMake.
Oh, okay! That makes way more sense, I was so confused, especially by your comment about "needing a backend". That explains a lot now that I know you were talking about ImGui.
Thank you for the tips though, I appreciate you looking. I try to do at least a little work on the project each day--some days significantly more than others--so expect it to be changing a lot!
Is there a particular part you're referring to when you say "put all your code in the aurora namespace"? The only thing I can think of off the top of my head that isn't in there is the Color class, and the oogl stuff is separate on purpose because I imagined it might actually be useful to other people as a separate thing, so I didn't want to couple it too closely with the rest of my code.
By "a clearer separation between your code and 3rd party library." are you referring to having everything all in the same include folder? I can definitely see a benefit to moving anything 3rd party into the "libs" folder with the two Git submodules.
Update: I moved all the non-Aurora stuff into the libs folder, and also made glm a git submodule because I didn't realize it was a CMake project until now.
I was also referring to the includes directory: at first glance, it was currently not obvious what is aurora (and may be modified by contributors) and what is not.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey!
I love
fmt, it's a great library!Unfortunately, there is no implementation for std::format() yet... See en.cppreference.com/w/cpp/compiler... But we can hope to have it soon :)
I completely support your choice for C++17! As seen in the previous link, support by the major compilers is already pretty good. Why sticking to C++14 while C++20 is already out (and already quite well supported).
And this the second time I hear about ImGui in the past weeks... Maybe I should try it ^^
Hi!
Yeah, ImGui is a great library, I’ve had a lot of good experiences with it.
I honestly would choose C++20 instead, but the main thing I’m interested in is the new module system and NO one is implementing that yet... including CMake so it isn’t really an option.
EDIT: Okay that's a lie about no one implementing it yet, GCC 11 and some others have it working, but that doesn't change that CMake doesn't support it last time I checked. :P
I have tried it today!
I took me a while to understand I need a backend and then to setup something working. But I got the demo running!
My first feeling is that the library has really a lot of amazing features but:
When you are used to framework with widget like Qt, the first steps are not easy, the paradigm is really different.
However, I am glad I have tried, I maybe useful for future projects. Thanks ;)
Oh you're a bit mistaken, it's nowhere near done yet. I wouldn't consider it even at an alpha state yet, it's essentially unusable... my bad if I gave off a different impression, this series of articles is basically me putting out my thoughts as they actually happen--aside from the OpenGL specific ones which are a little more retrospective from my first few attempts.
To address your points:
I appreciate you trying it though! You're looking at what's basically a conceptual idea, hence why there's no actual documentation, no README, no anything really aside from my own testing code.
Oh sorry! There was a misunderstanding: I was talking about Dear ImGui!
But the maybe the misunderstanding will be useful for you: don't make tje same "mistakes" ;) Your comments sounds legitimate.
BTW, I have also taken a lot at your GitHub this morning (before writing my first comment). I have noticed that it is still work-in-progress. The code seems clean to me. You should maybe:
auroranamespacestd::in front of type like uint32_ttarget_, liketarget_link_libraries()tolink_libraries()in CMake.I have started to watch your repository ;)
Oh, okay! That makes way more sense, I was so confused, especially by your comment about "needing a backend". That explains a lot now that I know you were talking about ImGui.
Thank you for the tips though, I appreciate you looking. I try to do at least a little work on the project each day--some days significantly more than others--so expect it to be changing a lot!
Is there a particular part you're referring to when you say "put all your code in the
auroranamespace"? The only thing I can think of off the top of my head that isn't in there is theColorclass, and theooglstuff is separate on purpose because I imagined it might actually be useful to other people as a separate thing, so I didn't want to couple it too closely with the rest of my code.By "a clearer separation between your code and 3rd party library." are you referring to having everything all in the same include folder? I can definitely see a benefit to moving anything 3rd party into the "libs" folder with the two Git submodules.
Update: I moved all the non-Aurora stuff into the libs folder, and also made glm a git submodule because I didn't realize it was a CMake project until now.
I was referring to
Colorindeed.I was also referring to the includes directory: at first glance, it was currently not obvious what is aurora (and may be modified by contributors) and what is not.