libGDX is perfectly fine for 2D. It is also strong for Android game development. See my first video of the series for more info: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-r9HnEGHbIQQ.html
The numbers of Java are pretty impressive. But I guess that makes sense when you compare an algorithm which only deals with numbers and you utilize an ArrayList. So there's very little interaction with the heap doing allocations and utilizing the garbage collector. I would imagine the more complex your application gets (using many classes, objects and relations) the more Java will fall off in terms of performance in comparison to C++. However implementing the same thing in C++ will cause much more headache (choosing between references, smart-pointers, applying rule of 5 and such).
In the context of Godot game development, a C++ call threw a GDExtension is not free, and there is an inherent cost to this. Therefore the more nodes that make C++ calls you have, the less a C++ solution performs, and the better GDScript performance gets relative to C++. The same for Java, the calls between the Godot engine and the JVM are not free.
But the thing one wants to see is how do calm waters with reflections look? How does a ship placed in those waters look? Can you mask out the interior of the ship, etc etc…
So you lose access to Performance data in release builds, and I needed debug to see differences in the amount of memory being used, which also provided some interesting results. I would not focus on the actual numbers too much. C# performs well, and even if it performs closer to C++ with release builds, it still cannot be used in HTML builds. C++ is the clear choice if you want speed in your HTML builds.
I reran the all tests on release build: - C++ and Java had the same performance: 44ms and 54ms respectively - C# indeed improved: From 178ms to 68ms - GDScript improved: 4538ms to 3058ms
@@AntzGames Great, it looks like both C# and Java looking great, I wonder when is html for c# comming maybe in .net 9, There is also a Godot for Javascript/TypeScript but it's on 4.1version which is supposed to export to html.
Good to know. This algo needs to add values to the end of the array during the execution, and technically does not know the final size of the array, but does know the maximum possible size.
@@guillaumemagniadas2472 Technically you can also call reserve() of std::vector which allows reducing the amounts of allocations to only one and forcing it to the beginning of the algorithm. That way the only difference between std::vector and std::array should be whether you access memory in heap or stack. So I guess it depends on the OS whether that makes a reasonable impact.
I use GDScript to design and test the Architecture (or build a prototype). Once I'm satisfied with the result, I convert it to C++. GDScript performs well, and for most developers, it makes only sense to do a C++ conversion if you are creating something computationally heavy, for example, AI that will be used by over 1000 NPCs so they can interact with each other.
That is where I am at. I plan to use it only for very expensive tasks. I went threw this exercise to learn how to do C++ GDExtensions. It is good to know I have options in Godot once you hit performance limitations.
Thank you for sharing this resource, ocean simulation and water simulation are subjects that I find fascinating, pair that with my interest with the Godot Engine and what it's capable of and you have my attention.
I list my hardware specs in the video description. This implementation makes it easy for you to change a few settings to increase your FPS by reducing some quality. There are some reports of some people with older 4GB graphics cards having some issues. Check out the issue list in the Github repository for more information.
This is just Acerola's code for for godot. The repo you are showing just implemented other guy's code, and put it in godot. Please do research before praising people and calling them scientists and PHDs...
2Retr0's repo does list Acerola's video in one of his references. But, I think you should do more research before making a statement implying that he `just implemented other guy's code'. If you actually read 2Retr0 detailed explanation of the techniques used it is far more detailed than Acerola's and 2Retr0 clearly details when he combines techniques. In addition he has GPUParticles for sea spray that I don't see in Acerola's. Acerola's shaders are not optimized (Acerola says this in his github repo), yet 2Retro0 has implemented optimizations for increased FPS. Some of these optimizations include load balancing cascades, include a update rate parameter, and other techniques to reducing overhead between the CPU and GPU in the pipeline. Anyhow I personally think 2Retr0 implementation looks way better than Acerola's.
It;s not Acerola's ocean, he did not even this nor came up with this idea. Most credits should go towards J.Tessendorf, Christopher J Horvath and others.
@@AntzGames Should be more: [1] Franz Gerstner. Theorie der wellen. Annalen der Physik, 32(8):412-445, 1809. [2] Jean Baptiste Joseph Fourier. Théorie analytique de la chaleur, volume 1. Gauthier-Villars, 1822. [3] Jerry Tessendorf et al. Simulating ocean water. Simulating nature: realistic and interactive techniques. SIGGRAPH, 1(2):5, 2001. [4] Christopher J Horvath. Empirical directional wave spectra for computer graphics. In Proceedings of the 2015 Symposium on Digital Production, pages 29-39, 2015. [5] Klaus Hasselmann, Tim P Barnett, E Bouws, H Carlson, David E Cartwright, K Enke, JA Ewing, A Gienapp, DE Hasselmann, P Kruseman, et al. Measurements of wind-wave growth and swell decay during the joint north sea wave project (jonswap). Ergaenzungsheft zur Deutschen Hydrographischen Zeitschrift, Reihe A, 1973. [6] Willard J Pierson Jr and Lionel Moskowitz. A proposed spectral form for fully developed wind seas based on the similarity theory of sa kitaigorodskii. Journal of geophysical research, 69(24):5181-5190, 1964. [7] Steven A Hughes. The tma shallow-water spectrum description and applications. 1984. [8] Sergej A Kitaigordskii, VP Krasitskii, and MM Zaslavskii. On phillips’ theory of equilibrium range in the spectra of wind-generated gravity waves. Journal of Physical Oceanography, 5(3):410-420, 1975. [9] Edward F Thompson and Charles Linwood Vincent. Prediction of wave height in shallow water. In Coastal Structures’ 83, pages 1000-1007. ASCE, 1983. [10] Ian R Young. Wind generated ocean waves. Elsevier, 1999. [11] Carl Friedrich Gauss. Nachlass: Theoria interpolationis methodo nova tractata. Carl Friedrich Gauss Werke, 3:265-327, 1866. [12] James W Cooley and John W Tukey. An algorithm for the machine calculation of complex fourier series. Mathematics of computation, 19(90):297-301, 1965. [13] Bui Tuong Phong. Illumination for computer generated pictures. In Seminal graphics: pioneering efforts that shaped the field, pages 95-101. 1975. [14] Joe Wilson. Physically-based rendering, and you can too! 2017. marmoset.co/ posts/physically-based-rendering-and-you-can-too/. [15] Mark Mihelich and Tim Tcheblokov. Wakes, explosions and lighting: Interactive water simulation in atlas. 2021. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Dqld965-Vv0.htmlsi=Jy0_un81KjUsWmk6. [16] Stephen Hill and Stephen McAuley. 2012-2020. blog.selfshadow.com/ publications/. [17] Libo Huang, Ziyin Qu, Xun Tan, Xinxin Zhang, Dominik L. Michels, and Chenfanfu Jiang. Ships, splashes, and waves on a vast ocean. ACM Trans. Graph., 40(6), dec 2021. 31 REFERENCES 32 [18] Dmitrii Kochkov, Jamie A Smith, Ayya Alieva, Qing Wang, Michael P Brenner, and Stephan Hoyer. Machine learning-accelerated computational fluid dynamics. Proceedings of the National Academy of Sciences, 118(21):e2101784118, 2021. [19] Fynn-Jorin Flügge. Realtime gpgpu fft ocean water simulation. 2017. [20] Jerry Tessendorf. Interactive water surfaces. Game Programming Gems, 4(265-274):8, 2004. [21] Jerry Tessendorf. ewave: Using an exponential solver on the iwave problem. Technical Note, 2014. [22] Peter Kipfer, Mark Segal, and Rüdiger Westermann. Uberflow: a gpu-based particle engine. In Proceedings of the ACM SIGGRAPH/EUROGRAPHICS conference on Graphics hardware, pages 115-122, 2004 github.com/Biebras/Ocean-Simulation-Report/blob/main/finalReport.pdf
I wonder if this test is comparing stack in C++ with heap in the C#, and C# in the editor without the released build, cause I tried it and got 3ms in the release build and around 12-16ms in the editor.
To add some context to your original comment and also this edited comment. So this algorithm is very bad in terms of space, and yes, 2 million is very big stack, even for C++. Time Complexity: O(N*log(log(N))) Auxiliary Space: O(N) I may redo the test using the test using the Segmented-Sieve algorithm: www.geeksforgeeks.org/segmented-sieve/ Which reduces the space needed for the algo to the square root of 2million (which is only 1414), shown below: Time Complexity : O(n * ln(sqrt(n))) Auxiliary Space: O(sqrt(n)) Also, I should also redo the tests using the release build as you suggested. Also I may add both Rust and Java/Kotlin GDExtension times, as many people have requested it.
@@throwplatethis is peak victim mentality. trans people get the tiniest bit of support from the community of a major game engine, and somehow you’re the victim here? stop making everything about yourself
This is a good request, I will add this to the video description: CPU: Ryzen 5 5500 GPU: RTX 3050 8GB (original) Monitor Resolution: 3840 x 2160 (4K @ 60 Hz) RAM: 32 GB OS: Windows 11 Godot: 4.3
Hiya, interesting comparison! I'm currently working on a numpy-like math API and came across this, so I wanted to have a go at this myself. My 2c, I'd be surprised if GDScript was actually 100x slower than c++, or 27x slower than C#, in the real world. C# may have some edge by being JIT'd and its the compiler having a better implementation than GDScript, but it's also possible the compilers even vectorized your calls automatically, elevating their speeds beyond what's expected from the benchmark designer. But it's hard to say what really happened without actually opening the guts of the binaries. Benchmarks are hard! Anyway, my gdscript implementation got comparable results to yours (about 160ms), while it took about 9ms with the vectorized calls (~16x decrease). That doesn't quite bring it to C# or C++ levels according to your test, but it brings it a lot closer! The library (NumDot) does use SIMD vectorization to speed up assignments, but it's somewhat handicapped in comparison to C++ plain because of the many abstraction layers between logic and assignment.
In a real world game example with a complex scene graph, GDScript performs much better, and many C++ GDExtension calls becomes more expensive. However, a highly computational and/or any algo that requires loops severely impacts GDScript. Also I think you might want to edit your statement >>> I'd be surprised if C# was actually 100x slower than c++, or 27x slower than C# I know you meant GDScript at the beginning.
I'm guessing the performance difference between the benchmark you posted (which was one big computation, and where kotlin performs really well) and this game (which performs many frequent calls, and where kotlin is behind gdscript) is due to the cost of crossing the JNI boundary for each call, right?
This is exactly correct. This project conducts benchmarks, and you can see the results here: github.com/utopia-rise/godot-kotlin-jvm/tree/master/harness/bunnymark They are working on batching the JNI calls and other performance goodies that will reduce the impact of the JNI calls. The interesting thing is with design changes to the BunnyMark code (they have 3 versions of it) you can make Godot Kotlin JVM 2.5x faster than GDScript all the way to 10% slower than GDScript. You can avoid the impact by making design changes in the node structure of your project.
C++ GDExtensions can be compiled using Emscription to produce a Web Assembly module (WASM) and run on the web, as I explain in the video. This is done automatically on export. Here is another example: www.reddit.com/r/godot/comments/1atvz4z/gdextensionc_game_on_the_web_with_wasm_sand_slide/
Good day, thanks for the video, why didn't you consider the option with JMonkeyEngine when migrating from libgdx? If the answer is in the previous videos about libgdx, then sorry, I haven't watched everything yet.
So this older Godot3 repo did some rust + GDNative (which is now GDExtensions): github.com/extrawurst/godot-rust-benchmark I would assume a rust shared library GDExtension to be relatively the same speed as a shared library C++ GDExtension.
So this prime number test is like the worst possible test for GDScript (and most likely Python). I used it specifically to expose the weakness of GDScript in code loops. I would take the results with a grain of salt. GDScript actually does pretty well in real world rendering examples. The official Godot benchmarks can be run here: github.com/godotengine/godot-benchmarks
