BVM 2 beta test : scripting systems made easy

Hello everyone.

I am pleased to announce that the sequel to Blitz Virtual Machine, now named "BriskVM", is entering its final beta test phase.

So what is BriskVM 2 ?
It is a powerfull and easy to integrate scripting system. It currently supports BlitzMax as the host language, but support for other languages is planned.
It is available for Windows, Mac and Linux.

Some of its most noticeable features and/or enhancements since version 1 are:

>> Easy integration.
Integrating BriskVM into your application is rather easy. Indeed, BriskVM's approach to integration is very declarative: you list in a file (the "command set" file) everything that is to be shared between the scripts and the host application , being functions, types or global variables. From this file, the necessary glue code is generated for you. Your task when integrating BriskVM is reduced to the very minimum, and you'll get back to code the creative part very fast.
And not only will it generate everything that is needed to let scripts access the host application, but the reverse is true also : special declarations will generate the needed code
to easily let the host application call any script function (as well as manipulating script objects). No more manual push or pop, it's now all transparent.

>> Eased debugging.
BriskVM makes script debugging easier by including a runtime debugger. You'll be able to pop up a debugger window at any time, and step into your script code like you're probably used to for your "normal" code. The source code of the debugger's GUI is freely modifiable, so that you can pretty easily tailor it to your needs, or even adapt it to use your favorite gui library.
From your code, you can also get the current script stack trace at any time for debugging purpose.
Finally, you can in a few lines of code integrate a debugging console that allows to enter instructions interactively (from within the application).

>> Many optional extensions to the core script language.
The core script language of BriskVM is (just like in the previous version) BlitzBasic itself.
On top of this core language, a set of extensions is available. These extensions give your scripts a lot more power, and make some tedious tasks become trivial. You'll find:

* Object Oriented Programming : take advantage of inheritance and polymorphism.
* Serialization : write and read your objects in just one line of code.
* Reflection : lookup at runtime which types are present, which are their fields, access them etc. Among other things, this gives you all you need to write a *generic* in game editor (that lets the user create new objects and edit them). That is, no need to modify your editor every time you write a new class in some script.
* Annotations : attach meta data - in the form of strings - to your classes and fields, and read them at runtime via the reflection API.
* Function pointers
* Scoping : specify access restrictions to your object's members (Public, Friendly, Protected and Private)
* Alternative syntax : use an alternative BlitzMax-like syntax, more natural to most programmers.
* Option Explicit : force explicit variable declaration and let the compiler catch typo errors.
* Garbage collector : objects manipulated by the scripts are tracked by a garbage collector. It means memory managing and object's life time in scripts are gracefully handled for you.
Nonetheless, you can still manage an object's life time manually, if it happens it better fits your need.
These 2 policies nicely live together without interfering, in a straight forward way: types deriving from Collectable (directly or indirectly) are entirely handled by the garbage collector, otherwise their instances have to be explicitely deleted.
* Handy syntactic sugar:
o Type inference on variable declaration:
Simply write "Local myVar? = New MySuperDuperType" instead of the too verbose "Local myVar:MySuperDuperType = New MySuperDuperType"
o Properties: transparently use getters and setters as if you were accessing a true type field.
Never write again
obj.setLocation(obj.getLocation() + obj.getSpeed())
Just write
obj.location = obj.location + obj.speed
You're still using getters and setters, but transparently, without the kludge.
o For EachIn : iterate over any collection without having to bother with loop indexes or iterators. Just do "For myVar = EachIn myList ..."

In accordance with BriskVM's aim of customizability, most of these extensions are optional and can be enabled or disabled depending on your specific needs.

As a side note, you'll also find that arrays handling is a bit more powerful than in the original BlitzBasic language, as you can now have multidimensional arrays in your types.

