Delphi & lua problem

[Cybermonkey]

I don't know how fast PascalScript actually is but Lua beats even some compilers. According to wikipedia it also uses bytecode:

Lua programs are not interpreted directly from the textual Lua file, but are compiled into bytecode which is then run on the Lua virtual machine.

And since the shared library is built with a C compiler it might be faster than an engine built with Freepascal. I think there was a discussion on the mailing list that GCC beats FPC in speed issues.

[phibermon]

There's a lot of choice when it comes to scripting (and I'd recommend to anybody to have a go at writing their own simply scripting engine as there's a lot of interesting aspects to it) and different scripting engines have different uses.

People always harp on about the performance of the code in this or that compiler and it really doesn't matter, the difference is negligible, such things should only be important when running code across a super computing cluster or writing a driver for a graphics card (and even then the really critical stuff is written in ASM)

Basically any scenario where you're maxing out the capabilities of a given platform.

I happen to know that Pascalscript will out-perform LUA in lots of ways, especially when it comes to the handling of object instances, large numbers of variables and recursive functions / nested loops. And LUA will beat pascalscript in other ways still, actual compilation speed for one)

But when it comes to performance we're talking a fraction of a difference, a few milli-seconds over hundreds of thousands of itterations.

And that doesn't matter when using scripting and indeed if you're relying on lots of heavy scripts running between frames to the point where it does matter, then you're using scripting in the wrong way anyway (at least when it comes to games) Any such scenario should lead to you hard-coding the functionality or at least abstracting as much as you can.

So in that sence, the only things that really matter when it comes to scripting is portability, how easy it is to intergrate into your code, that it's stable and that it allows you to provide the functionality via the scripting API in the cleanest manner possible.

--

Don't choose LUA just because you've heard it's used in nearly all games, it's a brilliant light weight choice if you're coding in C.

But since we're coding games in Pascal, why go to all the effort to use a C styled lib? relying on updated headers? relying on them being bug free? relying on the actual LUA libs being on the target device? having to distribute them to devices where it's not present? having to structure your functions so the calls are LUA friendly? no support for your objects? using the tools of the enemy?

Why not just do what the C developers did to make LUA popular in the first place and pick the one you can compile nativley into your game, is the easiest to intergrate with your language - offers the path of least resistance. That's why as C developers they chose LUA and that's why as a pascal developer, you should at least take a look at the native options, they really are very good.

[Cybermonkey]

I am looking for a FPC only scripting language, so Pascalscript is not useful since it requires at least Lazarus. I am using Lua in a complete different way, more like Löve does. (Just have a look at my signature) At the moment I am working on a Lua GUI interpreter which uses fpGUI, so it is possible to use Pascal objects with Lua although it requires a bit of work.
I have to admit that I am coding this not for the average Pascal programmer. (Speaking frankly I wanted to do my own BASIC interpreter but didn't manage to write one, yet). Maybe to better know what I am talking about I'll add an example, first of EGSL:

screen (800,600,0,"Hello World")
setframetimer (80)
colourkey (0,0,0)
--
sprite={}
sprite.image = createimage (32,32)
sprite.x=320
sprite.y=240


startimagedraw (sprite.image)
 colour (255,255,0)
 fillcircle (16,16,15)
stopimagedraw()
 --
 backcolour (50,80,250)
repeat
cls()
key=getkey()
if keystate (274) then
sprite.y=sprite.y+1
end
if keystate (273) then
sprite.y=sprite.y-1
end
if keystate (275) then
sprite.x=sprite.x+1
end
if keystate (276) then
sprite.x=sprite.x-1
end




putimage (sprite.x, sprite.y, sprite.image)


sync()
until key==27
closewindow()

This is a simple sprite example. The advantage of my interpreter is that one can build true stand-alone files because the source can be bound to EGSL.

Now the next example for fpLua (work in progress):

require ("fpconstants")


function button1_clicked()
    labelset (label1, POSITION, 200,200,200,30)
    labelset (label1, FONT, "Arial-14:bold")
    labelset (label1, TEXT, "You pressed the button!")
end


function button2_clicked()
    showform (form2)
end


function button3_clicked()
    closeform (form2)
end


function qtnClick()
   closeform (form1)
end


form1 = createform()
form (form1, "My Lua Form",640,480)


form2 = createform()
form (form2, "Another window",500,500)


button1 = createbutton (form1)
button (form1, button1, "Test Button", 20, 20, 100, 25, "button1_clicked" )


label1=createlabel (form1)
label (form1, label1, "Hi this is now some longer text.\nCan you read it?",50,50,400,50)


button2 = createbutton (form1)
button (form1, button2, "Another Button", 120, 120, 180, 25, "button2_clicked" )


button3 = createbutton (form2)
button (form2, button3, "Quit Form", 220, 420, 180, 25, "button3_clicked" )


quitBtn = createbutton(form1)
button (form1, quitBtn, "Quit Program", 500,450, 100,25, "qtnClick")


showform (form1)


-- after form1 is closed, freeform is executed ...
freeform (form1)
freeform (form2)

[phibermon]

I like the API layout, very concise! if you're already integrated to such a level then I couldn't recommend switching scripting engine, there's no point as long as you don't hit any walls in terms of using a dynamic library on a given platform, it only makes sence to choose Pascal script if you've not already implemented something else.

But I must stress that you don't need Lazarus for pascalscript, it works perfectly fine with just FPC or the Delphi compiler (got an old version compiling with GNU Pascal long ago) works perfectly on Windows, Linux, OSX, etc (anything FPC can compile for)

Any none visual componenet is essentially just an easy drag and drop alternative to including the units in your uses clause and then instantiating an object, with the added convenience that published properties are shown in a generic manner inside the IDE along with the addition of being able to execute code at design time (so for example GLScene can create a design time GL context for the viewport and show design time properties of scene objects, or somthing like that, it's out of date now, don't use it anymore)

Any component that doesn't render to a form can be used at the lower level (FPC) as that lower level is just wrapped up in a component container in the first place and you can cherry pick lots of useful code from visual stuff as well (for example I used to use the SynEdit Lexer in my hobby compiler projects)

[Cybermonkey]

I like the API layout, very concise!

Any component that doesn't render to a form can be used at the lower level (FPC) as that lower level is just wrapped up in a component container in the first place and you can cherry pick lots of useful code from visual stuff as well (for example I used to use the SynEdit Lexer in my hobby compiler projects)

Thanks a lot. I really got a plan this time (I love it when a plan comes together ).

I would appreciate if you could post a small example on how to use SynEdit to build a compiler/interpreter... (I already asked on the official Lazarus forum but they didn't recommend using SynEdit for this purpose).
Or if anyone has an example for plex/pyacc: Don't hesitate to post your knowledge.

[phibermon]

Oh only the Lexer, it's a stage you need when writing a compiler/scripting engine, essentially you're taking the source input and lexing it (eg. identifying strings, numbers etc) and then tokenizing (eg. looking at the lexemes, working out which is an identifier, keyword, operator etc) there's a lot of useful functionality in the synedit units to achive that goal, however I've written my own stages now (they're currently being used for syntax highlighting / hints etc in the script editor within JinkEd, didn't use synedit as it would of been a lot of work to convert it to use my GL widget toolkit)

Obviously there's a large part to writing a compiler that's not part of Synedit, you've got the parsing stages, validation etc then construction of the AST (if that's how you approach it) then any optimization stages, then you're spitting out machine code (or some intermediate language, so ASM in some instances or maybe machine code for the LLVM (clang etc) followed by more optimizations)

Lexers + Parsers are really interesting things to work on, however most people tackling compilers opt to use lexer generators such as flex etc as it saves a ton of time, there's ones out there that generate pascal code if I remember correctly (I'll have all the links and files in my archive so let me know if you need any details). These usually result in large, state based rule checking code used to validate and report on syntactical errors

