📦 Download the Example Project at www.patreon.com/posts/34702445
@danielyu30104 жыл бұрын
Great video! But I think you actually forgot to set the allocation to persistent.
@isaacsurfraz38584 жыл бұрын
Your presenting style and overall pace has gotten miles better since a year ago. Congrats on the great progress!
@Rytech_Dev4 жыл бұрын
Is there a way to cancel a job system mid execute
@hamzarylan78953 жыл бұрын
i guess im asking the wrong place but does anybody know a method to get back into an instagram account..? I was dumb forgot my account password. I love any tips you can offer me.
@jessekenzo87003 жыл бұрын
@Hamza Rylan Instablaster =)
@happyfarang4 жыл бұрын
Great stuff. I need to watch this a few times but i can see a future where i can master this now - and yes, more on the issues that we will bump into is welcome in future videos
@RussPainter84 жыл бұрын
There was a live stream the next day which goes a lot slower and deeper into why things are happening.
@magnusm42 жыл бұрын
Next step will be mastering how to set linear code on the GPU rather than on the CPU.
@robelso56462 жыл бұрын
Absolutely stunning tutorial! I'm so grateful there are developers like you that take the time to make such polished tutorials!!
@OTadashi1624 жыл бұрын
It's great to have a real world usage example. I haven't tried JobSystem yet, but looks awesome how it's easy to improve the code.
@ruslan_yefimov2 жыл бұрын
Just asking.. Have you tried it for the last 2 years?)
@XZYSquare4 жыл бұрын
you overwhelmed me with the intro and I know what that stuff means.
@Sarkahn4 жыл бұрын
Great video! A couple things though, at 7:55 when changing the data in the NativeArray, it's not really right to describe this as a "quirk of the job system". You're changing a value type inside an array, you would need to read the data, change it, and write it back to the array, regardless of whether or not you were inside of a job. Also typically with this setup you would want to schedule the jobs inside Update then call complete inside LateUpdate, this way your job actually has a chance to run in the background while other things are happening instead of just immediately blocking the main thread until the job completes.
@RussPainter84 жыл бұрын
Interesting. Could you complete them on the next update? Or is that just getting crazy?
@Sarkahn4 жыл бұрын
@@RussPainter8 You could! You could even wait for the job to finish on it's own before completing it, but obviously in those cases the results of the job would be one or more frames behind what the player is seeing, but that might be fine depending on what you're doing.
@dreamisover98134 жыл бұрын
Nice video - by the way, the job system example video you did back in 2018 I believe was one of the most helpful videos I found to get my started with the job system back then :)
@wes54574 жыл бұрын
Amasing video , your capacity for explane all simply is hight. Gracias.
@zendsub82882 жыл бұрын
Thank you so much! Very clear explanation of how these systems work and use in real cases.
@ristopaasivirta97704 жыл бұрын
Love your presentation and examples. Just the right amount of theory and practice. Keep rocking hard, dude!
@stefans65574 жыл бұрын
Yes, this looks very interesting, as it seems to be not too complicated. Will have to watch it over and try on a small example, before using it with a more complex project. But I am quite sure, I can get this running. Btw. if you schedule a job in Update() it is recommended to complete it in LateUpdate() (schedule early, complete late). PS: what I like about it: the real update code doesn't have to be in the Job itself, but can stay somewhere outside and be just called from the Job.
@modernkennnern4 жыл бұрын
I tried using full-DOTS on my first ever game. It feels very nice and intuitive at the start ("This object can move straight forward, can rotate on the X-axis"), but if you're getting somewhat further than just a basic level then it starts getting very difficult to know how to proceed. I scrapped that entirely after about two days and tried a standard approach. I occasionally get that itch though, you know
@carlosmspk2 жыл бұрын
You should try going full-DOTS for multiple projects, rather than working on a single project and trying to correct it. As you do things a particular (bad) way, the patterns will start becoming intuitive to you, and for each new project you'll find yourself coding things differently off the bat, simply because you know what you'll need later, what's useful in what layout, and how it should be structured. That, or, of course, follow tutorials...
@johnwarner55884 жыл бұрын
Man, these are great! You've got a good sense for brevity. You cut to the heart of an issue and explain it simply and quickly. I have to rewind a few times to catch up with what you did, but.... I can do that, because... ya know... it's a video. This might be one of the best video tutorials I've ever seen.
@ashtwenty124 жыл бұрын
Should have just had calcution for, number of Tennants * random number. Or randrange(12*tennentsCount, 24*tennetCount). Could also add some noise by adding randondom int, 1 to tennentCount
@JuniorDjjrMixMods Жыл бұрын
Very nice and simple, I just think it should make the comparison a little fairer. A part of the performance didn't come from Jobs, but from the fact that you only have 1 Update method instead of many. I'm starting to learn System Jobs and I already optimize my codes precisely by avoiding several Updates, using a Manager for this and the performance improvement is very good. You could have shown Manager performance before Manager+Jobs.
@Kolyasisan4 жыл бұрын
8:38 meow
@InfallibleCode4 жыл бұрын
Lmao good ear 😹
@noodle-eater4 жыл бұрын
Awesome dude, love all your videos. I start to understand the ECS by watching this video of yours.
@MQNGameDev4 жыл бұрын
Thanks for explaining this so well. You rock Charles.
@diplodocus34 жыл бұрын
Great explainer! thanks. Clearly you're set to be the best channel in the segment on YT! Some off-topic questions though, what's your desktop resolution and why do you prefer intelliJ over others (I can already see some reasons)? And would it be a good idea to use this functionality for certain things on my production ready app for the Android platform?
@InfallibleCode4 жыл бұрын
Thanks for you comment! I have 4K monitors and I run them at the highest resolution, but I typically increase the font size and zoom of all my applications by 125% - 150%. I come from a Java background and have been using IntelliJ for years. Rider has so many great features and Unity integrations that I don’t think I could possibly go back to VS lol And I wouldn’t suggest using the Job System in production until it’s been verified. You never know what could go wrong.
@diplodocus34 жыл бұрын
@@InfallibleCode that's a clear answer, thanks!
@diplodocus34 жыл бұрын
@@InfallibleCode Just tried Rider and mind has been BLOWN. VS looks ancient. But it's paid and I don't earn yet lol *sad face*
@Gildar764 жыл бұрын
Great video. I tried something similar a while back, and used a dictionary to map things back to game objects. It fellt like a few extra steps to take and a few extra collections to fill, but it was still faster :)
@erz30304 жыл бұрын
Marvelous video and topic Charles! Very well thought out and crafted as usual :) Keep up the fantastic content, cheers!
@Wobling4 жыл бұрын
Another great video, short and sweet. Thanks!
@RecOgMission2 жыл бұрын
Thank you so much - this exactly what I was looking for!
@alexandrebrownAI4 жыл бұрын
I'm a little bit on the fence about this new job system. It looks like it would require all the layers of the application to depend on Unity. It also requires a very strict and prominent structure. It's not very intuitive compared to modern asynchronous solutions. Something built-in to the language like async await looks more interesting to me even though it might not be as performant. This Job System seem like a lot to digest and forces you into marrying it... We shouldn't have to make these comprises in 2020 as Kotlin, Go, C# all have a way to write async code in a synchronous flow where you just write code like you would in a synchronous manner.
@IAmRyunis4 жыл бұрын
Keep in mind that the job system and async/await solve different problems; asyncrounous != multithreading. The job system is designed to compile to highly optimized, parallelizable native code. Of course that's not always necessary, so using async/await in other cases is completely legitimate. UniTask is a great plugin for async/await support. Be careful though, async functions in Unity always run on the main thread by default.
@lorencebuzon50232 жыл бұрын
async Task; however, already handles the Thread Assignment for you. Use a for loop or a for each loop on a Task
@entertainmentoverloaded57003 жыл бұрын
the only video i understood from this channel... most other videos are un-understandable
@scififan6982 жыл бұрын
that simply means you're not the target audience and you need to read more before coming here. What he explains is usually pretty basic stuff really.
@entertainmentoverloaded57002 жыл бұрын
@@scififan698 Fan dog spotted!
@zeejenkins4 жыл бұрын
You forgot to change the Allocator to persistent
@daviddesvaux97863 жыл бұрын
You don't want to dispose at the end of a method that is likely to throw exceptions, you should use a "using" block.
@syriuszb86113 жыл бұрын
Yeah, the jobs system with burst is a very powerful tool. The description under the burst is a huge understatement. It can increase performance even on order of magnitude, for free*. I'm wondering, why it is not accessible outside of jobs, maybe some day. It's easy enough for me to write jobs, but until it goes out of preview it's hard to use outside of "just testing stuff out". Also, I know it was a year, but you showed that you moved the code, but basically- it could not work at all, and we would have no clue. It would be nice, if you for example have power displayed and we saw that the total power before and after changes are same. I know, it's just example code, but still, until I have read the code few times and scratched my head I was not sure. Just because you added the power and did not reset it at new frame- that's no longer power, but energy! So yeah, I was wondering about that for a little too long. *the only cost is that some functions are not available.
@regulargamer19914 жыл бұрын
thanks for sharing! this ain't pretty but could get someone out of a tight spot.
@crazyfox552 жыл бұрын
I also think you should point out that taking a summation over a set of uniform random variables is the same as the Irwin-Hall distribution. From what I've read any summation above 12 tenets would be equivalent to a normal distribution. Therefore you could easily simplify this code. Even if this is just a side example.
@CreeperSlayer3654 жыл бұрын
This probably could do wonders for big AI battles
@JimJakubJames2 жыл бұрын
Great example!
@pudgystump2 жыл бұрын
This is pretty awesome.
@wazatojanai63334 жыл бұрын
Please continue doing DOTS stuff.
@noptanakhon66504 жыл бұрын
Very good example Thank you
@Spherous4 жыл бұрын
It would be safe and more proper to wrap the code and the dispose in a try finally or a using statement.. That way if something throws, you can guarantee that you don't get a memory leak. 😊
@InfallibleCode4 жыл бұрын
Thanks for the tip! I’ll mention that in tomorrow’s stream 😃
@AaronStatic4 жыл бұрын
Just fyi... the Burst compiler doesn't support try..finally and using
@EnriquePage914 жыл бұрын
This would be better said on a video rather than on a stream though! Maybe add some annotations to this video about it? Although we also have to consider the last reply here stating this isn’t supported by the Burst Compiler.
@marksmithcollins3 жыл бұрын
try statement is so much performance heavy.
@r6scrubs1262 жыл бұрын
@@AaronStatic which part of this is using the burst compiler though? I would assume if anything its only the code inside the jobs that is using it, so using a Try/Finally or Using statement in the part that is just scheduling the job might be ok? Can't seem to find much documentation on this
@snipe_irl4 жыл бұрын
Production quality is really good. Although I wish you'd explain new concepts for dummies. Sadly you didn't really explain in this tutorial, rather you read out loud what we have to type. I wasn't able to take away as much, as the concepts you used in the Jobification step weren't explained well.
@presidentmariachi42874 жыл бұрын
DOTS is not for dummies.
@magnusm44 жыл бұрын
@@presidentmariachi4287 NOTHING is for dummies, but it's not about being smart or good at it. You must always start everything from the basics. Just cause you're good with machines doesn't mean you can immediately start working on a nuclear power plant or space rocket. You need a base introduction to the mechanics and functions of everything so you know what everything does, how and why.
@rocksfire43904 жыл бұрын
@@magnusm4 i agree. isn't it weird that people just expect you to know everything? everyone starts from the basics and works their way up, that's the entire point of tutorials!
@mistermotomax4 жыл бұрын
Yeah, that's why you have to learn the basics of Unity first. For me, he was too fast in explaining the problem, maybe this helps: the scene has 65 buildings which do their update functions, this is expensive (65x update functions *one after another* ). Job system means 65 update functions *at once* (under optimal conditions).
@presidentmariachi42874 жыл бұрын
@@mistermotomax N0 NO NO NO... You have to explain everything cuz entitled!!! REEEEEEEEEEEEEEEEEEEE!!!!
@irybas4 жыл бұрын
You are incredible! We wait for the next great video :D
@rubyrails23294 жыл бұрын
Very helpful !
@mastermati7733 жыл бұрын
12:25 Why did you use TempJob instead of Persistent allocation even though you disposed the array on destroy?
@IdeaToGame3 жыл бұрын
He said that we'd need to change it to persistent, so I guess he just forgot to change it during the recording
@mastermati7733 жыл бұрын
@@IdeaToGame Yes, but as I remember lifetime of TempJob native collections are 4 frames. After that time you got an error that you haven't disposed them. Btw I stopped caring. I pre-allocate everything in my projects, even managed objects, so... I don't care anymore xD
@scififan6982 жыл бұрын
@@mastermati773 this is the right reflex indeed (assuming you can spare the memory): keeping a stable memory footprint and minimizing the usage of the garbage collector is the way to go for optimal speed. Re-use and pooling of objects is the way, instead of creating and destroying objects, etc. Even readonly List and such, with sensible capacity pre-allocation is a good idea, because it's way faster to .Clear() a list which is already in use (internally, it is just resetting the Count and keeping the Capacity anyway, so the memory will be re-used next time without re-allocation), than it is to allocate memory and stress the Garbage Collector. These old-school techniques are still relevant, also in managed languages, especially in games but also in industry high-speed algorithms. Also, the data cache benefits from contiguous memory usage, so keeping a tight memory footprint helps your application to keep good performance, instead of fragmenting memory by numerous different-size re-allocations. Only in low memory conditions and embedded systems, or on systems where memory is precious because of many concurrent processes or threads you don't want to starve out of memory, it is not a good idea.. but hey, in a game, you don't really care what other processes are doing anyway. Many mediocre programmers don't realize this until late in their project, and then they have to refactor their project for more stable memory footprint and linear memory access, which brings them great pain, so it is worth the attention to realize this from the start of a project!
@kokizzu4 жыл бұрын
what if the number of items to be processed dynamic?
@EnriquePage914 жыл бұрын
You know what would be killer? A video of the shortcuts you use the most for Visual Studio... you damned Keyboard Warrior 😂. (It’s for realz tho, pls)
@TommyTheITGuy4 жыл бұрын
I think he's using Jetbrains Rider.
@peny19812 жыл бұрын
Can I use this for Tcp connections, instead of c# threads/ tasks ?
@gamedevmode4 жыл бұрын
This is great stuff...but this very issue can be solved by having one manager With Update method and that will Call the Update1 Method for Every Building instance. But it's always good to have multithreading 😀
@crazyfox552 жыл бұрын
This would take the same amount of time as the original implementation because each update would run one after the other.
@scififan6982 жыл бұрын
@@crazyfox55 not really, it would actually be pretty fast, as there is less calling overhead in a simple for loop over consecutive memory than there is over framework code calling methods of objects spread all over the managed heap. A for-looped single threaded implementation over a consecutive array or contiguous list would probably would end up somewhere in the middle between a typical MonoBehaviour implementation and a job implementation. unless the optimizer does a very good job, of course.. then all bets are off and it becomes case-dependent. lol
@andriy_z Жыл бұрын
Nice!
@JohnVanderbeck2 жыл бұрын
Sadly this design patter -- which seems simple enough -- doesn't appear to work anymore? You can't run IJobParrallelFor on a Native collection unless you mark it as ReadonOnly, at which point you can't modify the data like you do in this video :(EDIT: I stand corrected. This pattern does still work as long as you are using NativeArray to hold the items. It does not work with a NativeList)
@greendino58683 жыл бұрын
How dots system fare now in 2021, is it really okay to go to that direction completely??
@RussPainter84 жыл бұрын
At 12:14 you mention changing the allocator to Allocator.Persistent, but that doesn't happen in the code we see on line 17. I'm wondering why it's still working with this array that shouldn't live very long?
@chronowalker18894 жыл бұрын
am i the only one finds keystroke sound very soothing xD
@miguelangelgalindo31242 жыл бұрын
will this way to return data from a job work with any object? I mean if tentants or PowerUsage were something different than an int. I need to return a Texture2d
@Jaqopx4 жыл бұрын
That was awesome.
@ultimatesin35442 жыл бұрын
Thanks a ton for showing how to minimize use of the new operator and reusing the same job struct, I've been looking all day and it seems like nobody else even considers doing this even though the whole idea behind jobs is to increase performance.. Thanks man.. Also just a question - OnDestroy isn't guaranteed to be called on mobile, and the doc for that method says to use OnApplicationFocus(bool hasFocus) for retaining data, etc... so should we be disposing (and then recreating) the NativeContainer there instead? Man you have no idea how hard it is finding basic stuff like this lol.. Thanks for the vid!
@ultimatesin35442 жыл бұрын
Oh btw - my question with mobile.. if we are disposing/recreating NativeContainer outside the scope of the running job.. doesn't that have the potential to break the job if it's still running when the app loses focus? I wish there was a simpler way of handling this stuff, thinking about just using the C# async/await...
@johgranger13043 жыл бұрын
FEEDBACK: I downloaded the project and there are missing scripts on multiple game objects. Also had an issue with using declarations because you don't show it at the beginning of the video so I couldn't get the Jobs interface to work.
@qwendolyn54212 жыл бұрын
You didn't change the allocator from tempjob to a permanent one
@scififan6982 жыл бұрын
indeed.. he said it, but didn't do it. oh well, a slight sloppy blemish on an otherwise rather good tutorial.
@sandsoftimer4 жыл бұрын
Awesome but if i have thousands of joint (For example: Fixed Joint) which is using physics update then how can i tell to calculate physics using Job System. Is there any possibility to calculate Fixed Joint through Job System. Sorry for my English.
@ibrahimAlbayrak0 Жыл бұрын
hello, I was going to use job system in my project, but I realized it didn't work. I used the example in your video and saw that the job system was working, but this time, when I deleted the math part you wrote, I saw that it didn't make any difference. So then why did you write the other codes? Does the job system only work for the math library?
@rani6004 жыл бұрын
I'm not completely sold about the job system, it seems like it complicate things code-wise, and only good to use in specific scenarios, such as rougelite games and such. anyways, great video as always.
@TheAndrejP4 жыл бұрын
Well, yes and no. Is writing code using the job system and jobs harder than writing a MonoBehaviour and dropping it onto a prefab? Yeah, a bit. But keep in mind when you'd be using the jobs system in the first place - when you have to multi-thread your code, which is when you're hitting performance bottlenecks. So if we start under the assumption that the scene contains a large number of instances of the same prefab with a MonoBehaviour that does some non-trivial, but not insanely complex amount of tasks in Update, which due to the amount of the instances is causing performance issues you will have to optimize. This could be anything from flocking behaviour of animals to randomizing events in the environment, characters and cars moving through a city GTA-style,... it's certainly not limited to roguelikes. The first thing I'd try when optimizing something like this - presuming I'm not doing something stupid like performing unnecessary tasks within an update of an object with a large amount of instances in the scene - is multithreading. So if you've got to write multi-threading code and the alternatives are just writing your own system that spreads out the work among multiple threads and using the job system I can with a great deal of certainty claim that the job system code will be far less complicated than anything that even begins to resemble a sturdy multi-threaded solution.
@milanstevic84244 жыл бұрын
@@TheAndrejP In fact, without the job system, you wouldn't be able to do anything multithreaded and related to gameobjects, because unity wasn't thread-safe to begin with. this is the only way to actually use multithreading in the core unity functionalities.
@petrosgiannopoulos1122 жыл бұрын
Very nice, and clean demonstration! One issue i find with using Unity Job System is that you have to have inside the Data struct fields in the simplest forms (int, float), but what if I am using an object of another class that has different types in it as well. Is there a way to include those without the unmanaged issue?
@DutchyChannel4 ай бұрын
A part of me is struggling with the fact all of this has to be done with structs, even though it makes sense in the context of what jobs do. The struggle is with how when you make changes to a struct, the entire struct is copied; with structs with a bit more complexity (more properties) this seems like such an inefficient method. Are my concerns valid, or is there something I'm overlooking here? Or is this copying not actually as 'heavy' for the processor?
@monkeyrobotsinc.98753 жыл бұрын
i dont get what the buildings are calculating. are they being created procedurally every frame? or what. is there no LOD?
@SchalaArchives2023ish3 жыл бұрын
Is there anything in the code preventing the use of Burst? Enabling Burst will optimise this even further.
@ewwitsantonio4 жыл бұрын
I'm a bit of novice programmer, so bear with me: Could you use the Job System to make SQLite database calls? I'd love to have a simple way to query a local database in a game but not have the main thread hung up every time I make a search. Imagine there's an in game Encyclopedia (all set up locally w SQLite), and I want to give the user an ability to search in game, without killing the frame rate. I've done some multithreaded code but it feels rather complicated for my current skill level. Thanks for the great video! Really helpful and well produced content.
@osten2223124 жыл бұрын
You can, but it will not prevent disk lookup locks, and is a bit overkill. Your example is better done in a worker thread as it is not a batch job of several instruction, just a main thread lock. It is easily solved with a coroutine, and does not require the job system.
@magnusm44 жыл бұрын
The main issue I can think of is implementing the open and close principles and other techniques into a system so reliant on splitting everything up and be so specific about every little detail. This is something that is bad in game design as simplicity is the key to versatility such as calling the interface function OnFire for example.
@Ayushmaan_Singh77 Жыл бұрын
Its just a doubt .....How can we instantiate GameObject using job , if its possible
@magnusm44 жыл бұрын
I imagine this job system will give the ability to have large open worlds with lots of living entities such as colonies of a species that live together, far less games with lag or performance issues and can focus more on just making the game they want, more complex mobile games and the ability for more people to make large scale strategy games. And of course I predict NONE of this will happen and it's potential will be wasted, as usual. Looking forward to the threads of people's creations with it tough
@burakgok29094 жыл бұрын
Hello, I would like to understand one thing clear when we use the job system its blocks the main thread ( main thread has to wait until the job gets done) right? It's similar to using thread.join( ). I want to know what is the reason for blocking the main thread since it will make the application unresponsive? why they don't work concurrently? Thank you for the tutorials.
@excellNexcel4 жыл бұрын
Unity can't even get finalized documentation (or any for that matter) on DOTS for the developer. Each iteration of DOTS is different from the previous version. Yes, it is more performant by default, and when Unity has a finalized version in about 2 years, then I will make the greater concerted effort to learn it
@ashfid89874 жыл бұрын
I enjoyed this really. Very simple and effective. But, what about raycasting? Maybe 1000 enemies raycasting? Do we use ECS’s raycast or we can use normal raycast?
@marcolozano13484 жыл бұрын
Hi @Infallible Code, im one of your new subs and i have a question. We should use Jobs for every class which repeats itself in the same scene right? For example an enemy script. I should then create an enemy manager and so on, right>?
@bruninhohenrri3 жыл бұрын
How to do it when your "buildings array" is dynamic ? I have a list of chucks that are always generated when the player moves, i want to use a job to generate the mesh for each one of those :)
@fernandodarci3 жыл бұрын
You are using List for vertices, List for uv mapping and List for triangles, right? Convert those lists to float3, float2 and int, fill the native array and do the calculations. After this, simply put the data into mesh (out of the job) and done.
@98josemam4 жыл бұрын
at 8:43, why you change int for var? I though that if u specify the class it was more optimized
@IAmRyunis4 жыл бұрын
He simply changed it for aesthetic reasons. In any case the "var" keyword is just syntactic sugar anyway, so you don't have to type out long type/class names. Since C# is a strongly typed language the compiler is aware of the underlying type at all times and result in exactly the same compiled code.
@98josemam4 жыл бұрын
@@IAmRyunis Cool, thanks
@Obyvvatel3 жыл бұрын
Don't you need to do something with the data after the job is completed? Like, wouldn't you need to pass every struct of BuildingData back to the building, since it's not by reference?
@simonchen6698 Жыл бұрын
Sorry late reply, but I believe this is the exact point he was trying to make at the end of the video. Using a Dictionary would probably be the most performant, instead of having to do a nested loop iteration.
@manishotaval83164 жыл бұрын
Does the "Unity Job" work for mobile platforms especially Android?
@quanghong39224 жыл бұрын
You missed Burst Compiler
@codingjammer64034 жыл бұрын
The ECS seems to be already outdated: docs.unity3d.com/Packages/com.unity.entities@0.9/manual/ecs_creating_systems.html Its using SystemBase (less code needed) Or am I wrong?
@daviddesvaux97863 жыл бұрын
Is this executing on the GPU or CPU ? I thought the job system was all about the GPU. Is the job's code translated into some compute shader ? Because otherwise, if it runs on the CPU, then I don't see what thiss brings, cause this is almost as easily acheivable by handling threads manually.
@scififan6982 жыл бұрын
if you really think what you wrote, you clearly did not understand any of it. you need to read more, and assume less. lol
@shintarouemiya4 жыл бұрын
Off topic question but... why is your Unity editor looks so smooth?
@bilal12e4 жыл бұрын
Sir what Compiler are you using ?
@scififan6982 жыл бұрын
the one built into Unity. lol
@r6scrubs1262 жыл бұрын
Its a little worrying to me that you can't even generate a random number in one of these jobs using the normal method. Like yeah in this case there's a unity alternative, but are there other things you can't do inside a job and where there is no built in unity alternative?
@scififan6982 жыл бұрын
when you think about it, that's actually pretty normal and expected, considering the regular Unity classes were never built with thread-safety in mind, and would be burdened by such measures like locking, lock-free collection classes etc. It's actually not a bad thing there are separate classes for this, from a performance point of view, although as a programmer-user experience this seriously sucks and looks messy and confusing, I agree. Maybe in a far future, Unity programmers will consolidate, but I wouldn't count on it, given their reputation to rather build new features than to fix their old issues. lol
@eyezl38322 жыл бұрын
very clean walk through of job system, but video editing is a bit distracting, almost feels like watching an indian soap drama
@thepeacekpr4 жыл бұрын
Thank you very much for explaining this concept. I have a question. I see you using var most of the time instead of just typing the class name. Why is that? Any coding reasons or you just like them that way?
@milanstevic84244 жыл бұрын
because it simplifies and improves readability of the code. var can be used thanks to compile-time type inference, otherwise you still need to explicitly declare a type, if the variable isn't locally defined, contains multiple declarations, or if the assignment is ambiguous due to inheritance. in all modern IDEs you can rollover the identifier and inspect its type, so you lose nothing, but might gain a lot. more often than not, compound variable declarations/definitions already contain everything there is to know on the right hand side, leading to redundant and annoying boilerplates here's a common example Dictionary processingDictionary = new Dictionary(); can be written as var processingDictionary = new Dictionary();
@thepeacekpr4 жыл бұрын
@@milanstevic8424 Got it.
@scififan6982 жыл бұрын
another good reason is that anything which is 'var' declared, will not have to be touched when refactoring types, since it will automatically (strongly typed, so you lose nothing) follow along with the type. If there would be an explicit type instead of 'var' in your declaration, a type refactoring would oblige you to also visit that line of code explicitly, manually or by tool, introducing needless risk of errors. That's just more work for nothing, so var is clearly a win. Most people who are against 'var' in C#, confuse it with habits in less strongly typed languages like javascript and believe it will be slower in C# and such nonsense. They simply don't understand the C# language very well. Nothing like that is true: 'var' in C# is as strongly typed as any other regular old-school declaration, but without the keyboard effort. It is indeed syntactic sugar of the good kind. And to those who still use Hungarian notation and such, I have only a middle-finger message: grow up already, Hungarian notation is an antipattern and you still don't realize that. lol
@sommmen4 жыл бұрын
Hi! so in my daily life i work with normal c# and just started to do a bit of Async programming now .net core is here. Is async not supported in unity - and why should i use this over asyn? i also read something about coroutines which i suppose could do the same? nice and clear tutorial btw!
@MrCorrectify4 жыл бұрын
Coroutines run in the main thread, they aren't parallel. Unlike standard functions, coroutines can wait. This is just a convenience that allows you to do stuff like speed up your game by distributing heavy logic over multiple frames, as well as create otherwise complicated functions that require timing (wait 5 seconds, do X, wait 3 frames, do Y). Async is supported and has the same limitations as jobs. Jobs is basically an architecture built around async to make it more safe, simple, and design friendly (profiling stats, intelligent distribution and queuing, etc.)
@sukhmandersingh43062 жыл бұрын
@@MrCorrectify coroutines are for IO intensive tasks it cannot speed up computations
@TheUncutAngel3 жыл бұрын
your code editor is so packed full of random indicators that it makes it very very hard to follow along--and all I'm doing is watching. Consider yourinterface on this as something less frilly and easier to look at. Might look second nature to you, but you risk alienating the audience over something trivial. So far the hardest part of this tutorial is finding out where and what you're typing, and where exactly it gets copied and pasted. Everything else is very clear and helpful. edit: like at 11:50 you said you were going to create fields. And then you click some hotkeys and text is generated-and-cut-and it's like... where the hell do I look?
@yoyomario2 жыл бұрын
This isn't a correct example to show performance gain, since it's well known single Update() from "Manager" class is superior to multiple single objects calling Update() each for them selves respectively. So if you want to show a practical code example, and actual performance gain, first write code with good architecture and then translate into the Job system. You did a mistake here of updating the code architecture of executing and moving it to job system where we have 2 major changes for performance.
@watercat12484 жыл бұрын
That sounds great but is 1 big problem i have no idea haw to find jobs system code in unity
@anton.m.korshunov3 жыл бұрын
It's just a dream
@XZYSquare4 жыл бұрын
wait why does that 1:30 second intro sound like an ad? the way you accent every half a second is why i click skip on ads :p the rest of the video seems ok tho
@RemusCroft4 жыл бұрын
Weird, non-intuitive, full of limitations. I don't like it. It feels like crutch. It feels much more complicated than actual C# mutithreading. Designing something like that whilst main competitor push visual scripting as much as possible is pretty questionable decision for Unity IMO. Anyway, great video. thanks!
@milanstevic84244 жыл бұрын
oh somehow visual scripting is comparable to multithreaded solutions. wow besides unity has its own visual scripting. as if that solves the world hunger.
@RayHorn51280880562 жыл бұрын
Your demo was flawed even though you did make your point during your video. The code you refactored to run in the background should have been run only once when the game initialized and surely not for every frame. I know you wanted to make your point and most people would not notice what I just said. There was no reason to have a bunch of static buildings update themselves in the manner shown on every frame. Also a state machine could have handled the background processing but only when the state of each building actually changed. In other words, the best approach would have been to perform the initialization of the building data when the game started and only once then if the building's state related to the computation changed while the game was being played the data would be updated but only when dependent variables changed and not otherwise. Under no circumstances should ALL of any object be updated for each rendered frame and this was the bug. What you demonstrated would also "seem" to "fix" the issue because your fix was no fix because the underlying issue was that of incorrectly updating a bunch of static buildings when nothing changed. It is always possible and desirable to avoid using background processing whenever possible. Video game developers have been using state machines for many years because state machines are very fast and very powerful. State machines do not require background processing. I think if you wish to make a point about programming you should stick to real world situations rather than building a broken game just to make a point. Kudos for the efforts. You got me hitting the subscribe button.
@PocopoKids9 ай бұрын
Improve more easy to understand your video
@afrakes45103 жыл бұрын
Thumbs down. unnecessarily confusing. I've watched it a dozen times and still am perplexed about all the back and forth, doing something, then declaring almost done, then changing , then saying , See, it works!! .. naah man.. redo this slop.