Hmm, that’s true, I think we’re using dlmalloc by default; you should try turning this off by also adding:
#define ALTERNATIVE_MALLOCto your Config.pp file. Also retain the DO_MEMORY_USAGE line. Then, once again, ppremake and make install everywhere (sorry about that).
Please let me know if this does or doesn’t make a difference.
David
yay! this just did it. i had the first panda program running with success.
this code
import direct.directbase.DirectStart
#Load the first environment model
print 'start'
environ = loader.loadModel("/Users/kaweh/Projects/panda3d/models/panda.egg")
print 'done'
environ.reparentTo(render)
environ.setScale(0.25,0.25,0.25)
environ.setPos(-8,42,0)
#Run the tutorial
run()creates a running application and this output
g5:~/Projects/pandatest kaweh$ p pandatest.py
DirectStart: Starting the game.
Warning: DirectNotify: category 'Interval' already exists
:display: loading display module: libpandagl.dylib
Known pipe types:
osxGraphicsPipe
(all display modules loaded.)
:05-22-2006 12:48:15 ShowBase(info): Default graphics pipe is OpenGL (osxGraphicsPipe).
osxGraphicsStateGuardian::osxGraphicsStateGuardian()
:display: Unable to set window properties: size=(800, 600)
:audio(error): LoadLibrary() failed, will use NullAudioManager
:audio(error): dlopen(libmiles_audio.dylib, 6): image not found
:audio: NullAudioManager
:audio: NullAudioManager
:audio: NullAudioManager
:audio: NullAudioManager
:05-22-2006 12:48:15 ShowBase(info): __dev__ == 0
start
:loader: loading file type module: pandaegg
:egg2pg: Reading /Users/kaweh/Projects/panda3d/models/panda.egg
:gobj: Loading texture /Users/kaweh/Projects/panda3d/models/maps/panda_torso.rgb
:gobj: Loading texture /Users/kaweh/Projects/panda3d/models/maps/panda_head.rgb
:gobj: Loading texture /Users/kaweh/Projects/panda3d/models/maps/panda_viser.rgb
:gobj: Loading texture /Users/kaweh/Projects/panda3d/models/maps/panda_hat.rgb
:egg2pg: Flattened 1 nodes.
done
:util(warning): Adjusting global clock's real time by -4.19311 seconds.
:05-22-2006 12:48:19 ShowBase(info): Got window event: origin=(0, 0) size=(800, 600) title="Panda" !undecorated !fullscreen foreground !minimized open !cursor_hidden
:05-22-2006 12:48:28 ShowBase(info): Got window event: origin=(0, 0) size=(800, 600) title="Panda" !undecorated !fullscreen !foreground !minimized !open !cursor_hidden
:05-22-2006 12:48:28 ShowBase(info): User closed main window.
:05-22-2006 12:48:28 ShowBase(info): Exiting ShowBase.these two lines in my Config.pp did it. compiled from yesterdays CVS head.
thanks a lot for the effort! i will give more features a try now.
is there a list of known issues on OS X, and things i shouldn’t/couldn’t try at home right now?
thanks again! happy me
update: the code from the manual’s tutorial section works without any problems. i have my nice walking panda… 
i’ll try to collect all this information into a single post if people are interested.
while working through the manual, i realized that i wanted to try out some of the tools in pandatools. ppremake and make install pandatools seems to have a problem early on:
cd ./src/pandatoolbase && make all
g++ -undefined dynamic_lookup -dynamic -dynamiclib -o Opt2-osx/libpandatoolbase.dylib -install_name libpandatoolbase.dylib Opt2-osx/pandatoolbase_animationConvert.o Opt2-osx/pandatoolbase_config_pandatoolbase.o Opt2-osx/pandatoolbase_distanceUnit.o Opt2-osx/pandatoolbase_pandatoolbase.o Opt2-osx/pandatoolbase_pathReplace.o Opt2-osx/pandatoolbase_pathStore.o -L/usr/local/panda/lib -L/usr/local/panda/lib -L/usr/local/panda/lib -linterrogatedb -lprc -ldconfig -ldtoolutil -ldtoolbase -lexpress -lputil -framework Python
ld: warning can't open dynamic library: libpandabase.dylib referenced from: /usr/local/panda/lib/libexpress.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)
ld: warning can't open dynamic library: libpipeline.dylib referenced from: /usr/local/panda/lib/libputil.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)
ld: Undefined symbols:
__ZN10MutexDebug10do_releaseEv referenced from libputil expected to be defined in libpipeline.dylib
__ZN10MutexDebug7do_lockEv referenced from libputil expected to be defined in libpipeline.dylib
__ZN10MutexDebugC2ERKSsb referenced from libputil expected to be defined in libpipeline.dylib
__ZN10MutexDebugD2Ev referenced from libputil expected to be defined in libpipeline.dylib
__ZN6Thread12_main_threadE referenced from libputil expected to be defined in libpipeline.dylib
__ZN6Thread16init_main_threadEv referenced from libputil expected to be defined in libpipeline.dylib
__ZN9CycleData17complete_pointersEPP13TypedWritableP9BamReader referenced from libputil expected to be defined in libpipeline.dylib
__ZN9CycleData6fillinER16DatagramIteratorP9BamReader referenced from libputil expected to be defined in libpipeline.dylib
__ZN9CycleData6fillinER16DatagramIteratorP9BamReaderPv referenced from libputil expected to be defined in libpipeline.dylib
__ZN9CycleDataD2Ev referenced from libputil expected to be defined in libpipeline.dylib
__ZNK10MutexDebug6outputERSo referenced from libputil expected to be defined in libpipeline.dylib
__ZNK9CycleData14write_datagramEP9BamWriterR8Datagram referenced from libputil expected to be defined in libpipeline.dylib
__ZNK9CycleData14write_datagramEP9BamWriterR8DatagramPv referenced from libputil expected to be defined in libpipeline.dylib
__ZNK9CycleData6outputERSo referenced from libputil expected to be defined in libpipeline.dylib
__ZTI10MutexDebug referenced from libputil expected to be defined in libpipeline.dylib
__ZTI9CycleData referenced from libputil expected to be defined in libpipeline.dylib
/usr/bin/libtool: internal link edit command failed
make[1]: *** [Opt2-osx/libpandatoolbase.dylib] Error 1
make: *** [pandatoolbase] Error 2one more problem i encountered. please have a look at this snippet:
import direct.directbase.DirectStart
from direct.showbase.DirectObject import DirectObject
class MyHandler(DirectObject):
def __init__(self):
self.accept('w', self.do_something)
def do_something(self):
print 'w'
h = MyHandler()
run()if i press ‘w’ i get my into do_something, but keeping ‘w’ pressed does not yield more calls to do_something. letting go of the key and pressing it again will call do_something again. there is no there is no key repeat happening, as expected. did you encounter the same problem?
this behaviour seems to be different on Windows (though i haven’t yet had the opportunity to test this exact snippet; but samples are using this construct and on Windows i get key repeat).
any hints?
put
messenger.toggleVerbose()in your code and try it again. The messenger should output what events get thrown along with the time each event gets thrown. Does the same thing happen?
yep. same thing happens.
for a press i get
:05-24-2006 00:12:49 Messenger(debug): sent event: w sentArgs: []
w
:05-24-2006 00:12:49 Messenger(debug): sent event: time-w sentArgs: [16.103248000000001]for release i get
:05-24-2006 00:12:52 Messenger(debug): sent event: w-up sentArgs: []
:05-24-2006 00:12:52 Messenger(debug): sent event: time-w-up sentArgs: [19.790804999999999]i do not get any messages in-between.
(and thanks for the tip: this is great for later debugging)
seems i have the same problem with mouse events. can’t implement mouse dragging because of this.
does anyone have hints where to look into the source code to see where these events are collected from the system?
Well… they are recorded in the osxdisplay functions you can fallow the flow from there.
But before you jump in there. What is the right behavior? Repeat code are only redundant and the timing of the repeat is not controlled by the application.
Would you not be better served by a state machine with transition points ?.
Curious as to what you all think is the right approach. I guess the windows implementation sends the code many time ?
RogerRoger,
I can now confirm that the Windows version sends the code many times (as long as the approriate button is keep pressed). I assume the “correct” thing would be to have the same behaviour on both platforms.
From my experience all event based systems allow the user to get to that information, I wouldn’t say it’s redundant information. 
Though you are right, that this could be done with a state machine, but especially for smaller applications that might be overkill.
All OSs provide these events as far as I know. Libraries like SDL handle it the same way. The same metholodgy would apply to mouse events too.
So in general the “correct thing” (and I agree with you that there might be better ways to do this for different applications) is to mimic the same behaviour on both platforms, and the Windows behaviour is the one that I assume most people would expect.
Do you have the time to apply a fix to CVS or shall I try to look into my local build?
Thanks a lot!
Well again IMHO any controller code using the repeat codes from the key board is just asking for problems. It must be prepared to not receive a repeat for seconds and possible receive hundreds or thousands a second. The rate can be changed external during your games execution……blah blah rant rant…
But I totally see the use in a quick applications.
I just dropped a new version of osxGraphicsWindow.cxx on Source Forge. You can grad that version or just type the changes if you like
(2 add lines)
In appEvtHndlr change
switch (kind) {
case kEventClassKeyboard:
{
switch (kind) {
case kEventRawKeyDown:
result = osx_win->handleKeyInput (myHandler, event, true);
break;
to
case kEventClassKeyboard:
{
switch (kind) {
case kEventRawKeyRepeat:
case kEventRawKeyDown:
result = osx_win->handleKeyInput (myHandler, event, true);
break; And in OSOpenWindow Change
{ kEventClassKeyboard, kEventRawKeyUp } ,
{ kEventClassKeyboard, kEventRawKeyModifiersChanged } ,to
{ kEventClassKeyboard, kEventRawKeyUp } ,
{ kEventClassKeyboard, kEventRawKeyRepeat },
{ kEventClassKeyboard, kEventRawKeyModifiersChanged } RogerThanks Roger. I will give it a try immediatly.
But I agree with you, I was just more concerned regarding platform consistency. And user expectation.
Btw: Do you guys use the bug tracker on sourceforge or is it better to go reporting any issues I’ll encounter with the OS X build on this thread?
Again, great work. Panda 3D rocks and especially on OS X . Btw: I wrote a test application using PyObjC, Interface Builder, and Panda 3D. This is just an awesome combination! Kudos to all people involved.
Roger, thanks, works as with the Windows version.
hi there,
two more (minor) issues i encountered today (but got no possibility to re-check on windows):
from pandac.PandaModules import WindowProperties
...
props = WindowProperties()
props.setCursorHidden(1)
base.win.requestProperties(props)this code (snippet) does not work as expected (from what i’ve read in the manual and on the forum). the mouse cursor is not hidden, neither in windows mode nor in fullscreen mode. is that a known issue?
again related to the mouse
base.win.movePointer(0, 0, 0)does not move the mouse / mouse cursor at all. is that also a known issue?
i did implement an avatar with a following/orbiting camera, and encountered these minor issues. i hope this little feedback is useful. i really hope that work on the OS X version will continue.
cheers,
kaweh
that was rather easy to solve. just adapt osxGraphicsWindow::set_properties_now in panda/src/osxdisplay/osxGraphicsWindow.cxx and include the correct section.
if(properties.has_cursor_hidden())
{
_properties.set_cursor_hidden(properties.get_cursor_hidden());
if (properties.get_cursor_hidden()) {
CGDisplayHideCursor(kCGDirectMainDisplay);
} else {
CGDisplayShowCursor(kCGDirectMainDisplay);
}
properties.clear_cursor_hidden();
}seems to behave as expected. can anyone add this to CVS?
i’m looking at move_pointer now.
hope that helps,
kaweh
ok, here is my solution for move_pointer on OS X.
osxGraphicsWindow (panda/src/osxdisplay/osxGraphicsWindow.h) needs a new method osxGraphicsWindow:: LocalPointToSystemPoint
void LocalPointToSystemPoint(Point &qdLocalPoint);with the implementation in panda/src/osxdisplay/osxGraphicsWindow.cxx
void osxGraphicsWindow::LocalPointToSystemPoint(Point &qdLocalPoint)
{
if(_osx_window != NULL)
{
GrafPtr savePort;
GetPort( &savePort );
SetPortWindowPort(_osx_window );
LocalToGlobal( &qdLocalPoint );
SetPort( savePort );
}
};last but not least we implement osxGraphicsWindow::move_pointer
bool osxGraphicsWindow::move_pointer(int device, int x, int y)
{
if(_osx_window == NULL)
return false;
if (osxdisplay_cat.is_debug())
osxdisplay_cat.debug() << "move_pointer " << device <<" "<< x <<" "<< y <<"\n";
Point pt = {0, 0};
pt.h = x;
pt.v = y;
LocalPointToSystemPoint(pt);
CGPoint newCursorPosition = {0, 0};
newCursorPosition.x = pt.h;
newCursorPosition.y = pt.v;
CGWarpMouseCursorPosition(newCursorPosition);
return true;
};this creates the correct behaviour on my machine, though this code probably lacks beauty and some more guards.
please let me know if i can prepare a patch and how to contribute the patch.
hope that helps,
kaweh
one fix to osxGraphicsWindow::move_pointer:
i did forget to set let panda know about the new mouse position. fixed.
bool osxGraphicsWindow::move_pointer(int device, int x, int y)
{
if(_osx_window == NULL)
return false;
if (osxdisplay_cat.is_debug())
osxdisplay_cat.debug() << "move_pointer " << device <<" "<< x <<" "<< y <<"\n";
Point pt = {0, 0};
pt.h = x;
pt.v = y;
_input_devices[0].set_pointer_in_window(x, y);
LocalPointToSystemPoint(pt);
CGPoint newCursorPosition = {0, 0};
newCursorPosition.x = pt.h;
newCursorPosition.y = pt.v;
CGWarpMouseCursorPosition(newCursorPosition);
return true;
};Kaweh … I just integrated the changes. I am glad you are digging in here. As I said I am no MAC expert and other people insights is so very important.
Since you are hot on the mouse issue there are 2 more we need to pounce on ( Cat pouncing on mouse 
) if you have the time.
Again nice work. I am not sure what the proper process is to get every ones hard work incorporated into the system. Maybe we can get some input from Jason or ??? on this .
Other outstanding issues I know about.
Off screen rendering / contexts
Convert the ggs model to only properties interface and remove virtual function behavior from Windows/Linux and other ggs systems.
Source.pp files are broken ( My Bad) The way it unconditionally adds deep shared libray dependacy to the link statement on OSX needs to take into consideration the package presences.
.. I am sure there is more ??
Roger
Thanks, Roger.
Did you also incorporate the -D__FLT_EVAL_METHOD__=0 flag into dtool/Config.osx.pp? Last time I checked with CVS this wasn’t the case. Currently this seems to be needed to compile Panda3D. (And I just remembered I need to write the instructions up again how I did it.)
Regarding additional contributions: I’ll do my best. But please be aware I’m not a Mac expert myself… As I create my prototype I will definitely encounter various other things. I will see what I can do about these and definitely report.
It would be great if we could at least collect bug reports or patches somehow. Otherwise all the good work done regarding the OS X build might get lost.
- Single Button mouse input (meta keys = virtual buttons).
Can you explain what you need here exactly? Do you mean pressing CTRL-Mouse1 = Mouse2? If that’s the case, I’ll look into this.
- Mouse Cursor image change out ( make this xxx my mouse cursor).
I believe, I know should get this working.
I also realized that Windows, is more strict regarding has_mouse/hasMouse, there are more checks in the Windows code (do not know about Linux). Shall I check that and mimic the Windows code a little more? I assume platform-independant behaviour is a goal for Panda3D?
One more thing: If you have time, could you have a look at the Joint Manipulation/Eve sample. It does not work on OS X. After the typical file path fixing to get the models to load, there seems to be an odd problem with attaching the models to the hand joint or moving the head. The objects are not attached, nor does the head move. Looking into this is beyond my current knowledge about Panda3Ds internals.
I really hope more people would jump on the OS X build to broaden the user base.
In that regard, I’m investing a lot of time in this so I wonder if it’s a dedicated goal to get Panda3D running on OS X and what the anticipiated time frame should be (though I understand that there are priorities and plans might change). It’s always good to have a goal in front of your eyes.
Anyways, thanks again. I’m enjoying my time with Panda3D a lot.
Roger,
I found another problem with the current implementation of osxGraphicsWindow::move_pointer. It seems to be important to disconnect mouse and mouse cursor before doing the pointer move. I realized because my tester created unexpected hick-ups (which seems to be related to lost events) and didn’t behave as fluently as the same code on Windows. The documentation is not quite clear of why this is really needed, but it made a huge difference. It just seems to be recommended to do so. Just two calls more to improve the code. So here is the new version:
bool osxGraphicsWindow::move_pointer(int device, int x, int y)
{
if(_osx_window == NULL)
return false;
if (osxdisplay_cat.is_debug())
osxdisplay_cat.debug() << "move_pointer " << device <<" "<< x <<" "<< y <<"\n";
CGAssociateMouseAndMouseCursorPosition(false);
Point pt = {0, 0};
pt.h = x;
pt.v = y;
_input_devices[0].set_pointer_in_window(x, y);
LocalPointToSystemPoint(pt);
CGPoint newCursorPosition = {0, 0};
newCursorPosition.x = pt.h;
newCursorPosition.y = pt.v;
CGWarpMouseCursorPosition(newCursorPosition);
CGAssociateMouseAndMouseCursorPosition(true);
return true;
};btw: switching to fullscreen changes the behaviour of my tester. So I wonder if mouse cursor calculation is influenced by going into fullscreen mode (by any layer of Panda3D). I couldn’t find any indication in osxGraphicsWindow, but on the other hand, I’m not quite sure what is happening to allow fullscreen mode. Can you shed some light on this, so I can dig deeper into this discrepancy?
Thanks,
Kaweh