Originally Posted by
Andreaz
One comment more i have is that your TLUA class contains both the wm and the script source in one class, would love to se an seperation there, meaning that you can run multiple scripts in the same wm, thus you have a shared vm where you can run a list of precompiled scripts or functions in thoose scripts.
What does WM stand for?
Originally Posted by
Andreaz
I'm not a expert of lua myself but as far as i have understod yuu can have many instances of the luaVM actictive and every instance of it has its own set of global variables that can be shared between many scripts, wich would be a nice thing to have easy access to.
Well, I'm no expert, but I'm quickly becomming one. Very quickly in fact
.
Originally Posted by
Andreaz
The whole idea behind this is that the user shouldnt need to call any core lua functions if he doesn't wants to, ie he dont need to know anything about the lua interface to be able to include his scripts and functions in a easy way.
Completely agree, see the rest of my comments below
Originally Posted by
Andreaz
I will add special functions for word wrapping and text formatting
The next part of the engine is probably to convert the glxtreeem gui engine, (have prewritten gui editor so will save alot of time) but with some changes, if you have any suggestions for it please post em here.
I have sample code for both of these that I use in JumpStart. Its written to work on a generic TCanvas so it should be easily ported. I'll admit though that it isn't pretty nor perfect, and not even close to optimized
. But it works
Originally Posted by
Andreaz
Then we have to deside how to work with game loops and timers, anyone has any good ideas on good solutions ?
Two thoughts; One we distro a compiled version that basically requires the user to write scripts to build there game. Most of what I've written up for JumpStart is completely portable (editors for game worlds and etc...). Two we also have the source available so that more advanced persons can download and build there own wrapper exe as they see fit. Many people won't agree on how game timers and control loops should be implemented. I like state machines for primary control and up front loading for speed. Others will say I'm nuts.
On the subjects about the scripting wrappers. Since DWS, Pascal Script for Delphi, and all of the others are written in Delphi for Delphi they can have some very nice features. Lua is not, and thus some of the nice features just simply can't be implemented without loss of speed or ALOT of effort. I'm not willing to give up speed, and I don't have alot of time.
So my solution is the pas2gen application. Basically it reads a given pascal file and generates a wrapper for your scripting engine. First engine out the door will be Lua (and this is almost complete, god willing and the creeks don't rise, by July 5th). I've spent alot of time on making the application as easy to use as possiable, but it still has its difficulties.
I think that you will find that if we do a good enough job, more Lua people will use the engine then Pascal/Delphi users. Simply put; more people know and use Lua right now then Pascal/Delphi. Its in most of the big games, and people love to mod. At least I'm surprised at the numbers using JumpStart (and its not even alpha release ready).
The largest problem we are going to have (as I see it) with the scripting engine right now is events. They arn't going to be easy. In fact they are going to be quite the pain. I've been working on this problem for quite some time. Hopefully soon I'll have a good working solution (instead of a poor working one, witch I currently have).
On the subject of multiple VM's. Yes you can have multiple VM's loaded at the same time. They do not play well together. They don't know about each other, they don't share process space, and forcing them to do so causes bad things to happen. JumpStart initially had all of these problems. Now I'm moving up to using Co-routines, basically VM based threading. This works quite well. We can run scripts seperately that don't need to know aobut each other. For example the debug console control script will be completley seperate from the game script. Unfortunately the actuall processing of the commands must be in the game script
.
Course all of this is once we get to an multithreaded environment. First it will all be single threaded, I have to walk before I can run, and personally I'd rather see the entire engine stable in single thread mode then migrated to multi-threaded.
Bookmarks