Python-Ogre Status

[Andy Miller]

As most of you have noticed I've been a little quiet on the email/forum front recently - partly because of changes/pressures in the real world, and partly because we've had a run of less than useful people making comments that simply didn't deserve my time in responding...

 

Remember that Python-Ogre is an opensource project, and by definition that means that anyone can make changes to improve on the existing code base -- so if you have an issue then have a go at solving it before commenting -- after all the real fun part of open source is in the learning :)

 

I've also realised that the work I put into getting Linux to build (in a semi reasonable way) is not what people expect (yes, it's not deb packages, however I was unable to find ANY other project that does what Python-Ogre does, and clearly uninformed comments about why we don't use SCONS/Make/Cmake/etc are not helpful) - And, the current BuildModule system works on Linux and Window (and Mac), and is based on Python so there isn't yet another language/format etc to learn..

 

So moving forward:

• My work will be focused on Windows, with perhaps Mac support to follow -- as an aside my own Linux work revolves around embedded systems for real time controller work, hence I don't have regular access to a 'graphics' Linux system
• I will release a Python-Ogre 1.2 binary for Windows and it will be based on the latest SVN version of Ogre 1.5 (although there won't be any breaking changes in the wrapper to Ogre 1.4 support) -- it should be noted that there aren't any outstanding issues with the 1.2 release - simply grab the latest of everything and go for it....
• Python-Ogre will be split into a base package (Ogre, OIS, QuickGUI, CEGUI, ??) and an addons package
• A Linux Maintainer is required (could be a couple of people that want to share the responsibility) - email me if interested
• A Site Maintainer is also required - I pay for the hosting etc, however there is Joomla site and Wiki that needs to be maintained and would be a great learning platform if someone is interested - again email me..

Basically my personal interest revolves around leading edge development (I'm not a 'maintainer') and to ensure that I keep interested in Python-Ogre I'm going to focus on one platform (Windows) and offer my support to others to support Linux (I believe we already have a proven platform independent framework so the Windows focused work should merge across to Linux without any issues). 

 

I'm also going to base my development on bleeding edge libraries and accept the challenges that this brings (again noting that it's simple to maintain a 'stable' version if someone desires)

 

Regards

 

Andy

 

 

 

 

 

 

 

 

[Jacob Everist]

Actually, I'm quite surprised how truly cross-platform this system really is.  Trying to integrate all these various components with their own idiosyncratic build systems while simultaneously making them build on 3 platforms is no easy feat and that's probably one of the biggest features of python-ogre I would think :)

Jacob

--

Jacob Everist

[JosephLisee]

Andy,

Thanks for keeping us up to date. It is a large accomplishment what
we currently have, and I can see where you are coming from the library
development standpoint. I definitely appreciate your generosity in
providing for python-ogre.org.

Platform Maintenance:
I think using some branches in SVN will the maintainers for other
platforms. When you decide you want to release 1.2, 1.3, etc. Make a
branch in SVN, like "branches/1.2", in that branch we can fixe all
project versions in the build script (ie remove SVN/CVS head
checkouts). Then the Linux and Mac maintainers can tweak all the
build scripts and patches to make sure everything works and not have
to constantly chase an upgrade train. Its really simple from tortoise
SVN to make a copy of the current trunk. This will also allow people
to develop a set of build instructions that *always* work for a
certain branch & platform combination.

Core & Addons:
I really love this idea. This will also simplify the work of people
on other platforms by providing a smaller set of libraries to get
working as a first cut.

I hope to be able to contribute more in the future.

-Joseph Lisee

[Alex Trujillo]

Python-Ogre is the key to bringing Python to the table as a viable game programming language. I can't stress how important it is to the Python community to have a fully-featured, high performance rendering engine. Andy, I'm very glad to hear from you that I can expect novel improvements to the library in the future. You sound motivated to do more work on the package as time goes on, incorporating technologies developed by the community as they continue to improve.

I am using your work as the foundation for games of my own, and I hope to push the limits of Python-Ogre as a way to best display its attractiveness to the rest of the world.

I look forward to your upcoming 1.2 release, and will continue to work towards the dream-- Python, as a language, for commercial quality open source and independent games.

- Alex Trujillo
Project Lead, Superluminon (http://www.superluminon.com/)

[Krešimir Špes]

so, what happens with ogre 1.4.x in python-ogre1.2? will it still be
maintained? I don't want to switch my projects to 1.5 to upgrade to
python-ogre 1.2

[Andy Miller]

From a python perspective I doubt there will be any interface change due to the underlying Ogre version

 

There ARE a small number of interface changes between Python 1.1 and 1.2, however they are all pretty easy to catch and are not subtle (ie there is a change in the number of arguments to a function call, hence a nice absolute failure)..

 

AND, you can build you own version to suit with the SAME scripts -- remember that fundamentally the Python-Ogre build process generates code based upon the underlying C++ headers, and as I adjust to Ogre 1.5 I'm doing so in a way that doesn't break Ogre 1.4 support so you can use the same "generate_code.py" on either...

 

Andy

 

 

2008/5/20 Krešimir Špes <kresim...@gmail.com>:

[Krešimir Špes]

first of all, let me clear one thing up: Ogre 1.5 is shoggoth, right?

if so, wouldn't it be better to just fork the current ogre wrappers
into ogre15 package, so building ogre 1.4 wrapper will still be
supported without hacking the build scripts.

[Andy Miller]

One "if" statement in generate_code.py and two "#if OGRE_VERSION_MINOR == 4" in the header files does not a hack make (and doesn't justify a fork)....

 

Got to realise that using Py++ makes things very cool........ :)

 

Andy

 

2008/5/20 Krešimir Špes <kresim...@gmail.com>:

[Krešimir Špes]

:D

[Lakin Wecker]

First, let me start off this letter by thanking you for all the work
you have done.

And although the BuildSystem isn't what I originally expected, I've
come to appreciate everything it does. It is nice having a build
system that fetches everything for you and ensure they are all built
appropriately.

So, to summarize what you're saying is - if the community wants to see
more improvements in the linux area, you're going to need help and
lots of it? If so then I'm game to help. I don't have time to be the
linux maintainer by myself, but I don't mind putting in hours in terms
of building and testing and doing some small amounts of development.

Would now be a good time to start a discussion on tagging python ogre
releases and perhaps creating branches for significant releases? For
instance, some people may not want to build with Ogre 1.5 and would
prefer Ogre 1.4. Or do you see this as something that the build
system itself will handle?

Lakin

On Mon, May 19, 2008 at 8:48 PM, Andy Miller <nzmi...@gmail.com> wrote:

[Andy Miller]

Lakin

I'm going to start a new thread to discuss Linux as there seems to be some clarification needed :)

Andy

2008/5/20 Lakin Wecker <lakin....@gmail.com>: