still waiting for cherno to implement women

@zdspider6778

Жыл бұрын

Can anyone really define what a woman is?

@Waffle4569

Жыл бұрын

@@zdspider6778 Like complex problems like Raytracing, we can approximate at best 🤣

@Taivuttaja

Жыл бұрын

[[maybe_unused]] constexpr Creature * g_Woman = nullptr;

@scififan698

Жыл бұрын

He did, but it didn't turn out as well as we all wanted, sometimes, so consider it 'under construction' and not ready for release yet ;-)

@xenhysics5926

Жыл бұрын

@@zdspider6778 An adult female human being?

Love the fact that you really put thought on the cost of the OOP approach, sometimes functions are the way to go!

I like your explanation style. The internet is full of random code examples. Getting the reasoning from someone experienced in exactly this kind of work, is great.

I feel like something being overlooked here is the option to just not use OOP at all for a lot of this. The debate over "should this object be static or not static?" goes away when there's no object to think about! I find a good rule of thumb is: if you find yourself creating a class called "ThingDoer", always ask yourself if your problem would be more cleanly represented by just having a function called "DoThing".

@proper_noun436

Жыл бұрын

cries in java

@askeladden450

Жыл бұрын

i would even say you should default to functions. you'll be surprised how rarely you actually need OOP. Your code will get way more concise and readable. But maintainability might get a litter harder.

@nox4000

Жыл бұрын

As C++ programmer with C and assembly background, this is what I do. Namespaces with functions are more often than not enough. Constexpr makes this approach even more powerful.

@virinom

Жыл бұрын

Coding without OOP approach should be illegal.

@proper_noun436

Жыл бұрын

@@nox4000 genuinely curious how you got into a c++ job. my area is saturated with java and c#

I love how he spends tons of time explaining what objects are, but then just starts using smart pointers like nothing 😂

Thank you for these videos, I really appreciate the thorough thought processes! Since I am self-taught, I tend to miss a lot of the architectural fundamentals

Great video, love the content, keep it up!

Love your videos soo much

"Let's continue on with doing whatever it is that we're doing, and I'm saying that because I actually don't know" - Also me in work meetings every morning.

I would argue that there should be a separation of concerns with regard to some things. If the renderer is what you use to display everything on screen then you should have a viewport before it that handles things like split screen functionality and obviously since multiple monitors exist you should have a renderer for each one. My wording might be confusing here though, because thesauruses exist and one person might say render, another display, and still others might say print or view.

Great Series! In my opinion, I think it would be better to not over complicate things. If the idea is just to create the game, then we wouldn't need to make sure that everything will work across multiple instances, etc. I assume the point is to make a game, not make a game engine, and a game on top of it. In which case, we can say we know exactly what the classes will be used for, and therefore can make then static, etc. Have a great day!

This series is the best

I've been wondering for a while now, which tool do you use for drawing on the screen? Excellent series BTW.

remember that accessing static member has some overhead (since c++11 I think) because it will lazy-check/initialize in a thread-safe manner (with a lock). Even if it is already initialized it will if it is or not (but no lock involved in this case because it used double-checking locking in most implementations).

This episode shows how convenient and useful DI frameworks such as Spring are

That was interesting, thanks!

0:18 everyone's first game!? 😂😂OMG!

Great to see maxmoefoe has really turned things around. Keep up the good work.

I use a static namespace to hold my game data; namely, structs of arrays that work like database tables. All screens/scenes/layers or whatever can always get to the data they need to render, or run other systems. Makes it easier, and cleaner. Too much OOP can become a problem later on.

"to static, or not to static? That is the question."

I like the high speed intro 😄

the explanations are why i'm here

Are you planning on doing a series about vulkan?

What does the "m_" in variables indicate? I see this a lot in games & game engines. Although I think UE4 uses a different letter. I've used this naming scheme myself for variables I use or access from other script files.

@DetectivePoofPoof

Жыл бұрын

Its a naming convention usually used to denote private variables in a class as "member" variables ( the m stands for "member" I think ). this way you know just by the name of the thing if its only supposed to be used inside the class itself. I prefer just having a "_" in front though, it gets the same idea across, its less typing and "m_" just looks incredibly ugly to me personally. It can be handy to know at a glance when you have functions in a class and some variables are the parameters of the function and some are from the class so this way you dont get confused about the scope of things.

