Godot C# vs Unity C# and ECS - Comparing Game Engine Performance

[@Its_Myle]

Godot also has an ecs plugin if you want to test it as well, great video anyway

[@SmartPenguins]

I'll check it out

[@xeteorblaze]

what version godot does the plugin support?

[@Its_Myle]

@@xeteorblaze godot 4

[@illya_ike]

3D test will be nice to see too. While, if you are going to do 3d tests, please keep 2 sets of 3d tests with and without physics. Everyone is so obsessed about physics, but first, not every 3d game needs physics. Second, it is nice to know if the bottle-neck is in the physics engine.

[@madjunir]

Good idea

[@herol7058]

Damn didn't know Godot is actually this fast

[@madjunir]

Godot is actually lightweight in every aspect. Open source project are usually know to be light weight and efficient. They constantly get optimization

[@askeladden450]

Godot is not particularly fast by any means. There are faster engines available (although with less features). Its just that unity is olobnoxiously bloated and slow. As is unreal to some extent.

[@herol7058]

That is why we should all focus on contributing to open source engines, I wish godot will become Like blender

[@RenderingUser]

​@@herol7058it defiantly seems like it's going in that direction On another note, I'm pretty sure godot can now directly import .blend files

[@natecoley160]

@@askeladden450 well since we talk about transition from unity, beeing faster than unity is already good enough

[@edward3190]

This is great, getting ECS performance without writing ECS code.

[@sebastian6121]

is the updated net core backend, unity is still using old mono.

[@RealChairNotFake]

Something to think about in the future: FPS comparisons can often be very misleading, as FPS = 1 / frametime, which makes it non-linear and very difficult to compare.

[@foldupgames]

Thanks for doing that load testing and sharing results! That's very valuable feedback.

[@obinnaokafor6252]

C# is amazing. With the modern C# and dotnet support coming to Godot, the performance, simplicity and experience of developing Godot with C# would be amazing.

[@CayawareGames]

I mean, Unity's C# is basically a frontend for the underlying C++ game engine. For someone who works with dotNET, Unity's flavour of C# would probably feel like a different language, whereas Godot uses the regular dotNET SDK. Also, the idiomatic dotNET C# is all about interfaces, factories, and dependencies injection. In Unity, you still cannot make a serializable field of some interface type without writing your own hacky editor script. Unity kinda pretends to be a C# engine.

[@madjunir]

Interesting. Seems Godot is more C# than Unity and is why Godot 4 is waiting for Microsoft's official release of the SDK later this year to solve a couple of bugs.

[@PoorlyMadeSweater]

[SerializeReference] on polymorphic objects and [field: SerializeField] on properties will get you most of the way in most scenarios. When you really need editor visualization and refuse to write an editor script, there's also TextusGames's free UI tool, or just drop the 50 bucks on Odin. Side note, I think us solo devs often forget that Unity assumes half of your job as a coder is to highly customize the editor with specialized tools for your team of designers and artists. One mans annoyance is another mans feature in this case. Also, Unity's serialization is great in the big picture. I honestly can't think of an another editor that runs its scene editing mode in parallel with the running game while simultaneously hooking into a profiling engine. I can't really agree with the idiomaticness of dotnet these days. In the slow corporate world, sure. Maybe 15 years ago, sure. However, C# is very general now, and Unity is very C# now, even down to async/await support. Hell, half my code is functional, the other half uses the Actor model, and I avoid DI and Inheritance (two things I don't like) almost entirely. ECS is effectively a DSL, so I wont mention it. Your pain is real though, I feel it too sometimes. It really all just revolves around interfacing the connection between the main threaded "design time" editor API (mostly MonosBehaviours and ScriptableObjects), with standard "code time" work. I agree that it's annoying as all hell, but also if you work with any big framework in any language, you'll deal with workarounds and hoops to get your code to interface with their code.

[@souleymaneba9272]

This is not said enough. I don't want to use a very old C#/.NET version but the latest. I was surprise that Godot allows it while Unity is stuck with this very old C#/ .net framework mono based version

[@TheMoArtis]

You can totally serialize an interface reference via the [SerializeReference] attribute in Unity. I also don't see how the implementation of C# in Godot is so different. It's mostly an API to call the underlying C++ engine via native calls. Actually a lot of features in Unity are implemented (partially or totally) in C# (Input System, Cinemachine, Addressable...). Don't get me wrong, Unity deserves a ton of hate but that one is a weird complain.

