Download the source code for all my videos here: patreon.com/vercidium Ask your optimisation, rendering or game dev questions here!

@SatisfiedOnion

5 ай бұрын

How would you apply this to a non-open world game where levels may not be physically next to each other?

@eineatombombe

5 ай бұрын

Have you tried Vulkan?

@Restart-Gaming

5 ай бұрын

​@@SatisfiedOnionit's fake

@Vercidium

5 ай бұрын

@@SatisfiedOnion I implemented this in Sector's Edge, which always has 3 'worlds' running: a shooting range, singleplayer and multiplayer. The player can switch between these whenever they like, which means they can practice in the shooting range when a singleplayer map is loading in the background, or play a match in singleplayer while waiting for the server to connect to and load the multiplayer world Since all the worlds are completely separate from each other (not open world), background threads can do whatever they like to world B while you're in world A

@Vercidium

5 ай бұрын

@@eineatombombe not yet! There are so many times where I think I've pushed OpenGL to its limits and think it's time to move to Vulkan, only to realise there's a feature I missed or a new function in OpenGL 4.3 that I can use instead. I would love to experiment with Vulkan's command queues though and dive into GPU multithreading, i.e. render shadows and run postprocessing like bloom at the same time

This is the first time I hear an English speaker say cache differently than cash.

@carlsagan2371

5 ай бұрын

I never knew that data was stored in a flan cheese pastry.

@emporioalnino4670

5 ай бұрын

It's prevalent in Australia and it bugs the hell out of me.

@mr.hi_vevo414

5 ай бұрын

I mean, it kinda makes sense since Es at the end usually make the vowel sound like the letter itself, changing "ah" to "ay". I might be wrong, but English spelling is just a mistake in general

@UmmerFarooq-wx4yo

4 ай бұрын

Time is money Cache is cash

@ifrite3

4 ай бұрын

I've only heard 'cash-ay' and 'cash', 'kaysh' is weird

he really said /keɪʃ/

@zoeherriot

5 ай бұрын

Australian pronunciation.

@evilotis01

5 ай бұрын

wait, how would you pronounce it?

@wyoung8331

5 ай бұрын

@@evilotis01 like cash

@ezikhoyo

5 ай бұрын

@@evilotis01More like how you would pronounce cash

@johnf5834

5 ай бұрын

@@evilotis01 /kæʃ/

Loading screens not fixes problem with cache/memory/disk/etc.. It just fix "strange" game behavior, for example imagine that some "invisible" enemy will kill you in game, because his model is not loaded yet. If we speak about multiplayer games its even more critical.

@uzzy2522

5 ай бұрын

You can still load in an area that's considered a loading zone where you can't be damaged when entering, instead of obscuring the whole screen preventing you from play. New features require newer solutions. This isn't hard to fix, maybe my example is still bad but there's definitely a solution for that im sure.

@Vercidium

5 ай бұрын

For multiplayer games it's about loading the next area/level while the player is still able to move around in the last. In Sector's Edge there's always 2-3 'worlds' running: shooting range, singleplayer and multiplayer. The player is always in control and can switch between these whenever they like, which means they could practice in the shooting range when a singleplayer map is loading in the background, or play singleplayer while waiting for the server to connect to and load the multiplayer world

The loading screens in my game have nothing to do with cache locality. They're there because the game doesn't have any way of knowing what data to load before it's time to load it. If you click to join a friend in Steam, the game finds out what data needs to be loaded at the same moment that it needs to be loaded. When you first open the game, there's no "in the background" that happened before. When the host issues a changelevel command, the client finds out what it needs to load at the same time that it needs to be loaded. A loading screen that looks like the game is still running but you're trapped in a box room until it finishes is still a loading screen. A loading screen with a minigame on it is still a loading screen. We could load lower quality versions of assets and stream the regular quality assets in during the level, but doing so would double the number of things the game needs to keep track of and degrade the visual quality shortly after a level load. Additionally, some data does not come from a device the game is directly attached to. For example, when loading into a multiplayer level, the server needs to send a snapshot of the dynamic state of the world. There's no "in the background" because until that snapshot is received and parsed, no game state exists. We could get rid of the loading screen and keep showing the main menu until the level is fully loaded, but that's just turning the main menu into a less understandable loading screen.

@Vercidium

5 ай бұрын

You're right about first opening the game - the game should load the bare minimum it has to (compiling shaders, allocating memory on the GPU, etc) so that the initial startup is as quick as possible, then load resources in the background. From that point on - whether the player is on the main menu screen, trapped in a small 'practice' area - they should retain control of their game. Whether something is being loaded from disk or from networking in a multiplayer session, they shouldn't be interrupted when trying to customise their character or settings, or practice in a shooting range.

