SFML2 V8 JavaScript Binding

[StevenC]

Greetings,

I am new to SFML and am going to be using the library in a project powered by the V8 JavaScript engine. I wanted to share with the community my V8 Binding for SFML 2.0.

If you identify any major issues with the binding please let me know. You can post your issues to this thread and I will attempt to address them if they are within the scope of the project. I will release new versions as needed to address the issues reported.

Before using the binding in a project you may want to consider looking at the ISSUES.TXT file. If that doesn't scare you off then go for it. So far though, everything appears stable. The binding works on Linux and Windows.

---- Update ----

I have updated the binding to version 0.5. Version 0.5 adds some important features such as the ability to copy and delete objects. Also, the JavaScript instanceof operator now works with the classes so one can distinguish between an sf.Image and an sf.Texture without testing for specific methods.

v0.5.1. The binding project now includes a sf_v8.js file. This JavaScript file contains definitions for context sensitive help for Eclipse. You will need to "link the file" to your Eclipse JavaScript project and then Eclipse will give you tool tips when using SFML JavaScript objects. This should make it 1000 times easier to write SFML code in JavaScript. Note: Full descriptions of methods and variables are still only available using the C++ documentation.

Updated to version 0.6.0 - The binding is now in the beta stage. It is stable and supports type-checking for classes to prevent crashes. I've tested it quite a bit internally and feel it is probably good enough for production use. It does need more testing though before I am ready to say that it is finished.

The binding is available for download on GitHub:

https://github.com/StevenChristy/SFML2-V8-Binding

[StevenC]

Accessing a static class method:

var modes = sf.VideoMode.getFullscreenModes(); // Returns an Array of VideoMode objects.

Creating new objects:

var vm = new sf.VideoMode(1024, 768);
var window = new sf.RenderWindow(vm, 'Hello World');

Accessing enumeration constants:

if ( ev.key.code = sf.Keyboard.G ) { // User pressed the letter 'G'
   // do something
}

Essentially you should be able to turn C++ code into JavaScript code fairly easily with just a few syntax changes.

[capz]

that's pretty neat actually.

so how should I look at this? you have a C++ project with V8 JS as a sandboxed scripting environment? or would one be running the V8 JS VM and all code would be in JS?

[StevenC]

so how should I look at this? you have a C++ project with V8 JS as a sandboxed scripting environment? or would one be running the V8 JS VM and all code would be in JS?

Either way. For my project I am writing everything in JS. It is possible to register only certain classes in the V8 engine, although its intended use is to expose everything SFML has to offer.

You could probably do half and half where maybe your core engine is written in C++ and you draw the UI using JavaScript or you could also make it so your application supports event handlers written in JavaScript.

I am open to suggestions on how to improve it. Some things I am considering or working on for future versions:

1. Make it modular to match how SFML is already divided up.
2. Expose C++ operators as methods in JavaScript.
3. Add a copy method to clone an object from within JavaScript (Copy constructors are not supported in the current implementation.)
4. Allow parameters to be passed using a Javascript object, i.e. sprite.setPosition({x: 100, y: 50}).

The time frame for these improvements depend on what other people request. Otherwise I will implement the features as I run into problems on my project.

In a couple weeks (or months) I will release my project as open source so there will be an example of a JS game engine written in JavaScript using SFML.

-Steven

[StevenC]

Version 0.4 adds support for passing parameters in a JavaScript object. For example, one could construct a vector like:

var vec = new sf.Vector2f( { y: 100, x: 50 } );

This could be used in other ways too. For example, if you already have a JS object in your code that has an x and y variable you could pass that object to construct a Vector, as any additional object properties would be ignored.

Like:

var PlayerActor = { x: 1, y: 1, name: 'Bob', otherstuff: { ... } };

var vec = new sf.Vector2f(PlayerActor);

The names of the parameters are the same as those found in the SFML 2.0 documentation except that they are always lowercase.

[Rogof]

I was thinking of doing something similar but as a node extension, so I'm quite interested in your project.

After a quick scan of your project, there are some things that I think would help you to improve it:

• If you haven't already, you may check how node.js ( http://nodejs.org ) does things. node.js is an example of an application "on the wild" which uses V8.
  
• A more "formal" documentation would help. Examples which show how to interact between JavaScript and C++, as well as some sample applications showing this will be a great help for people who want to try the bindings.
  
• You mention that you want to support linux but are only using VS, thus I suggest you to also use the mingw compiler, making the project compile with mingw will cause less headaches when porting to linux.
  