>> Documentation system.
If you plan to use scripts for a significant part of your application, documenting at least the base types and functions is definitely a plus. Especially if you're going to let the end-user modify and extend them. To ease the writing of this documentation, BVM includes a documentation generator similar to JavaDoc or the C# doc system. The generated document is in XML format, with a provided default style sheet to view it as HTML. Thus the documentation layout is not freezed, and you can entirely customize it.

>> Straight forward script imports
You can now import other compiled scripts in a transparent way, with a simple declaration:
Using "myModule.bbm"

>> Mix different command sets in the same execution context
It is now possible to use different command sets in the same execution context. So by example a script could import another script that uses a totally different command set.
This makes everything more flexible, and in particular allows to easily share compiled scripts with other BriskVM users : even if compiled with another command set, the
imported module can work with your very own command set provided that yours do provide the same needed functionailities.
This is made possible through the use of dynamic linking with the host application.


For more information, please visit http://www.koriolis-fx.com/


----------------------------------------------------------------------------------------------------


This beta test phase is semi public, meaning that only registered BVM 1 users may get their hands on the beta version.
Nonetheless, anyone is free to browse the online documentation, or participate on the forum. If you have suggestions, feel free.
When the beta test is over, BVM 1 registrees will get a free upgrade to BriskVM 2.

Please note that purchasing of BVM 1 is temporarily suspended.

BVM 1 registrees should have received a mail with instructions to get the beta version. For anyone who hasn't, please send me a mail with your registration information here:
koriolis <dot> fx <at> gmail dot com

awesome, finally here :-)

The new features of BVM2 are really useful, and it is much easier to integrate and maintain now.

Yep got your mail! Really useful and flexible.

Very interesting! When will it be available?

I can't tell for sure right now. It heavily depends on the feedbacks I will have from the beta test phase. It is actually already very useable (and *is* actually used, in particular by Joshua Klint), but work to do includes:
- enhancing the documentation
- fixing minor bugs here and there
- reworking a few existing features (mostly renaming, for consistency).

The rest all depends on the feedback and suggestions.
If I was over optimistic I'd say in matter of weeks, but let's be more rational : maybe a matter of monthes. Releasing anything below my expected level of quality is NOT an option :)

Wow, great news!

What format do serialized files take? Are they human readable/editable? Is the format layout configurable?

Sounds great so far.

Compiled scripts files (modules) are in a compact binary format, totally not human readable. Even string literals are not readable.

Serialized objects are serialized in a similar (binary) way, but in the current version strings are readable. I will change that asap. And I'm going to add the ability to customize somewhat the implementation of individual integer, float and string serialization anyway. But the overall layout will stay fixed, it will not be configurable (only the way integers, floats or strings are written will be).
However, I plan to finish a binary format to XML converter (both directions), so that you can then work on a human readable version of serialized data.
Ensuring that the end user can't access that human readable version of the serialized data can be achieved very easily with basic encryption of the binary version (the one BriskVM works with).

What does it take for someone who doesn't own BVM 1, to get his mittens on BVM2 (for instance) tomorrow? ... I sent you an email from your website, but didn't get any response :) You can email me at giles snail frecle dot net ... if you want.

Concerning the contact form, it seems there was a problem with it. Looking at the page code I'm clueless as to why it didn't worked, so I simply did a quick and dirty change, did a try, and it now works as expected.

