Quad-Ren scripting language

[hessiess]

If you don't already know what QR is see http://quad-ren.sourceforge.net/

I am considering Integrating a scripting language into QR, the question is which one, Currently I am considering Lisp, Lua, Python or possibly creating something completely new from scratch, any suggestions?

Incase anyone is interested, I am already working on a Python binding for QR, this will be almost identical to the C++ API. The scripting system is intended to function more like Flash (a number of objects which can send messages to each other).

 

[bzar]

Voted for python, because it's my main hobby-programming language
Could it somehow work in a pygame window? That way you could use pygame for everything else. I must say, I've been a bit intrigued by Quad-Ren since the announcement thread, but haven't gotten around to it yet (with the PandoraPanic and gazillion other projects ). One of my current projects using pygame might actually benefit a lot from Quad-Ren, since it uses somewhat much image rotation.

 

[lulzfish]

I would personally prefer Lua.
Python has that weird syntax where you start a function and then never end it [it end implicitly by indenting]
I like the indentation, but it doesn't look right when a function just trails off and then another one starts without the first appearing to end.

Lisp seems too abstract for scripting. It's all :twisted:

 

[Pleng]

I've used Holywood on the Amiga and Novashell on Windows, both of which are LUA based, and found it an extremely flexible and easy to use.

Having said that, I've never used any of the others...

 

[hessiess]

Voted for python, because it's my main hobby-programming language
Could it somehow work in a pygame window? That way you could use pygame for everything else. I must say, I've been a bit intrigued by Quad-Ren since the announcement thread, but haven't gotten around to it yet (with the PandoraPanic and gazillion other projects ). One of my current projects using pygame might actually benefit a lot from Quad-Ren, since it uses somewhat much image rotation.

The python API bindings will mean that QR will be usable from python, however it was designed to be a graphics engine in its own right, so cannot integrate with other drawing API's natively. You would need to replace the SDL back end in qr_renderer.cpp with one that renders to a texture, and then import that texture into PYGame. I have bean thinking about ditching the SDL back end anyway as it is limited to creating one window only, meaning that creating more qr_renderer objects dousen't create more windows...

If you just want to integrate rotation into your current application you would be better off using the rotation functions built into pygame, mixing API's like OpenGL/QR and SDL/Pygame could get verry messy, Consider re-wrighting the whole application with QR/OpenGL as you are doing a lot of rotations.

 

[bzar]

Voted for python, because it's my main hobby-programming language
Could it somehow work in a pygame window? That way you could use pygame for everything else. I must say, I've been a bit intrigued by Quad-Ren since the announcement thread, but haven't gotten around to it yet (with the PandoraPanic and gazillion other projects ). One of my current projects using pygame might actually benefit a lot from Quad-Ren, since it uses somewhat much image rotation.

The python API bindings will mean that QR will be usable from python, however it was designed to be a graphics engine in its own right, so cannot integrate with other drawing API's natively. You would need to replace the SDL back end in qr_renderer.cpp with one that renders to a texture, and then import that texture into PYGame. I have bean thinking about ditching the SDL back end anyway as it is limited to creating one window only, meaning that creating more qr_renderer objects dousen't create more windows...

If you just want to integrate rotation into your current application you would be better off using the rotation functions built into pygame, mixing API's like OpenGL/QR and SDL/Pygame could get verry messy, Consider re-wrighting the whole application with QR/OpenGL as you are doing a lot of rotations.

I probably will, if I can't get the current implementation running smoothly on a pandora. The whole thing was always meant to be a prototype, but then I got carried away

 

[billykater]

Some other alternatives
Squirrel. Mostly inspired by LUA with a more C like appearence. What I like about it is the object oriented part and a stricter variable checking (see "<-" in the reference). My personal preference.

GameMonkey although I haven't used it myself it seems to be easy to integrate and use.

From the Languages from the poll I would choose LUA.
Writing your own language can be funny but would be a huge task by itself and in the end you would end with a language similar to all others.

 

[CyruzDraxs]

I second GameMonkey, it integrates really well, is lightweight and it's already very portable.

 

[hessiess]

Thanks for the suggestions, Im defiantly going to look into game monkey.

 

[LastPucho]

