Irrlicht Engine

Oh thanks _maxim_ it fixed this one but now I have another :

../irrlicht-1.7.1/include/IGUIEditBox.h:88: Error: Syntax error in input(3).

:P sorry :P

jpalard wrote: ../irrlicht-1.7.1/include/IGUIEditBox.h:88: Error: Syntax error in input(3).

See instructions from irrlicht.i file near "%include IGUIEditBox.h" line.
You must edit line 88 in IGUIEditBox.h - delete L character before string constant "*".

Ok good it works, you should add this in da readme file :) Didn't read the whole .i file :P

But now I got :
[code]python Meshviewer.py
[...]
ImportError: No module named irr_pyXX
[/code]

What is irr_pyXX ?

jpalard wrote:What is irr_pyXX ?

Shared library ("pyd" extension on win platforms, "so" - on linux).
Try this archive http://kolosov.ath.cx/irrlicht_swig_ubuntu.zip for build minimal version.
I'm not sure of the correctness gcc commands, when I build this, my irr_pyXX.so return error with not found libIrrlicht.so.1.7, but file is exists.
Perhaps your attempt to be better.

_maxim_ wrote:

jpalard wrote:What is irr_pyXX ?

Shared library ("pyd" extension on win platforms, "so" - on linux).
Try this archive http://kolosov.ath.cx/irrlicht_swig_ubuntu.zip for build minimal version.
I'm not sure of the correctness gcc commands, when I build this, my irr_pyXX.so return error with not found libIrrlicht.so.1.7, but file is exists.
Perhaps your attempt to be better.

Do you find SWIG easy to use because I was going to use it for generating bindings for java

LizardGamer wrote:Do you find SWIG easy to use because I was going to use it for generating bindings for java

Yes, SWIG is easy to use and fast speed the development of wrappers, but this makes the additional costs (such as big size, many type checks with one function). I do not known Java, but if it have SWIG alternative (such as ctypes for Python), may be better to try them.

wrapper has some issues with pypy. some examples dont work. Quake3Explorer.py in example. Console doesnt output anything relevant except bunch of warnings about missing return types, but i guess thats ok.

roxaz wrote:wrapper has some issues with pypy. some examples dont work. Quake3Explorer.py in example. Console doesnt output anything relevant except bunch of warnings about missing return types, but i guess thats ok.

This example work with ctypes version, but not 100% (only run and show some gui interface).

yeah sure it works with ctypes and CPython. im testing it a little with pypy (since pypy is much faster than CPython). there is something with pypy that makes it not run as smooth as on CPython.

If someone is interested in pypy - know that debugging most of the time wont work if you dont have breakpoint at the end of pyirrlicht.py. Without that bp the other bps in your source wont be hit - weird! Also some examples would crash without logical explanation while they work fine on CPython.

roxaz wrote:some examples would crash without logical explanation while they work fine on CPython.

Perhaps this is answer "The interpreter implements the full Python language in a restricted subset, called RPython (Restricted Python). Unlike standard Python, RPython is statically typed, to allow efficient compilation." and "PyPy is able to run pure Python software that does not rely on implementation-specific features[4]. A translation for CPython C API extensions exists, but is incomplete and experimental." (http://en.wikipedia.org/wiki/PyPy)
Also PyPy recomendation with SSE2, this can work without, but require recompilation with "--jit-backend=x86-without-sse2" and whether it will be faster than CPython?

Thanks for the interesting news. I will seek time to test it.

nah its not that. what it said that interpreter of pypy is written in RPython. apps that are ran on pypy can use full power of python however.

A little note on debugging: today it works just fine, i guess reboot helped or what not.

roxaz wrote:apps that are ran on pypy can use full power of python however.

If I understand correctly, only pure Python apps, but pyirrlicht is not such.

pyirrlicht is ctypes wrapper.

PyPy’s ctypes implementation in its current state proves the feasibility of implementing a module with the same interface and behavior for PyPy as ctypes for CPython.

...

We reused the ctypes package version 1.0.2 as-is from CPython. We implemented _ctypes which is a C module in CPython mostly in pure Python based on a lower-level layer extension module _rawffi.

sounds like there should not be a problem with implementation eh?

Ok, as soon as I'm positive result with pypy, I post it here

also i got a suggestion regarding design. now every little thing in pyirrlicht is in global namespace of module. now that creates a little issue when debugging in eclipse - updating list of local symbols takes awful lot of time - like second. now stuff like 'dimension2di_ctor1' isnt used by user anyway so it could be hidden maybe in a class or secondary module. I would not mind encapsulating enum values with enum name too. Even if current implementation is very convenient - there is ton of enum values too, and those are included in that laggy list. what do you think?

EDIT:
also including documentation from c++ code would be super cool. did you use some scripts to parse c++ headers and generate ctypes wrapper? if so and if you shared that i could add stuff that myself.