But you can write them by hand, it's not rocket science, it just takes a while

[Cybermonkey]

Yes, the flex/bison port for Pascal ships with Freepascal known as pyacc/plex. What I actually want to do is to port an existing BASIC interpreter (ANSI C) based on flex/bison. But this seems a lot of harder than I thought. Maybe I should start with the beginning and read Jack Crenshaw's "Let's build a compiler", which was updated by pp4s.co.uk (http://www.pp4s.co.uk/main/tu-trans-comp-jc-intro.html).

[phibermon]

Ahh that's exactly the tutorial I started with, my lexer is just a series of refinements based upon Jacks tutorial, I wasn't aware that it'd been updated however, I'll have a read thru.

There exists templates for many of these compiler generators for pretty much all known languages, I'll bet you'll find one in a flex like format for BASIC that you can work from.

I never went down that route (not for any good reason, I just wanted to understand just how hard it was that people would create programs to generate them instead) and it took me a number of weeks of tweaking and brainstorming to get my Object Pascal lexing/tokenizing up and running with half decent error checking.

It would be very handy to refer to an existing set of generator templates in order to understand the syntax, how the language is defined in such a system. I think without the reference it'd probably take quite a few days of reading thru docs and tweaking your templates before you were happy with it, still faster than coding it by hand however

[Darkhog]

Anyone knows how to use PascalScript in a form-less lazarus application? After finishing Super Heli Land I'm thinking about making engine where all gamelogic things would be done in PascalScript (so I won't have to recompile game every time I want to change e.g. player's jump height) and rendering would be done using Allegro.pas. So aside of Allegro window, engine would be GUI-less.

Therefore I'd need a way to use PascalScript without form. I'd mostly welcome sample code (you can assume I've installed PascalScript the way it is on Wiki as I'm, not FPC purist and Lazarus outperforms default, turbo pascal-like IDE shipped with fpc, fp.exe I think?).

[SilverWarior]

Anyone knows how to use PascalScript in a form-less lazarus application? After finishing Super Heli Land I'm thinking about making engine where all gamelogic things would be done in PascalScript (so I won't have to recompile game every time I want to change e.g. player's jump height) and rendering would be done using Allegro.pas. So aside of Allegro window, engine would be GUI-less.

If you are only concerned by jump height values and such then simply don't hardcode them into your code. Use global variables instead. And yes you can populate theese global variables by loading information from some external file. Using INI files for this would probably be the easiest way.


As for pascal script in Lazarus:
I don't know how it is implemented there but if in normal LCL application you need to place certain components to the form, you can always create those components manually at runtime. How do you create them can difere from component to component based on their implementation but usually it is something like this:

var SomeComponent: TSomeComponent;
...
//Owner is another component which would take care of freing up this component. In VCL/LCL applications Owner is usually some Form or other visual component.
//But if you can always use TSomeComponent.Create(self). This would make class from whose method the creation of component is caled as its Owner. 
//In console (GUI-Less application) this would probably be the Application itself.
//You can even use nil so there would be no owner but then you have to make sure that you destroy the component and free up its resources by yourself.
SomeComponent := TSomeComponent.Create(Owner);

If in visual application you need to conect several components together by specifying one other components name in ObjectInspector you can also do this at Runtime bysimply pasing the name of such component to specific property of the component that needs this.