Is BriskVM dead? How do I get hold of?

Blitz3D Forums/Blitz3D Programming/Is BriskVM dead? How do I get hold of?

videz

(Posted 2014) [#1]

I have heard and seen this feature on games and tools that I played around with before I shifted to blitzbasic.

So is there a way to get hold of this nifty tool. Free or paid? What is the status?

Going to the author's site im getting 404
http://koriolis-fx.com/

xlsior

(Posted 2014) [#2]

It's been discontinued:

BriskVM is now discontinued

Hello fellow BriskVM users.

It has been a while now that any activity around BriskVM has fell flat, both from the users perspective and from my part.
Truth is, even though I could always find new features to add and things to rework, I have long reached the point of diminishing returns where any attempt to enhance
BriskVM would not bring anything subtantial and actually turn it into something it was not meant to be.

In any case, there is only so much one can do in 24 hours, and it's time to acknowledge that I simply moved on to focus on different things.

Anyway, it's been a thrill to work on BriskVM while it was still very much alive and kicking.

BriskVM is dead, long live BriskVM!

Best regards.

Régis JEAN-GILLES (AKA Koriolis), author of BriskVM.

Link: https://web.archive.org/web/20130921061837/http://www.koriolis-fx.com/index.php?id=106

Zethrax

(Posted 2014) [#3]

Pity this wasn't made available somewhere (Sourceforge, Google code, etc). A lot of useful tools have fallen off the map over the years.

Which is part of the reason many don't get acceptance to begin with. People are always wary of a new tool, library, etc being "here today, gone tomorrow" with outstanding issues unsolved. I've bought a few things that went that route, and avoided a few because I was wary of them.

videz

(Posted 2014) [#4]

Yes, it is a shame the author did not opensource it. Maybe someone who's still active here and knows him then he/she could contact him about releasing it?

GW	(Posted 2014) [#5]

BVM is one of the finest blitz related products ever imo.
It's a near exact copy of Blitzmax including function pointers, ref arguments, the module system and an integrated debugger, except it runs on its own virtual machine. It's even extended with jobs, processes and green threads(tasks). If Régis were to take the AST generated from BVM and make it spit out C code, I would personally fly to France and pin a medal on his chest. I've used BVM in a lot of projects and it's an amazing package.

Yasha

(Posted 2014) [#6]

BVM was certainly a fine piece of engineering.

But I never did understand the point of it. BlitzMax is a really poor choice of scripting language (too verbose, wrong type system, incredibly obscure - scripting code doesn't need to, and shouldn't, look like app code; the purpose of script capability is to cater to people who aren't the developer). I assume that was eventually part of its undoing as a commercial solution; good tool for the wrong task.

GW	(Posted 2014) [#7]

I think BVM mirroring bmax and b3d has the advantage that the developer is already familiar with it. just that alone goes a long way. All your critiques of BVM could just as well apply to Bmax as well. As it stands, I disagree with them. Mentally switching gears between BMax and another language (lua/Angelscript) is more taxing imo, not to mention dealing with all the glue code issues (which BVM doesn't have).
I think it wasn't that successful for a few reasons.
1. No one knew about it.
2. although BVM could be used from c++, other languages already have traction there.
3. It was always a side project for Régis.
4. It was originally written for people who wanted to add scripting to Blitz3d programs. Because B3d doesnt have function pointers, an auto generated bridge is used and that can cause a performance hit depending on the amount of functions you export to bvm. Mark has to share some blame here too because select/case expressions are compiled to nested if's instead of a jump table.
5. LuaJit + Lugi can often be a better solution now.

Regardless, BVM has it's place in my toolbox. I'm glad it exists and still endorse it.

Yasha

(Posted 2014) [#8]

That's exactly what I mean though: similarity to the language the developer is using is a "false friend" attribute. It's not a desirable feature for a scripting language, and mentally switching gears absolutely should be necessary.

Why? Because scripting is used in two main situations:

1) where someone else is going to write and mod them. Scripts should be accessible to outsiders, not go out of their way to make it easy to blend with app code at the cost of the main functionality. There should be a hard delineation that encourages to dev to keep their stuff separate and put internal code in the native section. You shouldn't be writing your own scripts.

2) where the programmer wants to use "two level programming", where you use two languages, usually a C core for performance in the loops and a nice language for the parts that can afford to be slow. In this case being different is the point. (this one is largely irrelevant, not what BVM is really for)

BVM differs from BlitzMax on point 1: Max is a native language and it doesn't matter if your users don't know it. BVM is a modding language, but your users definitely don't know it.

JaviCervera

(Posted 2015) [#9]

As others have stated here, it would be amazing if Régis releases the source code of BriskVM (and even better if it were under a license like Zlib, so static linking on iOS would be possible). Does anybody have a way to contact him?

videz

(Posted 2015) [#10]

or anyone has a full working copy here?? since this is already abandonware might as well share the bounty.. ;)

I heard it works with B3D/B+ but if this is for blitzmax only then I'll pass..

xlsior

(Posted 2015) [#11]

or anyone has a full working copy here?? since this is already abandonware might as well share the bounty.. ;)

Still illegal to do so - You have no rights to redistribute, regardless of whether or not the author stopped selling it.

videz

(Posted 2015) [#12]

Ok understood. how about a demo? I'm just curious how this works and if its worth it.

Otherwise, creating a LuaJIT front end would be an alternative.

Yasha

(Posted 2015) [#13]

Every major scripting language other than BVM is a pain to use with Blitz3D because they assume function pointers are available for hooking back into the host program. BVM is special because it was designed with B3D in mind and works around their absence (other engines don't offer this because basically every language other than B3D doesn't have such a bizarre limitation).

So to use another script engine such as LuaJIT, you either need an additional userlib to hack in function pointers - these exist and are stable, although it feels odd to use them - or you need to do some very heavy lifting and write a completely new engine frontend (nontrivial). Your third option would be to use a script interpreter implemented in B3D code... don't know of any good ones. (maybe it's worth translating Lua?)

(Not providing hooks into the host program renders a script language essentially worthless , for obvious reasons.)

Of course once you start looking into things like LuaJIT, you have to ask what B3D is contributing. Weird relationship when the "host" runs ten times slower than the "script".

videz

(Posted 2015) [#14]

Yes, the LUAJit thing is just an idea. I did find some cool interpreter scripts that I might try. but I'm still curious what this BriskVM do

Any demo link I could try out?

Of course once you start looking into things like LuaJIT, you have to ask what B3D is contributing. Weird relationship when the "host" runs ten times slower than the "script".

umm.. The 3D part ;-) I just need to test if a user "mod" able game is possible in B3D.. and what are my options

Spencer

(Posted 2015) [#15]

Blitz3D is open source, so couldn't you just include the actual compiler? Perhaps limiting the capability of user scripts, while allowing full access the games scripts. Then compile the whole thing (your game source + user scripts) at runtime.

xlsior

(Posted 2015) [#16]

You'd need visual studio to be installed to do the compiling, while you don't have additional dependencies like that when using using a scripting language to link extra code in.

Spencer

(Posted 2015) [#17]

I guess I should clarify: When you install the free version of Blitz3D, I think you also install "...\Blitz3D\bin\blitzcc.exe" I was under the impression that this was the B3D compiler, so you could write a Blitz3d program that references this compiler (and the linker etc). The first part of the build step would concatenate your game's source files with the script files. Next you save that blob of text into a single ".bb" file. Then you pass it thru the usual compilation steps. Then launch the program. Although as I read what I just wrote, it could be pretty dangerous.. lol. But, that's what i was suggesting.

Spencer

(Posted 2015) [#18]

This post lists the command line options, testing them now...

http://www.blitzbasic.com/Community/posts.php?topic=44544

Spencer

(Posted 2015) [#19]

OK so it works, but there are a few gotchas.

You need to set an environment variable BLITZPATH = "C:\Programs\Blitz3D\"
Or to wherever the root Blitz3D directory is.

Then from the command line call the compiler as follows

blitzcc.exe "C:\some_file.bb"

This will compile and run your program.

I think you can set environment vars from within Blitz3D, so this could be possible.
http://www.blitzbasic.com/b3ddocs/command.php?name=SetEnv&ref=2d_cat

Spencer

(Posted 2015) [#20]

Well it seems to work... not sure if its a good idea without some sort of control over the script side of things, but you could parse the scripts and check for IO or whatever else you didn't want to run... here's the program i wrote to test it, ( Also added it to the Code Archives)

Updated AUG-5-2015 to match screenshot. also fixed the "Chr(10) + Chr(13)" --> now "Chr(13) + Chr(10)". Includes some additional constants representing the paths.

Graphics 640, 480, 0, 2
AppTitle "Blitz3D Game Launcher"

Const SCRIPT_FOLDER$ = "C:\MyGameFolder\scripts\"
Const SOURCE_FOLDER$ = "C:\MyGameFolder\source\"
Const OUTPUT_FILEPATH$ = "C:\MyGameFolder\output.bb"

Const BLITZ_PATH_VAR_NAME$ = "BLITZPATH"
Const BLITZ_PATH_VALUE$ = "C:\MyGameFolder\"
Const BLITZ_COMPILER_PATH$ = BLITZ_PATH_VALUE + "bin\compiler.exe"

Global BLITZ_CMD_TEMPLATE$ = Replace("'" + BLITZ_COMPILER_PATH + "' '{PATH}'","'",Chr(34))
Global NEW_LN$ = Chr(13) + Chr(10)


Function CompileAndRun(CodePath$, ScriptPath$, DestPath$)

    Local FullSource$ = ConcatSource(CodePath,ScriptPath)
    Local Command$ = Replace(BLITZ_CMD_TEMPLATE, "{PATH}", DestPath)
        
    WriteAllText(DestPath,FullSource)
    SetEnv(BLITZ_PATH_VAR_NAME, BLITZ_PATH_VALUE)
    Print GetEnv(BLITZ_PATH_VAR_NAME)
    Print Command
    Input "Press ENTER to run..."
    ExecFile(Command)
    End

End Function



Function ConcatSource$(CodePath$, ScriptPath$)

    Local SourceCodeBlob$ = ConcatFiles(CodePath)
    Local ScriptBlob$ = ConcatFiles(ScriptPath)
    Local FullSource$ = ""
    
    FullSource = SourceCodeBlob
    FullSource = FullSource + String(NEW_LN,2)
    FullSource = FullSource + ";" + String("*",80) + NEW_LN
    FullSource = FullSource + "; SCRIPT SOURCE BEGIN" + NEW_LN
    FullSource = FullSource + ";" + String("*",80) + NEW_LN
    FullSource = FullSource + String(NEW_LN,2)
    FullSource = FullSource + ScriptBlob
    
    Return FullSource

End Function


Function ConcatFiles$(Folder$)

    Local DirStream = ReadDir(Folder)
    Local FileName$ = ""
    Local TextBlob$ = ""
    Local FilePath$ = ""
 
    NextFile(DirStream) ; skip .
    NextFile(DirStream) ; skip ..

    Repeat
    
        FileName = NextFile(DirStream)
    
        If FileName = "" Then
    
            Exit
        Else
            FilePath = Folder + FileName    
            TextBlob = TextBlob + ReadAllText(FilePath)
    
        EndIf
    Forever

    CloseDir(DirStream)
    Return TextBlob

End Function


Function ReadAllText$(Path$)
    
    Local Stream = ReadFile(Path)
    Local Contents$ = ""
    
    While Not Eof(Stream)
        Contents = Contents + ReadLine(Stream) + NEW_LN
    Wend
    
    CloseFile(Stream)
    Return Contents
    
End Function

Function WriteAllText(Path$, Contents$)
    
    Local Stream = WriteFile(Path)
    
    WriteLine(Stream,Contents)
    CloseFile(Stream)
    
End Function



CompileAndRun(SOURCE_FOLDER,SCRIPT_FOLDER,OUTPUT_FILEPATH)

RGR	(Posted 2015) [#21]

Very interesting - had BriskVM and played around with it when it was launched - but did not find a usage in those days for it.

While looking over the code above ... 2 things:

Global NEW_LN$ = Chr(10) + Chr(13) should be Chr(13) + Chr(10) - if only to totally exclude misinterpretations. .bb (and txt)-files use RET LF - not LF RET

And the Blitzpath thing ...
As I understood blitzcc.exe is in this case used as part of an app ... so the user will not have Blitz3D installed ... but gets blitzcc.exe etc. with the app and it is now in the app directory anyway. And should work from there. SetEnv ?

Spencer

(Posted 2015) [#22]

Good Catch RGR, updated the post and the code archives. Thanks for checking it out!

Regarding SetEnv
In testing i found a few more gotchas.

1) you MUST set the BLITZPATH variable. otherwise the compiler spits out an error.

2) The blitzcc.exe requires 2 other files. linker.dll and runtime.dll

3) These 3 files must be in a sub-folder called "bin".

4) This sub-folder must reside in the folder to which BLITZPATH points.

Normal Location

BLITZPATH = C:\Program Files (x86)\Blitz3D164\

Compiler Folder = C:\Program Files (x86)\Blitz3D164\bin\

Custom Location

BLITZPATH = C:\MyGameFolder\

Compiler Folder = C:\MyGameFolder\bin\

5) The "blitzcc.exe" can be renamed to something else, but the linker.dll and runtime.dll must stay the same. I renamed "blitzcc.exe" to "compiler.exe" and it still functioned.

SO, you can move the compiler, and rename it, but it must stay in the "bin" folder. Here is a sample folder layout.

I should say that this is merely a proof of concept. If you were distributing a program in this fashion you might want to do a couple of things:

1) "Scrub your Inputs" - Parse the user's script files and stop if there are any dangerous commands. File I/O is a good example. You don't want the user to read/write to files. So, you will need to parse and analyze the script files and throw an error on unwanted code. This is totally possible, but the code becomes more complicated and it would muddy up this example.

2) "Protect your Source" - Find a way to obfuscate you source files in the "source" folder. This way users can't easily alter the Game's source code. There are many different ways to do this, but they were omitted from the example code for clarity.