@jbritain

5 ай бұрын

​@@VercidiumI think that's dependent on how you choose what you're doing next. It's rare that I've played a recent game where you encounter a loading screen that actually interrupts the flow of what you're currently doing. It's usually a case where you wouldn't have anything else to do until the new data (i.e a the terrain around a fast travel point somewhere else in the map) has loaded.

@chadoftoons

5 ай бұрын

I agree with the sentiment, making loading speed optimal is important but it does not feel like many games actually neglect it. The example shown in the video has a whole bunch of setup screens where people would join together before they play and seemingly set up loadouts. Philosophy wise its archaic when an elevator traps you arbritraily long or a door takes too long to open to hide loading screens while a flat loading screen is atleast honest. I guess the issue that this is trying to speak on is that you cannot do anything during a loading screen but usually that is related to the game being a service model and needing to ensure the client state matches the servers so that you don't end up with "gear" that doesnt match what the server thinks is on you. Heck that could be an issue in a singleplayer game too. There are even mods that make loading screens longer now because the content parsed on them can't be read anymore for games that predate SSDs like cycle limits in dosbox so you don't happen to run a game too fast.

@SianaGearz

4 ай бұрын

I think one of the cutest things is a pre-fight lobby where people get to equip themselves and get to know each other before they get themselves sorted into enemies and allies - they can't wield weapons but they can jump on each other's heads, maybe give them "hi" wave emotes, that helps. It can be the same room for all fight stages that is placed in an oberver position above the map with the map visible, and you can have low LOD maps all being present and loaded at all times, just a single mesh with a baked texture at a very low resolution could do fine, and if someone joins mid match, they can get a "hidden load screen" with a 10 second "get ready" countdown where they can observe the players from that observer lobby. So sometimes there's a game design solution to loading screens. No need to force it, but good to consider.

@benjaminblack91

4 ай бұрын

Also note that data races aren't made signficantly worse by caches, each core proactively reaches out and clears the other core's caches when the write goes through to main memory. This is required for thread lock mechanics to actually prevent data races. This hardware requirement is one of the main limiters of the number of CPU cores, otherwise we would have CPUs with 100s of small efficiency cores in servers and such.

ok i feel like i’m missing something here because this had a “loading screen” when you pressed the play button. And even if that wasn’t the case, outside of stylization or artistic choice, most games would still need a loading screen because they wouldn’t want to show objects being drawn onto the screen one at a time like that?

@YuriMomoiro

5 ай бұрын

Well it's a obvious click-bait. Teetering misinfo imo.

@MrXRes

5 ай бұрын

The idea is to get rid of loading screens during play session by dynamic loading of resources, after you pushed the "play" button And you dont need to instantly show loaded object, but when it needed instead

@device.serial

5 ай бұрын

​@@YuriMomoirothere have been large scale games that had no loading scenes between areas for nearly a decade now, how is it misinformation?

@Vercidium

5 ай бұрын

The goal is to never lock the player into a loading screen, for example on the main menu you would still be able to customise settings or listen to the game's theme. For a multiplayer game you could practice in the shooting range while your game connects to a server and loads the next level in the background. For a singleplayer game with fast travel, you could 'prepare' the next area when you activate a teleporter, then enter the teleporter when it's ready.

@TannerJ07

5 ай бұрын

That makes much more sense :)

"Casche"

@YosheMC

3 ай бұрын

"Helmets"

Nice, however, you need some data for a game to work (so that your enemies won't fall through missing floor, for example), so you have to wait for all that. Then, you can absolutely stream the data in... many games do just that (Witcher 3 is almost 10 years old now and it's definitely not a first one). With a caveat that you are ignoring and that's the space. Your dungeons data and your forest data might be too big to coexist => you need to unload one before loading another. That's why you can seamlessly travel from one post to another in Witcher 3, but fast travel will show a loading screen. So I'm not really sure what your engine accomplishes in that regard. As a side note, watching ground without trees and flowers isn't better than waiting that quarter of a second and watching the forest.

@Vercidium

5 ай бұрын

For games that push the limits of its hardware (e.g. Witcher 3 consuming a lot of memory with its large render distance) the next world could be loaded from the outside-in, i.e. the render distance would slowly reduce while the distant regions of the visible world are replaced with the next area they are travelling to. Reducing the render distance or increasing the thickness of the fog would disguise the next area being loaded, and the player can continue crafting items or walking around their immediate area until the next level is ready.

@Zack_Wester

3 ай бұрын

@@Vercidium This works until it don't. Like Jak and dexter on the PS2 does not have Loading screens except it does. it just hiden. if the player runs to fast so that the PS2 and this was only possible tanks to clever level designs, almost perfect understanding on the PS2 hardware (dont do this or else you end up whit stuff like StarComand on the Dos that only work on this specific model of hardware or else it just break got a faster CPU then the Rakon300 they used... to bad the game will crash all the time). to slow it will crash whit memory violations errors. your 3.5inch Floppy drive have the 0.05sec read slip delay problem because its a Malkin model guess what the game crashed. and even if the player runs to fast Jak would randomly Trip over this was the games way to force the player to slow down for a few sec so that it could load the next level and it only worked thanks to clever design. most game can´t really afford that. another is the memory requirments there is a reaon why CS2 have the classic loading screen between maploads. because if the game would start to load the next level after the last round start map vote choice. most peoples PC would crash because loading 2 levels are just not possible on there machines. and no we can´t presume that they are on M.2 SSD. Valve expect that the users are playing SC on a 7+ years old PC whit CS on a 7000ish RPM HDD and there os on a 10+ year old 128GB SSD that's almost full. because PC player whit a less then 3 year old system is less then 1% of the total population.

The God of Optimization has blessed us once again. May your indie games be entertaining and optimized.

@Vercidium

5 ай бұрын

Haha I'm far off that title but thank you!

@Decrare

5 ай бұрын

Following Sector's Edge over the years makes me say that title is very fitting@@Vercidium

You explained it well in a very short time and the visuals are awesome!

1:58 this is definitely wrong, at least on x86. You can read Intel manual on this, it says "Writes to memory are not reordered with other writes". This can happen because compiler decides to swap these writes, but CPU can not do that.

@nowonmetube

5 ай бұрын

And why does it happen to him then?

absolutely amazing videos! I've been wanting to get into game dev too, but I also wanted to make everything from scratch including the engine. Haven't started anything yet and just researching stuff to get a game plan going. Definitely going to give the rest of the channel a look, and I can't wait to learn more!

I mean, it seems to me that loading screen exists specifically to not show half rendered world, no? You didn't solve the problem, which is waiting for the thing to load before being able to play.

@Vercidium

5 ай бұрын

The problem is being locked into a screen. You'll still have to wait, but you can continue your current task (editing loadouts, customising your character) until the next level is ready

@WunderWulfe

5 ай бұрын

@@VercidiumThe other complication i can see is taking resources away from the loading process, resulting in longer loading screens or stutters/lag in the interface from the intensity of map/game loading and initialization operations. I think an initial loading screen is always necessary, but after that you should be able to stream everything in the game efficiently unless you use separate levels, such as having a dissolve or animation effect to slide objects into place when you spawn in

@Vercidium

5 ай бұрын

​@@WunderWulfe that's true, it'll take longer to load on CPUs that don't have many threads. But for CPUs with 8 or 16 threads, it's more feasible to reserve 1 for the main thread and use the other 7 or 15 to load resources in the background. And yep there will always be an initial loading screen / startup process where the game compiles shaders and allocates memory on the GPU. I've been diving into multiple OpenGL contexts recently (loading and streaming textures on background threads) to reduce stuttering; I wonder if I could also compile shaders here for an even faster startup time!

@blehbleh9283

5 ай бұрын

Pretty sure precompiled shaders on disk is an optimization that Steam can use for Vulkan before you even start the game. I assume then it's just loading/streaming shaders afterwards

@besher532

5 ай бұрын

loading screens haven't been needed for a long time. The problem is more about game design, loading screens are often used as a way to relocate the player in location and/or time, for example, battle royal games load and unload regions of the map as you play, and the oldest game I played that I remember not having loading screens in gameplay is portal

This was an amazing video, and you explain the problem really well! I would just like to point out that the problem that you are running into is a consistency problem, and not a coherence problem. What is happening is that the CPU core itself (not the caches) does not do all of its memory accesses in order to increase performance. The fence instruction was included specifically in ISAs to get around this issue. However, it is important to note that having too many fences can cause performance degradation, so only use them if you have to.

@Vercidium

5 ай бұрын

Thanks! Is it not both a consistency and coherence problem? When both threads are running simultaneously and are not synchronised (for example the particle array being reallocated), the reason the background thread doesn't immediately start writing to the new particle array is because its cache contains a pointer to the old memory. This means momentarily both thread's caches contain a different pointer to the particle memory

@robot4000

5 ай бұрын

Cache coherence protocols handle this issue, as that is why they are there. They make sure that whenever a memory access happens, it will always get the most recent write from any of the caches (it is why many writes from many threads to the same cache block can be slow). The pointer thing should not be affected by caches at all, as caches are designed to be completely transparent

