Wouldn't it make more sense and be less of a hasle to just go back to the main menu, change the script, then start again? Although, changing it while it's running shouldn't be too hard, either.

So anyway, I'm trying to compile this spidermonkey thing and it's designed for msvc++, though it does compile on unix/gcc and mac... I could compile the dll in msvc++, but I'd rather work on the game itself in mingw.

Any ideas as to how to get that working in mingw (supposedly the entire mozilla tree can be compiled in mingw since v1.4b, not all features supporting, but I'd assume javascript is a critical part (considering the entire interface is coded in it)).

Here's an interesting link: projects using js engines Couple game-related projects there.

Thanks,

Marcello

I believe if you try this in Lua it should just work. (i.e. call lua_dofile again) Even if you do this in the middle of a lua method it will just rebind the method's name to a new instance, and the old one will eventually get garbage-collected.

Any comments, Korval?

Pete

Here's a link from the game developer's conference next year - there's going to be session devoted to Lua.

Pete

I don't think that will necessarily work. At least, not for the way that I use Lua. What I prefer to do is have each Lua script file represent a class (thanks to LuaBind), with an exposed global function that generates instances of that class. Which means that Ai scripts are actual instances of the pure-virtual AIObject base class, for example.

A LuaBind class is built out of a table of functions. Even if you change the file implementing the class, instances that have already been created will still point to the old methods.

PostScript has "script" in it's name. That doesn't make it an appropriate language for writing ray-tracers or non-printer code, even if it can be done. Just because you can do a thing in a language doesn't mean that it is the appropriate use of that language.

God, it was really nice not having you around.

Most printer drivers are written in C/C++, too. That doesn't make PostScript embedded. A scripting language is considered to be "embedded" in another language if the server language can expose an arbitrary API to the script language. Normal JavaScript doesn't have this facility, but both Lua and Python do.

I admit that it is possible to have hot-swapping of scripts. However, it isn't a trivial exercise, nor does it just come with any particular scripting language (unless you write one with that in mind. Which is doable, and might be a laudable goal for a scripting system). You have to do work at it to make it happen. Granted, C/C++ can't do it at all, even with .dll's.

My whole point is that you said that JavaScript can't be used to code games. Which is wrong. And the funny thing is, that you can't argue about that, since there're enough games which were coded in JavaScript.

I must admit, that I have problems following you here. I guess the idea is that since both "JavaScript" and "PostScript" have "script" in their name, and postscript is not intended to be used as an embedded language, JavaScript can't be used as an embedded language as well?

Agreed. Of course it's not the server language, but the server that's exposiong an API which can then be used inside a script.

Um... of course not, since the (to use your words) the "server" is exposing the API.
The DOM exposing the structure of a HTML document is not part of javascript. It's just an object exposed by the server (the browser).

Wow. That's news to me.
Last time I had to write wrapper functions in C and register these functions to LUA.
Can you tell me how Lua (or Python) can do this diretcly? Would make things more easy

BTW, the way of using LUA as an embedded language in your own programm is almost exactly the same as using SpiderMonkey

To make a long story short: You can easily use javaScript for games, and there's nothing wrong with that.

JavaScript is an embedded Scripting Language. In fact, it was desiged to be an extension language.

And even in an environment not specific to games (web browsers), you can use it to code great games. Now imagine what you can do with it if you embed it in a game specific environment.

I just downloaded the spider monkey source.
In order to compile it, I had to do some changes.

First of all, you have to define
-DXP_PC -DWIN32 -DEXPORT_JS_API -D_declspec=__declspec

Then I changed jstypes.h to make sure the gcc int64 version is used even if win32 is defined:

#elif defined(WIN32)
typedef long long int JSInt64;
typedef unsigned long long int JSUint64;

In jslibmath.h change

#if defined(_WIN32) && !defined(__MWERKS__)
#define JS_USE_FDLIBM_MATH 1

to

#if defined(_WIN32) && !defined(__MWERKS__)
#define JS_USE_FDLIBM_MATH 0

Then I got an error like this:

D:/GameProgramming/JavaScript/spidermonkey/prmjtime.c:429: undefined reference to `JSLL_Zero'

Which was fixed by replacing JSLL_Zero with 0.

Then it compiled without any errors...

[edit]
The reason it was not defined was that I removed the jslong.* files from the project.
After I added these files I had to change some lines in jslong.h

static JSInt64 ll_zero =  0x0000000000000000LL;
static JSInt64 ll_maxint = 0x7fffffffffffffffLL;
static JSInt64 ll_minint = 0x8000000000000000LL;

Take the .c files in the directory and feed them into a compiler.
In the worst case you'd line up all .c files

I'm using this makefile, which was generated by slickedit after I told it to use all files (but js.c - since this file is a demo).

But the script in JavaScript is used to show it's a embedded language.

Sorry. What I meant was "They even put a script in the name to show it's a scripting language".

Korval, the API used to access the server is not implemented in the scripting language. Not is is exposed by it.
It's implemented in the language the server is written in, and exposed to it.

You can't expose an API using LUA. You can create wrapper functions using LuaBind, but this doesn't produce "pure Lua" code.
That was my whole point: That your argument that Lua and or Python can expose an Api, but JavaScript can't is just bogus.

Korval, there's no need to "add something" to JavaScript. You're not changing the language. All you do is to expose some new objects and or functions to it.
And JavaScript was designed as an embedded language... I'm nost sure why you try to make up here...

And still it would be the server that's doing the work. Which makes sense

If you compare the way the integration with C/C++ is handled in Lua, Python and Javascript, you'll realize that it's almost the same.

Don't try to insist that JavaScript isn't a good choice. Try to keep an open mind.

I have the impression that you still link "javascript" with WebBrowser because that was the first application using JavaScript as an embedded language.

Hm... I think using JavaScript for games is better then talking garbage about PostScript raytracers
As I said, there're are many good games written in JavaScript.

But before we get down to that level again, could you please give me 1 reason why JavaScript should not be used as an embedded language for games?
Besides the fact that the name reminds you of postScript?

It isn't garbage; it's the truth. That code exists out there somewhere, as strange as it may sound.

Because it wasn't designed for use as a general-purpose embedded language. It is a web browser language that was eventually extended with the ability to be used in more applications. Lua and Python are designed with general purpose programming in mind. Lua, for example, was built for speed. Can the same be said for JavaScript?

I think the better question, considering that there are two other, quite viable, alternatives, can you give me a reason to use JavaScript for non-web browswer tasks?

Please tell me, what feature you need is missing?

Not true.

While JS was certainly not built to be the fastest kid on the block, it is pretty fast.

This is not the point here, but I'll give you some reasons later on. First I'd like to notice that "because other solutions are around" is not a very strong point. That's why there're quite a few languages besides C.

Ok, now that we have agreed on that there is no technical reason not to use Javascript as a scripting language for games, we come down to taste. Why would somebody want to use JavaScript for games?

The obvious reason is "because you can". On allegro.cc are at least 3 people at the moment using a javascript engine. And if you consider the small amount here actually interested in scripting , that's not bad at all.

But why do they want to use it? Why not Lua?
Hm... but why Lua if you can use JavaScript?

JavaScript is a powerful language. It's object oriented but is also great for procedural jobs. So the language itself is easy to use and offers lots of features.

Easy to learn It really is

Debugger support That's an important point for me.

Number of users JavaScript has a high user base. If I use JS as a scripting language I've a lot of people who could design levels.

Scripting system is easy to set up I downloaded SpiderMonkey when Marcello asked for help. And now I've a running scripting system. Neat.

Contexts I can execute scripts in different contexts but need just one runtime.

Security I can run scripts with different security levels easily.

For me "powerful language" and "number of users" was the key. I was toying around with the idea of using javascript for some time, but after I realized how easy it is to set up (which is the 3rd point) I'll be using it from this point forward.

I want to close with:

I gave you several above. Can you give me one reason not to use it?

The js lib has around 550kb on my system. I'm not sure if I can reduce that (I didn't really look at the source, I just compiled it). But I guess you can get a smaller executable if you include only the unicode or non-unicode version of the string functions.
I'm also not sure how much of the debug stuff can be thrown out for a release lib.

But yes, liblua is smaller.