[@levovix]

Amazing! Will be good to also test c++ performance in godot

[@SmartPenguins]

Thanks for all the comments, a lot of great points you guys are making, I'll try to provide more details on the test setup in the next video to answer all the comments. You can find the code here: Unity source code: github.com/smartpenguins/BeeTestsUnity Godot source code: github.com/smartpenguins/BeeTestsGodot

[@Antypodish]

Sorry but it looks like your ECS test is flowed. Are you biased toward Godot? Did you had burst enabled? Do you use multithreading? Which rendering approach id you use in Unity? I could run 50k boids school of fish example 2 years ago using older DOTS, just fine. And now I see, you barely run 10k in Unity ECS on screen? Something is defiantly wrong in your tests.

[@tompat9166]

Thank you for the good work, this is very interesting due to the current events in the industry.

[@CrimsonBlasphemy]

This isn't really a code comparisons. It's the whole stack. You should consider a few additions and run this again. Godot has split 2D and 3D renderers. Unity fakes 2D with its 3D. It would be good to see this done again, but with Godot 3D (use Sprite3D) and Unity set to 3D mode. Orthographic cameras. Which would give better comparison points about each stack. Also take a look at Godex (Godot ECS fork), for a comparison there.

[@mjKlaim]

Could you see if GDExtension with C++ and Rust have a big impact on this kind of code? That is just rewriting the script moving the bees in C++ for example. I suspect the boundary layer have a cost but it might still be worth it. (I'm experimenting with GDExtension these days)

[@sololeveling944]

great video, this will clarify godot performace for people who are coming from unity.

[@andrewm2048]

Without showing the code I am not sure if that is a good comparison. If you have 1 monobehaviour per bee that will always be slow - there are better ways to update 1000s of entities with regular C# code

[@iDerp69]

Yeah, I'm highly skeptical of this test. Something feels off, Unity should have no trouble running 10,000 bees at 60FPS. I've ran full 3D physics sims with higher numbers of objects more stable than this.

[@redstoneparadox]

There's a Unity game called Kingdoms and Castles and I remember the devs mentioning at one point that they had to make citizens into structs or something like that because of the performance implications. So, yeah, this isn't exactly a fair test.

[@saul8510]

​@@iDerp69ofc if you use compute shader, godot 4 has it too running millions of particles too.

[@SirRichard94]

In that case you would also need to start making optimizations for godot, and where does it end? I think it's a fair test of the base way one writes code before optimizing

[@ADarnSmore]

@@SirRichard94but, but! he didn't do this in godot! and he didn't do that in unity! and he didn't rewrite godot from scratch to be unity so they have the same fps!

[@muuubiee]

how are you managing to get so low fps with ECS? Even with 100k 3d object the fps will be higher.

[@natecoley160]

probably rendering issues

[@SMNtenshinoneko]

Love this video. It was informative and to the point 🎉

[@tales.sampaio]

Hi, great video! I wonder if you could profile it, instead of counting fps. I mean, it can be a GPU issue when comparing different engines.

[@Lua_Diurna]

that's good to know i want to make 2.5D games, so i'm already waiting for the next video 😇

[@paryonix3d6657]

I noticed you are drawing your bees in a rather small area of the screen. This can lead to a lot of overdraw which can impact performance quite significantly. If you want to compare script performance without the gpu/renderer interfering too much, I would either distribute your bees evenly across the screen, or draw them entirely offscreen - or not draw them at all. (Not sure if it changes any of the results in your test setup, but it is something to consider) Also as others have already mentioned, always compare frame times, not fps :)

[@davenirline]

This is a good point.

[@rameynoodles152]

whats the big difference in comparing frame times vs fps?

[@paryonix3d6657]

@@rameynoodles152 Because fps are not linear, they are calculated t^-1. If your baseline was 60 fps and you drop to 55 fps you lost approx 1 millisecond. Where as if your baseline was 100fps and you drop to 95 you only lost approx 0.5 milliseconds. So you cannot compare the loss of 5 fps in those cases with each other. Where as I can always compare when something takes 1 ms instead of 2 ms, than it is simply twice as fast.

[@mad_t]

Oh, and if you make comparison benchmarks like this it's a good pratice to publish a source code, so anyone could see that no black magic is going on

[@PolygonSquad]

Can you do Rust in Godot and c# in unity

[@riekumar6999]

