🔒 Locked
[ANNOUNCE] ScriptVision - Easy Lua Scripting API
Advertisement
Original Post
[About] ScriptVision, a simple, yet elegant API for Lua. Any language that supports standard WIN32 DLLs can be used. Also, ScriptVision can work seamlessly with various syntax highlighting editors such as conTEXT. [Features] * Based on Lua 5.0.2 * Easy, robust API interface * Bindings for Delphi & C/C++ * Works with any language that supports standard DLLs * Use the stdcall calling convention for maximum compatibility * Support for: * Error handling * call native/script routines and pass/get params * structs in both script/code * globals in both script/code * many stack oriented routines * run script from memory buffer or from disk * debug interface * And more [History] Version 1.0.3 * Added C/C++ Bindings Version 1.0.2 * Added SV_AddLibrary routines Version 1.0.1 * Initial Release [Download] ScriptVision 1.0.3 (~400KB) [Support] * Any feedback and suggestions would be most appreciated. * See the README.TXT for support details. [Edited by - BigDaddyGames on March 22, 2005 11:15:07 AM]
What sort of license? (L)GPL I assume?
Hi,
The plan was to allow anyone to use it in binary form for free in both commercial and non-commercial projects in exchange for feedback. SVDLL is the stand-alone version of GVScript which part of our game engine GameVision we are using to build our game projects. I've been working on GVScript for a while now and it seems to be pretty stable. I even got the debugging interface to a good point. Using the API, you can hook into an editor and step through the code. The editor that I was working on will even display the local stack frame. There are a few more little things relating to debugging that I still need to do otherwise I think it's pretty stable. I was hoping to get some feedback from other developers.
We are currently developing for the Windows platforms so there are only Win32 binaries at this time.
The plan was to allow anyone to use it in binary form for free in both commercial and non-commercial projects in exchange for feedback. SVDLL is the stand-alone version of GVScript which part of our game engine GameVision we are using to build our game projects. I've been working on GVScript for a while now and it seems to be pretty stable. I even got the debugging interface to a good point. Using the API, you can hook into an editor and step through the code. The editor that I was working on will even display the local stack frame. There are a few more little things relating to debugging that I still need to do otherwise I think it's pretty stable. I was hoping to get some feedback from other developers.
We are currently developing for the Windows platforms so there are only Win32 binaries at this time.
Here is a small demo showing a 3D star field created using ScriptVision. Some things of interest:
1. This example uses the Delphi bindings.
2. 3D to 2D conversion is done in script. (See the Point_TransformDraw function in starfield.lua)
3. Demonstrates dynamic module loading.
4. I bind the script system to GameVision inside the dll, then the running script can access any exported functionality. (See uStarfield.pas)
5. Edit SCREEN_WINDOWED in script to switch between windowed and full screen
[Download]
SV Starfield Demo (~900kb)
[Edited by - BigDaddyGames on April 7, 2005 9:49:05 AM]
1. This example uses the Delphi bindings.
2. 3D to 2D conversion is done in script. (See the Point_TransformDraw function in starfield.lua)
3. Demonstrates dynamic module loading.
4. I bind the script system to GameVision inside the dll, then the running script can access any exported functionality. (See uStarfield.pas)
5. Edit SCREEN_WINDOWED in script to switch between windowed and full screen
[Download]
SV Starfield Demo (~900kb)
[Edited by - BigDaddyGames on April 7, 2005 9:49:05 AM]
Quote:
[Download]
I tried to run it, but it appears you are missing a key .dll -
Quote:
The application failed to start because ScriptVision.dll was not found. Re-installing the application may fix this problem.
<edit :: Naturally, downloading the library solved the problem ... guess I was expecting it to be self contained. Right, so now it displays a nice window and a logo, but no starfield. Is there any way I can fix this ?
That's odd. It works fine on my computer : /. Did you get the same .dll from the first post Stormrunner? What are your computer's hardware specs.
Quote:
Original post by Drew_Benton
That's odd. It works fine on my computer : /. Did you get the same .dll from the first post Stormrunner? What are your computer's hardware specs.
For the record, specs :
Athlon 64 3400+ XP
GeForce 5500 FX
1.0 Gb RAM
2.19 GHz
As for the .dll, I did indeed rip it from the first post. Re-downloading and running it again produced another black screen, except about every 15 seconds a small white thing would whiz across the screen. This lead to an interesting hypothesis, and indeed the solution did indeed turn out to be simple - turn off all the lights. However, the effect is still rather faint ... I'm now convinced I'm going blind.
Just out of curiosity, Drew_Benton, was the effect on your machine more noticeable ?
BigDaddyGames - The examples(testbed) ran fine, however you need to remember that the .exes inside the test-bed folders can't see the path to the .dll, and therefore won't execute. Placing .exes outside or a copy of the .dll inside would prevent this problem. Looks like a nice lib, though.
Your comp is way better than mine [wink] So it is either a AMD or NVIDIA difference. I have an INTEL and ATI and this is what mine looks like:
ScreenShot.
It looks a bit better when I run it, that image is saved as a JPEG. As for the way the .dlls are placed, I think that's the standard way to do it - just place it once in the root folder then let user move it to the test apps, it's what I do as well [smile]
ScreenShot.
It looks a bit better when I run it, that image is saved as a JPEG. As for the way the .dlls are placed, I think that's the standard way to do it - just place it once in the root folder then let user move it to the test apps, it's what I do as well [smile]
Hi,
1. Oops, I forgot to include the ScriptVision dll. Fixed.
2. In windowed mode, the stars are hard to see on my monitor too. You can edit the starfield.lua script file and change SCREEN_WINDOWED to false and it will then run in fullscreen mode.
3. For the dll paths, what I usually do is keep the dll in the root and add that root folder to the Windows path. Assuming your running Windows 2000 and up:
a) Right-click on "My Computer" and select properties
b) Brings up the system properties dialog, next select [advance] tab
c) click the button, brings up environment variables dialog.
d) Click the path variable in the top window, then the edit button
e) Assuming you have ScriptVision folder off the root, carefully, move to the end and add ";c:\ScriptVision" (no quotes)
f) Click the and now c:\ScriptVision is visible to Windows and will search this path for DLLs and EXEs.
1. Oops, I forgot to include the ScriptVision dll. Fixed.
2. In windowed mode, the stars are hard to see on my monitor too. You can edit the starfield.lua script file and change SCREEN_WINDOWED to false and it will then run in fullscreen mode.
3. For the dll paths, what I usually do is keep the dll in the root and add that root folder to the Windows path. Assuming your running Windows 2000 and up:
a) Right-click on "My Computer" and select properties
b) Brings up the system properties dialog, next select [advance] tab
c) click the
d) Click the path variable in the top window, then the edit button
e) Assuming you have ScriptVision folder off the root, carefully, move to the end and add ";c:\ScriptVision" (no quotes)
f) Click the
The next version of ScriptVision will support saving/loading compiled scripts, via the SV_Compile routine.
Prototypes:
SV_Compile(SV_Char *aInPath, SV_Char *aOutPath); // c/c++
SV_Compile(aInPath, aOutPath: SV_Char); // delphi
You would use call it like this:
SV_Compile("starfield.lua", "starfield.bin");
Setting the aOutPath to null will use the filename of aInPath with a ".bin" extension.
You can use any of the SV_LoadFromXXX routines to execute a compiled script.
Prototypes:
SV_Compile(SV_Char *aInPath, SV_Char *aOutPath); // c/c++
SV_Compile(aInPath, aOutPath: SV_Char); // delphi
You would use call it like this:
SV_Compile("starfield.lua", "starfield.bin");
Setting the aOutPath to null will use the filename of aInPath with a ".bin" extension.
You can use any of the SV_LoadFromXXX routines to execute a compiled script.
I'm trying to get this running but am having a lot of trouble. Could you explain:
I mean, it seems to be how the MessageBox function is called from the script, but I don't understand SV_PopString(); I could be doing a lot more wrong because I'm getting a crash. Any plans for tutorials?
SV_Integer SV_CALL sf_msg(SV_Pointer p){ std::string msg; msg = SV_PopString(); MessageBox(0, msg.c_str(), "Message", MB_OK); return 0;}I mean, it seems to be how the MessageBox function is called from the script, but I don't understand SV_PopString(); I could be doing a lot more wrong because I'm getting a crash. Any plans for tutorials?
Hi,
The SV_PopXXX routines return the value from the top of the stack. After the call, the stack level will be decremented. In the case of SV_PopString, it returns a string pointer value. With strings, it is important that you cache the string locally because the value returned is just a pointer to string at the current stack level. After the call, this pointer value can become undefined with stack usage. This could be a source to the problems you're having. So:
std::msg = SV_PopString, will pop off the string value at the top of the stack and store it locally in msg. Note that params have to popped off in reverse order. If you pass p1 and p2 to a script function, you have to pop them off as p2 and p1. You can use the SV_GetXXX routines to access a stack value in index order such as p1 = SV_GetInteger(1) and p2 = SV_GetInteger(2). The first (lowest) valid stack index is one and not zero as you may expect.
Make sure all script functions are using the stdcall calling convention (already defined as SV_CALL) as SV uses stdcall rather than cdecl.
I will all tuts and samples in the official release and add a SV section on our website.
Summary:
1. SV_PopXXX pops values off the stack. You have to pop params off in reverse order.
2. You should cache string values locally and not directly refer to the string pointer.
3. SV_GetXXX can access stack values in index order. The first index starts at one.
4. All script functions and SV routines/callbacks use the sdcall calling convention (defined as SV_CALL).
5. An official ScriptVision release with tuts, examples and section on our website coming soon.
The SV_PopXXX routines return the value from the top of the stack. After the call, the stack level will be decremented. In the case of SV_PopString, it returns a string pointer value. With strings, it is important that you cache the string locally because the value returned is just a pointer to string at the current stack level. After the call, this pointer value can become undefined with stack usage. This could be a source to the problems you're having. So:
std::msg = SV_PopString, will pop off the string value at the top of the stack and store it locally in msg. Note that params have to popped off in reverse order. If you pass p1 and p2 to a script function, you have to pop them off as p2 and p1. You can use the SV_GetXXX routines to access a stack value in index order such as p1 = SV_GetInteger(1) and p2 = SV_GetInteger(2). The first (lowest) valid stack index is one and not zero as you may expect.
Make sure all script functions are using the stdcall calling convention (already defined as SV_CALL) as SV uses stdcall rather than cdecl.
I will all tuts and samples in the official release and add a SV section on our website.
Summary:
1. SV_PopXXX pops values off the stack. You have to pop params off in reverse order.
2. You should cache string values locally and not directly refer to the string pointer.
3. SV_GetXXX can access stack values in index order. The first index starts at one.
4. All script functions and SV routines/callbacks use the sdcall calling convention (defined as SV_CALL).
5. An official ScriptVision release with tuts, examples and section on our website coming soon.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement