Upgrading JavaScript engine options

[mcarans]

I want to discuss Javascript engine options.

With some work, I built the Spidermonkey from Firefox 23 (just before the major IonMonkey change). I had hoped it would still be fairly similar to the Spidermonkey used by Oolite, but when trying to build Oolite to use it, I ran into a problem. Spidermonkey 23 headers include C++ and an Objective-C .m file including a C++ header is not possible. This could be solved by renaming .m to .mm which allows C++ and making whatever changes are needed to support calling C++. Since this requires changing Oolite code, it would make more sense to invest the time on a much more modern Spidermonkey - for example Ubuntu has packages for Spidermonkey 115.

However, I thought I would look for alternatives and came across some pure C JavaScript engines, the most promising of which is QuickJS-ng which supports several platforms including MinGW64. This one is actively maintained, supports modern JavaScript and is actually designed to be embedded in other projects unlike Spidermonkey which is specifically tailored to Firefox. Its API has some similarities to the Spidermonkey currently used by Oolite.

The last option is to try to clean up the Spidermonkey that Oolite uses so that it is far less opaque than it is now effectively locking Oolite permanently to that version. The problem is right now, the only platform for which it builds cleanly is Linux. Windows requires a custom version of the code whose changes are not documented or understood. It has not been built on modern Mac and it may not be possible. Modernisations needed include removing the hard dependency on Python 2 which is obsolete by upgrading all Python 2 code to Python 3.

What are your thoughts?

[Lone_Wolf]

Due to size constraints it is unlikely QuickJS will ever support the Intl APIs.

That will make localization much harder .

spidermonkey 4 is supposed to follow ecmascript 5 standard.
Look for modern engines that provide ecmascript 5 compatibility .

[mcarans]

Due to size constraints it is unlikely QuickJS will ever support the Intl APIs.

That will make localization much harder .

spidermonkey 4 is supposed to follow ecmascript 5 standard.
Look for modern engines that provide ecmascript 5 compatibility .

The best bet for ECMAScript 5 is Duktape which conveniently has MSYS2 and Ubuntu packages. Alternatively, "Duktape is easy to integrate into a C/C++ project: add duktape.c, duktape.h, and duk_config.h to your build, and use the Duktape API to call ECMAScript functions from C code and vice versa" (although I think it would be better to use the packages for upgradabillity).

It is said to be less performant than QuickJS but it's hard to know how the really old Spidermonkey compares with either Duktape or QuickJS. However, it also lacks localisation being very small.

Localisation looks like something that was developed for later engines supporting newer JavaScript versions so if localisation is desired, upgrading the JavaScript version would be needed.

"One of the core principles of JavaScript is backward compatibility:
Older features are never removed.
Updates are incremental (not full rewrites).
This ensures that old websites keep working forever." (source)

This should mean that a JavaScript engine that is made for a newer ECMAScript version won't break on ECMAScript 5 code, so it may not be necessary to lock to the old standard.

Here's a research paper comparing lightweight JS engines.