Something feels very wrong with this test, I have had friends use ECS before and they were able to generate 100k's of objects without frame drops....but there is a struggle with 10k for yours. Are you sure everything is configured correctly or that you are using ECS correctly?

[@SmartPenguins]

ECS run pretty fast, I can run 1M bees at 40fps with Sprite Renderer turned off for the bees but as soon as I turn on Renderer for bees I get 30fps for 20k bees. Not sure if there is some setting that I'm missing or it's my PC, it's over 10 years old so maybe that is why I can't render that much.

[@oleyb123]

@@SmartPenguinscan you open source the projects so folks can inspect?

[@riekumar6999]

@@SmartPenguins My friend made a space shooter on Steam with a lot of sprites rendering from bullets, to collision effects, particles, enemies, individual stars and planets. It was blazing fast, so that's why I think maybe there was some setting missing maybe?

[@saul8510]

​@@SmartPenguinsso why sprite renderer not turned off?

[@freiaz494]

It is the PC, obviusly if your friends have a better PC they will experience less frame drops, in that case they should just continue the test until they see the framedrop

[@Victor_Js]

I have tried with NET 9 in Godot. Yes, NET 9 increases the performance of loops. Additionally, I have used pointers in C#, which boost performance by 50%, and I have used parallel loops, another approximate 50% increase. Then, in the compilation preferences of Visual Studio itself, I checked the box for maximum performance. This increases compilation time, but it doesn't matter since it's for generating user copies, and it further boosts performance by another 50%. Lastly, I disabled collision detection. The performance surpasses Unity by far! Simply spectacular!

[@BastiaanOlij]

Cool! I'm assuming when you run the game outside of the editor you're running a full release build and not a debug build?

[@SmartPenguins]

Yes, I have disabled debug option.

[@BastiaanOlij]

@@SmartPenguins Cool, just checking, I doubt it would make any difference in this example but the performance of for instance physics is night and day between debug and release builds

[@heavymetalmixer91]

Besides raw performance and calculations there's one key difference between GDScript and C#: GDScript doesn't use a garbage collector, but reference counting and manual memory management in some cases. This makes the game have way less pauses (or at least less noticeable) than what GCed languages like C# introduce. Depending on the genre of the game this may or may not be a deal breaker. For example: In a turn-based RPG these pauses don't matter at all, but in a fighting game (Street Fighter, King of Fighters, Mortal Kombat, etc) the pauses are HUGE NO-NO because how much the genre depends on frametimes stability.

[@ПошелНахуй-ш3и]

Garbage collection is not a problem at all, if u aware of object pooling

[@BanditLeader]

Not sure if you used godots default physics engine or jolt physics. But in the 3d test, you should use jolt, its known for having more performance over godots default. Or maybe test godot default vs godot jolt vs unity

[@madjunir]

2nd this

[@ManaGamesCom]

You didn't really compare the speed between Godot C# vs Unity C# ; however, you shown that with Godot C# and Unity ECS, the bottleneck is likely the rendering pipeline and not your scripts, and that with Unity C# the bottleneck is the scripts.

[@ПошелНахуй-ш3и]

So if we take all of this into account result is the same godot faster

[@Szmergolloth]

Really cool presentation

[@vishnuviswanathan4763]

Using a performance overlay tool like Intel PresentMon will give us more info also kindly add CPP to test suite

[@ChronoCZ]

How about you open source your test setup???

[@enzi_official]

There is something seriously wrong with your test to the point of misinformation. A while back a video got popular in the DOTS community called "Improved Unity DOTS vs Multithreaded Assembly benchmark" from Lingon Studios. He did a comparison of DOTS vs Assembly. In the video around 6:20 you can see DOTS is pushing 100k with 3.2ms which is 312.5 fps.

[@saul8510]

you talk like if everyone had the same pc

[@chaorrottai]

Industry needs to move to c++20, basically all of the reasons to use an interpreted language are gone in the modern day. Modern computers are fast, compilation happens fast, even for huge projects and the changes from c++98 to c++20 make coding in c++ just as easy, if not, easier than coding in c# or even python.

[@ribicb]

Good! I like C# better anyway - more powerful language, far better refactoring and code insight support from Microsoft editors and JetBrains Rider / ReSharper.

[@askeladden450]

Keep in mind that c# has limited support on mobile and web in 4.0, although that is being worked on.

[@mikolash8246]

@@askeladden450 I will be fixed in November :)

[@jesperpersson9388]

