INTRODUCTIONAs GMREC and several others may testify, this has been worked upon for some good time.Enough talk, what exactly is it?

In this package you will find two dll files. One is GMRA: the Delphi interpreter and the other is a pascal editing control called GMPE. GMPE features syntax highlighting, adding watches, adding error markers, and showing a messages in a lower pane.The focus though is all on GMRA. It is capable to run (with some limitations) delphi code. As an example, GM7 and below have all been made in delphi and both dlls are in delphi too .Now you'd ask, why's it an interpreter? It is because it doesn't really compile code! You cannot for example create standalone programs or dlls with it. Notice I said standalone meaning you can still use the dll in your GM program normally. You just cannot create exes or dlls from the delphi code. The delphi code must be passed as a GM string and then it can be executed.

DEMOSThere are some demos with current distribution, but here you my find some larger demos:-Skinned window demo - Shows how to fully skin a window. This demo can be used to produce skinned child windows and may be further modified to even skin the GM window!You can download the demo here.

CREDITSA lot of packages went into this project including: Project JEDI, Project Crystal Icons, PNGDelphi, Project SmartHelp, CDS...You don't have to give credit to any of them but is very much appreciated if Covac Software and JEDI Team are credited.

SCREENSHOTSThis is an interpreter as such screenshots may vary. I'll put some here for your leisure.DelphiEditor Running the paint dialog demo

DelphiEditor Running one of the demos and showing a bug

Other screenshots in next post.

BENCHMARKSDrawing on window test: At first GM was very fast at it, but GM becomes gradually slowwer with larger windows (rooms), at larger windows/forms the interpreter seems to perform better. Also, unlike GM it took a lot less processing power to draw on the form, the down side is, redrawing produces a flicker. I might have to add DoubleBuffered feature to the form to fix this. (Chris)Looping test: A loop to 1000000 took 10secs for the interpreter in the IDE while 5secs for pure GML. (icuurd12b42)NB: Speed is a considerable issue, but as GMREC said, it is bound to be slowwer considering the amount of features it has. I will work later on on a threading system were the interpreter would hold up GM while executing. Of course such a feature means you can't get a result value back.

HISTORY28-Nov-08 - Released package.01-Dec-08 - Released package: changes only in GMPasED.dll only.

I'll write more details as I already said. But basically here's an explanation.

You know what GM is made of? Delphi.You know what an interpreter? It's used to run scripts, like GM's GML interpreter.

Putting it together, Delphi Interpreter interprets Delphi code. You can in theory recreate the whole GM with this (for example).

Otherwise, you can use it forever other uses such as creating your own dialogs, controls...Other features include OLE (eg, to control OLE-enabled programs like MS Word) and to control dlls, so effectively you can call any other dll with this dll. No need for MaxWinAPI, WinAPI... you have all of it in one!

Chris.

EDIT:

Saw the documentation. Amazing stuff this DLL is. Btw, the download link is "broken" (it points to the docs)

I'll write more details as I already said. But basically here's an explanation.

You know what GM is made of? Delphi.You know what an interpreter? It's used to run scripts, like GM's GML interpreter.

Putting it together, Delphi Interpreter interprets Delphi code. You can in theory recreate the whole GM with this (for example).

Otherwise, you can use it forever other uses such as creating your own dialogs, controls...Other features include OLE (eg, to control OLE-enabled programs like MS Word) and to control dlls, so effectively you can call any other dll with this dll. No need for MaxWinAPI, WinAPI... you have all of it in one!

Chris.

EDIT:

Saw the documentation. Amazing stuff this DLL is. Btw, the download link is "broken" (it points to the docs)

Fixed!

is this the same JEDI which wrote JEDI-SDL (SDL4Delphi) ?

Sure is!

Please note that the documentation is only 5% complete (estimate)!

Oh, ok. Ill try it out!

0

If I was able to help you, please click the green (+) icon in the lower-right of my post. Thank you!

I am known as Jacic on yoyogames.com and a lot of other placesBorn-again christian and loving it!

This sounds really nice and good, but sad enough, I don't know a thing about delphi programming. I haven't learned anything about it, because I'm still learning C++, and I don't know if I even will learn it at all... Well, it looks good and I hope it works good as well! I think I'll try it in some way!