Finally, I don't claim to be neither a guru nor an expert, but anyway I would like to offer my help with the linux aspect of the project.

[StevenC]

Hello Rogof,

First, before I comment on your feedback, I want to thank you for taking the time to give feedback.

Regarding node.js:

My position on node.js is that it is a great platform which I know very little about and have absolutely no free time with which to learn more of. From what little I currently know, my objectives put my implementation at odds with some of the design goals of node.js. The biggest difference is that node.js emphasizes asynchronous JavaScript. My design is adherence to the SFML API design and not to make it asynchronous. So if I brush off any comments about doing things along the lines of  node.js it is simply because I cannot resolve my own design goals with my understanding of node.js's design goals. Because I can't find a common ground, I disregard it completely.

Still, I am open to compatibility with the node.js code base. If there is anything that I've done with the C++ side of the wrapper that makes it incompatible with node.js I would love to know how to improve it (within the design goals that I have already set forth.) Changing the C++ wrapper code to make it more node.js friendly is not against my design goals. AFAIK though all one needs to do is write an NPM module include the wrapper code. Not really my thing, someone else can do it.. its probably a dozen lines of code.

Regarding formal documentation:

The purpose of the wrapper is to implement such a complete implementation of SFML that documentation is largely unnecessary. Some conversions need to made. For example, JavaScript has no concept of namespace or classes so both are implemented as JavaScript objects. Ideally the 'sf' namespace should be implemented as the 'sf' object and if one does that then one need only convert the C++ syntax to the appropriate JavaScript syntax. There are probably a few exceptions to do this, but for the most part everything works as expected.

var myobj = new sf.RenderWindow(...);

is equivalent to:

sf::RenderWindow *myobj = new sf::RenderWindow(...);

Any place where the C++ and JavaScript don't match up 100% is either a defect in the wrapper or a limitation that I will need to add a workaround for.

You wrote "show how to interact between JavaScript and C++." That is a good idea. I definitely hope to add some examples showing how to do clever things with the wrapper code if the project gains enough traction and people are asking for it. One thing I ask you to consider though, calling C++ from JavaScript or vice versa is not really specific to my project. My project only makes it possible to use SFML within JavaScript, nothing more or less so most documentation that I will write will focus on differences between the SFML C++ and JavaScript syntax.

That said, if you need help with C++/V8 just let me know. I am happy to help, but I am a still a complete noob with both so don't be surprised if I have no clue. Maybe in a few months this will have changed.

Regarding linux and mingw:

I wish I had the patience to try and compile V8 in MingW. I was thinking about trying it last night, though after a few Google searches I decided it was a waste of time. SFML would compile easily, but the V8 dev team doesn't seem interested in supporting MingW out of the box. GYP is alien to me and I refuse to learn python (hence why I made this project). So, I will probably never bother with mingw even though I would love to have it working. Contributions and suggestions enabling support for mingw compilation are welcome.

Linux is a big priority for me. Although I am a windows guy, I really love the idea of giving users the freedom to choose their OS so Linux is a must-have. I haven't had time to setup the tool chain yet. Last I tried. I ran into a snag with getting SFML v2.0 RC1 to link. Laurent linked it against versions of libraries that I could not find releases for in my Ubuntu VM... More libs to compile I guess. I am sure in a few weeks I will have some time to set it all up.

The main issues I am anticipating with Linux have to do with the overloaded casting operators. It is entirely possible though that it would actually compile, the code is massive but not very complex.

Regarding help with the Linux port:

Your assistance is appreciated and welcome. If you attach a list of any compiler errors or warnings you get, I address them ASAP (assuming I know what is wrong). Changes can be safely made to v8wrap.h/.cpp too if you want to contribute modifications using GitHub I would definitely accept the assistance. (Avoid changing the wrapper itself since those changes made will not be compatible with future versions.)

Thank you,
-Steven

[Rogof]

Thank you for your quick reply.


About node:

First, I did mention that I wanted to use node, however my goal is to have JavaScript as a scripting language in my application, pretty much like you do. I choose node because it has a good environment and I have prior experience building applications with it (not much, I admit).

And although your goals does not match with node's, I still feel that something can be learned from it, for example, how node manages its modules (it's not asynchronous) or how its ObjectWrap class is used. Either way is just what I think.

About the compatibility with node, I don't know enough so can't say much (just started to fiddle with when I found your project).

