View Full Version : paxCompiler integration

07-06-2008, 05:15 PM
The new scripting engine in PGSDK is now based on the excellent paxCompiler (http://www.paxcompiler.com) by Virt Labs. Integration is pretty much completed now. There are just a few small remaining issues, but they should be resolved by the time the next version of PGSDK drops.

Here is an example what you can can now do with the new scripting features:

1. Full integration with PGSDK and your own native code.
2. Great interop between native and compiled script code (you can access native routines from script and script routines from native)
3. Generate standalone EXEs (GUI or CONSOLE) with version info and a default icon.

A demo showing these features can be found here (http://pyroginegames.com/downloads/ScriptTest.zip).

* uScriptTest.pas - native code
* Scroll.pas - main script code
* uScroll.pas - demo code
* uUnit1/2.pas - units to show how multiple units can be compiled
* Scroll.exe - generated exe with version info and default icon (this example will be a GUI type EXE)

The result is a stand-alone win32 EXE than runs the 4-way scrolling demo in PGSDK at 60 fps with streaming music. What's cool too is that the very same uScroll.pas unit can be compiled between Delphi and the scripting engine with no code changes. SWEET! PGSDK is now using ECOM so all the classes from the DLL can easily be used and extended on the client side. SWEETx2!

07-06-2008, 05:35 PM
how about the speed, did you made some tests?

i have paxscript here, but since i meet python i never used it anymore =|

07-06-2008, 05:52 PM
paxCompiler is actually compiled native code so it will most likely be faster overall than any interpreted scripting engine (the ones I've tested, including PaxScript). This alone is worth it (at least to me). Now in general the compiled scripts (at the present time) will be about 3 times slower than optimized compiled Delphi code. I'm sure this will improve over time too. I've been working with paxCompiler for a while now and I can highly recommend it. So for I've not seen any substantial differences in speed in my test cases. All in all it's a win/win for me (how often does that happen :wink: ).

Remember too that it's supports most of the Delphi language syntax and features such as classes, inheritance and more. Like I said, uScroll.pas can be compiled in both with no code changes. That's really impressive in my opinion. You can compile/customize on the fly in the same language that you use everyday.

As for Python, I've looked at it but never tried to use it. For me it's a lot easier to use the same syntax of my main development language. If you can also get great interop between them that's even better.

07-06-2008, 06:10 PM
3x slower than native compiler? Looks VERY good :)

07-06-2008, 06:55 PM
Thanks! Yes, the benchmarks (see in the paxCompiler distro) put it at about 3-4 times slower. In reality no matter what the results are, it will still be faster than your typical interpreted engine because it's natively compiled (only to get faster over time).

What's cool is the following methods I recently added to TPyroScript:

function GetAddress(..)
function CallRoutine(...)
function CreateScriptObject(...)
procedure DestroyScriptObject(...)

With them you can get the address of a routine, variable or method in script. Create an instance of a script class, use GetAddress to get the address of a method and then use CallRoutine to directly call this method passing any params to it like you normally would do and can even get the return result if needed.

You can register your native class so they are visible from script (in the OnRegisterNative event handler). If you want you can have your native classe's update routine call the script class update routine, this way your logic can be in script and modifiable by the end user. Anything you want to customize can be in modifiable script code. Or, you can just compile the whole thing to a stand alone EXE.

To register a class type, you can do something like this:

N,H: Integer;
s: TPyroScript;
s := TPyroScript.Create; // PGSDK will be registered for you when you create script object instance

N := s.RegisterNamespace(0, 'PyroResources');

{ TPyroLogFile }
H := s.RegisterClassType(N, TPyroLogFile);
s.RegisterHeader(H, 'constructor Create; override;', @TPyroLogFile.Create);
s.RegisterHeader(H, 'procedure Erase; virtual;', @TPyroLogFile.Erase);
s.RegisterHeader(H, 'function Write(const aMsg: string; const aArgs: array of const): string; virtual;', @TPyroLogFile.Write);
s.RegisterHeader(H, 'procedure SetFilename(const aValue: string); virtual;', @TPyroLogFile.SetFilename);
s.RegisterHeader(H, 'function GetFilename: string; virtual;', @TPyroLogFile.GetFilename);
s.RegisterProperty(H, 'property Filename: string read GetFilename write SetFilename;');
// add some code from disk file

// add code from a resource file
s. AddCode(ziparchive, 'media/scripts/test.pas');

// compile code
if s.Compile then
// run compiled code

// lets us save out the compiled image to disk

// or we can save out a stand alone exe
s.CreateExe('test.exe', exeCONSOLE, @versioninfo, 'iconfile.ico');
// display errors


or you can create a derived version of TPyroScript and override the OnRegisterNative event handler and place your registration code there which is the preferred way of doing it because any time the script engine changes (after a Reset for example) it can register your native code automatically as needed. Remember too that all these classes are coming from the DLL via ECOM (http://www.pascalgamedevelopment.com/viewtopic.php?t=5383).

Sweet man, SWEET!

15-06-2008, 04:54 PM
I've been working on adding debug support. At present paxCompiler has a debug component but there is no support for stand-alone EXE debugging which is what I needed. So, I added support for it. What I did was to actually add remote debugging support using the persistent network layer in PGSDK. I added a few new methods to TPyroScript that allow you to utilize a client/server debug relationship.

If you run the stand-alone EXE with a special command line option it will then start in debug sever mode and wait for commands from the client (Run, TraceInto, RunToCursor etc) and then execute the received command. In this case the client and EXE pass debug data between each other via localhost which in theory can be anywhere there is a network connection. I'm pleasantly amazed that it's actually working as I had envisioned. The screenshot below is a rudimentary IDE that I'm currently working on which at this point is in proof-of-concept stage. Now that I see that it will actually work the goal for the next release of PGSDK is to include a light-weight IDE that allows you to compile and debug your scripts. Thus you will be able to use PGSDK with Delphi or completely stand-alone. Over time I want to the IDE to grow to become a nice multi functional tool supporting your development needs.

Another feature added is the project information (search path, output name, version info) can be added as compiler directives in the source. This way it makes for much easier project management. No complicated command line params and configuration files.

I finally got capturing console output working smoothly. Some needed information such as source search paths and the exe output file is sent back to the client via the captured out. Special markers are placed around the text and the client will look for and parse this information out.


18-06-2008, 02:05 PM
Integration of paxCompiler is now pretty much done. I will defer debugging support until the next release of pgsdk. A few technical issues still need to be worked out for it to be a smooth as possible. Using the persistent network layer is sound, but there are other issues with the compiler component that still need to be resolved in order for it to be the way that I want. So, for this release I will try to get at least a light weight editor in. Scripting implementation is very robust and there is good interop between native and script. At this point, the whole SDK (excluding the scripting interface) is able to run under script. Overall I'm very pleased with what I've been able to do with paxCompiler. I think (I've never tried) it works with FreePascal as well.