Ok, i will test it as soon as possible 2007/2/1, Drew Whitehouse <[EMAIL PROTECTED]>:
Hi Adrian, There seems to be another issue with the keyboard handling. The modifier keys aren't being handled properly. To see it, try holding down shift or control in osgkeyboard. -Drew On 1/22/07, André Garneau <[EMAIL PROTECTED]> wrote: > > > > > Hi Adrian, > > > > Could you try out the osgkeyboard application and check if you see the > keystrokes ? It's working fine here. > > > > Thanks, > > > > André > > > > ________________________________ > > > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Adrian Egli > Envoyé : January 21, 2007 12:44 PM > > À : osg users > Objet : Re: [osg-users] Re: GraphicsWindowWin32 is here! :-) > > > > > But know we have another issue, Keyboard doesn't work, or at the least the > stateManipulator: 'w', ... , 'f' no longer work > > /adegli > > > 2007/1/21, André Garneau < [EMAIL PROTECTED]>: > > > > Thanks for the feedback Adrian. I'm glad it's working on your setup as well > (my ATI testbed was a somewhat outdated board). > > > > To Brede: If you are unable to debug the osgViewer DLL because its symbols > are not loaded (even if it's a debug DLL), you're not alone; this is an > issue I'm also seeing from time to time (it's not consistently that way). > The only workaround for this elusive issue is to rebuild only the osgViewer > dll and then your test application. Doing a rebuild all (all examples, > plugins, etc.) seems to confuse Visual Studio. Others on the internet are > reporting similar issues. Might be that it's fixed in VS2005 SP1, but I'm > not holding my breath. J > > > > André > > > > ________________________________ > > > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Adrian Egli > Envoyé : January 21, 2007 11:46 AM > > > > À : osg users > Objet : Re: [osg-users] Re: GraphicsWindowWin32 is here! :-) > > > > > Yes, i tried this change with my ATI X1600 mobile: It works . > > /adegli > > > 2007/1/21, André Garneau <[EMAIL PROTECTED] >: > > Hi All, > > I have been able to test on an ATI board last week and found the issue ATI > users are reporting (fix in my development branch but not released yet). > > The current workaround is to comment the following line (in > GraphicsWindowWin32::setPixelFormat()) > > attributes.set(WGL_SET_SWAP_METHOD_ARB, WGL_SWAP_EXCHANGE_ARB); > > In addition to that another issue fixed that may give problems is that the > sample OpenGL window used to select pixel formats was always created on the > primary device. If a window was created on a separate graphics card that > had > a different driver than the primary device (for example primary device was > an NVIDIA board while other cards were ATIs), then pixel formats would not > match. > This has been fixed in my private dev branch as well. I'm currently testing > the update and it should be released soon. > > André > > -----Message d'origine----- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part > de Robert Osfield > Envoyé: January 21, 2007 6:13 AM > À: osg users > Objet: Re: [osg-users] Re: GraphicsWindowWin32 is here! :-) > > Hi Carlo and Adrian, > > On 1/20/07, Carlo Camporesi <[EMAIL PROTECTED]> wrote: > > Windows System Error #0 : > > GraphicsWindowWin32::setPixelFormat() - No matching > pixel > > format found based on traits specified. Reason : Operation not Completed. > > Thanks for the reports, first step to getting it sorted. > > Currently osgViewer doesn't have support for relaxing the > osg::GraphicsContext::Traits constraints so if it asks for a format > that is not supported it in theory should just fail and not create a > window. This looks like its happening here, but there also could > perhaps be something else amiss with setting up the pixel format - > i.e. the pixel format *is* supported by the hardware, but > driver/GraphicsWindowWin32.cpp aren't working properly together. > > So there are potentially two parts to resolving this problem: > > 1) If its a problem with setting up pixel formats on ATI then we > need to look to what > that is and fix it/find a workaround in the GraphicsWindowWin32 code. > > 2) If its an issue of osgViewer not yet having a formalised system > for relaxing the > Traits so that a pixel format that is "good enough" fit, rather > than a perfect is > acceptable. > > I am curious what pixel depth are you machines set to? > > Robert. > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > > > > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > > > > > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > > > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > > -- Drew Whitehouse ANU Supercomputer Facility Vizlab _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
