It has always been 16, hasn’t it?
Though, there has been some refactoring of the fbprops quality code, I believe. Drwr probably knows more.
Again, the model cache is enabled for models (but not textures) by default. I don’t know why you think it isn’t.
Yes, you’re right !
So, it must be due to the new allocation of accum. bits, it’s 0 in 1.5.3 and a month ago CVS, but it’s 64 now.
So, I just comment it out and I got back 24bits depth buffer.
I just can’t live with 16bits, because even the result of 0.1 and 1000 near and far planes is already horrible.
No, it’s NOT.
Both lines were commented out, and Ralph was loaded in 18 seconds, instead of 1. I tried it several times just to be sure that it’s not cached.
Perhaps yours didn’t get updated upon installation, because when I removed it and reinstalled, it was NOT generated.
Hmm, would it be an idea if the color-bits and depth-bits were set to 1 by default (this means to get as much as possible) ?
Hmm. Are you sure yours got updated upon installation? I believe some linux distros don’t overwrite a config file if it was changed.
Cuz’ I can’t recall I changed anything regarding model-cache.
Here’s what Config.prc gets generated from:
panda3d.cvs.sourceforge.net/view … iew=markup
Which rpm/deb/source package did you use? Then I can see for myself.
Almost all the code you write in Panda will be in one task or another. The one exception is the code in the very first Python file you import, before you call run(). Anything other than that is running within some task, and therefore cannot call taskMgr.step() or taskMgr.run() again. For instance, anything that responds to a -repeat event is running in the eventManager task.
Sorry, I’m still not following this. I guess if you’re happy calling dataLoop and igLoop directly, we can consider this solved; though I’m still trying to figure out if we should have some more interfaces on the TaskManager.
Do you mean in the Config.prc file there’s a reference to 64 bits in the accumulation buffer, or do you mean that’s what the code was selecting for some reason despite the config file settings? I’m confused because I don’t think there’s any config settings for accumulation buffer, just depth-bits, color-bits, alpha-bits, and stencil-bits.
David
@RdB :
I’m still using Hardy.
Yes, it was updated, since I chose Yes at the prompt. Just to be sure, I reinstalled my own old build, and reinstalled your Hardy .deb. Yes, it was updated.
@David :
Yes, I already got it behave as needed, so let’s pretend I didn’t have any problem about it.
That 64 is not in the .prc, but from getFbProperties().
OK, I still need more help to understand. What does your FramebufferProperties.getDefault() look like? You’re saying that the window is selecting a context with 64 bits of accumulation buffer, even at the expense of depth bits, even though no accumulation buffer was actually requested? That certainly sounds like a bug, but I’m not seeing that behavior here. What part did you comment out to make it work?
David
@JH: I can confirm this, apologies. Upon further inspection, makepanda seems to comment out the lines internally, when creating the installer.
However, it has always been disabled on Linux - in fact, Josh explicitly disabled the model cache on linux in 1.4.0. I don’t have a clue why, though.
If you want me to enable it, that would have to wait till 1.7.0.
I only commented the depth-bits line.
FBP.getDefault() :
depth = 1
color = 16
alpha = 1
@RdB :
it’s up to you, at least now we know why.
Ah, right. The default Config.prc file is explicitly requesting 16 depth bits for some bizarre reason. The new, improved framebuffer configurator in 1.6.0 is honoring this request, and looking for a config with a depth buffer with 16 bits. Your graphics card actually happens to provide one (it also comes along with 64 bits accumulation buffer, but that’s just a distraction).
pro-rsoft, we should probably change that to “1” instead of “16” in the default config file, and for the color-bits too. Or maybe it should be “24”, which is what virtually every PC graphics card can handle by default, but “1” is more general.
David
Hmm, okay. Should I also make it 1 for the alpha, stencil bits and multisamples?
I guess it does make sense to pick up for 1.6.1, also?
Alpha and multisample bits are less critical, and not all cards provide alpha or multisample framebuffers, so we shouldn’t require them. Let people turn them on when they need them.
Some default stencil-bits might be generally useful, and I’m pretty sure all graphics cards do provide stencil as an option, but tinydisplay doesn’t, so maybe we shouldn’t mess with that either.
Yeah, this seems simple enough and important enough to pick up for 1.6.1.
David
I’m getting this error compiling 1.6.0 on openSUSE 11.1 and later: (the error comes from rpmlint, which checks the source for potential errors before it packages anything. It’s pretty strict.)
I: Function call needs to pass NULL-pointer as last argument
E: panda3d missing-sentinel panda/src/glxdisplay/glxGraphicsWindow.cxx:711However, line 708-711 are:
_ic = XCreateIC
(im,
XNInputStyle, XIMPreeditNothing | XIMStatusNothing,
NULL);I can see a sentinel for sure. Any idea what could be wrong?
Gee whiz. What if you explicitly cast the NULL to a pointer type: (void *)NULL?
David
Hmm, yes, that seemed to work, thanks. I’ve checked in the fix.
I seem to have the same problem as neo does above, the same errors are being given, and when I tried Thread.isThreadingSupported() it was false, however I’m on OSX, so drwrs guess seems unlikely unless it was missed out on both systems. It also seems unlikely that threading could be broken for everyone, so any ideas as to getting this working?
id try it out on my linux/windows machine, but im away from it for a month.
It can’t be the optimize level. I’m very sure everything is optimize level 3.
In my CVS Head build, uncommenting the showCollisions lines in Roaming Ralph doesn’t crash, but it doesn’t show any collisions either.
@fynn, does isThreadingSupported really return False? Did you use the OSX build from the download page?
>>> Thread.isThreadingSupported()
0i was assuming that 0=false in this case, if not 
and yes, i used the build from the download page.
Oops, you’re absolutely right–there was a genuine bug in there that was preventing the showCollisions() call from working. I just checked in a fix, tagged for the branch.
David
Excellent, thanks!
I can confirm this. The public OSX build, at least, does not in fact have threading enabled. Not sure what went wrong there.
Note that you do have to define both HAVE_THREADS and SIMPLE_THREADS in order to enable simple threading (SIMPLE_THREADS by itself is not sufficient).
David