Also, I forgot to include it in the other post, but the v8-juice project (http://code.google.com/p/v8-juice/) can be helpful too.


About the documentation:

I understand your position, in that regard I suggest to simply link to the sfml documentation and point the differences whenever is necessary. Anyway, code examples are always nice to have.


About the port:

I have attached some patches and the compiler error log, eventually I will setup github.

The v8wrap-gcc.patch fixes:

• Header Windows.h not found, in linux and mingw.
  
• `invalid initialization of non-const reference of type 'v8::Local<v8::Value>&' from an rvalue of type 'v8::Local<v8::Value>'` (lines 82 and 126).
  

The error log (http://pastebin.com/8vhzAdyR) is quite long, but most of the errors in sf_v8.cpp can be avoided simply by adding spaces inside the angle brackets, ie.

CastToCPP< ::sf::InputStream* >
CastToCPP< ::sf::Vector2<float> >

instead of

CastToCPP<::sf::InputStream*>
CastToCPP<::sf::Vector2<float>>

This is because expressions like `<:` and `>>` are ambiguous to gcc.


Note: as an extra I've added a patch that formats the readme using GFM + fix a typo.

[attachment deleted by admin]

[MorleyDev]

This is because expressions like `<:` and `>>` are ambiguous to gcc.

The old C++03 standard has >> and << as ambiguous and required spaces. The C++11 standard fixed this, which can be enabled in gcc. The nuwen build of the latest version of gcc at least uses the C++11 support by default now, not sure if that's becoming a standard gcc feature for the linux builds post 4.6 too.

[Rogof]

The builds of gcc I have (v4.7.1 linux, v4.7.0 mingw) uses C++03 as default, and even compiling with C++11 the `<:` are still a problem, I get:

 error: '<::' cannot begin a template-argument list

By the way, first time I heard of the nuwen build.

[StevenC]

Rogof,

Your changes have been applied. The latest version adds spaces to prevent the <:: issue. I was a little concerned about some of the warnings related to the casting function overloads... Hopefully they were caused by the spacing issue, but I am not certain.

I have setup a wiki on the github page. I will try and make a few entries with every major version release.

-Steven

[Silvah]

The builds of gcc I have (v4.7.1 linux, v4.7.0 mingw) uses C++03 as default, and even compiling with C++11 the `<:` are still a problem, I get:

 error: '<::' cannot begin a template-argument list

That's because <: is an alternative token for [, and [: obviously cannot begin a template parameter list.

[Laurent]

Here is a complete explanation for people who don't know about this C++ stuff that was used when dinosaurs were still on earth:
http://en.wikipedia.org/wiki/Digraphs_and_trigraphs

[Rogof]

Thank you all for the information.

That's because <: is an alternative token for [, and [: obviously cannot begin a template parameter list.

Yes, thankfully gcc output also explains it:

...
note: '<:' is an alternate spelling for '['. Insert whitespace between '<' and '::'
...

Here is a complete explanation for people who don't know about this C++ stuff that was used when dinosaurs were still on earth:
http://en.wikipedia.org/wiki/Digraphs_and_trigraphs

Sadly, when I was born there weren't any dinosaurs around... so I guess is normal that I don't know such stuff XD.
Actually, after reading the article, I (faintly) remember seeing something about trigraphs (but not digraphs) in my C class some years ago.


I've added two more patches, one fixes the HWND__ reference in linux + a typo with one the `AutoCastToCPP` overloaded function name, and the other fixes a formatting issue in the README file introduced with my "bonus" patch.

The new error log is here: http://pastebin.com/C2RSx5L2

[attachment deleted by admin]

[StevenC]

Hello Rogof,

The function that your patch adds a WIN32 ifdef around is an artifact. I'm going to remove it since it is not being used at all. It is not even declared in the header.

The error log is very interesting.. It confirms what I was most concerned about. GCC is not nearly as good with resolving overloads as VC++ and will need some help.. What that help is I am not sure just by looking at the log. From what I can tell it cannot match the class specific AutoCastToCPP functions. For example, the first error:

v8wrap.h:274:2: error: no matching function for call to 'AutoCastToCPP(v8::Handle<v8::Value>&, sf::InputStream*&)'

Should match:

sf_v8.h (1962): inline void AutoCastToCPP(v8::Handle<v8::Value> Value, ::sf::InputStream *&CPP);

But it doesn't seem to even try. The list of matches it tried was limited to those in v8wrap.h. It might be because the inline added to the autocasts in the sf_v8.h. The ones in v8wrap are not inline.

Would you try removing all "inline " from the sf_v8.h./.cpp file and recompiling and let me know if works?

Thank you,

-Steven