Blitz Virtual Machine rocks!

I have purchased BVM yesterday, and it's totally awesome. I am making some test to implement it into my game engine, so I can code the behaviour of my entities using scripts :)

I have some question about it tho:

I want my engine to do the following: When the engine runtime (the EXE) is executed, it loads all the .bbm modules it finds on its resource paths (by default, the EXE's folder, but you can define more paths), and then executes the main script (the same name as the EXE, but .bbm extension).

I can load a world in that script with the function csWorld_Load("world.b3d"). The world can contain some entities. For example, it would contain an entity named "info_player_start". In that case, one of the scripts loaded at bootup should contain a function called "info_player_start".

On the main loop of the main script, I call the function csFrame(), which wraps UpdateWorld, RenderWorld, Flip, and updates the entities.

To update the entities, i search on all the modules loaded for a function with the name of the entity. If that function is found, then i set that function as the entry point and call it. The problem is that BVM_Run() gives a "Memory Access Violation". Would you please Koriolis show me an example on how to do this? It's basically execute one script, which calls a function from another script and then continues executing.

It's maybe because i have both the main script and the entities scripts in the same contexts?

I have no idea what a virtual machine is?

Can anyone help?

IPete2.

I have no idea what a virtual machine is?

Can anyone help?

IPete2.

google good...

http://koriolis.free.fr/news/index.html

A virtual machine is an application that acts as a processor. The usefulness of Blitz Virtual Machine is that it works embedded into a Blitz program.

You can for example create a script (which is simply a blitz source file) which controls every element in your game (the player, the enemies...) and compile them to bytecode (this would be understood as the 'machine code' that your virtual machine understands). Plug the scripts in an 'entities' folder (for example) and use the virtual machine from your main Blitz program to execute the scripts and control the entities using them.

it's been posted about alot, maybe you should do a search on here for it.

Cool :) Are you close to a demo? I can't wait to see some kick ass production using BVM.

It would probably be better to keep the main loop in your host application, and to call in this loop a function in your "main script" that updates the entities. But that's only an advice.

If I understand correctly, you're trying to load & execute a script from within another script. If so, you should either:
1) put your updating function rather in the host program, and use the scripts only for your entity functions. There shouldn't be any problem.
2) if you really want to load & execute them from within another script, then you should indeed put your "main" script in another context.
I think I can make it so what you do right now works as is (I'll give you a firm answer on that issue later), but in the current version this is not doable that way.


BTW, the OO feature together with another one (I won't say too much right now, forgive me, as some things are still likely to change) that I'm adding will allow to do thies kind of things in much neater and simpler way :)
Shouldn't be that hard to convert your system later (when I release the new version), if you're ready to take the plunge into OO.


[EDIT]For questions, you may as well post on my new forum. Having a central place for this is better for BVM users[/EDIT]

Thanks guys,

I understand a bit more now.

IPete2.

Why not try this:

If all of your entitys are going to behave the same way, why not write one script
that process' that control.

Your script will have a function that takes a Type as a parameter. like:

Function Update_Entity(E.Entity)

	;; do something with the E type instance
	
End function 

Your entitys are created and defined in your main application, and exposed to the scripting engine
then simply pass each entity into the function and process them.

example:

;; setup your BVM context here ;;

For E.Entity =  each Entity
	BVM_PushInt(Handle(E))  
	BVM_SelectEntryPoint( <your entry point> )
	BVM_Invoke_<whatever>()
	BVM_PopInt()
Next 

(typeing from memory, the syntax may not be correct)

That way when you want to change the way your entitys behave, you just alter this one
script and reload. ;-)

Yep, that's grossly what I had in mind with point (1). It seems the simpler and effective alternative to me.

One note: better not use directly "Handle" to push the object, but rather use BVM_Push<TYPE>_<CMDSET> (cf the doc) and pass it the object. That way if I ever change the way objects from the host app are passed to BVM, that won't broke your code.

To refine it a bit, it *could* be:

;; setup your BVM context here ;;
;; let's have an additional field in Entity named 'hEntryPoint', that you previously intialized
;; to point to the suitable entry point (according to the entity name)

For E.Entity =  each Entity
	BVM_PushEntity_<CMDSET>(E) 
	BVM_SelectEntryPoint(E\hEntryPointP)
	BVM_Invoke_<CMDSET>()
	BVM_PopInt()
Next

And to avoid letting the scripts accessing the 'hEntryPoint' field (which they don't need to), just don't mention this field in declaration of Entity in the command set file.

But again it's all up to Jedive to decide what suits best his needs.

Thans for your answers. I worked on this very hard last night, and I have ducesfully implemented BVM in my engine the way I wanted to do it.

It were easier than I thought. I just created one context for the main script and another context for the entities.

When the csFrame() function is called from the main loop of the main script, it handles the entities the following way:

- Change the current context to the entities one.
- Do a For... Each loop to hanle all the entities (each entity has a Type variable)
- The entity var has a field with the script module of the entity, and another field with the entry point to the function that controls the entity, so i set the correct entry point for the context, i pop the entity, and invoke the virtual machine.
- After all the entities are processed, i restore the main context.

The good thing is that it works perfectly now and I have only lost 5 fps as much (the Century map ran @ 120-125 fps before with collisions and entities on it, now it rans @ about 120 fps).

A function that controls an entity has the following structure:

Function info_player_start(entity.csEntity)
Select Entity\Msg$
   Case "MsgCreate"
      ;Stuff that the entity has to initialize (mesh that it uses, etc)
   Case "MsgFrame"
      ;Standard frame nessage, the default message it receives every frame
   Case "MsgDestroy"
      ;Free stuff here, cos the entity will be deleted after executing this function
End Select
End Function

"MsgFrame" is the message sent when no entities has sent a message to the current entity. A bullet would for example sent this entity a "MsgBulletHit" message, and this entity would react to this message (decrease health, etc).

I would like to see something on BVM: The possibility to define constants in the .bcs file. The engien uses a lot of constants for the function flags, and now I have to include a file on all the scripts. I would like to simply add these contants to the .bcs file and this way these constants are known when compiling the scripts :)

Oh! And '[]' type arrays would be also cool :D But this is not that important for me, I am currently simply hiding array fields inside types to the scripts, and read them using functions.

That's some nice news :)
I'm particularly glad to read as the apparent complexity of implementing BVM is really this: an apparence. And as I always say, this setup is done once for all, so everything should go very smoothly now :)

Now you have no good reason not to release some demo soon, eh eh ;p

Agreed, it would be nice. I had originally considered this, but it wasn't very high on my TODO list as it's not required at all (using an include file as you do works without any problem), but "only" a bit more handy. I think I will add this, that will be more convenient that way.

I don't know right now if I will add it.

What Koriolis said is good advice..
Move *all* of your constants to an include file.
Include that same file in any script that needs them. that way all your constants are always synchronized. It also helps with the manageabilty of your codebase.

Actually GW, you'll see that's what Jedive currently does if you read more carefully his post :p

He's asking for being able to put some constants right in the bcs file. And indeed, for constants that are really part of the core engine it makes some sense to have them right in the .bcs file along with the exposed funcitons and global variables. That's why I'll probably add this possibility.

Sounds very interesting, Koriolis. When I first started with Blitz years ago, I couldn't care less about OO stuff, but as I've learned more, I've developed a hunger for it. One can sort of implement it in Blitz3D as it now is, but it's clunky. So, while waiting for BlitzMax (though it's taboo to mention that these days <g>), I look forward to see what you're doing with BVM. I *almost* bought BVM before, but since it sounds like it'll be getting more powerful, I fully expect to buy it after your next update - thanks. (This isn't just dependent on the OO stuff - I really like what I've seen of BVM.)