Hope you're enjoying this series as much as I am! ❤(and don't worry, I haven't forgotten about the Ray Tracing series!) While you wait for the next episode, check out Brilliant's new 30-day free trial! Visit brilliant.org/thecherno - and also the first 200 of you will get 20% off Brilliant’s annual premium subscription!
Considering there's no fading of alpha or otherwise in the sprite sheet, you could just replace the two magenta "alpha" colors with transparency and then of course use the alpha channel for the conditional draw. I'm sure you've already thought of that, I'm mostly just talking to myself lol
Watching these tutorials is helping me understand the conceptual aspects of the overall framework, which are used in a game code, much better. Thanks. (Don't know if that made any sense)
Hey Cherno, I am a newbie to C++ and I am curious about the usage of C-style casts vs Cpp-casts. For example, I see at 24:20 that you use a C-style cast (uint32_t*) instead of static_cast. Did you do that on purpose for some specific reason or is it just an old habit? Based on my limited reading I've gotten the impression that Cpp-style casts are better for readability and because cpp-style casts can be checked at compile time while C-style ones can fail at runtime. It's probably not a significant thing to point out in many cases, but as a beginner I am trying to build good habits from the start and thus why I mention it. Thanks in advance.
static_cast is preferable because it is more explicit about what kind of casting you want to do. In this case though he is casting to a pointer, which means as long as that object can be coerced into a pointer, there is no error raised at compile time either way. (I think static_cast would raise a warning for undefined behavior though). Hope this helps.
He's not following a lot of industry best practices. C++ style casts are somewhat safer, but it would be best to not cast it at all, just store the image as is. He didn't disable copy and move, so an accidental copy will result in double free. Constructors should throw an exception on error, not just write to the output. Raw pointers should not be owning. Using named algorithms would be nicer than raw for loops. If you want to write the best code, I suggest to read and follow the C++ Core Guidelines. You can use clang-tidy to enforce the rules and best practices.
You could also use constexpr with class templates to set all the solid properties of a tile class at compile time. I've been writing engines also 30 years so I'm very good at finding these types of optimizations
I think you should make a helper class for sprites so the math isn't repeated all over the place. Also, I agree you don't want to do the subclass like you did in Java. I would consider making a simple spritesheet editor that let you add or edit sprites, save the image, but also save the aatributes per sprite in another file. e.g. it's position, size, and other attributes like "should be affected by lighting" or "is not passable" or "kills the player" or whatever. It could also include important things like the width and the height (for allocating the mem), the name of the sprite sheet, what color is alpha, blah blah.
I think in this case since he is unlikely to add more sprites, i'd just hardcode the attributes of each sprite. It wouldn't be hard to hardcode attributes for sprites you add on later down the road.
If you really want to specifically get into graphics effects programming, there is a really good book called Real Time Rendering. It's not a coding book so there is no code in it, but it does a GREAT job of explaining the algorithms for 100s of different types of lighting and effects
Hey Cherno. I watched your game programming in Java series a couple of years ago and really enjoyed it. It seems like you assumed a bit more experience there than you are here in this series. I guess I’m encouraging you to take it up a notch, please - unless a lot of other people need help with array indexing arithmetic, of course. Great job, as usual. Love your videos.
I think modifying Walnut would be good, things like a cpu only image are features that should be in the library anyways, so if you can get content and features at once then might as well do it
You only have to break the sprite sheet into individual sprites once. Any why wouldn't you? You don't save memory keeping it in one sprite sheet. And with them all in one sprite sheet, your memory accesses are much more fragmented than they could be.
@@awsumturtle he did say that this series is made for beginners. There are other stuff he's done that are more complicated and less beginner friendly. As far as I understand, this series will be as beginner friendly as possible, and will only get to the "hard" stuff at the end, when he'll go one step further and implement all that stuff in vulkan.
@@Jkauppa "if you need to learn, you are clearly lacking and not perfect, do you see the difference, between perfect and lacking/empty" - why did you feel the need to point out that if someone needs to learn they're lacking and not perfect? This is obvious to anyone with a brain. And what human with a brain doesn't understand the difference between "lacking" and "perfect"? What is the point of your comment? Did you try to educate someone? Did you try to establish that you somehow posess forbidden knowledge that the "simpletons" don't realize?