@miko007

Жыл бұрын

they use it for member variables, because most cpp devs for some reason refrain from using "this->" at all cost.

@AlienFreak69

Жыл бұрын

@@DetectivePoofPoof Good to know I've been using it wrong lol. Thankfully they're all my own personal projects so nobody will be bothered by it besides me.

@NewPlayer4U

Жыл бұрын

I don't know how it works in gamedev, but those prefixes like 'm_' are treated as 'bad smell' of code. So generally I would suggest not to use them. You can find this information in Stephan Roth book which is around of the C++17 Clean Code topic.

@miko007

Жыл бұрын

@@DetectivePoofPoof i strictly use "this->" in all my codebases. cpp already is uncomfortably verbose, no need to abstract those few characters out. not signifying members at all is very bad in my experience.

very nice!

What about automated testing? Is it considered a good practise in video game development?

@voxelfusion9894

Жыл бұрын

You can test functions and stuff, but testing the game systems in action is significantly harder. There was some paper about using AI to randomly explore a region, to detect if a player can get out of bounds, but that's about it.

@JasonGrace69

Жыл бұрын

Yes, automated tests are always a best practice. Your game logic? Probably doesn't need testing. Navigating a UI automatically, and pressing random buttons to make sure everything pops up correctly, menus behave correctly, etc? Absolutely. Functions used for physics/collision/other important calculations? Definitely. On small projects, it's useful, and a good habit to pick up, but not "necessary". When making code for a large team or a large project, usually you will want to make sure that your code doesn't break anything (even if you think it doesn't, it probably will 2 months down the line and you'll have no idea). In terms of automated tests for gameplay logic itself, the most beneficial would be tests for any sort of pathfinding or other similarly/more complicated algorithms. Even a few automated tests can save you tons of work down the line. If you create your project with the knowledge that you will want automated tests for debugging, it helps a great amount. They'll be akin to a first-chance exception to any unexpected behavior. You can be as simple with you want by writing your own code or download some testing libraries to make it more managed. Even something as simple as: #ifdef DEBUG { run tests, print any errors } #endif would help you out on a large project immensely. tldr: yes, absolutely. less so for game logic, more so for (in order of importance): behind the scenes things used in//for important calculations/algorithms, and then any sort of UI which the player can interact with.

Just curious, if you weren't talking us through this, how long do you think this C++ adaptation would take?

@LetsDark

Жыл бұрын

Less then a day

i'd argue that even the gnarliest anti-patterns have valid use cases. really depends on the context and what you're trying to achieve. but as you said, singletons and global static functions can lead to all sorts of broken windows and code smells down the road. even worse when they have a deep dependency tree outside their immediate scope. good luck refactoring that shit in a large project without breaking anything. encapsulation, dependency injection, loosely coupled abstractions. establish a solid design from day one and posterity will (hopefully) follow your example.

Statics are just fancy globals, including singletons. I mean storage duration only, not linkage. Generally bad practice, but there are some good use cases IMO. Btw it's great how you avoided complexity by keeping concerns separate and dependencies minimal.

can you do a whole video like you did the intro? thanks in advance

@zdspider6778

Жыл бұрын

Just play it at 1.75x speed. 🤨

8:13 most interesting at this moment that it has function loadSheets, it just is not static.

plz continue the ray tracing series also

@TheCherno Can you also go through Iostream class implementation sometimes. It's very interesting to create your own stream class which will render output on console and may be write as well.

So if you set a smart pointer to static, you have to manually delete it with reset() otherwise it cleans itself up, is that right?

@TheCherno

Жыл бұрын

If you want it to be freed at a specific time then yes, otherwise it will be cleaned up after your main function ends during static shutdown.

Yes! I am not interested in game dev, but I am interested in C++. So those smaller videos are awesome

Still waiting for Cherno to fix my life

i am interested in this..but does my pc can handle this library? what are minimum specs?

@itsBlendish

Жыл бұрын

Yes, it most probably does. If you can run visual studio, then you can run this (even if not at 1000 fps). If you don't know if you can run Visual Studio, search that up on the internet.

@user-sl6gn1ss8p