(I've added to my earlier post an example of the modernisation that the existing JavaScript engine would need if we wish to stick with it - it has a hard dependency on Python 2 which is obsolete, so all Python 2 code would need to be upgraded to Python 3.)

[another_commander]

We first have to define the problem we are trying to solve. Why is the current js not good for Oolite, what issues does it cause? I am not referring to compiling intricacies here, I am referring to actual functional issues in the game.

Once this has been answered, the next thing to consider is what impact a js engine change would have in the existing Oolite js engine code. Different js engines, even different versions of the same engine can implement different ABIs and adjustments to the current scripting engine code within Oolite may be needed. This has happened in the past as spidermonkey was evolving and we were incorporating its changes in the game, before locking it to the FF4 version. Considering that the current scripting code is rock solid, going for a change like this has potential to destabilize the entire game. I would be extremely careful playing with Oolite's scripting code since a lot of its internal functionality (missions, AIs etc.) all depend on a stable script engine interface.

Finally and probably the most important detail of all: there are 1000+ oxps written on the current js engine. Changing that would require a verification that none of those oxps breaks. Who has the time to do that? Oxp compatibility is not negotiable so there is no way out of it, the verification of functionality has to be done. Only when we are happy that no existing oxps break would it be ok to make a switch official.

So you can see that this is not just a simple swap of some code. It is a huge core change that may have serious stability and expansion compatibility consequences. Given that we are a very small team, and risking sounding like an old broken record, I truly believe that whatever little time we can dedicate to the game would be much better spent on creating new features for it rather than chasing after its libraries. I would much prefer that time be spent on implementing, for example, shadow and environment mapping, rather than switching to QuickJS or whatever. I just see it as more productive, that's all.

[mcarans]

We first have to define the problem we are trying to solve. Why is the current js not good for Oolite, what issues does it cause? I am not referring to compiling intricacies here, I am referring to actual functional issues in the game.

Once this has been answered, the next thing to consider is what impact a js engine change would have in the existing Oolite js engine code. Different js engines, even different versions of the same engine can implement different ABIs and adjustments to the current scripting engine code within Oolite may be needed. This has happened in the past as spidermonkey was evolving and we were incorporating its changes in the game, before locking it to the FF4 version. Considering that the current scripting code is rock solid, going for a change like this has potential to destabilize the entire game. I would be extremely careful playing with Oolite's scripting code since a lot of its internal functionality (missions, AIs etc.) all depend on a stable script engine interface.

Finally and probably the most important detail of all: there are 1000+ oxps written on the current js engine. Changing that would require a verification that none of those oxps breaks. Who has the time to do that? Oxp compatibility is not negotiable so there is no way out of it, the verification of functionality has to be done. Only when we are happy that no existing oxps break would it be ok to make a switch official.

So you can see that this is not just a simple swap of some code. It is a huge core change that may have serious stability and expansion compatibility consequences. Given that we are a very small team, and risking sounding like an old broken record, I truly believe that whatever little time we can dedicate to the game would be much better spent on creating new features for it rather than chasing after its libraries. I would much prefer that time be spent on implementing, for example, shadow and environment mapping, rather than switching to QuickJS or whatever. I just see it as more productive, that's all.

The issue with the current JS is that it prevents Oolite working on Mac. Given that Oolite was originally developed for Mac, it is rather unfortunate that it now only works on Windows and Linux.

The shadow and environment mapping features you refer to: are they ideas for Windows or for all platforms?

I think it unlikely that a new developer will step forward, spend the time to learn Objective-C and the Oolite architecture, and write new features for the game if they cannot understand how the scripting engine is built let alone how it functions given that it is a core component of the game. The barrier to entry is still too high even though I've moved it lower and there is still a lot of technical debt to repay.

[another_commander]

The issue with the current JS is that it prevents Oolite working on Mac. Given that Oolite was originally developed for Mac, it is rather unfortunate that it now only works on Windows and Linux.

The Mac port has other much more serious issues than JS right now. Apple does not support OpenGL even, the game cannot start on a Mac at this point. Plus, support for Mac was dropped a long time ago and a lot of code has been written without taking Mac into consideration at all. I appreciate the desire to restore support, but spending all this effort for the scripting library on all platforms, when the result will still be a game that doesn't run on Mac, seems to not worth it, for me at least.

The shadow and environment mapping features you refer to: are they ideas for Windows or for all platforms?

All platforms.

I think it unlikely that a new developer will step forward, spend the time to learn Objective-C and the Oolite architecture, and write new features for the game if they cannot understand how the scripting engine is built let alone how it functions given that it is a core component of the game. The barrier to entry is still too high even though I've moved it lower and there is still a lot of technical debt to repay.

I don't see how knowing how the scripting engine is built would have any influence on a new coder's contributions. All contributors we had so far after the implementation of the FF4 engine in the game didn't know how the Windows JS was built, yet we did receive contributions from them. For a potential contributor in the scripting core of Oolite the important thing is to understand how the Oolite JS engine interface works and that can be achieved by studying the existing classes in the src/Core/Scripting source. Knowing how the JS dll is built is irrelevant, unless I am misunderstanding what you are trying to express. If the contributor is interested in contributing in other areas of the game, then understanding how JS is built is not an issue either.

[mcarans]

The Mac port has other much more serious issues than JS right now. Apple does not support OpenGL even, the game cannot start on a Mac at this point.

While Apple is pushing the use of Metal, OpenGL 4.1 continues to be supported on Mac. Does Oolite require OpenGL > 4.1?

Plus, support for Mac was dropped a long time ago and a lot of code has been written without taking Mac into consideration at all. I appreciate the desire to restore support, but spending all this effort for the scripting library on all platforms, when the result will still be a game that doesn't run on Mac, seems to not worth it, for me at least.

Had it been Windows that stopped working rather than Mac, would you have given up on Oolite or advocated for development to allow the future possibility of Windows support?

The shadow and environment mapping features you refer to: are they ideas for Windows or for all platforms?

All platforms.

I feel that indie games and open source even more so are attractive to gamers more for their gameplay and community than their graphics for which commercial games are usually more advanced. From the brief amount I read, it looks like Vulkan is the successor to OpenGL and SDL3 has some sort of integration with it for these sorts of effects. Trying to implement graphical improvements with older libraries will probably involve writing more things from scratch.

I don't see how knowing how the scripting engine is built would have any influence on a new coder's contributions. All contributors we had so far after the implementation of the FF4 engine in the game didn't know how the Windows JS was built, yet we did receive contributions from them. For a potential contributor in the scripting core of Oolite the important thing is to understand how the Oolite JS engine interface works and that can be achieved by studying the existing classes in the src/Core/Scripting source. Knowing how the JS dll is built is irrelevant, unless I am misunderstanding what you are trying to express. If the contributor is interested in contributing in other areas of the game, then understanding how JS is built is not an issue either.

I think it's helpful to consider how a new developer might choose a project to which to volunteer their free time. One of the most significant factors is likely to be project health. Few developers will want to spend time only to find that the project is abandoned or withers. When we consider project health, what might a new developer look at to guess the state of a project? Possibilities that spring to mind are:

When was the last commit?
When was the last release?
How many active developers are there?
What is the state of the project documentation?
Are there any tests and how much of the code do they cover?
Do I have the right skills?
Are the skills that might be learnt from working on it useful or desirable?
Are the dependencies used by the project outdated?
How hard is it to build non-standard dependencies?
Can I leverage new libraries or do I have to reinvent features?
Does the project require installing obsolete tools?
Are there other similar projects I could work on in a better state of health?
Can I set up a build environment and my desired dev tools to work on the project?
Are there parts of the project where no one understands what was done?

While a new developer could just take a copy of your Windows dev environment repo and use it to add features to Oolite, it seems unlikely that many would be satisfied with the experience, that the changes made within it are largely undocumented, that they cannot install whatever tools they desire etc. The JavaScript library is effectively a part of Oolite's code base since from what you've described, Oolite is to all intents and purposes locked to it. A developer may find they need to debug something where changes made are unknown or hard to understand. Even if they don't. it's likely a yellow or red flag for project health and a turn off for new developers not just for that but because it is a constraint on modernisation.

A project that provides a useful comparison is Pioneer. This is under very active development with plenty of contributors. It helps that it is in a more well known language C++. Even discounting that advantage, if answers to the list of questions above were compared to answers for Oolite, it should be fairly clear why a new developer might choose to work on Pioneer even though Oolite is arguably the more fun game.

You might then reasonably ask why I chose to use my spare time to work on Oolite. The reason is that I enjoyed playing it more than a decade ago. When I became aware of the state it's in now, I felt sorry that it had reached that state and thought that I might be able to contribute back. My motivations are hence highly unusual and not what will encourage new developers.

While project health issues might seem secondary to adding new features, in reality a project that looks like it is in decay is not going to attract new developers to work on improvements. Hence in order to have new developers work on things like the graphics improvements you mentioned, it is crucial to make the development experience rewarding and enjoyable rather than frustrating and limiting by doing whatever can be done to make it as painless, clear and simple as possible.

[MrFlibble]

The Mac port has other much more serious issues than JS right now. Apple does not support OpenGL even, the game cannot start on a Mac at this point.

While Apple is pushing the use of Metal, OpenGL 4.1 continues to be supported on Mac. Does Oolite require OpenGL > 4.1?

Plus, support for Mac was dropped a long time ago and a lot of code has been written without taking Mac into consideration at all. I appreciate the desire to restore support, but spending all this effort for the scripting library on all platforms, when the result will still be a game that doesn't run on Mac, seems to not worth it, for me at least.

Had it been Windows that stopped working rather than Mac, would you have given up on Oolite or advocated for development to allow the future possibility of Windows support?

The shadow and environment mapping features you refer to: are they ideas for Windows or for all platforms?

All platforms.

I feel that indie games and open source even more so are attractive to gamers more for their gameplay and community than their graphics for which commercial games are usually more advanced. From the brief amount I read, it looks like Vulkan is the successor to OpenGL and SDL3 has some sort of integration with it for these sorts of effects. Trying to implement graphical improvements with older libraries will probably involve writing more things from scratch.

I don't see how knowing how the scripting engine is built would have any influence on a new coder's contributions. All contributors we had so far after the implementation of the FF4 engine in the game didn't know how the Windows JS was built, yet we did receive contributions from them. For a potential contributor in the scripting core of Oolite the important thing is to understand how the Oolite JS engine interface works and that can be achieved by studying the existing classes in the src/Core/Scripting source. Knowing how the JS dll is built is irrelevant, unless I am misunderstanding what you are trying to express. If the contributor is interested in contributing in other areas of the game, then understanding how JS is built is not an issue either.

I think it's helpful to consider how a new developer might choose a project to which to volunteer their free time. One of the most significant factors is likely to be project health. Few developers will want to spend time only to find that the project is abandoned or withers. When we consider project health, what might a new developer look at to guess the state of a project? Possibilities that spring to mind are:

When was the last commit?
When was the last release?
How many active developers are there?
What is the state of the project documentation?
Are there any tests and how much of the code do they cover?
Do I have the right skills?
Are the skills that might be learnt from working on it useful or desirable?
Are the dependencies used by the project outdated?
How hard is it to build non-standard dependencies?
Can I leverage new libraries or do I have to reinvent features?
Does the project require installing obsolete tools?
Are there other similar projects I could work on in a better state of health?
Can I set up a build environment and my desired dev tools to work on the project?
Are there parts of the project where no one understands what was done?

While a new developer could just take a copy of your Windows dev environment repo and use it to add features to Oolite, it seems unlikely that many would be satisfied with the experience, that the changes made within it are largely undocumented, that they cannot install whatever tools they desire etc. The JavaScript library is effectively a part of Oolite's code base since from what you've described, Oolite is to all intents and purposes locked to it. A developer may find they need to debug something where changes made are unknown or hard to understand. Even if they don't. it's likely a yellow or red flag for project health and a turn off for new developers not just for that but because it is a constraint on modernisation.

A project that provides a useful comparison is Pioneer. This is under very active development with plenty of contributors. It helps that it is in a more well known language C++. Even discounting that advantage, if answers to the list of questions above were compared to answers for Oolite, it should be fairly clear why a new developer might choose to work on Pioneer even though Oolite is arguably the more fun game.

You might then reasonably ask why I chose to use my spare time to work on Oolite. The reason is that I enjoyed playing it more than a decade ago. When I became aware of the state it's in now, I felt sorry that it had reached that state and thought that I might be able to contribute back. My motivations are hence highly unusual and not what will encourage new developers.

While project health issues might seem secondary to adding new features, in reality a project that looks like it is in decay is not going to attract new developers to work on improvements. Hence in order to have new developers work on things like the graphics improvements you mentioned, it is crucial to make the development experience rewarding and enjoyable rather than frustrating and limiting by doing whatever can be done to make it as painless, clear and simple as possible.

Dayam! what he said! In spades!!! (a clumsy old penguin clears his diary as far as possible to join the cause).

[hiran]

I agree with mcarans .

Oolite development is not what you get paid for.
So if people spend time on it we should be grateful for their contribution rather than locking them up.

Maybe it is time to branch into Oolite 2.0 which comes with up to date dependencies that is not necessarily fully compatible with Oolite 1.x expansions. Once we have that watch if oxps get ported or new ones evolve.

[phkb]

While Apple is pushing the use of Metal, OpenGL 4.1 continues to be supported on Mac. Does Oolite require OpenGL > 4.1?

Check out this thread for my adventures (and failures) in getting Oolite to use OpenGL > 2.x: https://bb.oolite.space/viewtopic.php?t=21662

It may be supported, but getting Oolite to actually use it is another thing entirely!

[another_commander]

I started typing out a detailed response to the above points but realized that it doesn't really matter. I am not trying to prove anything here.

mcarans, go ahead with upgrading the JS library. You got this.

[Lone_Wolf]

I think the first step should be to create instructions to built oolite trunk with a different js engine then spidermonkey 4.

That should make it easy to test multiple engines.

[mcarans]

Thanks for giving feedback and encouragement.

I will need to have a convenient way to evaluate the JavaScript library because it may well turn out that the first JavaScript engine I try does not work as hoped. I think it will be helpful to write one or more tests that run JavaScript scripts to exercise some of Oolite's code. Ideally, these tests should be able to run without actually starting the game. This alone might mean a bunch of refactoring and I'm no expert in Objective-C. I'm considering trying QuickJS-ng, Duktape and/or modern Spidermonkey in no particular order as I'm thinking about and collecting any feedback on which engine might work well and be easy to build on different platforms. Another option could be Chromium's V8 (which has an MSYS2 package) - it would probably be the fastest and is likely to be around for a long time to come, but is more complex. If all else fails, then I'll try to properly integrate the current FF4 as part of the build on both Linux and Windows which would involve figuring out precisely what changes were made to the Windows version and possibly simplifying its build scripts. Whatever process results will need to be documented, but I'd likely aim to make an MSYS2 package of the JS engine if it doesn't already exist.

I think that in view of what I said earlier about project health, I will first focus on completing an Ubuntu build script using the current FF4 engine which I can build from scratch and use successfully on Ubuntu. I will then try to port the build to Flatpak. This way we get something working out there sooner rather than later. I had intended to complete these earlier but got distracted by trying out Clang Obj-C 2.2 which turned out to be a good diversion since it works on Windows and Linux and appears to produce more performant code (as well as being better supported by GNUStep with some additional lldb debugging features).

EDIT: just came across this MSYS2 issue opened last week to add Spidermonkey as an MSYS2 package. It doesn't sound promising - one of the linked issues says "SpiderMonkey requires both ATL and MFC on Windows. This is the reason why there is not yet a package for mozjs on MSYS2.". Mozilla provide their own build system that includes a customised MSYS2 so I think that rules out using a new version of Spidermonkey in Oolite with system MSYS2 (which quite possibly saved me a wasting a lot of time trying to get it working).

[hiran]

Unit tests is a great idea. Yet the Oolite source looks like there aren't any.

However there is this repository that might be reused:
https://github.com/OoliteProject/oolite-tests

From what I understood these tests would run in the Apple XCode IDE. Hence I believe they have not been applied for quite some time.

[mcarans]

Unit tests is a great idea. Yet the Oolite source looks like there aren't any.

However there is this repository that might be reused:
https://github.com/OoliteProject/oolite-tests

From what I understood these tests would run in the Apple XCode IDE. Hence I believe they have not been applied for quite some time.

It doesn't look like those tests exercise the OXP code much unfortunately, but it would be good to resurrect them.

We really need an Apple developer because the codebase is predominantly in an Apple language so there is probably a greater chance of encouraging a Mac developer to get involved than a Windows or Linux one. To do that means getting the Mac build working again somehow.