PyOgre Thread - Major Annoucement

Xingo · Post by **Xingo** » Fri Mar 25, 2005 12:34 pm

Any news on the py2exe? I am still building the concept game in Blender GE so I can keep building the server, but making GUI interaction is an overkill of programming, I have to create so many event catchers over submeshes for collsion detection w/ mouse. The Python lines are stacking up and I've yet begin adding the battle engine. Pyogre is so much faster in FPS and gives me more power...

Clay · Post by **Clay** » Fri Mar 25, 2005 6:00 pm

I took a closer look at it. The problem comes from the dlls. I have to specify with python 2.3 that the dlls and .cfg file in the Lib\Site-packages\ogre and ogre\plugins directories are "data files", which py2exe thinks they are not needed. As far as I can tell, I can't seem to make distutils understand it needs to get things other than pyd and py files. Under python 2.4 there's an extra option to make it work:

Code: Select all

setup(name="PyOgre",
      version="1.0.0-07",
      description="Python bindings for the Ogre 1.0.0",
      packages=["ogre"],
      #package_data={"ogre" : ["*.dll", "plugins.cfg", "plugins/*.dll"]},
      data_files=df
      )

But pyogre uses 2.3.

I think I finally found what I need to fix it here: http://www.python.org/moin/DistutilsIns ... aScattered

I'll get to work on it later today.

bjourne · Post by **bjourne** » Fri Mar 25, 2005 6:39 pm

It works!!! The last problems I had was because two of the types needed to be wstring insead of string. The mSyntaxCodes member in GpuProgramManager needed to be of type std::set<std::wstring> instead of std::set<std::string>. Same thing with extensionList in class GLSupport. Not all demos run but most of them do.

Pyogre is awesome!

Clay · Post by **Clay** » Fri Mar 25, 2005 6:57 pm

bjourne wrote:It works!!! The last problems I had was because two of the types needed to be wstring insead of string. The mSyntaxCodes member in GpuProgramManager needed to be of type std::set<std::wstring> instead of std::set<std::string>. Same thing with extensionList in class GLSupport. Not all demos run but most of them do.

Pyogre is awesome!

Wow excellent job. Mind submitting a patch (or explain to me exactly what needs to be changed where) to fix the problem?

Edit: A better question: Any idea why it needed to be a wstring instead of a string?

Clay · Post by **Clay** » Fri Mar 25, 2005 7:25 pm

Ahh here we go. Undo your change and define OGRE_WCHAR_T_STRINGS when you build the Ogre library. This will cause all Ogre::Strings to be defined as std::wstring. It makes me nervous changing only two of these definitions. Does this work in the same way?

Edit again: Actually change this line:

Code: Select all

#define OGRE_WCHAR_T_STRINGS 0

to this:

Code: Select all

#define OGRE_WCHAR_T_STRINGS 1

in OgreConfig.h.

See if that actually compiles. I cannot make it do so on my system. I'll have to get this worked out before I can make the change in cvs. I'll start playing with it. =)

bjourne · Post by **bjourne** » Sat Mar 26, 2005 1:13 am

I don't think changing OGRE_WCHAR_T_STRINGS will work. The source contains hundreds of string literals and they all will have to be wrapped in the _TO_CHAR() macro for it to work. Changing them all was to much work.

I can not make a patch because I've been using Ogre 1.0 and also used a code-reformatting tool on all the source which makes patch kinda worthless. This is how I did:

Code: Select all

// Set extension list
std::stringstream ext;
String str;

const GLubyte* pcExt = glGetString(GL_EXTENSIONS);
LogManager::getSingleton().logMessage("GL_EXTENSIONS = " + String((const char*)pcExt));

assert(pcExt && "Problems getting GL extension string using glGetString");

ext << pcExt;

while(ext >> str)
{
    extensionList.insert(str);
}

ext.str("");

In ogrenew/RenderSystems/GL/src/OgreGLSupport.cpp changed to:

Code: Select all

// Set extension list
std::stringstream ext;
std::wstring into;
std::string tmp;
	
const GLubyte *pcExt = glGetString(GL_EXTENSIONS);

LogManager::getSingleton().logMessage("GL_EXTENSIONS = " + String((const char *)pcExt));

assert(pcExt
            && "Problems getting GL extension string using glGetString");

printf("Doing things with ext.\n");

ext << pcExt;
while (ext >> tmp)
{
    into = std::wstring(tmp.begin(), tmp.end());
    extensionList.insert(into);
}
ext.str("");

And in ogrenew/RenderSystems/GL/include/OgreGLSupport.h:

Code: Select all

std::set<String> extensionList;

to:

Code: Select all

std::set<std::wstring> extensionList;

In ogrenew/OgreMain/src/OgreGpuProgramManager.cpp. From:

Code: Select all

    bool GpuProgramManager::isSyntaxSupported(const String& syntaxCode) const
    {
        if (std::find(mSyntaxCodes.begin(), mSyntaxCodes.end(), syntaxCode) != mSyntaxCodes.end())
        {
            return true;
        }
        else
        {
            return false;
        }
    }

To:

Code: Select all

    bool GpuProgramManager::isSyntaxSupported(const String& syntaxCode) const
    {
	std::wstring tmp(syntaxCode.begin(), syntaxCode.end());
        if (std::find(mSyntaxCodes.begin(),
		mSyntaxCodes.end(), tmp) != mSyntaxCodes.end())
        {
            return true;
        }
        else
        {
            return false;
        }
    }

ogrenew/OgreMain/include/OgreGpuProgramManager.h:

Code: Select all

typedef std::set<String> SyntaxCodes;

to:

Code: Select all

typedef std::set <std::wstring > SyntaxCodes;

I have no idea why it works. Maybe it has something to do with the python-bindings expecting unicode strings where there is normal strings? Or maybe it is gcc's treatment of strings..

Clay · Post by **Clay** » Mon Mar 28, 2005 11:02 pm

Quick update, I'm working on getting a python2.4 version built. Next release (possibly by this coming weekend) will have a fix for the packaging issues brought up by Xingo, and a few minor bug fixes.

Xingo · Post by **Xingo** » Tue Mar 29, 2005 3:56 am

*falls stiff twitching* Yay! clay my hero!

Xamusk · Post by **Xamusk** » Sun Apr 03, 2005 6:46 pm

