Hi,

do you have any comparison tests or idea about the difference of (nearly) similar Lite-C and C++ codes? (And C# just for fun.)

My experinces:
Recently I have ported the static part of my RTS map decomposition codes to UE4, which - surprisingly for me - works at least 10, maybe 30 times faster than in 3DGS (1-1.5 sec stop in UE4 game thread what is approx. 30sec with 3DGS but with a few interim waits to avoid long freezing). It consists of large dynamic struct array allocations, several memset and few memcpy of arrays, passing arrays as function parameters by pointers, large loops with many complex computations. And significant amount of ray tracing, but it is rather an OBB vs. PhysX3.3 question (it is fast enough with 3DGS, lightning fast with PhysX).

I know it is heavily code dependent as it can be seen in C++ vs. C# benchmarks, but I would like to get a rough idea and a confirmation of that my AI related codes also would run similarly faster with UE4-C++ than in 3DGS-Lite-C (consisting of mainly dynamic array struct management - lot of array memsets, and loops through arrays - and expensive computations like tons of A* pathfinding). Moreover in Ue4-C++ I can convert my codes to run in separate threads in the background for the cost of more memory (each thread would require its own, not like when they are running after each other). Or course UE4 actor system and ticking is different from 3DGS entity system, where I could avoid using separate waits for my RTS units (I use only one loop with wait() as the main game loop and another for MapBuilder editor UI loop).

Thanks for any info

Just use a high precise timer and check the times of a test app you made.
I bet C++ is a little bit faster then lite-c because of better compiler optimizations but C# isnt comparable at all. I had a simple .net program which should read the bytes of a file and write them to a text file. It ran for around 5 hours where my C++ programm took 3 seconds...

I asked C# only for curiosity. I will probably switch to C++ and UE4 (more attracting than C# and Unity for me), and keep Lite-C and 3DGS only as a fast-to-develop test bed because I am familiar with it.

as I remember earlier on the 3dgs home page it was mentioned that Lite-C is faster than C#, now it is compared only to scripting languages. I saw a couple of benchmarks where surprisingly C# was faster than C++.

c++ and c# comparison depends highly on what you are doing and how you are doing it.

Lite-C is more then a scripting language, the code itself gets translated to direct assembler, the question is how good this translation is.
And seriously, if you create a multiplayer game dont even think about the word unity. Even the greatest retards can drag a dll into their project and use YOUR classes and functions because .net code isnt secured in any way.
UE4 reversing is not even close to what happened to UE3.
On UE3 you are able to dump a whole SDK for your game hacks by injecting a DLL to the game. But Im sure the same will happen to UE4 some day

UE3 was using unreal script, some sort of jvm-like vm language. UE4 uses c++ i doubt that will happen

They still save function and class names/size with the UE4 insert class member macro

multiplayer is a future plan for me, but the current UE4 system does not really suits an RTS (but they have plans to extend it at least). there are several other RTS projects in development, I will see how they work, or stay with single player only.

the thread again went a bit offtopic.

Naturally, the Lite-C compiler isn't as optimized as the Visual Studio compiler, period. So, it is a well known secret that if you do your code in a DLL, it is a lot fast. So, if code execution is an issue, just drop it into a DLL function - should be straight forward.

The only thing you can't drop into a DLL are wait(1) calls. So if you rely on classic Gamestudio scheduling, you could build e.g. classes for actors that encapsulate the behaviour which is called by the "framing" wait(1) construct in Lite-C. Sounds awful, though.

Best way would be to design your code with as less wait(1)'s as possible and shift later to DLL.

thanks for the detailed answer.
apparently my code is the bottleneck again (but I should do again a deeper analysis again to define which parts), so it means I could put my whole game loop into a dll...