Видео

Hi the cherno, thanks for this content of graphics programming, a little inspired by you, I've started to learn Vulkan and D3D12, and I found the VMA brother the D3D12MA, and now I've pulled request 2 features, all in cmake. I've followed the cmake path, instead of premake that your prefer, but i really thank you to be introduced in this content.

Just today a compiler crashed on me after coming around to compile my hobby project after a year. I have something of this level every 2 months. 😅This is nothing

With memory mapped files you wouldn't need different back-ends for memory and files. It also happens to be faster than file streams. Just something to consider.

Thanks

running on 165 hz, 6 ms per frame

I love your videos and want you to keep doing them💛💛

Fascinating. I vaguely remember some of this from when I was first learning C++. I think that C# multidimensional arrays are really single-dimensional arrays under the hood, so they avoid some of the downfalls of actual meta-arrays listed here.

Have you considered a merged writer reader serialization interface? Since it's possible to use the same interface to do both using pointers. This reduces the amount of serialization code and massively reduces the error of needing to write the code twice!

I wish everything was manual and simple. All the magic behind the scene is not worth the time you invest learning what is happening there

Endianness, padding bytes, different sizes of data types in different platforms, etc will cause you quite a bit of headaches soon. That's why I forgot about binary serialization and just went with text sterilization. Not super efficient but easy to deal with.

I do a very similar thing, even in C#. The only real addition is that I version every non-trivial section, i.e. every implementation of Serialize/Deserialize in a class. On read, if the version of that section is less than the current version, it calls the method to read that version. It only ever writes the latest version, but it can read every previous version in addition to the current version. This way it can always load old data, and updates it when the data is saved again. Deserialize() { byte version = ReadByte(); switch (version) { case 1: DeserializeV1(); break; case 2: DeserializeV2(); break; } } DeserializeV1() { // Reads V1 data into the current data structure, adapting/updating where necessary or filling new fields with defaults } DeserializeV2() { // Reads V2 data into the current data structure }

std::format in C++ 20 🔥

Best series i ever seen, #Thanks_Cherno

what's memory leak??

Lot of questions left unanswered I felt. Why was Printable turned into a pointer in the function argument? lot of scrolling which left me confusing ://

Yeah this whole video just went over my head :/

Vulkan series pls

As a related topic, I'd love if you could cover versioning with respect to serialization. Seems not as trivial as I'd hope.

That's not always true. Sometimes you have to introduce complexity for flexibility and extensibility purposes

15:18 "Non trivial types" Why not deconstruct them and save a mapping + the data?

IMO Complexity Demon enters code-base when requirements are not clear and one doesn't see the common denominators. When abstracting things down to the common and shared denominators a system becomes most simplistic in a way, that is so generalized it will fit any use-case. Yes, things can be really simple if built for one thing, and one thing only. But they can also be simple, if not simpler when they were built to the underlying mechanics that govern whatever system you are building.

I'm not great at C#, but why couldn't they just have used a local variable in the Main function instead of a static member object? I suspect it's not happy with the Window being not null because the class in which the Main function sits doesn't instantiate the Window object in its constructor, but that would mean having to still instantiate a brand new unrelated object, and have a constructor for it, just to remove the question mark

What a fun and easy process

i did some serialization in zig. let me just say that it's much less hassle for the task than in c++.

I wouldn't write a size_t to a stream, it *could* be different on different compilers/platforms/OSes, should *always* use a known size type when doing data streams. It's been mentioned in other comments, but endianness can also come into play, but also a majority of systems out there are little endian... So that's less of an issue IMO.

Way too much babbling. I lasted 10 minutes, then stopped.

MGE 🤔

Any reason for not using any of the serialization formats that use a code generator? Protobuf, cap’n’proto, msgpack etc.

While this code effectively reads and writes int32_t and int64_t, it's important to note that it may not be cross-platform due to differences in endianness between systems. Little-endian and big-endian architectures store bytes in different orders, leading to potential incompatibility when sharing binary files across platforms. To ensure cross-platform compatibility, consider explicitly managing byte order or using libraries like Boost which have functions like native_to_big and big_to_native to handle endianness conversion.

