For many games (particular on Windows of yesteryears) and applications, I have changed resolutions and 3D effects once the application or game has started depending on the frame rate performance. Thus if possible it would be best to implement a feature into OSG to change resolution, though how this would be done internal can be very platform dependent, so more work would be needed to implement this feature.
My 2c worth. Rizzen Lucas Goss wrote: >>> That could work, but I am not sure whether it is actually worth the >>> trouble - the original poster only wanted to change the resolution >>> before starting the application, not during runtime, so this could be an >>> overkill. Perhaps a poll to figure out whether this is a one-off request >>> or a more general issue would be a good thing to do. >>> > > Actually I want the resolution to be able to be changed anytime in the > application. So the user starts the application, finds that the the > application runs a little slow, changes some settings for detail and > resolution, and now the application performs at a good rate. And a > smart application would be even nicer where it tests the users machine > and automatically configures this stuff for them (but still allows > them to change it). > > >>> I see. I would say that a most future-proof solution would be to >>> implement support for the RandR extension >>> (http://keithp.com/~keithp/talks/randr/). >>> >>> This is now supported by everything running X.Org X servers (Linux, >>> various BSDs), however proprietary Unix doesn't support it (SGI, Sun, >>> HP). I am not sure whether that would be a significant issue or not. >>> However, it is not 100% foolproof solution, because not all drivers >>> support it (ATI and nVidia do, though). >>> >> RandR support would be a reasonable way forward. SGI and other older >> workstation class machines are not so prone to users wishing to change >> resolution - Once I had 1280x1024 on an SGI Indigo Elan back in 92 >> this didn't change till my final contact with SGI's with the Oynx >> IR2... If if users do wish support on these platforms they can step >> forward and implement it. >> > > That's what I was thinking as the solution is already not 100% > foolproof. Because if you compile your code on Linux/BSD/Unix/etc. and > expect it to work the same on every platform, it doesn't (works on Mac > and Windows though). So at least including the Linux/BSD and others > that support X.Org is a little better than not supporting any at all. > Currently OSG just silently fails when making this call, which you > could still do for those platforms that don't support the RandR > extension. > > Lucas > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
