As the Python-Ogre project is a couple of year old now, and has progressed
through multiple versions of Ogre and associated libraries I'd like to start
a discussion on where to take it next..

To me it's proven the functionality of Romans Py++ and Boost.Python -- in
that there hasn't been a library which has proven unwrapable, and we have
yet to see any real bugs along the way (certainly have areas that need
attention and unsupported functions, however nothing that isn't fixable).

On the downside it's still a complex beast to build -- and while the Windows
binary version is simple to install there are times that the Linux version
requires a bit of 'c'/'scripting' skills to get it to compile (although this
certainly has improved significantly thanks to contributions from the
community) -- and the Mac version stabilized nicely before the latest
version of OSX kicked in and broke it again...

While I'm obviously going to continue to support the latest and greatest
version of Ogre I do see issues in that there are currently too many
supported libraries, and the learning curve for using Python-Ogre is steep,
especially considering that many people are probably using it because the
prefer the simplicity of Python over the complexity of C++..  An example of
this would be pygame which is simple and drives incredible community support
(Panda3D comes close, however it's issue in the underlying technology I
believe)

So how about:

   - Create a 'core' package with reduced libraries -- ie one (or two)
   GUI's, one Physics, one sound, one or two addons, networking, I/O
   - Build a Python Framework specifically for game creation that makes it
   easy to use the libraries
   - 'Prove' this by converting a current C++ opensource game to Python-Ogre
   (SuperTuxKart etc)

There are lots of other todo's on my list (move to WAF for the build system,
create a new windows installer with NSIS, review non Boost technologies to
reduce memory footprint etc) however none of them fundamentally change what
we have today or drive the overall usage in a broader community.

Thoughts???
Andy

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andy,

This sounds like a great idea, one that would give python-ogre quite a
boost in use and popularity if done right. The one thing that put me off
was the complexity and difficulty in using 5-6 separate APIs that all
worked in a different manner.

The problem is of course that there are multiple libraries for
everything you state above (ODE/Newton/Bullet, CEGUI/quickgui/betagui
etc). Everyone has his/her own set of favorite libraries in their own
framework so you're bound to create some friction here, even though it
will be better in the long run to rally around a single set of libraries.

With this out in the open, which libraries will be in your 'core' package?

cheers,

Alex

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktyirwACgkQQeuQA5TF/Uur7QCeKg0o9pXXBEwQ8/rdBWHiL6Kj
wSwAn1mxRkGYGaLWM09E8adXeTVO8a8b
=vtiA
-----END PGP SIGNATURE-----

I totally agree, we should have a core package that is maintained the
most compared to other libraries. imho, upgrading to newer versions of
boost.python should be taken with a grain of salt.

I still think the best solution is to separate development into trunk
and stable branches, porting fixes from the stable branch to the trunk
and updating the stable branch each time a new stable release is made.

as for proofs of Python Ogre usability, my company has already made 5
commercial games using Python Ogre, all of which work on the PC and
Mac, and more are on the way, so keep up the good work!

Hi all,

This is definitely the key. When reducing the amount of supported
libraries, the user community becomes happier and stronger ("if it is
in the core package, then for sure someone already the same difficulty
that I am facing").

We are here using python-ogre with wx (essentially because when we
stated Qt was not available and would have brought license issues). If
you support Qt or wx in the core package, you are likely to extend the
user community outside the game world (e.g. scientific visualisation).
Do you plan to support one of them?

Cheers,
chpod

Also note that Ogre is moving to a distributed source control model (almost
certainly Mercurial) and one thought is to implement changes to the
development model as part of a move away from SVN (or keep SVN as the stable
??)

As for core libraries I'm considering the following: (open for discussion)

   - *Ogre* (including all the 1.7 components such as terrain and paging)
   - *OIS* (for input)
   - *Bullet/OgreBullet* (Physics) -- accepting the fact that this might
   require updates to the base OgreBullet C++ modules which is not a bad thing.
    The other physics libraries are either 'old', don't support all platforms,
   or not open source -- and bullet seems to be under heavy development and
   being used commercially.
   - *Hydrax*, *SkyX* - great water and sky effects
   - *OgreOggSound* (sound)
   - And not sure about the GUI :) -- have a thought about support 2, one
   that is "complete" and the other "simple" -- perhaps *CEGUI* and *
   ButtonGUI* or *QuickGUI*... Hadn't thought about 'wx' however that might
   make a lot of sense for a "windows" app that has 3D presentations..

Comments...
Andy

