Видео

Odin

The universe provides

Yes, unless Odin does something truly wild(!) behind the scenes like mmap a terabyte of virtual memory for every [dynamic] array or something. Even worse if the video author themselves didn't realize -- my guess is the author is mostly familiar with garbage collected environments, isn't used to working with pointers, and just want to encourage memory pooling or arena allocation in general and picked an unfortunate way to show it. Instead of returning pointers, one way to solve it would be to just return opaque IDs or something like that (indices into the array, for example) that act like Node pointers -- if the language provides the option to overload "dereferencing" (like in C++/Nim/Rust/etc., I don't know if Odin can do this).

@@frankhestvik9859 I imagine the video maker is very familiar with manual memory environments, but mapped an example that used an arena or bump allocator onto a dynamic array for simplicity of explanation.

Yes, in that case, you can use ids rather than pointers, or make sure not to keep pointers across calls that may realloc, or use a larger preallocated pool, etc

This seems nonsensical or a misunderstanding. The "individual" in "individual lifetimes" that Rust focuses on is a completely different concept than the "individual malloc()/free() calls can cause fragmentation"; that's like conflating the size of a for loop in the source with the number of iterations during run-time. In practice it might actually be the opposite: Rust's type system is such a pedantic pain in the ass that people end up "giving up" on their (usually bad) linked list/heap-node strategies and instead just go back to using a vector/ECS/data-oriented approach, e.g. backed by vector storage or an arena/pool allocator, which tend to be much simpler to do in Rust -- and which is exactly what this video seemingly would argue for... I mean this is why I don't like Rust either, but to say it doesn't encourage data-oriented design seems wrong. The main problem you would have in Rust with this code tho is that it would (correctly) tell you that what you're doing is bullshit because you're returning pointers into a seemingly dynamically allocated array that may move around on the heap (unless Odin does something truly wild like map every dynamic array to its own terabyte of virtual memory).

It's interesting that you say that because I feel the exact opposite way Once I started thinking in groups, it became much easier to program What do you usually do in systems programming?

@@DylanFalconer i'm a student taking a class on low level programming in C in which we are asked to frequently write console applications for linux/unix systems, i just came back to this video because today i received an assignment in which grouped lifetime thinking is probably the best way to solve my problem efficiently. so i guess i was totally wrong because i actually did exactly what you described in your video, we had to implement a kind of stack that rotates and in which you had to pop and push elements sometimes. i used a memory pool with a free list to keep track of which elements were popped so i can reuse their slots and it worked wonderfully!

Maybe educational purposes, Idk.

You still keep the properties of why you want a linked list. It allows you to add and remove items faster, because you don't need to moving memory around. Arrays/Vector/dynamic arrays are just blocks of memory.

I am more of an array person myself, you often do not need to store pointers. But grouped lifetime thinking can also be applied to tree like structures (and if you are weird you can see a link list as a tree where every node only has at most one child). Linked lists have some advantages over array,s especially in the functional programming realm where they are a persistent data structure.

Yeah it is basically a pool allocator The linked list example is just as an example - because that's something we learn very early and it's usually the individually allocated elements way That said, you can still back a linked list with a pool (probably different to this one so you don't get reallocations) and get decent cache locality while maintaining characteristics you want from the list (->next, ->prev) Why you'd want that just depends on what you are working on

Same, in practice I usually use arrays for most things unless there's some good reason not to

Absolutely

Also neat to sometimes leverage globals, const or not, for static storage. And stack too.

Somehow I also became a huge fan of templates, something I once sought to destroy.

It is really good for performance and I find it to be much easier to reason about

That means a lot! Thank you

Hey Diego 👋

Yeah, it's quite nice!

Thanks, Bill :)

Thanks!

Yeah, for multithreading, you'd be looking at bespoke systems that don't fit here I've only multithreaded rendering before, so I'm only speculating here... You could split routines into threads if they don't affect each other Let's say physics in one, updating status effects in another Or you could use some spatial data structure to query entities nearby each other and send results to a job queue

(Messed up the sizes, which is really important for this, so changing it. I said it was 7 megs, but it 28 megs (7*4)) How to scale it depends on needs (which youve supplied). So, for a mass scale RTS, I built a prototype of a chunk based "ECS" (though, this idea would work for the other 2 options also). So, each block of data was a compile time constant size, 4096 being really solid. My ECS was also double buffered, and allowed reads from last frames data by any thread AND made things faster for me (bonus!) Then, for my systems I basically did: foreachcore( process chunk_stride_start+core_i ) {I say "ECS" but it was a chunked structure of arrays system per archetype (much like most ECSs are under the hood)} Its part of my billion active entity updates / second (prototype) project. I got there on my AMD 5950x + 3090 (though the video card was just mostly idling). The only entities I had in at the time however was projectiles flying all over, and so more experimentation is needed. { I dont personally care about strict deterministic behaviour (which is a long story), but given storing both old and new states, it should be very doable. I havent put a huge amount of thought into it yet though } A couple of big takeaways. Gameplay data is very often (even for an RTS) a very small portion of all the data a game needs to deal with. So, doing things like double buffering of it (or potentially even more) is very often not a huge deal. Lets say you had a million units, like actual individually instructable units (not like what Total War does). Even at full res for position, youre going to have 3 floats for position, and 2 for orientation (4 of you must). So thats 7*4 or 28 megs on the outside and can absolutely be shrunk if you need more units/less data, so 56 megs for updating its Pos+Orient data. 1 2048x2048 texture is 16 megs by itself (granted, youll be storing that as something like DXTC<blah bla> or whatever, but still) Going >1million units is still doable to about 10million, but over 10 or 20 million Id start coming up with ways to process groups of them more like particles than units.

@@marcsh_dev My units were easily 2kb in size for a basic unit implementation (for a game with mechanics, not a battle demo. ofcourse this is not including game date which was just a pointer/unit id to another table somewhere), not even with all the behaviors I currently support in Cosmonarchy Not sure about chunks btw, I have not tried/seen such implementation. I tried making an ecs, but got pretty complicated pretty quickly when I wanted to start implementing deterministic multithreading (which I need for lock step multiplayer)

2kb of dynamically changing data per frame? Thats the data Im talking about. You can have all sorts of static / per unit data, and only occasionally changing data in different spots. The point of the double buffering is solely for the small per frame subset of data.

Re Chunks: If you have a flat array, its relatively simple. You can even just do it with a single command on many different languages and systems. Ie they often have a 'parallel_for( my_huge_array, num_cores )'. Its also easy enough to go from something like std::vector to motive::vector_chunk, and just have a set of pointers to vector chunks It is slightly tricky to add and remove entities from the chunk, but not hugely different than doing it from a big array

potentially enum EntityId : int {} don't recall if it works well in plain C though

You don’t even need to do this typedef int entity;

@@snesmocha no, that's still an int, i.e. weak type. compiler won't help

wish typedef covered this case

@@snesmocha That's just an alias for an int. A struct is a complex type, and the type checking will work.

Thank you! I'll make sure they are larger next time

Yeah, it was tough I won't lie! C will always have a special place in my heart

@@DylanFalconer It was hard for me too. But slices, custom allocators, "batteries included", defer, array programming, context etc. were too good to not swich.

Giving me ideas of using simple shapes with a bunch of post processing

Glad you enjoyed!

Raylib is simpler to use out of the box as the API handles most things you would need to program a game on the graphics side, while, SDL is more flexible and, is designed in a way to be easily integrated with other libraries and APIs

Raylib also provides functions for 3D graphics (model loading, animation, rendering) that SDL does not.

Raylib have built-in camera and collision system, in SDL you should implement that from scratch.

Good question, I think everyone else already covered it so thanks guys!

No, when the program exits, the OS itself destroys the window and clears it's memory, which is more efficient than doing it yourself

@@LeoAzul-xo7fy won't there be a memory leak?

@@CoolestPossibleName The OS clears the memory, as stated