How much better is a real game engine?

[Xonok]

I've once made a 3D projectile motion simulation system in warcraft III that started to lag at about 1500 projectiles or so. (I don't remember precisely)
It was a bare-bones system that didn't handle anything except movement(duration was handled by making the projectiles have negative life regeneration and removing them when dead).

How many projectiles could a functionally identical system handle in a more efficient language such as C++?
Does this factor of difference apply roughly to all things in warcraft III modding or are some things remarkably faster/slower?

 

[GhostWolf]

That would obviously depend on the code (e.g. type of collision detection, spatial information, dynamic batches for rendering, and many other things), but 1500 is pretty much nothing.

For something more concrete, you can go and watch the countless demos on youtube of millions of rigid bodies, handled by different engines (e.g. large towers of cubes breaking apart).

Warcraft 3's Jass interpreter is very slow, its rendering code is completely obsolete and slow. I can't say anything about it's physics system, but I would assume it isn't exactly the best out there either.
It's also so old, that the code generated by whatever compiler they used, is probably far less optimized than it would be today.

In short, Warcraft 3 is slow in every aspect. Not that this is anything new...

 

[BlinkBoy]

That would obviously depend on the code (e.g. type of collision detection, spatial information, dynamic batches for rendering, and many other things), but 1500 is pretty much nothing.

For something more concrete, you can go and watch the countless demos on youtube of millions of rigid bodies, handled by different engines (e.g. large towers of cubes breaking apart).

Warcraft 3's Jass interpreter is very slow, its rendering code is completely obsolete and slow. I can't say anything about it's physics system, but I would assume it isn't exactly the best out there either.
It's also so old, that the code generated by whatever compiler they used, is probably far less optimized than it would be today.

In short, Warcraft 3 is slow in every aspect. Not that this is anything new...

well JASS isn't really THAT slow since it's not really interpreted but Just-in-Time compiled. the problem is the way you must simulate physics in JASS and how you manage projectiles. It also has to do with how you manage physics. Most people just compare projectiles with each other all the time which is slow.

You need to find an engine which supports atleast dynamic octrees.

Also rendering is important. In the case of wc3, it assumes your projectiles are units so it does less simplifications that you could do with other engines.

 

[Dr Super Good]

well JASS isn't really THAT slow since it's not really interpreted but Just-in-Time compiled.

No it really is THAT slow because it is not just-in-time compiled. Sure it has some form of byte code for what operations need to be done but all names are still resolved during run time. This applies to locals, globals and functions as well. Each time one is referenced multiple hashes are taken of it (well the code seemed to do that as it iterated the name string 3 times) which are used to eventually locate the resource referenced. This means that you are looking at 100s of instructions, some conditional, just to resolve a single named element in JASS, and most operations require multiple named elements.

Lets compare the following.

// Simple increment of A by B in JASS.
set A = A + B;

// Simple increment of A by B in C++.
A+= B;

In the JASS example it will need to perform at least 3 named lookups as well as process the byte code. In the C++ example it could end up being a single instruction depending on how A and B are used (otherwise it will need 4 instructions, read A, Read B, increment A and then write A). If those variables were to be appended with "ABCD...WXYZ" the JASS code would take much longer to execute (probably multiple times longer) while the C++ code would remain as fast (still possibly 1 instruction). This is why people often call it interpreted as it does not statically link code even if it does undergo some compilation process.

Just-in-time compilation is not a problem. JAVA uses it and for a lot of purposes has speed very close to C/C++. However the difference is that JAVA JIT compiles into native machine code with an optimizing JIT compiler where as JASS just converts it into virtual machine code and does not even statically link named elements. In fact you could say that JASS's version of JIT compile does what the Java pre-compiler does to class files.

the problem is the way you must simulate physics in JASS and how you manage projectiles. It also has to do with how you manage physics. Most people just compare projectiles with each other all the time which is slow.

The main issue is WC3 lacks any form of interpolation. In SC2 everything is run at 16 FPS with the art interpolated between frames. This means that your physics only need to run at 16FPS so perform 16 updates (possibly with multiple tests per update). In JASS you needed to run at 60 FPS to achieve similar results which is considerably more resource intensive.

Non-deterministic state physics can also be offloaded to things like the GPU or terminated pre-maturely in case of low resource availability. Something you could do with your own game engine but not in WC3 or SC2.

You need to find an engine which supports atleast dynamic octrees.

Depends how much Z axis is used. If most of the game is played out in the X/Y then quad trees should suffice. A 3D space simulator on the other hand would probably benefit from oct trees.

A major benefit could be if part of the physics were simulate-able on the GPU as that does 3D single precision floating point vector calculations considerably better than the CPU.

Also rendering is important. In the case of wc3, it assumes your projectiles are units so it does less simplifications that you could do with other engines.

WC3 is also very old and was written using Direct3D 8 technology. Many optimizations that are used today for current generation graphics did not exist back then so the rendering as a whole is probably quite slow.

There is also an argument of floating point vs fixed point mathematics. Fixed point can end up being faster (especially if running as a 64bit process doing 32bit long fixed point) as CPUs generally have far higher integer operation throughput then floating point but the mathematics becomes more complicated. Floating point on the other hand is much easier to use with a lot of libraries existing to do things such as vectors and also does not suffer the finite rage issues that fixed point does (floating point is open ended from 0 to infinity at the cost of having an error). Old video games mostly used fixed point for the lack of floating point units in old consoles (yes many did have "sub pixel" positions).