@@mikolash8246 It will be fixed upstream by Microsoft in November with .NET 8.0. I assume Godot 4.3 (releasing sometime early next year I imagine) at the earliest will be able to move to that platform. Godot 4.2 is soon to enter feature freeze and will release around the same time as .NET 8.0 so at that point it will be too late to put the changes into 4.2. Edit: I should say I'm just speculating here but this seems to be the most logical conclusion I can make.

[@YouTubsel]

Super cool. Please continue those Stress tests. Potentially also for more complex scenarios. *subscribes

[@PoorlyMadeSweater]

I dont buy it tbh. Right off the bat, is the IL2CPP compiler enabled here? Im very doubtful Godots high level C# can compete with Unitys low level C# to C++. JIT should really only be used on platforms with AOT issues or other niche cases. Second, is this using a properly setup URP (as it should) or is it HDRP/standard? Has the pipeline been setup for simple 2D performance? Are the resolutions the same, and is Unity also running compiled outside of the editor (Unity's editor is a serialization king, which adds a lot of overhead). Is your sprite setup done properly (no mips, point filtering, rect mesh, no physics shape)? Are you using an instanced unlit URP shader? On Unity architecture, its not a 1:1 map. MonoBehaviours are heavy. They have a lot of features and QoL stuff that make them ideal for a smaller number of heavy objects, but slow for larger numbers of light objects with deep hierarchies. Nodes are light, and good at the opposite. At a bare minimum, if the bees are all going to be GameObjects, they should be empty (sans a sprite), and should be animated by a single bee manager mono somewhere else, and ideally that manager should use Jobs and the burst compiler, which is specifically designed for this scenario. If I was going to do this for a core game effect (bullet hell or something), I wouldn't even give each bee a GameObject, I would use RenderMeshInstanced. On ECS...IDK how you messed that up but I was rocking over 1 mil animating cubes on my laptop. Outside of technique, when it comes to engine vs engine, Unity is a 3D engine with sprite and pixel perfect support, which makes it very powerful for 2D, mostly since its a breeze to make 2.5D games or mix in 3D effects, particles, scrolls, zooms, and etc, but that will never beat a raw 2D engine in raw 2D performance. If you need a 3D engine, you won't use Godot's 2D engine. I want to see this again in Godot's 3D engine for fairness. For the record, I believe Unity is the best engine on the planet in terms of out of the box power, flexibility, and support (although accessing that power is difficult for beginners). PERSONALLY, I use Godot for the same reason I use Krita, I hate the company that owns the competition (Adobe and Unity)...also F# rules lol.

[@GBSCronoo]

Wow, thank you for doing this.

[@AdemOmerovicBA]

4:40 GODOT multi thread features? Can you test that also 🙏

[@SmartPenguins]

I'll put that on the list, great suggestion!

[@IvarDaigon]

would love to see a rigid bodies physics test in both engines.

[@pete275]

Are these Godot bees each a node with a script, or a bunch of canvas items controlled by one script or a particle system, or what ? Makes sense tho since unity is like 50gb download and Godot is 50mb, there's found to be some overhead

[@SmartPenguins]

node with a script

[@mad_t]

lack of C# export to webgl is the only thing that's keeping me from switching overall script performance in godot is really impressive

[@BlackJar72]

I wonder what effect IL2CPP would have on Unity's performance.

[@SmartPenguins]

I ran this test with IL2CPP, for ECS there is no improvement but for MonoBehaviour there was 20% improvement

[@toolbuddy]

Which Unity build did you use, Mono or IL2CPP? For such scenarios having a large amount of moving objects, Mono can be quite slow compared IL2CPP. This even pushed me to publish a free Unity asset that optimizes Mono build. Its name is Frame Rate Booster.

[@saulsantos4132]

He uses ecs,so prob the later.

[@SmartPenguins]

I ran the test with IL2CPP, for ECS there is no improvement but for MonoBehaviour there was 20% improvement

[@saulsantos4132]

Good, then same or better performance than godot #, also you could try c++, multimesh or servers with godot for a fair comparison in the 3d stuff. @@SmartPenguins

[@VoonNBuddies]

You can also write scripts in lower level languages like C++. This is supposed to boost performance even further than C#!

[@Spiral_Arch]

It's good to see these results. Can you do a similar test but testing in a 3D environment?

[@arabhuzaifa]

Please do a physics test and also async scene loading test for streaming large scenes.