as a beginner, i always make sure not to miss any of your videos, such helpful and practical tips, really gives me the insight. please keep the excellent job

your video formats are amazing for explaining concepts and practical implementations from code to screen.. cant wait to see more of your videos.. i find this stuff fascinating as a general software developer

@Vercidium

5 ай бұрын

Thank you! That means a lot

MORE, I NEED MORE !!!

1:00 It sounds to me like the problem you're describing does not need cache coherence issues, just an array that re-allocates upon resizing, and a pointer that doesn't get updated after re-allocation. Old comment, still true, but slightly different bug: -It sounds to me like you're describing a race condition that can occur even though processors handle cache coherence for you. Two threads can read the same value, and both decide that it's fine for them to write. Unless you use atomics. I think it depends more on how threads happen to be scheduled, and your own code, than on cache.- Explanations of this I really liked can be found on Day 123 and 124 of Handmade hero, about Atomics and Cache Coherence/MESI (in the Q&A section at the end) respectively.

@Vercidium

5 ай бұрын

That's right, the pointer won't be immediately updated in the background thread's cache, so in the meantime the background thread continues writing data to the old memory

@RC-1290

5 ай бұрын

@@Vercidium are you talking about some kind of software cache? Because the hardware deals with the coherence of its cache. Once again, it just sounds like you're having an issue with a pointer that didn't get updated when an array reallocated its buffer. If you're working with C# interacting with native code that's not all that weird, because the whole memory pinning stuff can be quite confusing.

we need more videos like this. pure gold.

Props to Dhewm3 for showing that once you remove all the junk you can load levels in a fraction of a second, and that's without streaming!

I cant believe i always learn something new from each video its crazy. Hes such a great teacher

Worst games were battlefield 3 and 4 on hdds. It was so bad that you could use a usb drive to speed it up as a cache. It went from 3 mins to 1.5mins with usb and then 10 seconds on ssd

This video is very good at explaining data races and the mutex pattern to newer audiences, and people coming into software engineering.

I usually enjoy your content, but this one is a bit of a miss. The video could be summarized in one sentence: "Load assets asynchronously to improve load times." This is somewhat presented as a breakthrough, as if modern games didn't do it already. In fact, many titles employ a multitude of much more advanced strategies for asset streaming. For those titles that do suffer from long load times, the solution is hardly as simple. Next, I take issue with convoluting this high-level idea with a crude explanation of low-level synchronization. Memory ordering is a very complex topics that needs quite a bit more screen time to even cover the basics. There are a number of mechanisms leading to data races - cache coherence isn't the only one. Both your compiler and processor modify and reorder instructions as an optimization, unless appropriate barriers are present. So the only thing you need to go and do to write safe code, is to look at what your language offers you in terms of barriers/fences/atomics and forget everything you might think you know about the machine. Otherwise you rely on hardware/implementation details and are destined to lose portability. Now, *fast* code is a different story, and it can be worthwhile to understand microarchitecture for performance, but in the context of asset loading that would be way overkill. You're well-spoken and the animations are great, so I'd hope to see more direction in future videos. If you do cover complex topics, make sure you understand them well and don't oversimplify to the point where unbeknownst viewers are borderline misled ;) Cheers!

@Vercidium

5 ай бұрын

Thank you for the honest feedback. Great point about portability - you can dive pretty into the rabbit hole when optimising for specific hardware, but that's a task most game devs don't need to go down (we'll save that for the unreal engine devs!) In terms of breaking down complex topics into simple explanations, this is the kind of explanation I needed when I first started out with multithreading. I faced so many issues because I didn't understand why cache coherence was such a big deal. I will definitely dive more into the details with specific examples (multithreading for raytraced audio, generating meshes, skeletal animations, loading from disk, OpenGL contexts on background threads) in future videos though.

@juliandurchholz

5 ай бұрын

@@Vercidium The viewers new to concurrency will come out of this video thinking "I need fences because of cache coherence", which is misleading. Allow me to reiterate: The same problems arise on single-core machines due to out-of-order execution and compiler optimizations. For instance, looping on a boolean written by another thread may never terminate, when the compiler transforms this memory read into a local constant. The solution is not a fence, but declaring the boolean volatile, making this optimization illegal. Similarly, instruction reordering will mess with the misconception an author has about implications in program order. The language only guarantees sequential consistency from the perspective of a single thread, and that is the main point you should be making. When it comes to solving that, there are many more options than fences, so I would suggest this warrants a much longer video, as to not give viewers the wrong idea :)

@juliandurchholz

5 ай бұрын