The reason why the beta is only open to existing BVM 1 users is very pragmatic, it ensures that people reporting bugs or suggesting enhancements have at least a basic understanding of how BriskVM works (not that it's so hard to grasp, but anyway).
This makes it unlikely for me to be flooded with total beginners questions, and also gives me more time to enhance the documentation (existing users are at this stage more likely to forgive a few documentation lacks here and there).

I will contact you to see what can be done to statisfy people in your position. In any case I'm certainly glad to see you are potentially interested in BriskVM. [edit]for information, I've finally settled for a special case arrangement with fredborg[/edit]

I actually want the user to be able to edit serialized data. Will this be possible, or should I use some other method (INI?) to get my data in (and out)?

why would you want that? it like having the user edit an encrypted file?
Anything that can be serialized can be unserialized

Then you could simply give him access to the XML version of the serialized data. Just DON'T encrypt it, and that's about it.
Or even better, provide a GUI to edit the objects from inside the game. This can be achieved using "reflection" (it is the primary intended use of this feature).

It's more about "obfuscation" than real "encryption". You usually don't want the end user to easily be able to tweak savegames by example, this would remove any challenge if it was so easy to do.

Cool, I will check it out!

Are there any speed comparsion benchmarks beetween native BlitzMax code execution and BriskVM script execution time?

Here's a quickie test I just threw together and tried in the BVM2 beta (debug off in all cases):

Local start = MilliSecs()
Local a# = 3.14, b# = 17.76, c#
For Local i = 1 To 100000
	c = a / Rnd(20) * b / Rnd(17)
Next
Print MilliSecs() - start

In BlitzMax it took 40 millisecs. In BVM2 it took 287.

And another:

Local start = MilliSecs()
Local a$ = "here's a test string", b$ = "and another string", c$
For Local i = 1 To 1000
	c = c + ( a$ + b$ )
Next
Print MilliSecs() - start

In BlitzMax it took 69 millisecs. In BVM2 it took 36.

WendellM, BriskVM now includes built-in mathematical and random number functions. This means you don't need to expose similar functions, and as a nice bonus it's faster. So you can remove the declaration for "Rnd" in your command set, and replace

	c = a / Rnd(20) * b / Rnd(17)

with

	c = a / Rand(0,20) * b / Rand(0,17)

With the latter change, the BriskVM version is then even faster than BlitzMax on my computer.

As for the second test, I can confirm that string manipulations are not significanly slower than in pure BlitzMax, and actually often faster (as is the case here).

In any case, I'd like to point that pure speed is not the main concern as far as scripting goes. Classical virtual machines are necessarily slower than pure machine code,
but if well written it should be plenty fast enough to run all your high level code without any significant slowdown.

So you'll ask, is BriskVM fast enough? I've done a few quick benchmarks to give you an idea of the speed, and here are the results:

- Benchmark 1 : fibonacci ( fib(30) )
BriskVM 2 is 2.8 times slower than BlitzMax

- Benchmark 2 : Simple loop
BriskVM 2 is 3.6 times slower than BlitzMax

- Benchmark 3 : Simple string manipulation (concatenation + substring search)
BriskVM is 1.9 times *faster* than BlitzMax

- Benchmark 4 : iterative computation of PI
BriskVM is 13 times slower (that's still more than decent, just take a look at some other scripts/native code comparisons)

This tends to show a pretty good speed.
If someone wants to see the source, just ask and I'll post it.

Again, these numbers should really be taken as very rough estimates, and not be given too much importance anyway.

Thanks, Koriolis. I tried what you mentioned, and that first BVM2 test is now down to 54 millisecs for me compared to the native BlitzMax speed of 35 - much closer.


I agree, but it's still impressive to see how well BVM2 is doing. It's in the same general area in most cases - well done!

Thanks :)

really stunning performance comparisions.

Seems that BriskVM has great perfomance, thanks for sharing benchmarks results.

I should also have mentioned that you can try the scripts *online*.
There is a link on my site to an online sandbox where you can enter script code snippets and execute them (you can also simply follow the link in my signature).
It's a good place to go to get a feel of what it is to write BriskVM scripts.
You can even submit code snippets that you find interesting, for others to try out.
But please don't flood it or I'll have to remove it.

I have just finished the implementation of exception handling.
This means that you can now throw and catch exceptions in your scripts.
I have uploaded a new build of the beta.
Documentation is not updated yet (nor is the sandbox), but exception handling uses the same syntax as in BlitzMax so hopefully this should be pretty straightforward to anyone.

The next step is to add support for "Finally" (as found in C#, Java, python ...), and to find the best way to convert some BriskVM runtime script errors (such as dividing by zero, currently reported to the host via an error code) into exceptions.