I've often seen the terms used to distinguish between an interpreted language and something compiled to machine code, but I'll take your word for it about the performance.

Jibb

EDIT:
Actually there's a misunderstanding. lostclimate was saying that GS's sales are mostly Com and Pro, not Extra, in response to AlbertoT saying GS's situation would perhaps be the opposite of Unity's.

EDIT2:
To me that is a big deal. A lot of games need pathfinding, to continue your example. Even if you don't do something super cpu intensive, a faster language at least means you can run it on older computers (though I guess that could be a stretch, since graphics are usually the bottleneck).

EDIT3:That's not true with Unity Indie, given the lack of Render to Texture (huge these days) and PP effects.

yes, sometimes the terms get used like that but i think it doesn't make much sense. interpreted languages are programming languages too.

and with jit compilers and stuff like that there often is no clear line anymore between interpreted and compiled.

i think "scripting" often gets used kind of deprecatingly. like it is something lesser but actually many "scripting" languages are more powerful than something like c.

Yes, you're right. It wouldn't have been hard at all for me to say "interpreted" instead of "scripting" and compare it with "compiled" instead of "programming", and I'll try to remember that from now on as there's much less ambiguity there

I certainly think of it almost in that way -- though from a speed point of view, not power (if "power" means features). To me Python is the most powerful language I've ever played with, but I'll never make a whole game in it because of the speed (that's not to say I wouldn't use a mix: using a language like Python to make triggers and story/level events easier and more natural to deal with).

I hadn't heard of "jit" compilers; I'll wiki it tonight. I guess I have a relatively old-fashioned view of interpreted languages, and should educate myself about that

Jibb

yes, you are right about python and its speed. there are languages like boo though which are a very good power/speed compromise.

by the way, there are jit compiler projects in the works for python too (google's unladen swallow and pypy). with them it should be possible to speed up python a lot but because of the very dynamic nature of python it's unlikely that the speed of statically typed languages like c# and boo will be reached.

I agree. And this is the point where there business starts. They want to sell the pro and this is one of the incentives to get it. So if you need this feature you simply have to buy one of the commercial engines or get deep into Ogre.

But if you do some prototyping or learning, then the free ones (including Unity Indie) are very good alternatives.

"They want to sell the pro and this is one of the incentives to get it."

Yeah , and they are actually being very clever , as a lot of people are looking to dev for the Iphone , and you used to be able to buy Unity Indie and then buy Iphone Basic , which would total in like $600 or something to dev for the Iphone , where as now , if you want to use Unity for Iphone you need Pro plus Iphone kit , which totals now to like $1900. Works out very well for them if you ask me.

I dont think so
Lets say

Unity Indie == 3dgs Com
UnityPro == 3dgs Pro

Apparently most of Unity revenues come from UnityPro
Assumimg that the member's share is 50/50 than about 13 % of the Unity incomes should be generated by the Indie version,
It is not an negligible amount of money , in my opinion, such as to justifiy a free version
I must suppose then that , let's say 80 % of the Unity members own the Pro version
I dont think thatthis is the case for 3dgs

There is something strange

Their business of course

C-Script has a JIT ("just in time") compiler.
It is compiling on startup, where all those dots in the startup window pop up.

Lite-C also features a JIT compiler, it is running every time you run your game in debug mode.
But it also allows pre compiling, and according to jcl this will result in faster code execution.
In this case you don't have to deliver the source code with the finished game as it is the case for C-Script without using resources.

Most likely they are leaving away certain optimizations for the JIT compiler to keep the startup speed acceptable.

Still I think that the speed of the language is not the most critical point.
Whenever I had problems with the frame rate it was because of level/object rendering. Personally I never ran into a problem where a script was too slow.
Bad coding which performs poorly can be done in every language.
Back to the example Pathfinding: Why is it so slow? Well you have a lot of linked lists, but the slowest thing are all the traces for obstacle detection. And this is an engine function, not a script issue.

Okay, I did know about "Just In Time" compiling; I thought "jit" was something I didn't know about. Thanks for that.

About the pathfinding example: Apart from reducing traces as much as possible by giving each node a linked list containing every node it can see (and only recalculating these lists when obstacles change), I have optimised my pathfinding by writing my own ray-trace.

Now, to expect to imitate an engine function and then out-perform it is ridiculous. However: my particular situation allows me to reduce the trace to something performed in 2D space with far simpler obstacles, I can have all sorts of different groups of obstacles so that the trace only considers obstacles that are only relevant for entities of certain sizes, and since all I'm concerned about is the PASS/FAIL of the trace (rather than the normal, the distance to the point of contact, the position of the point of contact, among other things that c_trace automatically does for you) each trace can terminate as soon as an obstacle is found instead of searching for the earliest contact.

I like how all that comes out really fast and I don't have to look at making a DLL or anything to make it worth using over c_trace.

Although, I don't think many users will go that far, and so like you said: it won't be an issue for most.

Jibb

i am not sure if this really is jit compiling? c-script compiles ahead of time. it just does it every run.

i think with most jit compilers the code first gets run by the interpreter and then a code analysis happens which tries to find the hotspots that make most sense to be compiled. the machine code results also often get cached for further runs.

theoretically this should be an advantage because the jit compiler has more information about the code and its runtime behavior than a normal compiler. better optimization should be possible because of that. it's just that normal compilers are around much longer and still have many more years of research invested into them but eventually jit compilers will catch up.