[@nickgennady]

We’re all those bees each there own node in GOSOT or are they all done in 1 Node using arrays for bee data?

[@SmartPenguins]

All the bees are their own node in Godot

[@nickgennady]

@@SmartPenguins wow that’s crazy to be ecs speeds.

[@puzzud]

Nice work! It's a pretty complex thing to test scientifically. There can be a lot of different factors that can make these test results misleading. But when we're talking 5000+ objects, a stress test is a stress test--so useful nonetheless.

[@KENISEG]

need compare with godex (ecs library for godot) c:

[@eduardomoura2813]

what's the point on comparing something that will hardly have any impact in the performance on a real case scenario WHEN just by setting 3 or 4 slight more detailed 3d models on my viewport will drop my fps from 40 to 15 with a good gpu?

[@weregruyere]

Would you mind sharing the Unity project? Based on your other video I believe you're generating unnecessary garbage and GC is taking up most of the frame time for ECS. On a modern machine it should be relatively simple to get a million bees at 60 FPS with ECS.

[@akuno_]

Could we get the project files to better understand the setups?

[@谜之铁皮]

Was the built of unity il2cpp-master?

[@Kilakilic]

Would be nice to tackle micro stutter in godot, as it can feel laggy even with one moving object

[@chutneyio]

As another comment has pointed out, the math in Godot for square is faster than in Unity (circle). I conducted the test myself with objects distributed randomly and obtained the opposite result. In Unity, I could handle 5000 objects before a framerate drop, whereas in Godot, it was only 4000, and it decreased to less than 10 fps with 5000 objects. If you don't believe me, just try it yourself; don't let others mislead you. Remember: Add all of the objects in one loop and not do any math at all in Update, we are only test the internal C++ performance of both engine, not the C# part because Godot .Net Core is faster than Unity Mono.

[@kooostia16]

But its the point of this video, compare c# performance and gdscript, not core performance

[@chutneyio]

@@kooostia16 Why need to complicated things when you can just compare mono c# and .net core c#, and there are plenty of it already. Beside, this video makes it looks like he is comparing performance of the engines, just read the comment section and you will see many people claimed that godot is faster.

[@MrXlee1967]

Please do a 3D test. personaly i dont think godot 4.2 is ready for 3D, its missing a few basic things that i hope they will be putting back in. But wont know unitl i see the road map for 4.3. im a noob so i could be wrong but people say "IK :Inverse Kinematics" is missing and still wont be in 4.2. with IK missing can you still make a 3D game? can anyone clear things up for me? Thank you

[@redstoneparadox]

Godot does have IK, but it looks like it may be only for 3D? I dunno, it seems like the 4.X docs are still heavily being worked on.

[@MrXlee1967]

@@redstoneparadox I thought it was removed because of bugs. I must be wrong. To be honest I'm only interested in learning and using 3D. There's a lot of material in 2d for godot but very little in 3D. Just don't want to go down learning godot to latter find out it can't handle the project or its got too many features missing that unreal has built in. Any advice is most welcome

[@saul8510]

​@@MrXlee1967they use the 3.x ik for 3d, 2d uses the new one brought into godot 4.

[@jfkenz2713]

is the unity ecs using burst?

[@Antypodish]

Most likely it doesn't by looks of the test. There is something wrong with the performed ECS side test of Unity. I was able run on my mid end machine 2 years ago 50k fish with no FPS drop below 30.

[@محمدالجوادجعفر-ج3ض]

Use jolt phyics in the next video default godot phyics is wired and hight impact on performance

[@lawrenceredmacher4382]

how would circle be more calculations than square?? with circle all you're doing is checking if the object is a distance away from a single point. with square you have to check if the object is within four different points.

[@kooostia16]

In square you just check coordinates while in circle you also need to perform math operations before checking

[@DanielMircea]

Hard doubt this comes even close to unity ecs performance.

[@illya_ike]

I'm curious, why Unity's bees look different? Is it the same sprite?

[@saul8510]

if 3d and you use physics make sure to add jolt physics too.

[@marko95g]

Would be great if you use c++ in third test :D

[@SmartPenguins]

The bottleneck is in rendering and how the nodes are handled but I hoping I'll get some time to run the C++ test as well

[@CPalanysamy]

impressive that godot can beat unity's ECS in this instance

[@pity4657]

always on a test give your pc specs

[@SmartPenguins]

