Видео

Check out the GitHub repo in the description. It will get you 90% of the way.

1. Like libGDX, the project uses gradle. 2. See: godot-kotl.in/en/stable/user-guide/debugging/ for how to debug in Intellij. 3. You can see your java code in the Godot Editor, but you need to develop java code in Intellij. P.S. all of the documentation is at: godot-kotl.in/en/stable/

Godot has a lot of ECS options. Most of them integrate seamlessly with Godot's node system which are better than the ports, imo. Just do a 'ecs + godot' google/github search and you will get some examples. GECS is actively being maintained and is listed in the asset library: github.com/csprance/gecs

Your code (kotlin/java) runs in a JVM and is exported as a JAR, but you still need to package it with the Godot engine runtime and a java runtime. See: godot-kotl.in/en/stable/user-guide/exporting/ for more information.

@@AntzGames oh thats cool. i realy like your videos about not doing 3d in libgdx. i spent years on 2d libgdx game its basically just building your own engine like you said, i even reinvented in game tmx editor just to eventually save all the things in sqlite database.. :D and i would just love to just start making a game, not wasting time on every single thing like even f-cking parallaxing or animated icons or whatever or this b-s scene2d with no visual editor. however i got my game running on steam deck and i dont want to reinvent the wheel with godot. but will look into that, thank you!

and also i love intellij idea

So, I was talking to Frank the guy who is making this game: ruclips.net/video/aZmeyoEIE9s/видео.html He and his buddy made this demo in 3.5 months with Godot, and is on steam's wish list: store.steampowered.com/app/3219160/Taverna/ I know people in libGDX that have been making a game close to 9 years. What I am saying, if you want to make a game, specifically a high quality desktop game, as fast as possible (or for the least amount of money), then please do not use libGDX. Especially if its a 3D game.

@@AntzGames fuck thats me.. its like 6 years of preproduction, making super advanced game editor for almost everything, my own solutions for rendering parallax layers with implementing vfx that of course didnt work and its all for 2d game, and just hit and miss with all the additional tools like talos that doenst work with other tools or emitters or whatever... i wrote my own python tools to integrate my workflow of moving and packaging assets from procreate through libgdx asset packers etc. to be honest i made it all work but its not making games... its making tools for game workflows :D i would love to just start making a game :D

8192 vertices is the maximum per mesh because the vertex animation textures maximum is 8192x8192. Not all GPUs can support bigger images. If you look at Unreal Engine 5 Matrix city demo, the final LoD uses this VAT system. For closer up LoDs models, they do not use this approach. Some ideas: Reducing the poly count from 20k to 16k (i.e. get the vertex count down to 8192) should not impact your models appearance that much. The other limitation is you cannot blend animations. All animation have to be pre-baked. So as you can see, the price of performance is lack of flexibility. This solutions has its specific use cases.

I made this into a plugin so its reusable as a node. I have a link to the new plugin in the description, but I will update the description better. Here is the link to the plugin: ruclips.net/video/BIbEaiVOu6k/видео.html

Excellent work Arseniy. Both Anamorphic Lens Flares and Film Grain will be great effects to have. Looking forward to your video.

@@AntzGames and it's done, feel free to check it out!

If you take a look at the GitHub repository, I have documented a section about the plan to add more features, including key-binds. Check it out.

I had over 13 years of Java experience when making the game in libGDX, but I had zero knowledge of GDScript. I actually did more learning on Godot than libGDX. I have completed a few NEW 3D games using Godot from SCRATCH and I can tell you that at least for me, using Godot results in 10-20x less development time per unit of game output, when compared with libGDX. Development with libGDX for 3D games is very cumbersome, lacks proper tooling, poorly documented, feature incomplete, and performs poorly when compared compared with Godot. I have a complete video series (over 2 hours of content) explaining this here: ruclips.net/p/PLQxIUTu_M7Z_5rwPRWBOjEzACH-f2_yX6

Hello. Thanks for the feedback. Keep in mind this is an initial release and I made it so I can quickly get a settings screens for my game jams. Also this release's goals where to flush out bugs and gather feedback. Here are some comments on your items: 1. So this option is WINDOW RESOLUTION, so if not in window mode, its ignored. If you are looking to change the FULLSCREEN resolution, then Godot in FULLSCREEN mode only allows to change the viewport resolution which bleeds into your 3rd point. 2. You can change the resolution drop downs in code of the plugin dictionaries. This needs to be documented. But it is possible. 3. Are you talking about having the scaling modes and stretch modes as an option? Well, I do 3D games exclusively so it was not a priority. I would like to know how you see down sampling options work/look/designed. 4. Thanks for the kind words. This plugin still need a lot of work. Feel free to add an issue/feature request on the GitHub repository as you can paste images and is a better way to communicate ideas and suggestions as you discussed in item 3.

I added documentation on how to add more resolution options on the github README.md Cheers!

This is the exact use case why I made the plugin. Enjoy!

Hello. - So you can hide any of the settings by setting the proper node in the plugin visible = false using the inspector, but its not documented. - The plugin will only show the Voice audio bus if you have an audio bus called Voices. This is explained on the GitHub repo. - No you cannot add custom options unless you modify the plugin, which you are free to do. - Yes you can assign a custom theme as described in the GitHub repo. - No translation support, but you can change modify the plugin to do this if you like.

I was doing research for my own project and I thought I would share some findings. Thanks for watching.

No this is meant to prebake animations to make your GPU do more of the animation work, instead of using bone animations that are are mostly done on the CPU.

I only tested with a wired gamepad, but I its the browser that is providing the interface to the controller so to the game, its just a controller.

So the Godot Kotlin JVM does not export to the web for now. I am working on some other non-performance related projects, so no plans short term on performance comparison videos.

I disabled Godot threads so both Godot and libGDX ran on single threads. libGDX was hitting max CPU on a single core while Godot was GPU bound and never hit max CPU on a single core. I think the reason why libGDX sucks here is that libGDX has to calculate (CPU) bone weights every frame for every 3D mesh instance, while Godot is using prebaked animations on a single mesh. Again UE, Unity, Godot have already figured out ways to pre-bake light, shadows, animations, LoD, and so much more that libGDX cannot handle advance 3D use cases, like 300 instanced skeletons. This is the truth. This is why I am not going to do any more libGDX v.s Godot videos as the only people who care are libGDXers, which is a small community, and these people get upset and defensive when they see videos showing libGDX getting it butt kicked so it is basically a lose/lose situation for everyone.

@@AntzGames Thanks bro I love your video

The current shader on GitHub allows any number of animations, but ALL of them need to be 40 frames each. The total number of frames for all tracks is limited to 8192 but that should never be an issue. ******** In my recent game jam, I can now support any number of animations, each with a different number of frames. I will make a PART 3 and update the GitHub repository with this updated shader. Here is recent game jam: ruclips.net/video/zTJlpS3jQCc/видео.html

I created a Godot plugin. It allows any number of animation tracks and each track can be different sizes in terms of frames. I still need to clean it up and document it but here is a early peek: github.com/antzGames/Godot_Vertex_Animation_Textures_Plugin

There is also a PART 2 video: ruclips.net/video/XBm6MkOaN-A/видео.html and also I did a game JAM using this technique at: ruclips.net/video/zTJlpS3jQCc/видео.html

For all desktop platforms an embedded JRE needs to be included. For Android and iOS no embedded JRE is needed. See the Android export section at: godot-kotl.in/en/stable/user-guide/exporting/ for more information.

Its all written in Java, and 80% of it is the original Java code is from the libGDX game. The remaining 20%, is mostly the math classes, and the rendering framework that had to change. I should have been more clear in the video.

@@AntzGames Oh I see. Thanks for clarifying

​@@AntzGamesi think you might fail to optimize your libGDX game. Are you sure game is not mindlessly spawning assets? Or collision detection is effective so it does not slow everything down? It is not so obvious.

@@greenheart5334 I have way more experience optimizing libGDX games than Godot. There are very few assets. One skeleton, one mage, and all textures are in an atlas. I only spawn the instanced skeletons once and just move them at the start of a new level. The collision detection system is the EXACT same java code in both Godot and libGDX as I am using simple math to detect collisions. libGDX is just slow as the 3D engine has not been modified and/or enhanced in close to 8 years. Godot on the other hand is constantly updated/fixed/optimized. Check out ruclips.net/video/vMdqeVIcF6I/видео.html for more comparisons.

I made this simple game during a 1 week game jam, so it is not pretty, and therefore its not ready to release to the public. Use this tutorial (includes source code) if you want to learn how to do 3D with libGDX: monstroussoftware.github.io/2023/11/01/Tutorial-3D-step1.html

I like the C# option a lot, but it cannot do HTML builds which is a show stopper for me. If and when C# can produce HTML builds on Godot 4, I am going to switch to C# in an instant.

Yeah and for your use case that is correct. But who knows what use use case other people can have.

No plan for this.

Pointless? They did all that work, and their results are pointless? Don't be so mean, please. More testing is already on the way.

I have a 2018 Linux HP laptop and a very old 2014 Mac Mini that I test on so I can cover all 3 desktop platforms. From experience the worse the hardware, the more the difference in FPS.

There are going to be many libGDX users that will be very threatened by these results. I expect some backlash, so no need to defend me.

@@AntzGames Only testing can tell. Not FPS but FPS difference between Godot and libGDX

If you watch the video the bottom line says the FPS difference between Godot and libGDX. Godot is 40% faster than libGDX in this instance based game on Windows. I also forgot that the libGDX version does not work on the Mac, so there goes 1 platform.