Jim Wilson wrote: > So I guess my question is this: can I change this to allow the panel > xml to have final say on the y-offset even though there might be a > user or two out there that sets y-offset elsewhere? Or am I > underestimating the importance of this?
I have my own peeves about the panel coordinate conventions. One of the things I'd really like to see at some point is the ability to "paste" a 2D panel onto a polygon in a 3D virtual cockpit. In principle, this should be easy. In practice, the use of screen coordinates makes this difficult. How should one interpret y-offset in a 3D environment, for example? I guess what I'd like is something like: + The panel itself has a 2D coordinate system defined by <x-size> or whatnot. This can be 1024x768, or the unit square, or anything convenient to the author. But there's no offset or positioning information stored in the panel itself -- coordinates outside the size range are undefined. + The 2D panel renderer holds the mapping of the panel quad to screen coordinates via <x-max>, <x-min> or something similar. + The 3D panel renderer gets a mapping of the panel quad into 3D coordinates. It's also worth pointing out that the current HUD code has this disease in a vastly more serious form. Screen coordinates and pixel dimensions are pervasive in the HUD renderer. Even getting the HUD to draw correctly in the face of a display size change (I use 1152x864) is a huge chore. Lots of code here may have to be chucked to get it working in a 3D environment; I know Norman wanted to rewrite it for similar reasons. Andy -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
