Game development tutorials focused on Unity, C# & Blender . Covering all kinds of topics surrounding the creation of video games and experiential technology.
Just finished watching the series and gotta say man, great stuff! :D I finished my post grad in 2018 and never went into the industry. And its safe to say Iv forgotten some of the basics and alot of the more complex shit too but after watching this series I feel like I could make the next viral indie game thanks a heap man!!!! :D Im shocked your videos dont have more views, they are amazing.
Absolute lifesaver <3 For anyone who was dealing with the Moq and castle.core references being cleared magically from visual studio. Re-install Moq, quickly go to right click your test .csproj open in notepad and then you can find your moq version.
Fun times. I had to do very similar things for a console game way back in Unity 4.5. Memory management has always been the weakest part of Unity despite being critical for high performance games. What I found (on memory constrained hardware at least) is that you have to avoid using managed memory as much as possible if you’re expecting to have a long running game. Every once in a while, the GC will expand its heap instead of doing a collect, to potentially avoid a GC hitch. However, that heap never shrinks so you eventually end up with a massive managed heap. This means future GC.Collect() runs will take longer and less memory for stuff like textures (managed natively by engine) to be loaded. The solution is to pool your frequently used objects and reuse them. More extreme cases may require you to just write a C lib to manage your memory and just use pointers in C#.
you probably got alignment problem in EngineStruct.Thrusters because you should have +1 byte padding It may work slower that AntiGravThruster.Size*8 or even not work on some platforms
For clarity, this example works. Its part of the code I'm actively using. Its possible I have some glitch in the memory because of it, so I'm not ruling that out. Can you give some more detail please? I'm not sure why I need a 1 byte padding on the arrays. I've needed things like that for low level external C APIs, For instance putting the buffer between data elements so it locks a 3 byte structure into 4 bytes because it was compiled that way. But I'm not aware of an actual limitation even on performance for this in C#. I'm not saying there isn't, but I haven't read anything detailing that. Only the offsets I occasionally need are for interacting with external libraries. And for me, I wrap that up under the concept of protocol. When reading the data from cache ram to a CPU register, I'm under the assumption that an exact byte position is used at no extra cost over a 4 or 8 byte chunk of memory. Again, this could be mistaken. AntiGraviThruster is only 40 bytes in size and so only 280 bytes for the thruster byte array. I'm not aware of that being an issue on any system. I believe the modern CPU/Cache RAM setup is loading 64 to 128 byte chunks into cache ram at a time, and so we would exceed a single RAM read, but it will still load the content over all. I'm generally trusting of Unity ECS's 16K chunk size, that it would work on most any hardware that Unity supports. I.e. I'm not planning to exceed 16k for a single memory block. But don't see a reason why I shouldn't go right up to 16384 bytes at a time. Now, I'm not an expert in this either. This is some 30 years of programming knowledge, down to bits, baud, 7400x ICs, minor assembly, and lots of managed code, but no formal education. I have a lot to learn but have done heavy studies into this. I gladly welcome more knowledge. Perhaps something in my response is incorrect, and I would love to get more detail on how I can improve my understanding. If I'm wrong, I'm wrong.
@@dvsdev usually to get some data into CPU register, it should be word size (4 or 8 bytes). Otherwise OS will copy memory to a temporary buffer. With other things you are right. CPUs have 64bytes L0 cache, so whole object should fit inside for best performance. Also fields should be ordered in their access order, so CPU could walk with small offsets in one direction on data
@@morglod So in that case, since the thrusters are 40 bytes each, and are largely self-contained (- the engine offset), I could put those in a single array of 28 thrusters. I would also move the engine data, which is just a offset for each of 7 thrusters, into an extra variable in each thruster. Going up to 52 bytes. It would take more memory, but each 64b chunk would contain that engine offset, and not need to load it from two different chunks. Thank you for this insight. I'll research this some more.
@@dvsdev yep; I missed the thing that you have Size*7 bytes so there is no need in padding actually. So I was actually a bit wrong in my first comment. May be I missed and you said it, but this is called SOA (Structure Of Arrays). In some languages there are special decorators/codegeneration that may make from array of structures -> structure of arrays. array of structs: Object objs[10] structure of arrays: struct ObjectsChunk { objField1[10]; objField2[10]; // .. etc } I think all ECS should have codegeneration that will generate optimal structs instead of trying pack it in runtime. Thats the main problem
@@morglod Agreed. everything I'm doing could likely be done faster in ECS, but the goal I'm pushing for is to cut out Unity physics and replace it with my own. By taking control of the memory in the process at the same time, I *should* get more perf out of this. And not have to worry about staying up to date on ECS API changes. This is the latest test from the current physics system. I haven't fully replaced Unity physics in it yet. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-9s2gVsEMmqk.html - but I've still got plenty to learn and apply. Looking forward to the journey.
Around 33:01 I failed to show how to get the thruster. The problem being that you can't do a fixed inside another fixed. The method to get a thruster from within the fixed engine pointer, is this AntiGravThruster* thruster = (AntiGravThruster*)(engine->Thrusters + (thrusterIndex * AntiGravThruster.Size)); We didn't need to get a pointer, as we were already in one; making "->Thrusters" act as the thruster's pointer offset directly.
I didn't figure out how to get Span<T> and Memory<T> to work in Unity until after this. (Kept trying to import name spaces and library references, but C# couldn't see it) Then I finally found the reference that said turn on Unsafe and it just shows up. :facepalm: However, this is generally how Span and Memory works, to the stack and heap. So I can still achieve all the same things. For instance: List<int> numbers = new List<int>() { 1, 2, 3, 4, 5 }; Span<int> numbersSpan = CollectionsMarshal.AsSpan(numbers); This is similar to fixed(int* iPtr = &numbers[0]) where in this case I'm getting an int pointer. Incrementing an int instead of a byte, you increment by 1 and it moves the length of the type. so if iPtr is address 1000, and you say iPtr + 1, you would move to address 1004.
At present, ECS would probably be the same speed, because my current code only takes on the index a single car. I need to run a collection of these replace rigid body, and collider physics, specifically, I need to control the memory structure of the environment. And I'm not aware of a way to replace what RigidBody looks at, so I'll be recreating it. This is what I'm writing the Vigilante Racer code to do, and I will run a comparison on performance after. In FPS per car count in the same test environment most likely.
Just my own class. Its part of a design tool to allow me to morph/deform the car into other shapes. It doesn't hold any real meaning to this video. Though once I have the morphing working how I want, I'll probably do a video on that as well.
In this overly shortened version, I missed including where the shake everything concept came from that was in the first draft. Back somewhere between 2005 and 2007, I was teaching game development at a college in Illinois. (Hartland Community College) and had taught the first simple camera shake as a response to losing a life in a galaxian clone. two of the students were working together that excelled, and came up with a different approach, which involved shaking the stars, the ships and the UI all distinctly. It was awesome. From what I had used and taught up to that point, this was a major upgrade, and with a background of black, it had a moment of shock seeing it. (I hadn't even seen a game do that at that point.) After that point, that became the standard of what I taught in following classes.
Just realized, I said "Crazed is one of the members on my discord server", but I didn't mention that the first video clip was from his game. (bad edit, sorry Crazed!)
Hi, great series. Really enjoying it, would the edge reduction functionality still be needed if we aim for an infinite terrain as you are doing here instead of an island? Thanks!
