Whats next for Python-Ogre???

[Andy Miller]

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

[Alex de Landgraaf]

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

Hi Andy,

Andy Miller wrote:
> - 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)

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-----

[Krešimir Špes]

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!

[chpod]

Hi all,

> especially considering that many people are probably using it because the prefer the simplicity of Python over the complexity of C++

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

[Andy Miller]

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

--
You received this message because you are subscribed to the Google Groups "Python Ogre Developers" group.
To post to this group, send email to python-ogre...@googlegroups.com.
To unsubscribe from this group, send email to python-ogre-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/python-ogre-developers?hl=en.

[dermont]

If this is your intention why not just support an existing game engine
such as OgreKit which appears to have most of the core modules,
including loading blend files directly:

http://www.ogre3d.org/forums/viewtopic.php?f=11&t=54431&p=370477&hilit=OgreKit#p370477

As for the switch to Mercurial, I don't really see the point since
python-ogre is basically maintained by a single developer with little
or no community support. Maybe I'm missing something obvious.

If it were me I would split python-ogre into core(Ogre and OIS) and
python-ogre-addons(the remaining modules), concentrate on one build
only the current svn or 1.7 version of Ogre, update the build system
to separate the downloads and build and move to CMake.

Andy Miller wrote:
> 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 <kresim...@gmail.com> wrote:
>
> > 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!
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Python Ogre Developers" group.
> > To post to this group, send email to
> > python-ogre...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > python-ogre-devel...@googlegroups.com<python-ogre-developers%2Bunsu...@googlegroups.com>

[dermont]

@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.

[Andy Miller]

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

To unsubscribe from this group, send email to python-ogre-devel...@googlegroups.com.

[Alfred Morgan]

> Thoughts???
> Andy

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.

> the learning curve for using Python-Ogre is steep

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.

> it's still a complex beast to build

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.

> pygame which is simple and drives incredible community support

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.

> Build a Python Framework specifically for game creation that makes it easy to use the libraries

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

-alfred

[Ivan Vučica]

On Thu, Feb 11, 2010 at 02:02, Alfred Morgan <alf...@54.org> 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.

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

this was after 2 weeks of trying to compile python-ogre.

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

[Enrico Zschemisch]

Hi,

Am Mittwoch 10 Februar 2010 09:41:13 schrieb Andy Miller:
> 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)
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

[dermont]

> 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.

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.

>> Andy wrote: There are lots of other todo's on my list (move to WAF for the build system,..

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.

[Alfred Morgan]

On Feb 10, 3:13 am, Andy Miller <nzmill...@gmail.com> wrote:
> 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
> ??)

I've really liked working with Bazaar (I'm a former SVN guy myself).
It would be nice to have python-ogre hosted on launchpad.net for
Bazaar access.

Here are some comparison points:
http://wiki.bazaar.canonical.com/BzrVsHg