Жыл бұрын

I think walnut requires vulkan? So maybe if your gpu is from before the 2010s it wont. It should be very quick to test that though, and the rest should be no problem, as @Blendish mentioned

@itsBlendish

Жыл бұрын

Report the spam comment guys

To me, honestly, the singleton pattern is perfect for cases like this. It'll allow me to _un-static_ the class whenever I wish. Another idea would be to make this class un-instantiable, and create a static field in another class that holds an instance of this class. How? Java has 'package'-level visibility for constructors. There has to be a C++ equivalent!

Cherno: *Explaining why his game engine might not want static objects. Me: *Trying to determine if the guitar in the background is full size.

isn't that the singleton principle that you describe at the first half?

Cherno needs a funny unexpected intro like the one from Hikaru Nakamura's channel

I NEVER got thought how to do programming, but part of my job is programming astronomically expensive software

Who can guess how many times de did that intro😂😂

Hey. Is there anybody that has watched this C++ series from the start? Would you recommend it for a complete beginner?

@itsBlendish

Жыл бұрын

this series? like the whole 4 episodes of this series? The series is still just getting started, so its hard to recommend it (we'll see how it goes.) Cherno's definition of beginner is also not very much a beginner. If you know C++ then this series is great, if you are just getting into C++, probably not as much.

@headred76

Жыл бұрын

@@itsBlendish yes realised after my post that this wasn't the one I thought. I was referring to a series Cherno posted a few years ago.

@Mobin92

Жыл бұрын

Not really, to be honest. I know how to code and I feel kinda lost because he talks too much... Also it weirdly switches between basic things, and then suddenly complex things.

@ItIsYouAreNotYour

Жыл бұрын

@@Mobin92 What's complex? It's all pretty basic. His design choices are the only thing complex, imo.

I avoid static members and singleton patterns entirely, using static members in much larger code bases can make the solution extremely difficult to navigate as it results in spaghetti code. It's been one of my biggest gripes in larger commercial and enterprise applications. For most use cases, enforcing local instantiation and dependency injection is always a better choice in the long term.

@KonradGM

Жыл бұрын

Curious how would that be? From strictly game dev view assuming static / Singleton is used for single manager of sorts, that is used only to maintain a data that needs to be saved on the device, how would you say a singleton can cause the previously mentioned navigation nightmares in large codebase?

@jamesmussett

Жыл бұрын

​@@KonradGM It really depends on how the code base for your game is structured. If you have 10+ classes that are referencing your singleton manager then you create a very tight couple between all of your classes, this can make it very difficult to change if you suddenly decide to redo your architecture. On the other hand, if each class is given the dependencies they need instead referencing the singleton manager directly, then it makes it much easier to make those larger architectural changes. You could argue that a simple project like cherno's java game rewrite wouldn't have those issues, and it won't. But it encourages bad practises that can lead to making these types of mistakes later down the line on larger projects.

@Mobin92

Жыл бұрын

Wouldn't a proper dependency injection system allow you to automatically create singletons when you need them?

@jamesmussett

Жыл бұрын

@@Mobin92 absolutely, and that’s definitely an accepted approach! However, I don’t like associating the singleton lifetime of a DI object to the singleton design pattern (which usually uses static members), completely different concepts.

What's this VS theme, please?

@vaguelobster356

Жыл бұрын

he customized it himself using gruv as a base for the colors

Too static to be the first here

@oamioxmocliox8082

Жыл бұрын

;))

👍

While I find myself kind of agreeing with the comment shown, every video does have some sneaky tidbits in there that make me go hmmm. Like weak and shared pointers, my programming in C++ is very basic so I never got past raw pointers. Thanks for sharing and giving me something to google ;-)

Please Unreal engine COURS :D

Dont listen to that guy, when you explain things in depth its awesome and i learn so much, that guy who commented not to is probably just trying to copy your code to make his first game

Seems like there's some dissonance between C static and C++ static. Polar opposites, eh?

Haha ❤

Don't listen to Nik Kiselev. I want to see all the steps in creating the game, especially the "thinking part". I mean, if you work as a programmer for like 8 hours, you would probably write code for like 4 hours. And in the other 4 hours you would think about what you should write