Lua is easy and simple, so I'd choose it. Never heard of GameMonkey until now... looks pretty cool, to say the least. But Lua would still be my choice because of its supportive community, ease of use, constant develpment and beign used for a wide variety of applications :wink:.

By the way, thanks a lot for intending to make Quad-Ren accesible through scripting... great idea! Whatever script language you choose, I'll defenitively use it / learn it .

 

[Sandman]

Have a look at Bennu (wiki: http://wiki.bennugd.org ), it may be a nice choice. It is the continuation of Fenix and designed for games. Plus, integration is easy to do. Good luck with the project.

[EDIT]
Though this game monkey looks interesting too at first sight.

 

[dorkfish]

I would suggest embedding the mono runtime in the engine (if it's working on ARM). Lua, Ruby, Python, and several other scripting languages have implementations on top of .net/mono and would allow scripters to choose what language they would like to use, and since they all compile into CIL, they're all interoperable.

 

[dflemstr]

I would suggest embedding the mono runtime in the engine (if it's working on ARM). Lua, Ruby, Python, and several other scripting languages have implementations on top of .net/mono and would allow scripters to choose what language they would like to use, and since they all compile into CIL, they're all interoperable.

Well, we all know what to say about Mono. Patent/copyright issues? Morals? Flawed API due to half-supported non-cross-platform PInvokes? Crappy CIL structure?
If you want to chose what language to script in, then why not just go for Java/JVM when you are at it... It has support for all of the mentioned languages and more, like Erlang, Scala, etc, and is far more stable, cross-platform and usable.

 

[hessiess]

I would suggest embedding the mono runtime in the engine (if it's working on ARM). Lua, Ruby, Python, and several other scripting languages have implementations on top of .net/mono and would allow scripters to choose what language they would like to use, and since they all compile into CIL, they're all interoperable.

I am reluctant to embed something as large and complicated as the mono runtime, though i *may* look into .net bindings for the lib.

 

[dflemstr]

I would suggest embedding the mono runtime in the engine (if it's working on ARM). Lua, Ruby, Python, and several other scripting languages have implementations on top of .net/mono and would allow scripters to choose what language they would like to use, and since they all compile into CIL, they're all interoperable.

I am reluctant to embed something as large and complicated as the mono runtime, though i *may* look into .net bindings for the lib.

If you'd develop Java bindings, you'd really make a lot of people happy. Hm, who knows, maybe I'll make a wrapper myself, it's not like it's difficult (jut just make a java class that has the same methods and variables (but abstract) as the public classes in quad-ren and done)

 

[hessiess]

I would suggest embedding the mono runtime in the engine (if it's working on ARM). Lua, Ruby, Python, and several other scripting languages have implementations on top of .net/mono and would allow scripters to choose what language they would like to use, and since they all compile into CIL, they're all interoperable.

I am reluctant to embed something as large and complicated as the mono runtime, though i *may* look into .net bindings for the lib.

If you'd develop Java bindings, you'd really make a lot of people happy. Hm, who knows, maybe I'll make a wrapper myself, it's not like it's difficult (jut just make a java class that has the same methods and variables (but abstract) as the public classes in quad-ren and done)

If you do decide to create a binding then please release it as LGPL so that I can include it into the distribution. Credit will be given of corse.

 

[lippy]

Lua all the way! But then again I'm pretty biased as I've never used python.... only lua for http://springrts.com...

 

[GreyIBlackJay]

Lua. It's syntax is simple and its the language I have actually learned.

 

[White Flame]

Aw, too few Lispers in here. It's one of the easiest language to implement, ridiculously configurable, and incredibly powerful with just a few simple basic building blocks.

Are you talking about writing full games in this script, or just a sort of configuration/trigger sort of thing?

 

[hessiess]

Aw, too few Lispers in here. It's one of the easiest language to implement, ridiculously configurable, and incredibly powerful with just a few simple basic building blocks.

Agree, If I do go the `custom' route then it will almost certainly be a dialect of Lisp, because other syntaxes would be to hard/time consuming to implement.

Are you talking about writing full games in this script, or just a sort of configuration/trigger sort of thing?

I'ts mostly intended to be a replacement for the on_event, on_animate and possibly on_drop, to allow node behaviours to be stored in the QRDD file along with the animation frames, collision mesh and anything else. Hence why I am favouring languages with small implementations.