GameMonkey Script

GameMonkey Script Forums
It is currently Mon Nov 20, 2017 3:34 pm

All times are UTC




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Instancing the Machine
PostPosted: Fri Feb 19, 2010 12:29 pm 
Offline

Joined: Fri Feb 19, 2010 12:21 pm
Posts: 10
Greetings!

First of all: I'm a fledgling C++ programmer, meaning that I may use expressions that aren't entirely accurate and may also misinterpret what you're saying or simply act in a misinformed manner. Just wanted to give that little heads-up.

I'm working on a system where I can let scripts run continuously in the background and tell a game system when to load/unload assets based on scripted event functions, via messages from script.

I.e., you could write a script like so:

table RoomOne = {
name = "First Room",
connections = { RoomTwo, RoomThree, RoomFour },
assets = { MetalDoor, WoodenFloor, UglyEnemy }
}

...and the game would then -- if you use either connection -- unload RoomOne and load either of -Two, -Three or -Four, depending on script specification.

I've built the static library and tried to follow the GameDev tutorials and reading through the manual, but I'm so far uncertain how to instantiate the virtual machine. Whether to treat it as something static or to have separate machines per class and somehow tell the game when to expect scripts... I'm not sure.

Most of the examples are written in such a way that they do something, print out the result and then exit. Is there anywhere a fundamental example of a "complete" game or workflow that's possible for a n00b like myself to grasp?

Sorry if I'm not phrasing a real question or asking for too much, here, but any kind of help would be very much appreciated!


Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 19, 2010 2:55 pm 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 698
Welcome to the forum Devain :)

You will normally need only one or two instances of gmMachine. Perhaps one for in game use (which lives during the lifetime of a game level), and perhaps one for other game superstructure or level loading scenes. Take care of you are using multiple OS threads for this as GM is not 100% thread safe, the compiler needs a mutex.

Since you will only need one or so instances, you may want to have the main one accessible as a singleton or just a publicly accessible instance pointer/reference. That is really up to you. Whether you want to re-create a gmMachine each level start or just clean it out is up to you. It should be stable but you may want a fresh start anyway.

Scripts can run continuously in the background. They will do this already as each native call to script is actually a script thread, but do use the gm thread functionality for best effect. Also remember GM does not use preemptive threading, it is cooperative routines so make sure the threads regularly sleep, yield or block so they don't hog CPU time. Each game frame or such just pump the gmMachine::Execute() to keep it running.


Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 19, 2010 4:30 pm 
Offline

Joined: Fri Feb 19, 2010 12:21 pm
Posts: 10
Ah. I see. So, really, what I do is treat the whole application like a single scope and then create another instance only while it's being used. I think a single instance is enough in that case.

Just found the "Game Object Extensions" part of the Reference document. I'll dig into it and see what I can come up with! Looks like a perfect match for my needs.

But I can't promise that I won't ask more questions. ;)


Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 19, 2010 5:10 pm 
Offline

Joined: Fri Jan 14, 2005 2:28 am
Posts: 439
I can't really think of a situation where you would ever need more than 1 instances of a gmMachine. Can you elaborate on that?


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 20, 2010 12:05 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 698
DrEvil-OB wrote:
I can't really think of a situation where you would ever need more than 1 instances of a gmMachine. Can you elaborate on that?

DrEvil, I think the only time I used 2 gmMachines was when I used one to process some things during level loading in one thread (eg. display play tips during loading screen) while the other machine was actually being populated with level data / configuration. Since GM does not work with multiple OS threads accessing the same machine, this was useful to eliminate unnecessary OS thread blocking. Other than that, a paranoid programmer might want to keep the current game VM, which is instantiated on level load, separate from a VM running the super structure (menus, game flow etc) but there is no necessity to do so.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group