I have the PC Build list in the video description, www.amazon.com/hz/wishlist/ls/BE5JB7KV4D0Q?ref_=wl_share&tag=smart-penguins1-20

[@jlewwis1995]

I think unity will win the 3d physics performance test, I don't think godots 3d physics is as optimized as unity, I remember watching a unity vs godot 3d physics video before with falling rigidbodies and unity was quite a bit ahead though iirc that was for 3.x not 4.0 so maybe things have improved since then

[@jlewwis1995]

Oh yeah and if you're going to be doing a lot of mesh spawning in the 3d test make sure to use multimeshinstances instead of meshinstances because meshinstances don't get batched like multimeshes do

[@TheLemonify]

You are correct. I've actually tried to convert my game which relies on generated 3D tilemap and Godot was in average 2 - 2.5x times slower than Unity's URP without any ECS. I'd say unless you are developing a 2D game (like pixel art), Godot is not right choice. Also, if your game needs realistic graphics then your options are pretty much just Unity's HDRP or Unreal.

[@natecoley160]

Godot has drop-in replacement of physics with Jolt Physics it much faster

[@nanimuwu]

Can we see the code used?

[@jarusca3933]

This is misleading, since with Unity ecs + jobs + burst and a lot of optimization patterns, you can literally achieve in the hundreds of thousands, if not a million

[@jarusca3933]

My CPU is an I9 13900hx btw

[@JIN-TECH]

Interesting

[@adityamohanta8902]

Thumbnail is not interesting as compared to video😂. Just put screenshots and it will boom💥

[@containedhurricane]

Unfortunately, Godot is way behind Unreal for realistic graphics and massive scenes, since the creator said it will never adopt data-oriented design or ECS for its gameplay scripting. Its Nintendo Switch porting cost is $3,000 and there is no tool to port a Godot game to Switch ourselves

[@natecoley160]

Unreal does not use ECS. You could implement external solution for ECS or basically anything. And why do you need realistic graphics anyway?

[@containedhurricane]

@@natecoley160 Unreal uses C++ for its gameplay scripting, so it doesn't need a data-oriented design implementation to boost the performance. Realistic graphics are required for some games, movie production and architectural visualization

[@natecoley160]

@@containedhurricane ECS performance based on the way data stored anc accessed, by utilising more efficent data structure (basically array pools, which stored in stack instead of heap, so it's easier to iterate), it's not related to language. Also Godot supports C++ and itself written in C++. Unreal is more mature feature rich engine indeed, especially for "cinematic" production. yet it's much slower in terms of prototyping new stuff. so development cycle will be slow and more expensive, bad choice for indie dev. If you are indie it's better to create something new. Refreshing, experimental gameplay mechanics, instead of good looking but mediocre "walking simulator"

[@BanditLeader]

That console porting is true for every engine tho. Console porting requires an SDK, which you only get by not only paying for it, but also signing an NDA. Nintendo has the "advantage" by allowing individuals to get the SDK, unlike the Xbox and Playstation that require you to be a company. But Xbox is slowly moving towards the Nintendo model, especially since the xbox sdk is semi open source. Unity and unreal "support" console porting by having a template, but you still need the sdk. Lone wolf technology offers help porting for starting price of $3000, pineapple works is undisclosed. W4 games hasn't opened yet.

[@saul8510]

​@@containedhurricanegodot too with gdextension 😂

[@vincenzopanella2705]

Probably you are more biased towards Godot rather than Unity, i did the same tests with Unity ECS anf got far greater performance with UNity, Unity always wins

[@saul8510]

ofc if you do with 3d physics test with the default physics engine and bad configured to make godot look bad

[@vincenzopanella2705]

@@saul8510Exactly , Unity wins always

[@fictitiousnightmares]

"Probably you are more biased towards Unity rather than Godot."

[@vincenzopanella2705]

@@fictitiousnightmares No I truly love Unity , the best engine in the world !!!!!!!!!!!!1111111111111111 ( obviously I am sarcastic )

[@MathsPlusGames]

Keep the variables the same throughout, this test is a lie, the unity circle one seems to have a lot more bees and moving much faster, the worst part is, your making me defend unity and I dont want to, But don't lie to us just to get us to leave unity, we plan to do that anyway

[@DeafMan1983]

What is the h**l? Why are you using Windows?????? Where is proof under Linux/BSD. Unity3D and Godot work as well. And I don't believe that on Windows is very slower than Ubuntu 22.04