hmmm... nice idea this one of PyOgre.
I just wished I could help...
Anyway, I'm a debian linux user, and am still trying to learn python (failed to gather enough concentration/motivation to learn C/C++). Yes, I know that as I'm still learning I have not much to offer, but would like to help in making pyogre work.
Actually, I was thinking about learning python by making a 3D game (yes, it's not a very easy task to learn all that together) and thought Ogre was quite an engine too, specially as I use Blender to create meshes.
OK, I have no skills whatsoever, just trying to be helpful.

Clay · Post by **Clay** » Sun Apr 03, 2005 8:10 pm

Big annoucement about pyogre.

After fog and I have spent a LOT of time trying to resolve problems with pyogre (fog has been working on linux pyogre, I have been working on some of the nasty iterator bugs), we have decided to undertake a major update to pyogre to make it both Linux friendly and more pythonic in nature. I will be working on NOTHING other than pyogre for the next few weeks until we have things back in a semi-stable state.

Until that time I am flagging pyogre as inactive. You can download and play with the pyogre source, but I will not be accepting any patches until further notice. fog and myself have to get to a stable state before I will start accepting patches again.

I expect this to take around 1-2 weeks before we are ready to open it back up for contributions and patches. If you are interested in working on pyogre or learning how to use it, I would wait a week or two for the updated version.

Finally, note that I will not garauntee that pyogre will remain source-compatible in the next release.

Thank you for your patience!
Clay

jpfarias · Post by **jpfarias** » Fri Apr 08, 2005 3:47 pm

Can someone compile pyogre on python 2.4 for windows?

Thanks!

--
JP

Clay · Post by **Clay** » Fri Apr 08, 2005 4:26 pm

Pyogre currently only works for python 2.3 under windows. If you give us another week that'll change.

jpfarias · Post by **jpfarias** » Fri Apr 08, 2005 6:31 pm

Ok!

Thanks for your (quick) feedback. I surely can wait one more week for pyogre on python 2.4.

Just curious: Will the actual pyogre compile as is on python 2.4? If that is possible I can try for myself, ever if I have to build all the ogre thing...

--
JP

Clay · Post by **Clay** » Sat Apr 09, 2005 6:01 am

Basically, the current pyogre in CVS will probably compile against python 2.4. The main problem is that I havn't taken the time to get boost.python compiling for python 2.4. My requests for help getting it compiled went unanswered. =/

Even if you could get it compiled under python 2.4, the next major release will break source compatibility, so be warned if you start using it now you will have to re-learn a good chunk of the library.

This, on top of the fact that we'll be officially supporting 2.4 in about a week means you should probably just wait for a bit longer.

KayNine · Post by **KayNine** » Sun Apr 10, 2005 3:06 am

This looks incredibly interesting, and I'd love to try it out. But pls excuse these very basic questions.....

I downloaded http://www.idleengineer.net/files/PyOgre-1.0.0.py23.zip. Is there any doco on how to get the demo to run? (Yes, I read the readme.txt, and yes, I copied across to MEdia directory)

Is 06_PyOgre-1.0.0 suposed to go in the Python23 directory? The error I get is ....

Code: Select all

Traceback (most recent call last):
  File "C:\DXSDK\Ogre\06_PyOgre-1.0.0\demo\smokedemo.py", line 1, in ?
    import localogre as ogre
  File "C:\DXSDK\Ogre\06_PyOgre-1.0.0\demo\localogre.py", line 15, in ?
    from ogre import *
ImportError: No module named ogre

Also, will it run with Python2.2?

Thanks.

KayNine · Post by **KayNine** » Sun Apr 10, 2005 3:52 am

OK, well running the exe instead of the zip resulted in the files going in the correct place (under the python23 folder). Then upgrading to DX9c fixed the initial error. Then there was a media error (I had copied the media folder from Ogre1.0.0). So downloaded http://www.idleengineer.net/files/media.zip - which contained the required chiropteraDM.pk3 (missing from the Ogre 1.0.0 media folder).

...and it works. And it's great. Terrific job.

Clay · Post by **Clay** » Sun Apr 10, 2005 3:59 am

Nah, it doesn't work on Python 2.2. The next release will hopfully work on python 2.3 and 2.4, and if there's interest I'll try to get it running on 2.2.

If you downloaded the .zip file you should cd into the directory and run "python setup.py install" (be sure you run that with python2.3 if you have multiple ones installed. Alternatively, just download the .exe installer. It does all the work for you and puts the ogre demos into your python directory.

rufus · Post by **rufus** » Mon Apr 11, 2005 6:34 am

this is probably no immediate help to anyone but...
I've been trying to compile pyogre (from cvs) on an AMD64 running fedora core 3, following the instructions posted a couple of weeks ago, using ogre 1.0.1
A couple of problems:
I had to manually patch a couple of the header files using the patch file
and then ran into problems with pyste, sorry I'm not a c++ enthusiast but I did have a similar problem to this with boost.python caused by changes in gcc from 3.3 to 3.4

any ideas ?

/usr/bin/python tools/pyste.py -I src/pyogre -I include -I include/ogre -I src/pyogre -DPYOGRE_BUILD --cache-dir=build/pyogre_/cache --multiple --module=pyogre_ --out=build/pyogre_ --pyste-ns=py --export-enum-values src/pyogre/Animation.pyste
In file included from include/ogre/OgreStdHeaders.h:14,
from include/ogre/OgrePrerequisites.h:88,
from include/ogre/OgreAnimation.h:29:
/usr/include/c++/3.4.2/cmath: In function `float std::acos(float)':
/usr/include/c++/3.4.2/cmath:103: error: `__builtin_acosf' undeclared (first
use this function)
/usr/include/c++/3.4.2/cmath:103: error: (Each undeclared identifier is
reported only once for each function it appears in.)
/usr/include/c++/3.4.2/cmath: In function `long double std::acos(long double)':
/usr/include/c++/3.4.2/cmath:107: error: `__builtin_acosl' undeclared (first
use this function)
/usr/include/c++/3.4.2/cmath: In function `float std::asin(float)':
/usr/include/c++/3.4.2/cmath:120: error: `__builtin_asinf' undeclared (first
use this function)
... several dozen similar messages....
Traceback (most recent call last):
File "tools/pyste.py", line 11, in ?
pyste.main()
File "/home/billhart/src/pyogre/ogreaddons/pyogre/tools/Pyste/pyste.py", line 427, in main
status = Begin()
File "/home/billhart/src/pyogre/ogreaddons/pyogre/tools/Pyste/pyste.py", line 264, in Begin
return GenerateCode(parser, module, out, interfaces, multiple)
File "/home/billhart/src/pyogre/ogreaddons/pyogre/tools/Pyste/pyste.py", line 382, in GenerateCode
declarations, parsed_header = parser.Parse(header, interface, tail)
File "/home/billhart/src/pyogre/ogreaddons/pyogre/tools/Pyste/CppParser.py", line 165, in Parse
declarations = self.ParseWithGCCXML(header, tail)
File "/home/billhart/src/pyogre/ogreaddons/pyogre/tools/Pyste/CppParser.py", line 126, in ParseWithGCCXML
raise CppParserError, 'Error executing gccxml'
Pyste.CppParser.CppParserError: Error executing gccxml
scons: *** [build/pyogre_/Animation.cpp] Error 1
scons: building terminated because of errors.

bjourne · Post by **bjourne** » Mon Apr 11, 2005 9:03 pm

I also had the same error. The problem is that gccxml is not entierly compatible with gcc 3.4. A workaround that worked for me is to change #include <cmath> to #include <math.h> which makes it so gcc uses C's math functions instead of C++. See also this http://public.kitware.com/pipermail/ins ... 11921.html

Clay · Post by **Clay** » Tue Apr 12, 2005 4:59 pm

Ok all of you pyogre guys. We have made a major change to development (we got rid of Boost.Python in favor of the more linux and python friendly SWIG). Please use this thread for all future pyogre discussion: http://www.ogre3d.org/phpBB2/viewtopic.php?p=66906

bjourne, I'd like to personally thank you for the work you did on pyogre with Boost.Python. We have made the decision to make everything more linux friendly, and worked our butts of to make it happen. I hope you like it. =)

Clay

Ogre Forums

PyOgre Thread - Major Annoucement

Python 2.4

Ok