The "difficult" part is not structs/objects... it's shared struct/objects, that are saved in one place and then, pointers to them need to be recreated when loading... pointers can act as a "uid"... but that means that a struct/objects when loading need to have a place to store the pointer at save time, and when loading look for it in the loaded objects. That is introducing some dependencies, and so, the order to save and load becomes important.

Great content, but where is Vulkan series? :d

Why to use char* data to represent bytes in 2024? Is the std::vector<std::byte> not good enough? We have std::byte since C++17 if I'm not mistaken...

Someone already commented this, but if you get something like this #error OpenGL already defined The reason is your includes in ImGuiLayer.cpp has to be like this #include "voxpch.h" #include "ImGuiLayer.h" #include "imgui.h" #include "backends/imgui_impl_glfw.h" #include "backends/imgui_impl_opengl3.h" #include "Voxen/Application.h" #include <GLFW/glfw3.h> #include <glad/glad.h> If it looks like it is the exact same as what you have, it isnt, you are likely including 'imgui_impl_glfw.cpp' and 'imgui_impl_opengl3.cpp' but those both need to be the .h in the ImGuiLayer.cpp

Cherno, you don't need to call the .close() method on std::ofstream in destructor because RAII (Resource Acquisition Is Initialization) automatically handles closing the file when the object goes out of scope. Manually calling .close() leads to redundancy since the destructor of std::ofstream closes the file automatically.

"I'm not even sure how that code I wrote yesterday worked at all" - Every programmer 23:39

What about endianess of architectures? Am I correct that you don't handle it or am I missing something?

why not use std::ostream and std:istream interface?

Yeah, as others have said, add versioning. The first few bits should be used for checking the version.

I still think you should just use an open source library for some configuration format like TOML and just serialize all data that doesn't fit into a basic type as a b64 encoded string, but that may just be me who is thinking that and you'll never read this anyway. Also, you must have written Java for many years looking at how you're designing this.

How much simpler would this be with something like Serde in Rust? Is there no good C++ equivalent, or is something like that generally not suitable for a game engine?

It doesn't look much different conceptually than Apple's Foundation NSCoding protocol. Serialising and deserialising is totally manual but extremely simple too.

I would really recommend you to dump std::ofstream, wrap a low level FILE (fopen) API, as it can easily be between 2x to 10x faster to read/write files than std::ofstream. Please test it.

4 things that got to my eyes instantly: - Like you mentioned the useless if - The usage of what I call an "OG loop" ahah, honestly a foreach would be cleaner here, since the index "i" doesn't seem to be involved in any other things rather than just getting the element from the array. - The usage of 2 "GetComponent" that can be associated to a variable like this: Collectable coll = g.GetComponent... - And also a check to see if the component "Collectable" actually exist on the gameobject.

I don't understand why you need to explicitly define a destructor to call m_Stream.close() when the destructor of m_Stream itself will close the stream. Standard streams already use RAII. It would also probably make more sense to construct m_Stream directly in the constructor's member initialiser list rather than constructing a temporary and move assigning it in the body.

To me the static member function is polluting the data type. You can just make functions, so you may even put the serializers in another file and don't have to include your serializers if you don't need them.

I once implemented a serialization framework where I abstracted write and read to a certain extent. Instead of readInt() and writeInt(), there was processInt(), with a pointer to an int (and so on). The reader object would fill in the pointer, the writer object would write out the pointed-to value. Maybe 5% of code needed to test whether it was reading or writing, for instance if it needed to initialize other structures on read, but you didn't want to run that code on write. Doing it this way really removed a lot of the boilerplate associated with such systems. [In general you have my full agreement on simple, though. In my experience self-deriving serialization libraries are only useful for tech demos, for real code it is worthwhile to do it right the first time.]

what's the visual studio color theme

So the first 10 minutes is you crying on your little project

The simplest solution is the best solution - and that's why I chose C++ :) Just kidding, I know there isn't much of an alternative really

This pattern is gonna be so useful for my final project. Thanks man