thatsaveryfastandshortintrowhichwasveryeasytofollowandunderstandwhatyousaid XD

I don't get it... Why not use a raw pointer? And set to nullptr in the destructor. Obtaining a shared_ptr from a weak_ptr... is like... why? 🤨 I didn't even know you could do that. weak_ptr is usually used when you don't want to increment the internal counter of a shared_ptr and you just want to "peek" at the data.

@ChrisCarlos64

Жыл бұрын

It is up to you and your design to consider but weak pointer doesn't hold ownership, so it means it also won't hold a reference and prevent deletion. One example and use I like it for is the observer pattern. Imagine in one scenario you have a list of observers but don't know who is still observing and who has gone away. Instead of having a strong ownership between observer and subject, you could perform the lock when your ready to notify the observers and if that lock succeeds, you can notify them, if it fails, you could remove them from the list. If the holder of observers held onto them with shared pointers, then those objects could never be deleted properly because you'll always hold onto them unless the subject dies out. That maybe won't be a problem in your design but I think it's a flexible way of managing lifetime of ownership without having to subscribe and unsubscribe to the subject. It allows the subject itself to smartly manage without any additional calls from the observer after setting it up. Again this is dependent on what you want out of your system. If anything, I find it quite useful in cases where I want to possibly use something but there is a chance I never may, and I want or expect the thing to die outside my lifetime. If it does, it shouldn't break my system and I can go on without it.

@TheCherno

Жыл бұрын

It kinda sounds like you've never used a weak_ptr before... considering the only way to use it is to obtain a shared_ptr from it, so what are you talking about

"to static, or not to static?" context plz!

No code no like :D

I like it more verbose.

i will insist on avoiding global state at all cost. 😂

No way it's sex code

Your variable names are so long that they don't even need to be an array...... xDDDD Programmer humor...

Just my two cents, but for this one verbose is the way to go in my book. This is a secondary channel and also straight-forward tutorials are plenty already, besides open source projects of all sizes and etc. I also think there would be relatively little value in a straight-forward porting of the old project, while taking it as an opportunity to discuss design choices and architecture is pretty nice. Maybe some people expected a "just get a simple game done as simply as possible" series, which might be nice too, but I think for this one the discussion has been nice so far.

Pro tip. Always watch Cherno videos I’m 1.75 speed

@ChrisCarlos64

Жыл бұрын

I'm usually around 1.5x myself lol but once in a while do the 1.75

Lol Lil' Cherno the womanizer and all his lil' minions

I am not too fond of this series to be honest. I really appreciate the content you put out and watch almost all of it. I'm even a Patreon to support your work. However I feel like this is the least interesting series of yours. It's of course better than none, but I feel like with your limited time more viewers would prefer more regular dev logs or episodes in the raytracing series. I of course could be totally wrong, so sorry in advance if I am. I'm trying to provide my opinion here, this is not meant to sound rude. Thanks for all the content you are providing for free

@itsBlendish

Жыл бұрын

I personally disagree. Dev logs don't feel like they can actually apply to me, unless i am also trying to create a crazy game engine like the Cherno. And the ray tracing series is a rather obscure thing, and unless i want to implement ray tracing in my games, i also wont need that. While with this series, it covers every aspect of making a game from scratch. And (being targeted towards beginners) is a little easier to consume. This series actually feels like it will change the way i program my games.

@user-sl6gn1ss8p

Жыл бұрын

@@itsBlendish yeah, I agree. I think maybe more explicitly setting a focus for the series would help manage expectations?

UwU

;)

Cherno, when you spoke about static object, which exists forever, in fact, you was wrong. It won't exist forever, only from first instantiation/access to the object till the end of application life. The heap isn't something system-wide, it belongs to the application process and after application finalization this memory will be freed by OS kernel. That's definitely not 'forever'. Also, regarding threads, how do you estimate the number of threads you will use? Since all the threads share same CPU time provided to the process, it's obvious that number of threads should have upper limit, otherwise most of your threads would just wait their turn.

@TheCherno

Жыл бұрын

Obviously by "forever" I meant for the lifetime of the application, not till the end of time! Not sure what you mean by the number of threads question, but you can always query the current hardware at runtime to see how many cores/threads are available and utilize a subset of those as necessary.