@@Vercidium As far as the other topics you mentioned, they're great choices to teach aspiring game devs, but I do wonder about using multiple OpenGL contexts. Haven't seen that used in a long time. The standard today is streaming into large persistently mapped buffers. Many complicated techniques play into that, like custom allocators, CPU-GPU synchronization, indirect drawing etc... And I would add occlusion culling to that list, it's a big deal these days. Looking forward!

Been playing Judgement, it's one of the most impressive games when it comes to loading. From one side of the city to the next in a blink.

you know you've made it when people comment "first", "second", and "third"

@Alice_Fumo

5 ай бұрын

*scrolls* I only see the "third" comment. Presumably, the other two might've been flagged as spam or something. Wait no, I found the "second", but "first" remains missing!

@Crazyzooka

5 ай бұрын

@@Alice_Fumo the lore is vercidium made the pinned post first, so technically he was first!

@kobedev

5 ай бұрын

@@Crazyzooka yeah that's what i thought too

Second Edit: Nice video! Running a piece of thread around my garden now, can't wait for it to create a fence.

Im excited to start using fences.

The thing that concerns me is that you could have lag spikes if it starts loading stuff in game!

@Vercidium

5 ай бұрын

Absolutely, my 2nd last video covers one of the reasons these lag spikes happen :)

Quick question, can't you make so each time a thread mutates a value in memory it will run a function inside of other threads that checks if that value is in the cache and then if true it just updates?

kayshes are so important for games, we should take advantage of kayshe more

I've been pushing for modern engines to support multithreading for a long time, but unfortunately, some programmers are still fixated on single-core performance.

On 3:06 on video it look like 6 second loading screen. Idk but it seem weird to me

I'm dealing with stutter issues currently when loading in assets on my project and it immediately made me go back and what your other videos. Even if it isn't 100% applicable to me or something I can act on. It's so interesting to get insight on this stuff! Great as aways Verc

My question is, myself being a Game Designer (and Producer and Game Audio-er) with non-professional knowledge of Programming, how deep of a dive I need to do in knowing Graphics Programming to be able to communicate and even lead a team where professionals of this area are present? How can I properly communicate my demands and understand theirs, spot if they're doing a good work or not (unfortunately I've dealt with people who faked knowing a lot but not even a quarter of that in practice; or once I was doing FMOD for a Unity project and the team's programmer put me to do the integration and mapping of every parameter into it), or even how to look at a graphics programmer's portfolio and knowing "this is a good one" if I'm not one myself? Do I need to "become one" up to what extent?

@Vercidium

5 ай бұрын

It's a tricky question! There's no 'threshold of technical understanding' you need to achieve and there will always be things you don't understand. Even as a programmer, there are other programmers creating things that I have no clue how they work! Ironically - from a management point of view - it's better to have a team lead that has very little technical understanding. They won't try to insinuate their ideas or micromanage, they trust the team to get the work done. If devs and artists are faking their work or don't actually have the skills you need, that's a hiring problem. At my workplace we have a developer in every interview to ask the technical questions. > How can I properly communicate my demands and understand theirs Involve the programmers and technical artists as soon as possible. As soon as you have an idea, ask them what they think about it and how much effort it would be. We appreciate being involved in the early ideation stages! We can tell you what you can't do, and we can also suggest other similar things that are technically feasible. It's also much easier for us to reject an early idea, than be pressured to try to implement an idea that you put a lot of effort into. > how to look at a graphics programmer's portfolio and knowing "this is a good one" It's best to have another programmer review their portfolio, but if the prospect is able to explain complex tasks they've done in plain English, then I'd say they're an excellent developer and communicator and worth having on your team.

I'm not sure I agree this fix will work for vRAM/memory-related constraints. How do you actively swap out assets whilst maintaining the previous scene without any load time on the next scene in a way that doesn't show a loading screen to the end user with limited vRAM? Also, I don't believe you say cache that way. :D

The main thing ruining my immersion in games (at least dead space remake and many UE5 games) is traversal stutter that’s unrelated to shader comp. Side note I hope PCs do on the hardware side if they can account for this stuff better and the software side. It’s been getting worse and worse. Was so happy to see Horizon Forbidden West did NOT have these issues. First game I’ve played in ages without those issues.

I remember reading something about how some big game companies purposefully make the loading time longer if it's not instantaneous loading, because it makes it feel like a more quality game that way

"Casha", lmao

I dont think this is true. I belive the bool must be updated before anything you do after. Like if not then like mutexes wont even work (assuming a mutex functions the same).

great video! thank you. what program did you use to make the video and animations?

@Vercidium

5 ай бұрын

Thanks! All animations are done in engine with C#, so I can reuse all my code, shaders and models

Did you set the trees as grass to make them sway in the wind...?

@Vercidium

5 ай бұрын

