Hey, I understand the purpose of the lite-C language, and while I think it may help beginners, I don't need this sort of programming aid, and I don't think it really speeds up the prototyping process.

There are also other particulars I don't like about lite-C like the wait() function, and all the other special syntax keywords like action, event, ect.

So my question is, is it possible to make a game with the A7 engine in C/C++ only, that is to say without the lite-C language. If so, how would I go about this, are there any tutorials that start you off? Is there a manual or means for me to figure out how to access the engine the way that you would usually do with lite-C.

I appreciate the help.

Edit:
I'd also like to point out I have already read this tutorial on getting a basic entry point from C/C++.
http://portfolio.delinkx.com/files/GS.pdf

Update: I still am seeking information on how to write a game mainly in C++, would like to know stuff like, is it even possible?

all functions are same with lite-c. you can use lite-c manual with c++.

but starting with lite-c and getting overall understanding of engine and function concepts and switching to c++ after that is a better path to follow imo. Lite-c is not a new language you need to learn from scratch, it's just c with automatic typecasting and pointer helping thing.

Ah, this explains a lot thanks.

I do understand that lite-C is really just an advanced C compiler that has a lot of A7 specific integration, however, I wanted to learn the engine without having to use the wait() function a lot in particular.

Apparently I have to use the wait() function quite often if I plan to make a game. Even for things as simple as animation. There are a few reasons I am against the wait() function, the main one being how unorganized the order of execution can get. So is there a set of callbacks, like a function or something that is called every frame that I can use to perform once-per-frame functionality, so that I can avoid using wait frequently if at all?

well, just try to use it, it's not actually what you think it is.Well it'll become so natural that you wont even think that you are using it when you are typing the code.

when you create function with a infinite while loop and put wait(1); at the end of that while, that while will loop only once per frame. wait makes the loop wait for the next frame. and youll get one per frame functionality.wait doesnt make the whole functions to wait for the next frame, it only makes the function which is wait called from to wait.



about "action" keyword, it is actually "void" type.

acknex.h line 12: typedef void action;

only diffrence is that in wed, actions show up in behaviour list, and you can assign this funtions to your entities that you have placed in wed.

if you use and a while(1)...wait(1) loop in you actions(entity functions, whatever you want to call), you'll also get another function that runs once every frame. Then tehre is "my" pointer which refers to the entity which is currently calling that action.then you can use "my" in your action, which will point to the entity that is calling the action, and you can access all entity properties using my, point it to something else, pass it as a function paramter etc.

so when you write an action like


and assign this to an entity in wed, and run your script, your entity will start to spin like crazy. and wont stop spinning.

Concep it very easy yet very powerfull.

Skim thru the workshops, and you'll find your self diving deep in the manual and prototyping you game in full speed.

Thanks Quadraxas, are you absolutely sure there's not a viable alternative to the wait() function?

I understand how to use it, but it really feels like its an unnecessary aspect of the engine, I would rather have a callback system.

I don't want to have 50 entities on screen all with wait(1) loops. If the looped functions get large enough there could be noticeable performance implications; that's 50 functions that have to be sent to the scheduler all with their own variables that have to be preserved ect.

I keep hearing "It's very powerful" and although in a sense that is true, I'd like to point out its a very inefficient alternative to engine callbacks, why not just give an entity things like onFrame, onCreate, onDestroy callbacks? I'm planning on adding this functionality myself.

So my question is, are there any engine callbacks that get called every frame that I could use to do entity based updates (like updating animations ect)?

Note: I've completed all the workshops and skimmed the manual

yes there is on_frame event, which is called every frame, afaik you can use it in c++, and that's the alternative to wait.

http://www.conitec.net/beta/on_frame.htm

it's not beta, it's just the url that online manual is located.

edit: teher is also EVENT_FRAME flag, if you set this flag of an entity, it's event will be called onece every frame.

Quoting AlexH.

(Can the same be done with 1 list of entities, 1 loop to iterate over that list, and 1 wait(1)?)

::Dumb rhetorical questions of limited relevancy can be thoroughly ignored.::

Thanks I actually found this just before reading your reply, this is awesome no more wait!


Yes, however this would be the slower alternative to a simple on_frame function like above.

So do I still have to use lite-C? How would I implement things like actions and event callbacks from C++?

how do you know?

Because wait(1) would place the function on the scheduler, store local variables and other state-specific information, where on_frame is just a simple function call and does not involve the scheduler.

Could anyone please point me in the right direction to using C++ to write my game? I've written with C++ many times before and have developed a sort of work flow that is more close to a standardized development process, so that it is easier to work in a team oriented scenario. Not to mention C++ has classes and inheritance, which is really a beautiful thing and it sort of confuses me as to why it is not in lite-C already. When I started programming classes/structs are one of the first things you understand, I didn't really find them mind boggling.

I under stand lite-C is very similar to C++, but I don't understand how to use things like the c_trace function which sets a variable "target". How do I access this from C++? Or can I not do this?

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.

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!