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.
Thanks for clarifying -- so you specifically have a memory leak in our TCP client/server examples (the ones I happened to rework a lot last week,
https://castle-engine.io/wp/2024/04/12/improvements-to-our-client-server-tcp-communication/ ).
Tested and addressed:
1. We indeed had one memory leak in CGE code connecting CGE + Indy, fixed in
https://github.com/castle-engine/castle-engine/commit/7b7cfb7129e9b153907d90c9831d74c75cc76f76 2. But in general, Indy is leaking memory by default, by design -- this is unrelated to Castle Game Engine. I documented this now on
https://castle-engine.io/manual_network.php#section_indy_memory_leaks , pointing how to avoid it (define FREE_ON_FINAL in Indy sources) but also warning it is not reliable (Indy source code warns that it will only work if your code gives all Indy threads time to terminate -- e.g. this means you cannot just disconnect right at application exit; so first disconnect, give some non-zero time for threads to finish, then close the app).
Experimenting, I was able to have CGE examples client/server indeed exit without memory leaks, tested with FPC HeapTrc, adding "<compiler_options detect_memory_leaks="true">" to CastleEngineManifest.xml .
But I also saw why this is not default in Indy, as one can indeed get application crash (Access Violation) at exit when FREE_ON_FINAL is defined and you stop server / disconnect client right when application exits.
This sucks, but I'm afraid we cannot do anything more with this on CGE side, i.e. this is how Indy works, unrelated to CGE. Hopefully my new documentation at least makes it a "known limitation". If this is a blocker, you should just not use Indy. We support other networking options and we plan more -- see
https://castle-engine.io/manual_network.php which I updated today. There's TCastleDownload to communicate with HTTP REST, we have example using RNL, we plan Nakama integration.
As for memory leaks, in general, if you find a memory leak, please let me know. This is a bug, we fix it like any other
We care about memory leaks, we have a documentation page dedicated to it (
https://castle-engine.io/memory_leaks ), we have option in CastleEngineManifest.xml to easily activate leak detection too. Even if the leak isn't large/often, we want to fix it, to avoid "obscuring" from developer more important leaks. And fixing memory leaks generally means also "making the code properly organized, to consciously control the lifetime of your objects" which is a good thing for code quality, so we do advise it.
Regarding everything else, it isn't really my intention to critique CGE and make Godot look more favourable.
No worries, and I'm really open to all feedback, including critique and including comparisons with other game engines! We only learn from it.
Background: CGE did improve a lot in recent years because we removed a lot of "friction points" based on user feedback. And we do look at "what others do" in various situations (in particular Godot, Unity, Blender -- while Blender is not a game engine, some UX ideas translate) and this has been beneficial as well. In all of this we keep our own vision (modern Pascal, but also focus on standards glTF, X3D and resulting interoperability with other tools, also how components for UI and TCastleTransform work together...), but we would be foolish to ignore what others do right. So I need a feedback, I need these comparisons too, to be able to improve CGE in the right direction.
As for your points about Godot, I agree. Godot does have bigger user-base than CGE, this also implies more people providing support and tutorials. In general, Godot along with Unity and Unreal Engine rule when it comes to popularity, CGE is just a contender here
With hopes to grow.
As for Pascal, we try to address the common question "why Pascal" by
https://castle-engine.io/why_pascal and
https://castle-engine.io/modern_pascal . And compared to other games engines, we do benefit from e.g. having both engine and games written in the same language (all people who make games also automatically can tweak the engine!) and from using a standard language, not specific to our engine (we're happy to delegate hard work of making compilers, transpilers etc. to FPC/Delphi
). I feel these properties of Pascal give us some "edge" over some other engines. Time will tell how much.
I have to play more with MonoGame and Heaps.io that you mention. Admittedly most of my "other game engines" experience is from Unity / Godot / Unreal (roughly in this order of familiarity). Something for me to learn!
Thanks again for feedback and really keep it coming!
Recent