There’s a separate vertex shader for the grass and the trees, but they share the same wind strength code that moves the vertices back and forth based on their altitude

The origin of the word cache is the French caché surely, ergo it should be pronounced 'cash' or 'cash-eh'

I actually wanted to try making my own game engine, and so your videos have been very informative! However, one thing I've been having trouble with is understanding where and how to get started. I think it would be really cool if you put a video out on what all a game engine needs, and how to start on making one. Considering your 6 years of experience, I'm sure you'd have a lot of advice on what to do/what not to do, and what kinds of pitfalls to avoid. Also, "Caysh"? (lol I kid, just that in the US we pronounce it like "Cash")

@Vercidium

5 ай бұрын

Making your own engine is a huge task to undertake, I'll make a video or blog post on Patreon about all the things my engine does, but you don't need to create the whole engine before you start using it for games. I would say to build it iteratively along with the game you're trying to make. What kind of games do you want to create with it? For example with 2D games you can skip shaders and rendering pipelines, and with 3D games you can skip spritesheets/platformer physics. I built this engine alongside Sector's Edge, so I started with voxel rendering, then figured out how to load textures and apply them to voxels, then created a Player class and started working on mouse and keyboard input so I could control the player, then added a gun the player could shoot, and then realised I could've done this all differently and rewrote half the code base. It's a constant iterative process of adding new features, then going back and rewriting and improving the things you've already repeated. Rinse and repeat for 6 years and you'll learn so much along the way! I knew nothing about rendering, audio, networking, physics, etc when I started and learned each topic as I needed it

Great video. This wouldn’t work with every game of course though. Like generating a minecraft world for example. There’s no way to generate it ahead of generating it if that makes sense

@Vercidium

5 ай бұрын

Generating worlds that are divided into smaller chunks like in Minecraft are excellent applications for multithreading! The world can be generated iteratively over time on background threads

Cool but I'm not a technical dev so nice to know it can be done...

Are you using Open GL in C#?

@Vercidium

4 ай бұрын

I am, I’m using the Silk.NET OpenGL bindings

@theashbot4097

4 ай бұрын

@@Vercidium I am trying making a voxel engine in unity but it has a bunch of stuff that I do not need, so I have been trying to learn C++ so I can make a voxel engine, but I could have been using this the whole time! LOL. Thank you soo much for the fast reply!

@Vercidium

4 ай бұрын

@@theashbot4097 the performance difference between C# and C++ is negligible these days, for the majority of things. Plus C# is an elegant language and constantly improving, I love working with it

@theashbot4097

4 ай бұрын

@@Vercidium I always thought that C++ was noticeably faster then C#, but I never tested it before. I am going to try that Silk NET ASAP now that I know about it! I Love C# much more then C++. Thank you soo much for the help!

I've been watching your videos from last, and I can say that your content is simply amazing. The explanation, the knowledge, you are making the perfect videos. But can we please get an In-depth video of implementing your concept in different engines and scenarios? Much Love

@Vercidium

5 ай бұрын

Absolutely, for multithreading specifically? I have a lot more examples for things it can be used for (raytracing audio, generating meshes, blending skeletal animations) that I'd love to makes videos on

@shubhambatra178

5 ай бұрын

@@Vercidium I've seen your video on ray tracing audio. It makes me feel like such a simple thing like audio can have such a HUGE effect on games. I would love to see it implemented in unreal or Godot.

Is your engine available for public use?

@Vercidium

4 ай бұрын

Not yet, currently the source code is only available on Patreon

Cache is pronounced like cash, not kaysh. Other than that absolutely brilliant video! And sort of confirms my suspicion: The Renderthread locking up during load is not something that cannot be avoided, some languages just make it harder to solve the issue. If you want to see the extreme version of this check out loading into a race on rFactor 2, everything just hangs while cars get loaded into ram.

@Vercidium

5 ай бұрын

Thank you! Here in Australia we speak strangely ;)

@EduardoGabrieldeOliveiraVictor

5 ай бұрын

​@@Vercidiumthe way you pronounce is better than the American way

@zoeherriot

5 ай бұрын

@@VercidiumAustralian here - 100% confirm that “Kaysh” is the correct pronunciation - but all my US colleagues disagree. ;)

The KASHJE

1:04 as far as i know this isnt a problem on desktop cpus theyre already cache coherent (to write to or read from memory you need to own the cache line and the cpus garauntees a cache line is assigned to only one cpu),race conditions are never caused by the cache the worse it does is slow down your program

Thank you for the video. It seems to me that your demo version uses too little SSD resources. Try creating a demo with asynchronous loading of several gigabytes of memory and tens of thousands of assets. Asynchronous loading has been in use for a long time; currently, the main bottleneck is the speed of the hard drive. Solving this problem is much deeper and more complex than simply enabling asynchronous loading.

