| [ Home ] |
744 FORUM (vertical frame)
Overhead Panel Framework: Q's for PS1 Dev's
Posted By: Matt Stephanson (rlit-164-107-201-201.resnet.ohio-state.edu)
Date: 25 NOV 2004 - 03:01z
Fellow PS1 Developers,
For the last few days I've been thinking about the idea of an overhead panel framework, as Jeroen H. suggested. Although it's probably not very high on anyone else's lists, if it's on there at all, I am curious if any of you have any suggestions or ideas you wish to profer. Here are my ideas so far:
- Overall, the scheme would be similar to MSFS's gauge framework. That is, each gauge consists of a dll that FS runs. Each dll defines various drawing elements, such as needles, sliders, sprites, etc., and the functions specifying how to move these elements. It also defines mouse rectangles and functions. Ours would be similar, except that we would only need static elements (display a single image) and icons (display one of several images, depending on the value of some variables). A more general frameword would require more elements, but this would be enough for the entire overhead panel, with the exception of outflow valves and light dimmers--a pretty good start, I think. Now, instead of flight simulator loading these dlls, we would write a program (an überpanel, if you will) that loads a background image and the gauges.
- One of the biggest questions is how to give gauges access to variables. Obviously there should be no need to have to deal with Broker/IPC directly. My idea is that each gauge notifies the framework of the offsets that it wished to access. The framework then makes a list of these (removing all duplicates) and tells Broker to notify it for all these variables. The framework then updates the variables as data comes in. Each gauge would get a constant pointer to the variables it wants, allowing it to retrieve the data. In MSFS, a gauge has to call a function to get the most recent value of a variable, but I think that would be exteremely wastful in this context, since most of the variables change very very little with time--it really doesn't make sense to ask about the pack selector switch position five times per second. The VMREAD.cfg file would contain entries like "o67A6", meaning the variable at offset $67A6. Although there shouldn't be many duplicates, since each gauge implements a different section of the panel, and it's not especially readable, I think it has the advantage that it doesn't restrict the gauge programming to a limited set of variable, the way MSFS does.
- The MSFS frameword embeds images withing the gauges as bitmap resources, but I don't think this is the best approach for our system. First, it would be nice to allow a wide variety of file formats, such as JPEG and PNG. Second, I think it would be convenient to allow people to alter the graphics without having to recompile the gauge. Therefore, rather than storing a bitmap resource, I suggest storing a string resource that contains the path to the image, and the image is then loaded from the file at runtime. A related question is what library to use to for the graphics. My very limited graphics experience consists only of GDI/GDI+, so that's my suggestion. But if anyone thinks OpenGL, DirectDraw, etc. would be better, I'm open to suggestions, provided you're willing to either write some code for the graphics routines or put up with some questions as I learn the library.
- Language: I don't know .NET, and I don't like requiring people to download megabyte-size runtime libraries or controls, so my preference is straight C++/Win32 API. Ultimately, I think this will come down to how much code others are willing to write. If other people will contribute significant quantities, I'm willing to compromise. Otherwise, I'm doing it my way
.
- Features: Should the panel be stretchable, or fixed to the size of the background image? Should it support multiple panels (like the MSFS system) or just one big panel with all the gauges? ...other things I havn't thought of?
I appreciate any insight you all can offer.
Matt Stephanson




| [ Home ] |
744 FORUM (vertical frame) is maintained by the men behind the curtain with WebBBS 5.12.