here my first try with the new baby on my 64 machine (see below for details). I tried either the windowsXP and the ubuntu hardy package installers and I found a convergence in that they both showed the same behavior and errors.
Firefly demo - it gave me repetitive errors on console if I resize the window:
C:\Panda3D-1.6.0\samples\Media-Player>python Tut-Media-Player.py
:util(error): Unable to open /etc/Confauto.prc
:util(error): Unable to open /etc/Config.prc
DirectStart: Starting the game.
Known pipe types:
wglGraphicsPipe
(all display modules loaded.)
:gobj(error): Texture::read() - couldn't read: /c/Panda3D-1.6.0/samples/Media-Player/Panda
Sneezes.avi
:gobj(error): Texture "/c/Panda3D-1.6.0/samples/Media-Player/PandaSneezes.avi" exists but
cannot be read.
Traceback (most recent call last):
File "Tut-Media-Player.py", line 81, in <module>
w = World()
File "Tut-Media-Player.py", line 26, in __init__
self.tex = loader.loadTexture(MEDIAFILE)
File "C:\Panda3D-1.6.0\direct\showbase\Loader.py", line 519, in loadTexture
raise IOError, message
IOError: Could not load texture: PandaSneezes.avi
and of course no video
another issue, but I’m not sure if is a bug or a devs choice, is that now the .prc variable ‘texture-path’ is not taken in consideration anymore by the loader so that even a line like:
issue a IOError: Could not load texture. That would not happen though if I specify my textures folder path with the ‘model-path’ variable instead the ‘texture-path’.
That’s it for now - there is something weird things happening on kubuntu with the P3D surface overlay that often flickers and do not disappear when i minimize the window but I’m not pretty sure if this depends on buggy ATI drivers on kubuntu or what else.
The PandaSneezes.avi issue has already been reported in the other thread talking about 1.6.0, and has already fixed for 1.6.1.
We have removed the texture-path config variable altogether. There never was any good reason to have two variables instead of one; all it did was create additional complexity and add to confusion. Just use model-path now.
I find confusing as well the actual situation where the ‘model-path’ name is used by almost all the loaders (texture, model, font, shader). My idea is that either you choose to use a single variable for all but with a more consistent name, as is ‘resource-path’ or to use one variable for each single resource (my preferred way), ‘texture-path’, shader-path etc. but actually the situation is still not clear.
A good point. “resource-path” would have been a better choice for the variable name. But we have “model-path” for historical reasons, and it’s difficult to change this now.
Did anything just change to interrogate on the cvs head?
*** Error in /home/pro-rsoft/Projects/panda3d/thirdparty/linux-libs-x64/artoolkit/include/AR/ar.h near line 233, column 1:
syntax error, unexpected IDENTIFIER, expecting '{' or ';' or ':' or '='
Error parsing file: 'grutil_composite1.cxx'
ar.h lines 231-233:
extern ARParam arParam;
/** \var int arImXsize
This always has worked before, I didn’t change my artoolkit version or so.
Hmm, I did just change the way that inherited virtual methods are handled by interrogate. But this change has nothing to do with the C++ parser part of interrogate, and that seems to be what’s going awry now.
I do see some recent additions to Config.pp et al for definig ARTOOLKIT_IPATH and such, but I guess you know about those?
Yeah, I added those, since I was tired of having to switch to makepanda every time I wanted to use artoolkit. The error was after I added the stuff to ppremake, it has worked well with ppremake as well.
I hate that interrogate messages are so cryptic. What does this one mean? Does it mean “ARParam” is not defined or so?
Yeah, that’s a likely guess. I can’t imagine why it would suddenly start complaining about it, though. Well, you can shadow the header file(s), I guess, like we always seem to end up doing anyway.
Wait, what? There is already an ar.h in parser-inc? Then it shouldn’t be reading the one in the system header files at all, and the datestamp has nothing to do with it. Something else has gone wrong. Are you sure the parser-inc directory is getting correctly named on the interrogate command line and such?
Hmm, well, nevertheless, if you’re getting the same error, it’s not finding that file. But it may be that ar.h is not the top-level file included by source code; you should figure out which file(s) this is, and shadow this one or ones instead.
Oh, wait, now I see what’s going on. arToolKit.cxx includes artools.h, which is shadowed in parser-inc, but Josh simply forgot to put it into the parser-inc/Sources.pp. Now, it works.
Still weird why this exact same build (with ppremake too) did work before but stopped working now. Oh well, doesn’t matter now.
You actually need to add -Dvolatile to the interrogate flags (and probably -Dmutable too), since interrogate itself doesn’t know about the volatile keyword. The interrogate flags should be similar to those added by ppremake (see SYSTEM_IGATE_FLAGS in Config.*.pp).
I guess the only reason makepanda hasn’t done this before is that we never tried to use makepanda to build a thread-aware version of Panda before.
built/lib/libpanda.so: undefined reference to `save_thread_context'
built/lib/libpanda.so: undefined reference to `init_thread_context'
built/lib/libpanda.so: undefined reference to `switch_to_thread_context'
Sounds like makepanda overlooked panda/src/pipeline/contextSwitch.c, probably because of the extension. (It helps for this file to be a C module, instead of C++, because it’s calling such low-level C functions.)
gcc -fPIC -c -o built/tmp/pipeline_contextSwitch.o -I"/usr/include/python2.5" -I"built/tmp" -I"built/include" -Ipanda/src/pipeline -O2 -DBUILDING_PANDA panda/src/pipeline/contextSwitch.c
panda/src/pipeline/contextSwitch.c: In function ‘setup_context_1’:
panda/src/pipeline/contextSwitch.c:261: error: ‘CS_JB_SP’ undeclared (first use in this function)
panda/src/pipeline/contextSwitch.c:261: error: (Each undeclared identifier is reported only once
panda/src/pipeline/contextSwitch.c:261: error: for each function it appears in.)
Storing dependency cache.