And you will never know when/what the level you need to load.

back in the days of N64, loading screens didn't exist, the system was so limited that it didn't need one

Idk, I feel like people with decades of experience know what they're doing.. usually AAA games also have more than hills, flowers, and trees

@toxiccan175

5 ай бұрын

AAA games are also incentivized to prioritize content and quantity over optimization and quality.

@williamowens2063

5 ай бұрын

@@toxiccan175 I won't deny that however they will get heavy backlash from poor performance, which will hurt profit in the end. While it is true they prioritize content over optimization (I'd say that is reasonable), it doesn't mean that optimization isn't also a priority. Obviously not all optimize nor test their games properly, but I think it may be due to corporate greed (rushed deadlines etc) rather than lack of skill or trying.

@Vercidium

5 ай бұрын

There are AAA games without loading screens, the Uncharted games are excellent at this. They use cutscenes and staging areas (like moving into a tight space) to unload the previous area and load the next without you knowing

@williamowens2063

5 ай бұрын

@@Vercidium I did not know that actually. I even played Uncharted 3 twice, but now that you mention it I don't think I really saw any loading screens once in-game. Huh...

This could be explained a different way, showing a obvious loading screen and playing an intro or some mini game to obscure the fact that the game is loading is different than just removing the loading screen althoughther, the textures popping up when loaded look worse than loading animation does IMO

Ur vids r amazing but u forgot to put some papers in the desc 😢

@Vercidium

5 ай бұрын

Hey what do you mean by papers?

@starplatinum3305

5 ай бұрын

@@Vercidium like, sources and informations about the things in the vid that you might have read to make this vid

Starfield would need this.

You should send this video to Bethesda.

So this is like a simple lesson in multithreading? I want to know why companies don't utilise it (other than the reason: they don't want to spend money on optimising in this way)

@TheArtikae

4 ай бұрын

They totally do, in fact, use this.

bro try vulkan

The actual reason why we have loading screens, is because levels. Levels are easy to make and think about. the easiest way to use a level is to load it all at once. Even if you use asset streaming, you need some information already there to do stuff, when the player appears. Since most ppl don't want to watch half empty levels loading in, you put a screen in front of them. The same goes for the dreaded online features, You're just waiting for a server instead of the hard drive. Honestly, I feel like you haven't given this video much thought, since how did we get from loading screens to caches?

@Vercidium

5 ай бұрын

Absolutely, the player shouldn't be dropped into a half-loaded world, but they also shouldn't be locked into a screen while waiting for the next level to load. They should retain control of their character in the previous level, or at least be able to customise settings / loadouts / characters while the next level loads on background threads. The reason I talk about caches in the video is because multithreading is powerful yet very confusing and crash-prone. I faced countless issues with offloading work onto background threads because I didn't understand the risks when multiple threads referenced the same memory.

There's also the fact that games don't recycle objects. Instead when you die. You clear everything. And reload everything. It's a quick fix. But sloppy programming

Caysh? :D I thought it's pronounced cash [kaSH]

It's "cash".

@Vercidium

5 ай бұрын

Next you'll tell me it's pronounced Australia, not 'Straya

@AlexTuduran

5 ай бұрын

@@Vercidium And of course, it's 'Murrica, not America.

mutex moment?

O look I have an super SSD I 23 processor and my PC can play games without needing to load... Like nice good for you but games that are made having 1p year hdd in mind need to know limits you can fake loads and stuff but it's not like you can load the entire game to a 4 gig memory there is a game with almost no load time and it doesn't give you no time to load (naraka bladepoint) I use this game to benchmark my server I run the game directelly from my server. Every time a new enemy with new effects or skins or a new skill is used I get for 2 seconds or something 5 fps because the "hdd"(server) can't load in time the animations and particles so yes really good idea but wen developing have in mind not everybody has NASA PCs at home

Legacy of Cain: Soul Reaver laughs at your outdated and laughable attempt to surpass it, 25 years later.

@Vercidium

5 ай бұрын

Just checked it out, that is a super smart loading system

first time hearing "Kaysh" for cache

@zoeherriot

5 ай бұрын

Hah hah - I use it all the time. I think it’s an Australian thing, because all my US coworkers always say “what on earth is a kaysh?”.

@artemonstrick

5 ай бұрын

@@zoeherriot we all know the right pronunciation is "tscatsche"

@zoeherriot

5 ай бұрын

@@artemonstrick you’re right… :)

Kaysh???

"cache" is pronounced like "cash" not "caesh"

@Vercidium

4 ай бұрын

