PyTorque - TGE Python Module

#1 Interesting Joshua! I can see some definite plusses to this. Does this mean that the TGEPython embded version is canceled? Any chance you'd drop it's current version on us?

#2 The only part that leaves me with the willies is

Quote:
-> into their python programs... there is no EXE!!!! No need to compile any C++ !!! This means that Python programs can use Torque without owning the SDK ... which is perhaps a bit interesting :)

not sure how that will play with the GG 5 some and the EULA

Other than that, this sure does turn a new leaf and sound very very exciting!

-Ron

#3 If you think about it, it's not fundamentally different from the current situation vis a vis writing scripts to customize engine behaviour... After all, the Python code can't directly manipulate the engine, only use the exposed scripting interface.

At least, that's what I think. GG might have another take on it.

Josh, how nasty is it to get Torque to compile as a library for this purpose?

#4 @Donavan - TGEPython is sprouting wings... it is likely that TGEPython will become a subsystem of PyTorque ... something like ConsoleObject which will be a generic interface to the Torque console system(which is really what TGEPython is)... slight renaming perhaps being necessary... but no real evil...

@Ron - it really shouldn't be a problem... you still need the SDK to do anything in C++, which in games is often necessary for speed reasons... BUT... it would certainly be possible to make compelling games with just the Torque Python module.. it also makes code sharing incredibly easy and modular:)

@Ben - yup, a subtle, yet very pronounced difference... getting Torque to compile as a shared library is completely trivial... changing some linker settings is all that is necessary... don't get me started on Dynamic Linking :)

PyTorque is a little ways out... I will be looking at Boost.Python today, to see about binding parts of the engine that were never meant for "script"... muahahahaha :)


-J

#5 *Excellent !!!!* (rubs hands together in true Burnsy fashion)
...then starts jumping up and down in excitement and glee, in a very youthful and exuberant, totally not Burnsy way ;)

Hmmmmm, pythonic... (sounds like an Old One, or one of their minions in the Cthulu mythos)

#6 Things are really cooking...

I spent the better part of a day with boost.python, it features some of the most amazing template compiler magic around... which is really cool for building small C++ extensions, quickly, and efficiently... sadly, it's not a terribly good fit for this amount of binding... under these conditions: insane compile times, gigantic code bloat, and compiler heap overflows were unavoidable ... I will use boost in the future, maybe on PyTorque... we'll see...

I have decided on Swig (which is the same system that wxPython and many others uses)... this is a very good fit... Swig has matured a lot over the course of 8 odd years... and it's GREAT for this application... the biggest selling point: the amount of customization you can apply to the binding process.. for example, I hooked up the existing TGEPython system as a submodule... under to hood of PyTorque, is a generic TorqueScript<->Python binding... VRROOOOM... VRROOOOOM

I've written a PyTorque distutils... it is capable of compiling the PyTorque extension from the command line in RELEASE/DEBUG ... this is the plan for Mac/Linux compiles too... automated building systems are The Way To Go(tm)... makefiles are so 70's

In addition, the distutils can generate a Visual Studio Workspace (.dsw + .dsp files)... complete with costume build operations for Swig interface files... it's very cool... I never have to touch the visual studio project/workspace settings(not even to add new files)... I can regenerate the Workspace at any time... THE DSW and DSP FILES DON'T NEED TO BE IN CVS... finally! >:|

I do have a question for Garage Games on this... When PyTorque is distributed in source form the Swig interface files will need to go with it... these are basically pseudo headers that Swig parses to automatically generate bindings...

The interface files are pretty much useless on their own... though, there will be quite a number of them and they can be quite representational of Torque internals... You can't really do anything with the interfaces. But I will stress , there will be a lot of them... Perhaps there is some way of distributing only to sdk users? or maybe it doesn't matter???

Also, if I modify a (very) few core files, say less than 10: Can I include those in the distrib? or do I absolutely have to make a patch?

I'll put some source out shortly... it's fun just to play with the build system :)

ZZZzzzZzzzZZZZzzz,
-J

*EDIT* Code snipped question answered

#7 Hey Josh,

Very cool stuff... however, distribution of the module, in .dll form alone is not allowed by the Torque Engine license agreement. See section 2 (License Grant):

Quote:
Licensor grants Licensee a limited non-exclusive and non-transferable license to reproduce and use only for purposes of making source code and object code for electronic single or multi-player games ("Games"), the Torque Game Engine code version of the Software...

and section 3 (Restrictions):

Quote:
(a) Licensee may not: (i) modify or create any derivative works of the Software, including translations or localizations, other than the Games;...

You can definitely make the source code changes and build process available to SDK owners, but if you want to release a DLL only version it would have to be under a seperate license agreement negotiated with GarageGames.

#8 Interesting Joshua, I've used swig to build custom Perl extensions before. I thought there was some reason you chose NOT to use a tool like swig when you were working on the original TGEPython stuff?

#9 Mark,

I see, the EULA, yes... almost forgot about that... hrm

Well, if Garage Games is interested in PyTorque, the amazing TGE Python Module, being released into the wild.. please lemme know... I do think that far from hurting the engine sales, it would help them... via increased visibility, and a great way to try the engine out... I am commited to making PyTorque absolutely kick ass :)

$100 for the complete source is *definately* something I would sign up for :)

For distribution to SDK Owners, does a Private SDK forum link suffice? ... or do you want something more secure?

I am really excited to get a prerelease out for people just to see what all the foaming is about...

Thanks,
-J

#10 Donavan,

There are a number of points to make on this... a primary one is: I want to extend python and not embed it... the original post gets somewhat into this...

TGEPython is great for using Python with Torque via the Torque console system... though, this suffers from limitations of the console system and imposes some performance penalties for all the translation... TGEPython is still very useful, and will make some things that are hard to do, much easier... to get TGEPython now you just import pytorque.tgeconsole :)

Swig will (automatically) bind stuff that the Torque Console system doesn't touch... it also gets rid of all the string passing... etc etc... it will bind native C++ functions with minimal wrappers for speed... and it is really really fast to export LOTS of stuff to Python with...

As you mention, Swig does lots of other bindings : Guile, Java, Mzscheme, OCAML,Perl. PHP, Python, Ruby, Tcl

So it would be possible to do other bindings... but this isn't exactly a trivial process... wxPython is a great example of using Swig with Python... anyone intrested should download the source... it isn't a matter of just Swig'ing the engine... there lots of design decisions and coaxing involved... a fair amount of hand wrapping/splitting/etc ...

I'll elaborate a little on the build stuff...

cd pytorque

setup.py install

This compiles the extension (in Release) and installs it all from the command line... (#note, no need to enter visual studio whatsoever)

setup.py build --debug install

This compiles the extension (in Debug) and installs it all from the command line... (#note, no need to enter visual studio whatsoever)

setup.py --build-dsw

This automatically builds the pytorque.dsw and all .dsp files... and is the only step necessary if you want to just use Visual Studio to build the extension.. the dsw stuff is all set up including projects/dependcies for the libraries ljpeg, zlib, etc... it knows how to Swig (and when to)... it knows about the .asm files... at the end of the compile it runs the distutil to install the extension properly into your existing Python system... so from the IDE you can just run: python torqueDemo.py -game rw .. and away you go, it'll use the newly compiled extension :)

The build system might also be a good fit for Torque outside of PyTorque... Win32/Linux/Mac configuration from a central point is very cool... and is quite popular these days... it's some work, but could be well worth it...

-J

#11 There is a PyTorque page up at ActionRPG...

As I wrote a Vision Statement and initial Roadmap, this counts an an official project launch :)

Interested coconspirators should consider joining the ActionRPG Mailing List for discussion of the project.

Vibes,
-J

#12 Josh,

You are a rebel and I love it! People need to stop writing, maintaining and debugging custom scripting languages. Using a Python type HLL is the answer. Sign me up!

I see you changed your mind about SWIG.

#13 This is looking VERY interesting...
Looks like I've got a really good reason to learn Python now (on top of all the other good reasons, that is).

I really hope this takes off in a big way.

Cheers - Steve

#14 Incidentally, this works with VS.NET just fine.

I've tested the generated .dsws and they work (though there's a small problem in the postbuild step which will have to be fixed. It's an easy fix.)

I'll be porting this to linux and possibly bsd soonish.

This is definitely the best way I've seen to build the engine :)

#15 I have to get my butt in gear on making this work under OS X.

#16 @Jeremy:

Quote:This is definitely the best way I've seen to build the engine :)

Yay! I am very glad that it built with no trouble on .NET from the command line, and the imported .DSW only had a / misplaced for .NET to complain about :)