Well sort of... More like publishable. Been trying out different scripts and when the dll wasn't changed for a month, I decided it was working ok.

wouldnt it be weird if this ran code faster than GM...

You have any benchmarks?

No benchmarks at this time, but I did try some tests and it proves fast enough.

The test I tried is drawing a curve graph on a form and in GM. It did finish first .

But benchmarks differ, even a different formula might work differently.

You the bechmark guy, try it your own way

Chris.

I did... a quick test loop to 1000000... 10 seconds in the dll, via the code editor, 3 seconds in GM. Still. Because you can compile (if you can call it that, it's obviously not compiled) it first and run it later... It's sure to be much faster than execute_string. I don't have time to test the theory as I know very little pascal/delphy... When I get into it...

This DLL can be used to do things Game Maker can't and things a DLL hasn't been made for yet. Like my Flash and Console DLLs are made in Delphi, it may very well be able to run the source with a few modifications.

This is NOT Pascal or Delphi, it is an interpreter (runner) that is part of Project JEDI. It doesn't compile at all, nor does Game Maker. The speed may be affected by the...syntax of Pascal.

Even if Game Maker runs faster then it, you need to think about the fact that Game Maker is calling it and it is doing something. It will always be a bit slower unless the actual speed of the DLL kills Game Maker's by a lot. Also, this has way more features the Game Maker, if GM had many more data types and a better DLL system, it could use the WinAPI in scripts.

I did... a quick test loop to 1000000... 10 seconds in the dll, via the code editor, 3 seconds in GM. Still. Because you can compile (if you can call it that, it's obviously not compiled) it first and run it later... It's sure to be much faster than execute_string. I don't have time to test the theory as I know very little pascal/delphy... When I get into it...

Uuf6429, I have a small issue with Delphi. I get an error when I try to show a form (from a DLL). I've shown forms before, I must have forgot how to do it right I also know you don't come on MSN as much as the GMC.

Well, I made the form in Delphi and don't want to create it at runtime. The form has it's own unit that's included in the DLL. Form.Show; is giving me an error and would I have to create a new one of them then show?

But exactly, what does it have to do with GMRA? Or is it a different problem?
Because you know...GMRA can also load forms from delphi dfm files (untested though).
GMRA can also load code from pas files, just as you do in a Delphi IDE. I think this feature is disabled for the time being.

Do you know of a good site to teach how to make forms and such. All I was able to do was make a blank from. I tried to add an edit box but it just does not show. So a online help site would be nice. I spent an hour trying to see if there was one somewhere... Must not be looking right. I'm sure you know of one by now.

Found a bug.The GMPas Editor.dll does not support the TAB key. Weird !?Also, Sindarin says,

it is a Delphi interpreter, meaning you can use the Delphi programming language right into your game!

How though ? Its great to be able to execute arbitrary pieces of Delphi code in your game, but how does one do a certain thing in the game when the user clicks a button on a form created with Delphi code.Like execute "room_goto_next()" when the user clicks a TButton.

You make the TButton's OnClick event set a variable in Delphi and then you call it to return that variable. It can be whatever you want. 0 or 1 to see if it was clicked? Just think about it, it does store variable data.

Also it doesn't support the Tab key and that is why I don't like it very much, it's not a bug though. (Tab size 2 ftw)

@icuurd12b42 You need to set it's parent, I will get you the variable but I need to go right now.

Do you know of a good site to teach how to make forms and such. All I was able to do was make a blank from. I tried to add an edit box but it just does not show. So a online help site would be nice. I spent an hour trying to see if there was one somewhere... Must not be looking right. I'm sure you know of one by now.

There is the online help (which I'm still extending), link on first post. You can also check the demos, they do show good examples.

The GMPas Editor.dll does not support the TAB key. Weird !?

Has been fixed.

How though ? Its great to be able to execute arbitrary pieces of Delphi code in your game, but how does one do a certain thing in the game when the user clicks a button on a form created with Delphi code.Like execute "room_goto_next()" when the user clicks a TButton.

You can return a pointer to the variable and use it as an "id" to find it back. There's an example in preview.gm6, in the form of progress bar dialog. As you can see, it makes a dialog and then finds it back using this technique to set it's progress and finally to free it.

There has to be a Delphi Site like MS online help for c++... Since this is Delphi code, you won't have to make your own help system; simply refer to a good existing online Delphi manual...

Answered, but the point of my help files is for basic usage and examples. I will only include the most used properties/methods, which are fully supported by the interpreter.

Delphi BasicsAbout (Delphi)Delphi Land

Some useful sites, there is also the actual manual in the Delphi IDE. (It's really useful)

Good list! I will in fact add support for looking up code on the net on one of those sites.

Exactly how much Delphi functionality is there in this? Full WinAPI? Inclusion of libraries? Can it interface with GM?

EDIT

Your 'direct link' on the main page is rather a misnomer.

EDIT

Also interesting how you stressed that it doesn't compile, yet your editor has a build button which says the program has been 'compiled'.

1) It can interface to the Delphi VCL (aka the forms and controls) and any other dll, thus API functions can be defined and called there (as shown in DllDemo.pas).2) It is very direct. We are trying to eliminate hotlinking.3) It cannot create standalone code, but can be converted to pointer'd code much like bytecode. Same thing with java's compiling. Fair is fair, don't complain. Besides, this is faster if you compile it once and run without changing it rather then running normally.

I can't use anything from GM, I am sure it can use pointers if Delphi can. (It can obviously) You can use the full WinAPI as the WinAPI is all a bunch of DLLs, it supports DLL calling.

Small bug, if you do not have a Main function in the editor, it will bug out and do nothing but highlight the first line in red.

Pointers are used invisibly, eg, at the moment there's no way to use Delphi @ or Addr(). I working on this.It cannot directly interface to GM objects/instances normally, but I can see at least one way to do this.As to the main "bug", not really; the code must always have a main procedure or functions.

Thanks!
Hope it will come very useful. I might in the long run make this open source. Would surely gain some advantages.

Anyway, it will be using a different memory manager from Windows' called FastMM4. This has two significant advantages:
Better memory management, faster allocation (eg, it will be even faster at creating objects) and fixes some bugs with Windows' memory manager which were found by icuurd.

If you create a modeless form, dont set the parent handle to the game window, show it when the room starts, You close the game (The window still up or invisible, does not matter, but visible, you see it half drawn on the desktop), the form stays up and it crashes and GM does not come back...

However, if you remove
cvc_gmra_fini();

from the game end, it closes when you quit the game... And GM comes back

GMREC - I assumed it's very easy thus not much important to explain.I think everyone here knows how to use those dll functions? If not check the script's comments and the helpfile in DelphiEditor (I think).The problem you had, though, was because of the Delphi code not the GML usage. If you have problems with specific parts of the code please just ask.

icuurd - This problem is because the form was not freed. In delphi every object must be removed ( .Free() ) when you're not using it. The problem in this case is that the dll allocated/made that form and that script (cvc_gmra_fini) attempts to free the dll with the memory still allocated.This "bug" is a clear indicator of badly written code. I'm not saying anything about you using this, because this thing is sort of too "Delphic" and GM works very differently.

In short, to fix this either Free the form at game end (before running that script) or make the object managed by another object. I will describe what I meant by the later option.In delphi, an object can be connected to another one in two ways (typically); having a parent object and having an owner object. The parent contains the child (eg a button in a form) while an owner owns it (that is, deleting an owner deletes it's children). Deleting the form in the example above, the button won't be deleted. To set a parent, you typically use Parent or ParentWindow. The owner is the first paramater of the constructor (eg: TForm.Create(nil) ) it is usually nil, but you can set the owner.

In short, if you want that form to be automatically deleted use:Form1:=TForm.Create(Application);Application is an object which represents your program. It is created automatically. When the program ends, Application is automatically freed, thus it's childs which it owns (like this form) are also freed.

In my opinion, I prefer the method where you Free your objects at game end, it is much safer.

Regards,Chris.

NB: In the next version there are several updates of major importance:Interpreter: saveral fixes including pointer operations support, unit file loading, executing functions, weird bug found by icuurdMemory: Now use FastMM4 memory manager, faster and fixes some bugs.DelphiEditor: Instead of the GM example, a delphi one is going to be shipped (it's faster and much better) the demo source of the GM one will still stay there.GMJCRA: Now features (an optional) error catching and reporting dialog.Preview.gm6: Adds a set of scripts for easy control management, example GML:

Then I suggest you change your example code for the modal from example so you follow your own suggestion...
Form1.ShowModal;
Form1.Free; //<<--Missing

I don't free because, as you know, it causes an error which you told me will be fixed in the next release.
As soon as you put up the fix for the free on non modal forms which I reported earlier, I will have "not badly written code" and will be able to call finit when the game ends

I don't free because, as you know, it causes an error which you told me will be fixed in the next release.As soon as you put up the fix for the free on non modal forms which I reported earlier, I will have "not badly written code" and will be able to call finit when the game ends tongue.gif

Ok ok, no problem. What I only meant is that "bug" is only because of not freeing objects. The next version might even show a log of such unfreed objects.

Menu Example - Easy!ListBox/DropDownList Example - Even easier!Scrolling Window Example - Depends. You can have a TScrollBox which is like a panel but with scrollbars. But every form already support such a thing - just move child controls out of it (eg, form width is 200 and button left is 210)Docking Example - Ok, but that can only work on vcl forms (not GM window), but you can still embed windows.

Is there a way to have a window that stays on top of GM's window yet not have GM's window has parent? TopMost/ZOrder example

Just set FormStyle to fsStayOnTop, but it would be topmost of every window (not only GM's).

Also, an example of a container holding multiple classe(s) instances like an array or ds_list can hold object instances in GM would be cool.

Not sure what you mean, but if I get you right, you can store Forms/Controls in a StringList ( IntToStr(Integer( TForm.Create(nil) )) ) and then only return the Id of the StringList to GM.

Docking Example - Ok, but that can only work on vcl forms (not GM window), but you can still embed windows.

I assumed I could place a docable form (A form that accepts docking forms) in the GM window that other forms will dock on...

Just set FormStyle to fsStayOnTop, but it would be topmost of every window (not only GM's).

Not really what I want, on top but not top most. I've done it in VB and c++. A floating window that can be anywhere, including outside the main window but still always visible yet not on top of any other application.

Also, an example of a container holding multiple classe(s) instances like an array or ds_list can hold object instances in GM would be cool.

Not sure what you mean, but if I get you right, you can store Forms/Controls in a StringList ( IntToStr(Integer( TForm.Create(nil) )) ) and then only return the Id of the StringList to GM.

An example of your Data Structure claim... in c++ like code it would be

I need this, personally, to setup a lot of data in a array or container when the game starts, to store all my data used by objects (including instance ID in gm) for my room editor... So that I can quickly change the display data of a properties window dialog so that I'll go back and forth from the form to GM as little as possible.

I assumed I could place a docable form (A form that accepts docking forms) in the GM window that other forms will dock on...

Yeah that sounds ok. Just not docking directly into the GM window.

Not really what I want, on top but not top most. I've done it in VB and c++. A floating window that can be anywhere, including outside the main window but still always visible yet not on top of any other application.

Hmm maybe ToolWindows? To do this change the form's BorderStyle property.

An example of your Data Structure claim... in c++ like code it would be

Unfortunately that's a bit buggy for the time being, I've even got to check it with FastMM. But it should be possible:

type__MyData=record____count:Integer;____text:String; // string is a data type, can't be used as name__end;

Just set FormStyle to fsStayOnTop, but it would be topmost of every window (not only GM's).

Not really what I want, on top but not top most. I've done it in VB and c++. A floating window that can be anywhere, including outside the main window but still always visible yet not on top of any other application.

Apologies for the sceptical note, but what is the advantage of this over, say, writing your own code in Delphi directly, compiling it and linking it to your game? If you need to write something in Delphi, you might as well do a real build and compilation, and end up with a library that is much faster, and much, much smaller. This DLL adds 1.4 MB to the game file.

The only difference I can see is that you can alter the code at game run, which makes it level to execute_string and execute_file... You don't gain much with data exchange, as you're still stuck with reals and strings.