*Australia has entered the chat*

Cache coherency is a problem that is handled completely by your hardware and is not a problem that is visable to the programmer unless you do some extremely low level development on specific embedded systems. I feel like this video being based around this concept as a whole is very misleading as the solution for the problem is not actually solving the problem that is presented. This has much more to do with instructions that might be called in different order or asynchronous loading calls which will update the boolean before reading from the disk has been finished, causing the program to use data that is not initialized properly. You obviously put a lot of work into the video and I like your other videos but my honest take is to pull the video down to revise it. I feel like if your goal is to educate game developers on good practises and for them to understand problems at a deeper level to make more robust solutions, this video is very counter-productive to that goal. There are obviously people in the comment section that noticed this also. If this was a longer video and this was just a mistake, it wouldnt really matter much but seeing as the whole video is prefaced with cache coherence as the problem, it feels really weird to not bring up and question the information being sent out.

Kaysh

Braid didn't have a loading screen

Games need loading screens.

I havn't heard anyone pronounce cache that way, I think the a in cache is the same as in "apple" usually. I don't think there is a correct way to pronounce anything but just wanted to inform you just in case.

@zoeherriot

5 ай бұрын

It’s a common way to pronounce it in Australia.

@DemsW

5 ай бұрын

@@zoeherriot Interesting, I don't have much experience hearing australians, thank you

@zoeherriot

5 ай бұрын

@@DemsW we have a lot of weird pronunciations. :)

sounds like async

**cough** portal 2 **cough**

What I find amusing about games is that they spend most time actually loading from disk, no NVME is fast enough as RAM is. Come on, I have 64GB of RAM, just map the game file to RAM so Windows can just load it once and keep it there forever (people complain Windows 11 uses too much memory, but that's what its there for, speeding up disk access) Game only needs like at most 8GB of RAM with user data (at least those with static geometry), it stupidly spends time swapping things from disk to RAM over and over again every loading screen. I hope with initiatives like putting NVME on GPUs, games can stop doing that and just get rid of loading in the middle of the game-play after you open the game for the first time, if you only play a couple of games that can fit it, no more loading screen ever.

@Vercidium

5 ай бұрын

I never considered putting NVMEs on GPUs, that's genius

Caysh

caysh

All in all, learn how to thread stuff properly. Pretty much everything can be threaded.

My life is a lie.

keich

"cache"

Bethesda hates this one trick, find out more link in bio. Bethesda needs to learn that everything doesnt need a loading screen.

why are people saying that australians say kaysh? like there isn't hundreds of videos of australian geocachers saying cache as cash. just admit the video is mispronouncing it, it's not a big deal.

@hemerythrin

5 ай бұрын

True, everyone knows there is only one way any word is pronounced per country. :) (If you open up Wiktionary you can see it list keɪʃ as a valid Australian pronunciation)

@Portponky

5 ай бұрын

@@hemerythrin dictionaries aren't even real

@Vercidium

5 ай бұрын

I admit it, those hundreds of videos are mispronouncing it

@Portponky

5 ай бұрын

@@Vercidium now that's a stance I can get behind

third

nineteenth

std::mutex

███▒▒▒▒▒▒▒

I'm stun locked by the way you pronounce 'cache'

keish

I hate the way you say cache

@Vercidium

5 ай бұрын

Cache me outside, how bout that

The explanation around threads it's absolutely abismal and misleading, it simply ignores the reality. And show the extreme ignorance behind the actual possibilities. If you have X threads reading and operating on the same chunk of memory it's just matter of using the appropriate mechanisms, including atomic operations which GUARANTEE data coherency......as well a smart use of volatile and memory barriers will provide the same level of guarantee with even better performances.... If you are aware that you need to expand the memory your algorithm should be built with that in mind and use, as silly example, a list of arrays as underlying data structure so that you still have large chunks of sequential memory, which is great for the cachelines and allows simd operations, and at the same time if you really need to grow you add a new large chunk as a second block and with some metadata stores at the beginning of your data struct you keep track of the number of blocks, their pointers, the space available, etc. Also with minimal changes the same approach can provide a simple reservation logic so that you can hold a chunk of memory to be used and let other threads do their stuff afterwards... Moreover, you can use mmap to allocate hugepages to reduce tlb misses and you can internally cache the pages or hugepages for future reuse to avoid paying the price of the initial allocation. I would really just throw away the video because it's just full of terrible infos....maybe I would save just the last 2 minutes...

finally skippable loading screens...

Soo just learn Assembly

I fuckin HATE how you say cache. Ive literally never heard it pronounced that way in English

@Vercidium

4 ай бұрын

Haha before posting this video I didn't realise there was another way to say it

kaysh