Rock on!

@C J:

There is a zip file you'll need :) Shoot me an email when you're ready for a look...

Actually, there is the CVS question... on and on...

-J

#17 I am pleased to present a demo of the PyTorque Build System

From the readme.txt:

PyTorque - The Amazing Torque Game Engine in a Python Module

Vision Statement and Roadmap

Front Matter
------------

This is a demo/test release of the PyTorque build system. It should be of interest to anyone who:

1) Is interested in Python
2) Is interested in Torque
3) Is interested in hardcore build environments

Requirements
------------

1) This version currently compiles with MSVC6.0 or .NET, other compiler support is in the works.
2) Python22 or Python23 from www.python.org (Python22 is preferable as latest stable release),
get the Windows Installer!


Installation and Compilation
----------------------------

1) Get HEAD Torque as of 3-13-03 ..
2) Unzip PyTorqueBuildDemo into your Torque folder
3) Execute PyTorqueBuildDemo_Patch.bat now located in your Torque folder
4) Go into the pytorque/win32 folder and execute vc60_build_RELEASE.bat
5) Go into your example folder and execute torqueDemo.py
6) Be amazed :)

Alternatively (we like alternatives right?)

4) Go into the pytorque/win32 folder and execute vc60_build_DSW.bat
5) Go into your newly created torque/pytorque_vc6 folder and open pytorque.dsw
6) Build in RELEASE mode
7) Go into your example folder and execute torqueDemo.py
8) Be amazed :)

***IMPORTANT NOTE*** Unless you have Python configured for DEBUG builds (it isn't by default), DEBUG builds will fail, no worries you're just trying this out right? :)

What you are seeing
___________________

1) You can build/install Torque as a standard Python module either from the command line using Python distutils,
or you can generate a Visual Studio Workspace for Vc6 (which can be imported into .NET) and build/install it that way.

2) A completely automated build system, capable of *automatically* adding/remove source and interface files, compiling ASM,
executing Swig to generate new bindings, etc... again from the command line distutils or from the auto-generated
Visual Studo Workspace... they even build to the same folders so use them simultaneously :)

3) A completely clean example folder, with only torqueDemo.py added, is capable of running the samples... in addition,
command line options, like -game rw work :)

4) The future

-Joshua Ritter
www.actionrpg.com

#18 Way to go JR!!!

I will be nabbing my copy later this evening :)

time to put away those polynomials for a while and play with TGE ;0

#19 Say I'm writing a game in Torque. As the getting started file says, most of the work should be done in script. Now, say I want to write a function to print the numbers between one and ten. In TSL I do it like this:

function useless()
{
for (%i = 0; %i < 10; %i ++)
echo(%i);
}

In python I would do it like this:

for x in xrange(0,10):
print x


I want to do all my scripting work for my game in Python. Just what would I have to do to get it working?

#20 Is this dead?

I see a 404 at actionrpg.com

tone