libGDX is perfectly fine for 2D. It is also strong for Android game development. See my first video of the series for more info: kzbin.info/www/bejne/qGqrn3h9fcd8h7M

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.

@@AntzGames Very interesting. I have only used GDScript in Godot so far but wanted to develop a GDExtension in the future. I'll keep this in mind.

no, WebGL has no compute shaders, geometry shaders or tessellation, you'll have to use WebGPU instead

This is correct. Compute shader are used in this project.

Thanks. I wonder when ThreeJS will support WebGPU in WebXR then.

So there is already a request on GitHub to add some of the features you mentioned here: github.com/2Retr0/GodotOceanWaves/issues/3

So I have close so 3 hours of content making my case that libGDX is not good for 3D games. Can you back your statement with some facts or experiences?

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.

​@@AntzGames Yeah, for html5 sure, if at least there was an 3d engine with a high level language like C# that support html5, that would be nice.

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.

@@everythingcouldbesimplify818 unity

Indeed it was private. Set to public now. Thanks.

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.

@@AntzGames yes, that’s what I meant, utilizing the knowledge of the maximum possible size (if it’s not a problem)

@@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.

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.

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.

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.

@@AntzGames it's the same base idea, which is the hard bit.

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.

@sauliusvincevicius8688 This is 2Retr0's references list: Flügge, Fynn-Jorin. Realtime GPGPU FFT Ocean Water Simulation. Hamburg University of Technology. (2017). Gunnell, Garrett. I Tried Simulating The Entire Ocean. (2023). Horvath, Christopher J. Empirical Directional Wave Spectra for Computer Graphics. DigiPro. (2015). Tessendorf, Jerry. Simulating Ocean Water. SIGGRAPH. (2004). Matusiak, Robert. Implementing Fast Fourier Transform Algorithms of Real-Valued Sequences. Texas Instruments. (2001). Mihelich, Mark. Wakes, Explosions and Lighting: Interactive Water Simulation in 'Atlas'. GDC. (2019). Pensionerov, Ivan. FFT-Ocean. GitHub. (2020).

​@@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. kzbin.info/www/bejne/eqLPlWxsapKJrJIsi=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

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.

that's why it's the best engine 🏳‍🌈🏳‍⚧

@@kira.herself keep telling yourself that transmission.

How so? The engine is still the same as it was two days ago

@@azaa2188 you can't reason with them, I also wish to know where all this random hate comes from, but I never get a real factual answer

​@@kira.herselfthey don't consider it hate, they think they're morally correct by hating on minorities.

go cry about it

Agreed. They're not attracting prospective game devs by publically dehumanizing those who chose not to put 'gender justice' in their games

@@ahslanabananaHe is, and we are. That's the whole point of the comment. Odd choice of rhetort.

@@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

god forbid a community manager tries to engage with its community. Go cry a river cultist.

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

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.

@@AntzGames you got it right, i meant GDscript there :) statement is edited.

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.

There are several java based games on Steam and the most of android games are made in Java/Kotlin.

Hello. V8.0.303 C:\Users\antho>dotnet --list-sdks 8.0.303 [C:\Program Files\dotnet\sdk]

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/

So I added a GitHub repository so you can run the GDExtension on an HTML export yourself: github.com/antzGames/GDExtensions_VS_GDScript_Test

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

The workflow is 2 steps. You build the jars in IntelliJ but you need to use the Godot Kotlin/JVM editor to run the game. I would start with the getting started template that is listed on the website and follow the instructions. I forgot about the 3D demo to try out. I will try to build it next weekend. So excited!

@@AntzGames Maybe possible to combine it with Graal Native for Demo performance tests?

@@shoeoffhead3692 So a new version of Godot Kotlin/JVM is coming out in a few weeks (I heard sometime in October). So going to wait until this new release and I am going to make a video series just focusing on this amazing project.

See my next video of the showing how to run the Kotlin 3D demo: kzbin.info/www/bejne/b3LNf618l7l5jNE I also show performance comparisons vs. the original GDScript version.

I was talking to one of the contributors to Godot Kotlin/JVM project today and they say that capability is on the roadmap. Most of them are ex-libGDX devs who still love using Kotlin/Java but want to use Godot. So stay tuned!