@malckhazarsteamcat9817

Жыл бұрын

@@TheCherno Sorry for big comment, but I guess that it's better to fully explain my thought - that will save the time for both of us. Obviously, 1 CPU core can execute only 1 thread at the time. The simple assumption here is that if you have multicore CPU you will execute several threads at the same time... but this is wrong. The truth is that you are not guaranteed that your CPU will provide several cores to the same process - it depends on what is going on system-wide and cores may be busy with other processes. Now, imagine that you have ideal situation that you've been provided several cores to your task with several threads. Since in multitask OSes CPU provides only some limited timeframe to a single task, this timeframe will be split between the threads in your process. This is high bound for the time. There is another limit for the time - the minimal time for CPU operation is 1 tick, so it's impossible to provide time for the task less than 1 CPU tick. This is lower boundary for time. Third boundary is that switching between threads requires switching the contexts, which is heavy operation with relatively constant execution time. This leads to an assumption that there is an number of threads optimal to performance. As I recall, there was a math formula for this point. And, in general, that formula is true. But in cases where you trying to reach the best performance with very small timescale (around microseconds timescale), this optimal point may deviate to a lower number of threads since the timescale units becomes close to context switch time. And here is my question - how do you estimate this optimal number of threads for performance-critical projects (like Hazel, for example)?

Please, can you either tune or add a high-pass filter to your signal chain, or add a better pop filter further away from your mic? Either you’re hitting your desk or the mic, or your plosives are being picked up - not sure. However, it’s frequent and a tad distracting, as it’s like there’s someone thumping on the ceiling every few seconds.

@meowsqueak

Жыл бұрын

OMG it just gets worse and worse. Sorry, I can’t listen to this. Your channel has the weirdest audio problems…

@zdspider6778

Жыл бұрын

@@meowsqueak I didn't notice anything.

@vaguelobster356

Жыл бұрын

@@meowsqueak i am pretty sure it's your setup... i haven't noticed any issues since one of his old game-engine-series episode (EDIT: i originally wrote episodes, that was a typo... sorry) where there really were problems with the audio, and he knew that but tried to fix it... just check your setup!

@user-sl6gn1ss8p

Жыл бұрын

didn't notice it either (using very simple headphones)

@meowsqueak

Жыл бұрын

​@@user-sl6gn1ss8p I have pretty decent in-ear phones, and it's very noticeable, but I'd suggest that it might be too low frequency to pick up on simple headphones or small speakers. It's definitely there, though.

It's not just that it is verbose, it's that you are waffling and sort of going a bit too abstract about concepts. Like it's probably really beneficial to a lot of people but instead of trying to explain the entire pros and cons and discussion and statics, I feel it would be better to describe the options roughly and then point to your own explanation videos which go into more detail. Right now it just seems like you are letting your thoughts run too far into an effort to try explain every part of your thought process , which then leads you further away from the practical side of implementation. Just my thoughts, love the series though but I had to skip past several parts and was a bit disappointed with seeing little progress overall. No hate though of course, just trying to be constructive, love your content and everything you do!

IMO the whole weak_ptr bit is a waste of time. the only time Get() returns nullptr is after some logic error in shutdown. this is a bug that should be fixed, not silently ignored/coded around. also: don't use a shared_ptr when a unique_ptr will suffice (don't hand out pointers to your private parts), don't use a unique_ptr when just a value will suffice.

@TheCherno

Жыл бұрын

It’s a teaching example

why so complicated for some simple output

@fanisdeli

Жыл бұрын

It's fairly simple, but he is talking about a hypothetical scenario where this could be a huge game/game engine, not just about the task at hand. That's his way of teaching.

@Jkauppa

Жыл бұрын

@@fanisdeli I talk in general, so much talk/text for accomplishing so little, God gives so abundantly, with no talk

@Jkauppa

Жыл бұрын

@@fanisdeli I mean text is not very efficient in making/describing anything, its like you better off not talking at all, and already having it all, nothing to be learned, from humans, only as given directly by God, inside you

@HelloThere-xs8ss

Жыл бұрын

@@Jkauppa what?

@Jkauppa

Жыл бұрын

@@HelloThere-xs8ss see talk/text has hard time conveying meaning, in any efficient form