The scheduler is quite intransparent. This can
lead to problems when syncronising two "entity actions" or
sharing data.
In a singel game-loop approach, the programmer can always
find out in what order functions will be called, and
thus know whats will be changed in what order.

There are always methods to make both approaches work correct.
its a question of programming style.

--

the VAR is for beginners. Its simple to use.
And thats good for its purpose. Just like BASIC is good to
learning programming.
And since you can use other datatype, there is no
reason to comaplain about VAR.

I have not come across this problem. I am currently running multiple entities( more then 10) with testing my rpg combat system and statiscally I dont have a problem (yet),but I do keep it in mind and watch it. So if there really is much of a difference during registration then it must be so minute as to not be seen by human senses. I'm not running a mmorpg though either, so I dont know.

Basically all engine functions have var as parameter or return var. Panel digits require vars. So you do have to use var, although in many cases other types would be a much more logical choice.

Caroutines: I wouldn't complain about them, because you don't have to use them. Except maybe if you need inkey/inchar.

hm... i always know (or can easily find out) in what order the functions get called even with the scheduler. it's not intransparent.



the reason to complain about vars is that the engine uses them for everything. so even if you use something else you will lose precision if you pass your values to engine functions.

the poor var precision also is the reason for quants. using meters as unit (like all other modern engines do) would be much more intuitive for humans but because of var you can't because you would get jerky movements.

fixed point variables are a relic from times when processors didn't have fast floating point units.

The thing is, that when I store in C++ my coordinates as float or double and calculate the fps by myself, I have a floating point precision time_step equivalent and can use this to update my coordinates as precise as possible. This will result in a much smoother movement, because I have a precise arithmetic, even when I am forced to transform the float XYZ back to var (but not using these values for my floating point coordinates, of course!).

I doubt that you see stuttering just because the entity snapped from 0.000 to 0.001. Stuttering comes from multiplying with the low-resolution'ness of the time_step factor.

the quants come from Quake.
Its was referred to as inch there.

Gamestudio builds up on the old quake standards.

In fact WED is a reworked Quake leveleditor.

yes, and the quants in quake come from fixed point variables.

yes, you are right. last time i experimented with this was in c-script and there you can only use vars but i did some quick experiments again and it seems like you really can work around most problems with lite-c. it still would be better if the engine didn't use vars anymore though.

Lets start a petition.

• Replace all var engine variables with float (and ints, if the type is suffiecient)
• replace the time units in ticks with milliseconds as float (or double)
• make coordinates floating point, too and replace quants with meters or the like
• change all percentages through 0..1 floats
• to guarantee backward var arithmetics, support var as a float macro

Or: do the above and simply remove C-Script support and the var datatype as a whole (--> enforce people to learn C).

[EDIT]

And add now unions, trinary operators and enums!