On 10 February 2010 18:47, Krešimir Špes <kresimir.s...@gmail.com> wrote:

@chpod
Why is there is no need to support Qt or wx in the core packages? Can
you not easily use both with python-ogre module via wxPython or PyQt/
PySide.

I indeed would suggest using an existing framework with OgreKit being one of
a number of options out there  (I did look at OgreKit specifically a while
back and it didn't seem very complete, however may have improved)-- again
welcome suggestions....

Andy

On 10 February 2010 19:48, dermont <dermontg...@gmail.com> wrote:

Stick with 64-bit friendly and Carbon-free libs.  I got stuck with OIS
not supporting 64-bit or using Carbon or something of that sort.  I'm
still running python-ogre in 32bit mode on my Snow Leopard because of
this.

I didn't think it was too bad.  The python-ogre tutorials really
helped a lot.  I never used ogre before and I was able to get a bunch
of ninjas attacking me on a varying terrain in one day.  Of course
this was after 2 weeks of trying to compile python-ogre.

If python-ogre had an easy binary installer for all the major
platforms then it would lower the barrier to enter.  or even a "python
setup.py install" that worked.

I loved pygame, I used to use it all the time, but I stopped ever
since Leopard came out.  Then when they finally got a Leopard binary I
moved on to Snow Leopard.  Pygame is always one step behind :( But
anyways, one of the things that captured my attention in pygame at the
beginning was a short and easy to follow how to build a "punch the
monkey" banner ad game.  If python-ogre had some simple step by step
"how to make a FPS" then adoption would increase.  Also, when you go
to pygame's website the first thing you see is games and cool stuff
that people built.  It would be cool to have python-ogre have a
spotlight section.

This will be key.  High level libraries makes awesome how to docs
easy.

-alfred

While Cocoa is needed to be future-proof, consider that most players will be
running Leopard. Consider that (at least our) publishers demand support not
for 10.5, but for 10.4 minimum, and for PowerPC. Yes, in 2010.

Also, don't dismiss Carbon so easily. I found it hyper-cool that I could
easily import Carbon framework using ctypes and use various API to resolve
issues while porting code from PC, and all without wrapping and re-wrapping
whenever I needed a new API.

Examples of stuff that I used thanks to a C API that I could use with
ctypes:
* carbon.CGDisplayShowCursor(ctypes.c_uint(0)) --> hide cursor
* carbon.HideMenuBar()

Also I had to do tricks with exiting event loop because in full screen I
could not get mouse input. I added code to the wiki some time ago.
http://wiki.python-ogre.org/index.php/OSXFullscreenBug

I think it's not just OIS that uses Carbon, I think Ogre itself uses Carbon
in its Mac port. Correct me if I'm wrong, I didn't dig deep enough.

Now, maybe I'm not knowledgeable enough to use Cocoa APIs from Python, but
this is what worked for me and what was easy enough.

Of course

I think this sums up the problems perfectly. Python-Ogre needs to be
continuously tested before being committed, and a stable branch needs to
exist which would be refreshed on a fixed schedule (e.g. 3 months). Also
binary builds need to be produced for multiple platforms. Another mail about
that in relation to OSX.

--
Regards,

Ivan Vučica

Hi,

Am Mittwoch 10 Februar 2010 09:41:13 schrieb Andy Miller:

I would love to see that happen :-)
When there are some sample applications, usage and coverage would immediately
rise, I think.

Additionally I would like to have "official" 64Bit support for Windows/Linux.
From your previous emails I get this is of no interest for you. I have still
no idea why Ogre fails to load certain files, as the 64 Bit version of Ogre
itselfs works without problems so I guess it must be a problem in the
bindings. Need more debugging here...
I asked some time ago if somebody can make a working Windows 64 Bit build but
got no answer :-(

Regards,
Enrico

From Andy's previous mails I thought he had already stated that he
didn't have a 64bit machine. I'm pretty sure if he did it would have
been resolved a long time ago.

I don't really understand why none of the users with 64bit machine
haven't come up with a solution yet.

Given that there is a known problem with 64bit builds on Linux, why is
there not a stickied thread on the ogreaddons forum to inform users of
the fact? Imagine how frustrating it must be to go through the whole
build, only to find out it doesn't run and it is a known issue.

You should maybe add documentation to that list, the python-ogre  wiki
installation instructions for Windows (excluding the auto-build)
section is out-dated and pretty poor.

On Feb 12, 2:22 am, Enrico Zschemisch <enr...@vicampus.com> wrote: