Then I had to do some research to find out why an almost empty CGE game project was showing up as leaking memory in heaptrc just to learn that the Indy network code is intentionally leaking memory and that it's safe to ignore it. Which is bothersome because it makes heapstrc annoying to use on Windows unless I redirect the output to a file.
Note that we don't use Indy. Except client/server examples ( https://castle-engine.io/wp/2024/04/12/improvements-to-our-client-server-tcp-communication/ ). Our web request class (TCastleDownload) is based on FpHttpClient, which is part of FPC.
There was indeed a known memory leak, for which we had a PR: https://github.com/castle-engine/castle-engine/pull/581 .
- Original note: It's not something we want to ignore -- on the contrary, memory leaks are something we treat like any other bug and they have to be fixed. It's just that in this case, this is not so trivial (I want to test and iterate on the solution from PR, as it is a bit cumbersome), and it didn't seem priority (an "almost empty CGE project" doesn't use TCastleDownload, IMHO 
-- but this of course depends on the project type you want to do). You can subscribe to https://github.com/castle-engine/castle-engine/pull/581 on GitHub to be notified when it's applied.
- Edited note: I did some changes and applied PR https://github.com/castle-engine/castle-engine/pull/581 No memory leaks should occur anymore. If you observe any leaks in CGE, please submit a bug (using GitHub issues, https://github.com/castle-engine/castle-engine/issues ).
Apologies, I had worded it wrong. I should've said that I used the example TCP server/client networking example on which I later started building my own project on. But the example was already leaking memory prior to me making any changes (thus me calling it an "almost empty project"), to which I discovered that it was because of the way Indy is handling threading and that it's leaking memory on purpose.
I use the Indy package that can be downloaded with the Lazarus package manager. So it might be a bit outdated, and the current version might not be leaky anymore. I haven't checked it.
...
Regarding everything else, it isn't really my intention to critique CGE and make Godot look more favourable. I was pressed on time to finish my post before I had to leave, so I might've rushed a bit.
My idea is that Godot is better for beginners purely because of its popularity, which in turn means that a lot of tutorials (be it good or terrible) are being constantly written by its users, and you can easily get the advice you need from their currently large user base. That popularity also means that they get more financial support to develop the project. Factually speaking, Godot is a stronger project in that sense.
CGE is in peculiar spot. It being written in Pascal might put a lot of folk off (I myself learnt about Object Pascal being a thing just a year or two ago despite learning to program in Pascal for 3 years in high-school and 2 more years at college, yikes!). Our friend circle would always joke about Pascal and how it doesn't have any real world use cases - which isn't true. Our year being the last one to be taught Pascal didn't make it any better since the argument to changing the whole education system to teach C++ instead was based on the premise that it's more useful in the real world and has objects and classes. The prejudice against and the low popularity of Pascal might hinder CGE's popularity greatly, thus making it harder to get that critical mass that Godot has. Which means less user-written tutorials or general advice beginners can get online.
I, myself, currently see CGE to be something more akin to XNA or MonoGame, while Godot seems to be like Unity and Unreal. How true is that is for people to check for themselves as I've only used CGE for just a few weeks and I am not that well versed in the engine or its tools yet. But my opinion here might be unfair to CGE because I dived into code first, mostly ignoring the bundled GUI Castle Editor. However, unlike Unity or Unreal, Godot doesn't have that many commercial successes made with it, and I think CGE actually has an advantage here, being able to compile to machine code thanks to Pascal.
Likening CGE to XNA or MonoGame might be a bit unfair as I find CGE not only easier to use but it also supports proper 3d, which at least when I tried it in MonoGame a few years ago was a pain to do. Not to mention how easy it is to set up on different OSes compared to MonoGame.
Functionally, CGE reminds me of Heaps.io. However, CGE has way more documentation than Heaps.io ever had, and if you do have some prior knowledge of using a game engine, you can find your way around. Not to mention that CGE is built on top of existing quite robust technologies (FreePascal compiler) unlike Heaps.io (having to work with haXe + HashLink + Heaps.io stack of custom mainly gamedev-orientated software, with HashLink not even properly supporting Linux when I had last used it).
I don't think I had played around with CGE or Godot enough to write something of more substance, so I can't really give any proper suggestions.
Recent Posts
