you're right, but still a scheduler is not necessarily slower than function calls.

Hello? Can I please get a reply, it honestly does not look like I can program a full game with C++.

lite-C is annoying, limiting, and easy to make a mess of. Entities for example can't have anything other than variables of type "var" attached to them, no inheritance, no initialization and stuff like that, I'd really like to use C++.

You can program a full game with cpp. There is no problem. In the manual is a simple tutorial under "engine sdk". Things like the "target" vector is stored in the enginevars struct. You can use it with ev->target, or with v(target).

how to used v(target)x or evt->taget in cpp,
could you give me a example?
and in cpp,how can used you and me ?

me, you, target, etc. are global variables in their respective type. Just access them via the engine vars struct like

VECTOR* target = ev->target;

or

vec_set(ev->target, vector(_VAR(1), _VAR(2), _VAR(3));

Since _VAR and his relatives are annoying it might be efficient to use a default vector class and only transfer back the Gamestudio-vector format (count var in, var is annoying) when finishing your calculation.

If you are about speed, then calling all functions and use one wait(1) (--> in Lite-C) is actually faster. The Lite-C compiler is way away from being optimized and a lot of users recognized that a lot of concurrent wait(1) functions are swizzled up in the scheduler -- in a slow fashion. I doubt JCL will proof this or proof this wrong since this is a kea feature of Lite-C, but experience it yourself and you see.

And if you are really about speed, do the same in C++ and do not try to invoke DLL functions for each frame for each entity. It is fast, no doubt, but the reason for while-approach is simple: 1.) no 1000 entity dll calls per frame, only one or two global ones maybe and 2.) (and maybe most important) if you do it in a while and all your entity functions are not dependent on each other you can parallelize easily the function calls per while iteration (actually, when you use e.g. OpenMP, its just one single added line to achieve that).

Just my thoughts. I think, you have to test it on your own to get to know about all this stuff.

There is no need to use wait() at all.
(only once in the main loop)

In all other games, there is usually a single
Game-loop, wich uses a sleep() function to time the game
(unless it renders with maximum fps)

You can do the same in lite-c.

But then you have to manually call all functions of the gameloop.
And handle all entity actions manually. (using their pointers)

Bottom line, you can write a big game using just a single wait(1), wich is needed to let the renderer take over.

It might be cleaner to program this way. As you dont have
functions running in paralel. And you have full control
of the order of processes.

Have fun reinventing the wheel in C++.

the scheduler doesn't run functions in parallel either. it also is just a list of functions that get called after each other. you have full control over the order. the big difference is that local variables get stored/restored at each wait().

i think wait() can be very convenient and very fast to work with but it tends to lead to less well planned code because of that.

I'm trying to figure out an answer to your question but the only thing that I can think of right now is that you may possibly do not truly understand the functionality of wait or scheduling and how it really works "behind the scenes." Why wait is used and when to use it is important for giving the engine time to store local variables, pointers and allow the engine to schedule functions before returning back to the action after designated frames or time and having 50 entity's on the screen with wait doesnt mean you'll wait 50 seconds for the engine to make up its mind. You can overload time without causing any problems because different waits can be run parallel. Why you would think that wait is a bad thing just makes me think that maybe you should do a little bit more reading up on it or work with it more, maybe you just dont understand its use.

I didnt write this as an argument or an attempt to belittle you but maybe you will look at it closer and try to really understand it as a means of helping yourself.

Why do you feel that using var is bad? Just dont understand your thinking.

Coroutines are an indeed fine concept. Though, since their execution order is not transparent, you have to assume that they are non-deterministic. This leads to akward code and side effects when you attempt to snychronize e.g. several entity actions. Plus, freezing code which is intersected with wait(1) statements leads to a A) proprietary compilation which is B) not optimized (it is a safe bet that the compiled game runs way faster if you use the VS compiler because it does a hell of optimizations) and C) slower due to the fact of freezing code (storing and restoring local variables, instruction pointers, parameters, etc.pp) and D) single threaded (atm and I wouldn't bet on it that JCL ever makes the execution of all concurrent coroutines multi-threaded!).

If you use the event-hook so that the engine calls one callback function each frame you can do a semantic thread of execution by yourself which avoids all these problems. It forces you to think about your coding (opening coroutines by random just because you have wait(1) is evil, it looks easy and tempting, just because it is easy - but in the end you are yelling around just because refactoring your code is painful. This applies to most novices.). And it gives you the opportunity to do better coding. Things like polymorphism comes into play, which is great (others too, I am just mentioning this one).

and...

var is a fixed point type - which is, technically speaking, a pain in the ass. It is limited, it is unprecise, it is inconvenient. Working with var's feels sometimes like arguing with a woman.