Re: [Flightgear-devel] Re: Obvious Speedups
On Thu 21. March 2002 19:09, you wrote: Martin Dressler writes: I think that we should pass on this patch for now -- I have no clear explanation of how it might help the framerate, and I cannot imagine that skipping a single glViewport call could make any difference. It also removes some existing functionality (such as resizing the view with the panel) and provides no measurable framerate change for most users. But makes 10% atleast for Norm. Did someone else tryed it under win in gamemode? I don't know if anyone else uses game mode, but we've had a few problem reports from others with Norm's patch -- I don't think it's a good idea to break existing functionality for a speed gain that most do you mean that you can't set resolution via a property manager? people are not able to reproduce. Besides, glViewport gets called every frame anyway, since the 2D panel makes its own call to it. I used game_mode sometimes :) And Why is called glViewport in Cockpit. IMHO it doesn't have any function there, because it only set glViewport to /sim/startup/[xy]size, what we have already set from initialization or from fgReshape when window change. Reagrds, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
On Wed 20. March 2002 18:54, you wrote: Erik Hofman wrote: While I don't see a direct improvement in framerate I notice a real effect on the screen update. The old behaviour had a small bump in the update every second or so, while the new code elliminates that. This doesn't make much sense. All of the changes in that patch were inside the per-frame loop. They certainly couldn't cause or fix stutter over many frames, nor do I think have they been claimed to. Perhaps something happened in the tile loader to do this? Permanent window resizing can make strange artifacts and force to render frame again. If you still resize to the same dimension it is only optimalization to not make anything and some other implementation of OpenGL can make something. This is rapidly getting on towards voodoo coding, and I think perhaps we should step back a bit. What, exactly, are the changes in this patch that make it worthwhile? What does it eliminate? What is the evidence for speedup? BTW. This is probably only noticable on slower machines with a slow OpenGL implementation like the O2 I work on. The patch didn't touch any OpenGL code so far as I can tell, so I'm at a loss to explain this one, too. If glViewport() isn't OpenGL code then I don't know what is. Why are you all so definsive about deleting of code which isn't usefull for anything. IMHO when you can delete code which run every frame and replace it with code which run only at some special case then it is right to delete this code. Regards, Madr - Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
On Thu 21. March 2002 13:38, you wrote: D Luff writes: With Norman's main, maximising the window and then returning it to 800x600 leaves the external view of the plane (and probably the scenery but its hard to tell) all scrunched up. I think that we should pass on this patch for now -- I have no clear explanation of how it might help the framerate, and I cannot imagine that skipping a single glViewport call could make any difference. It also removes some existing functionality (such as resizing the view with the panel) and provides no measurable framerate change for most users. But makes 10% atleast for Norm. Did someone else tryed it under win in gamemode? Madr ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Norman Vine writes: David Megginson writes: Norman Vine writes: Old binary (about 2 days old, pre-property changes) --- From 4,000 ft: 45-46 fps From 8,000 ft: 29-30 fps Current CVS --- From 4,000 ft: 49-50 fps From 8,000 ft: 35-36 fps This speedup is most likely my new hitlist code 8-10% I checked the dates, and I installed my old binary on Monday evening, after your hitlist code was already incorporated, so unfortunately it doesn't come into the equation. I don't have any similar test from before that, but it could be that the framerate was even slower before. I have no idea what caused this speedup -- I doubt it was the property rewrite. Current CVS with Norm's main.cxx patch added From 4,000 ft: 49 fps From 8,000 ft: 35 fps Hmm... My guess is that this has something todo with your running in a wIndow and glut is doing stuff behind the scenes that is not necessary on a windows box in game mode That is possible. We're on different OS's with different windowing systems and drivers -- you may have identified a performance bug that affects only Windows systems. I posted your main.cxx to a temporary URL (http://www.megginson.com/flightsim/main.cxx), and I'd love to hear from other Windows users. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
David Megginson wrote: Norman Vine writes: Current CVS with Norm's main.cxx patch added From 4,000 ft: 49 fps From 8,000 ft: 35 fps Hmm... My guess is that this has something todo with your running in a wIndow and glut is doing stuff behind the scenes that is not necessary on a windows box in game mode That is possible. We're on different OS's with different windowing systems and drivers -- you may have identified a performance bug that affects only Windows systems. I posted your main.cxx to a temporary URL (http://www.megginson.com/flightsim/main.cxx), and I'd love to hear from other Windows users. While I don't see a direct improvement in framerate I notice a real effect on the screen update. The old behaviour had a small bump in the update every second or so, while the new code elliminates that. This makes me vote for including the patch. Erik BTW. This is probably only noticable on slower machines with a slow OpenGL implementation like the O2 I work on. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Andy Ross [EMAIL PROTECTED] said: Erik Hofman wrote: While I don't see a direct improvement in framerate I notice a real effect on the screen update. The old behaviour had a small bump in the update every second or so, while the new code elliminates that. This doesn't make much sense. All of the changes in that patch were inside the per-frame loop. They certainly couldn't cause or fix stutter over many frames, nor do I think have they been claimed to. Perhaps something happened in the tile loader to do this? I don't know, cpu cycles are cpu cycles...they're good for anything aren't they? If you reduce per-frame-code-load then that frees time up for other tasks like disk io. Or am I confused about this? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
I don't know, cpu cycles are cpu cycles...they're good for anything aren't they? If you reduce per-frame-code-load then that frees time up for other tasks like disk io. Or am I confused about this? You are confused about that. Most modern processors are memory bandwidth limited. That's what killed RISC. If you inline code, you save on the frame setup, but it costs memory bandwidth. So, you have to ask whether there will be more idled instructions, while waiting for the processor instruction cache to be filled with inline code, or instructions that are constructively doing the frame thing out of cache (because the subroutine itself is probably in cache). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Andy Ross writes: Oooh, which reminds me: has the default logging level changed? I was noticing last night that lots of stuff that used to be printed isn't anymore, including the YASim solution report which I'd like to preserve. I looked briefly for something that might have changed, but couldn't find anything obvious. I think Curt made some changes a few weeks back -- a high default logging level is murder on the Windows users. If you want to see everything, try this: --prop:/sim/logging/classes=all --prop:/sim/logging/priority=bulk All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
David Megginson writes: Andy Ross writes: Oooh, which reminds me: has the default logging level changed? I was noticing last night that lots of stuff that used to be printed isn't anymore, including the YASim solution report which I'd like to preserve. I looked briefly for something that might have changed, but couldn't find anything obvious. I think Curt made some changes a few weeks back -- a high default logging level is murder on the Windows users. If you want to see everything, try this: --prop:/sim/logging/classes=all --prop:/sim/logging/priority=bulk I'm not aware of changing anything there at all, unless someone submitted a patch that changed the default logging level and I didn't notice it. If it did get changed, could someone put it back to what it was? I'm not familiar with this section of code myself. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Andy Ross writes: This is rapidly getting on towards voodoo coding, and I think perhaps we should step back a bit. What, exactly, are the changes in this patch that make it worthwhile? What does it eliminate? What is the evidence for speedup? gprof is your friend Cheers NOrman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Norman Vine writes: This is rapidly getting on towards voodoo coding, and I think perhaps we should step back a bit. What, exactly, are the changes in this patch that make it worthwhile? What does it eliminate? What is the evidence for speedup? gprof is your friend gprof will show where CPU time is being spent, but not how much of a framerate increase you can expect. Even for CPU time, it's iffy -- for example, SGPropertyNode::getDoubleValue was showing up high in the profiling stats for JSBSim, but that's because it was invoking a lot of inline accessor methods that weren't profiled (because they were inlined). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Norman Vine wrote: Removed fgReshape() call from main loop That's undoubtedly a good thing. Never mind who can see a speed benefit and who can't. I can only imagine it was put there to work around some bug. If so, let's see if the bug shows up again, and fix it properly if it does. Removed fgIdle from the main loop once things are up and running 1) initially glutDisplayFunc() is set to new mySplashDraw function 2) when idle state reaches 1000 glutDisplayFunc() set to fgRenderFrame() glutIdleFunc() reassigned to fgMainLoop() This only saves a few integer comparisons at run time, but looks like a good logical clean-up. Made a local copy of a property value when it is used multiple times inside of the same function and used it moved static property nodes pointers from function scope to file scope. I'm ambivalent about these. I can't check frame rate because mine is continuously fluctuating by about 10% from one second to the next, and depends very strongly on the exact view. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Julian Foad wrote: Norman Vine wrote: Removed fgReshape() call from main loop That's undoubtedly a good thing. Never mind who can see a speed benefit and who can't. I can only imagine it was put there to work around some bug. If so, let's see if the bug shows up again, and fix it properly if it does. With Norman's main, maximising the window and then returning it to 800x600 leaves the external view of the plane (and probably the scenery but its hard to tell) all scrunched up. I suspect this is probably what you're looking for... Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: Obvious Speedups
Melchior FRANZ writes: * David Megginson -- Tuesday 19 March 2002 19:16: Would it be possible either put out a version without the spurious whitespace changes, or to post a message showing only what you actually changed? You could also patch a copy, make your own patch with diff -bB between the patched and the unpatched file and then apply this patch to the original. Thanks, that did the trick (it still left a lot of whitespace differences, but it got rid of about 75% of them for me). I managed to get it compiled, but I see almost no change in framerate -- instead of 44 fps it flickered between 44 and 45 fps, which is inside any reasonable margin of error. If Norm can tell us what the patch was supposed to do, perhaps we can help find a way to make it work. I'm going to leave it out for now, though. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Curtis L. Olson writes: diff -w ignores white space, but that doesn't necessarily help if you are using emacs ediff to compare the files and merge the changes. It could, perhaps, if you do something like this: diff -w main.cxx /tmp/new-main.cxx main.patch patch main.cxx /tmp/main.patch xemacs main.cxx then, in xemacs, M-x ediff-revision All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Curtis L. Olson [EMAIL PROTECTED] writes: diff -w ignores white space, but that doesn't necessarily help if you are using emacs ediff to compare the files and merge the changes. `ediff-ignore-similar-regions' is a variable declared in Lisp. -- loaded from /usr/local/lib/xemacs/xemacs-packages/lisp/ediff/ediff-diff.elc Value: nil Setting it would make its value buffer-local. Documentation: *If t, skip over difference regions that differ only in the white space and line breaks. This variable can be set either in .emacs or toggled interactively. Use `setq-default' if setting it in .emacs ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Norman Vine wrote: FWIW for vertical virtual panel added 3 lines to Panel.cxx to get and multiply panel matrix by gui_quat_ matrix added 5 lines to viewer.cxx add gui_quat_matrix and a get function removed line from viewer_rph.cxx and viewer_lookat.cxx that declared gui_quat_matrix external changed 5 lines in the GUI code to use the viewer-gui_quat_matrix instead of the local one. Note that this isn't enough. The panel already works fine (heh) vertically, but only when directed by the euler properties. I use a hat switch, and not the mouse, to control view direction. This modification will fix mouse support but break the eulers. The right fix, here, is to control the eulers from the mouse code and move the GuiQuat stuff somewhere unified. Having completely separate GuiQuat matrix and euler angle control over view direction is a Bad Thing, and must be fixed. Andy -- Andrew J. RossNextBus 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
Re: [Flightgear-devel] Re: Obvious Speedups
Andy Ross [EMAIL PROTECTED] writes: Derrell Lipman wrote: `ediff-ignore-similar-regions' is a variable declared in Lisp. -- loaded from /usr/local/lib/xemacs/xemacs-packages/lisp/ediff/ediff-diff.elc You, sir, have clearly been spending *far* too much time in info mode. This has to stop. I fear for your health. Hehe. Hey, XEmacs is my universe -- after having first been a guru level 'vi' user for many years, so I'm allowed to have a strong opinion: The difference between vi and emacs is similar to the difference between sleeping in a tent and sleeping in your bed at home... The former is fine for occasional use, but I wouldn't want to have to live there. :-) Although I don't use all of these features, I've been using emacs for long enough that I'm familiar with them (and have tried many of them at one point or another) and have a good idea how to quickly find the documentation. BTW, it wasn't info mode. Use the source, Luke. :-) Cheers, Derrell ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
[EMAIL PROTECTED] writes: Hey, XEmacs is my universe -- after having first been a guru level 'vi' user for many years, so I'm allowed to have a strong opinion: The difference between vi and emacs is similar to the difference between sleeping in a tent and sleeping in your bed at home... The former is fine for occasional use, but I wouldn't want to have to live there. :-) Although I don't use all of these features, I've been using emacs for long enough that I'm familiar with them (and have tried many of them at one point or another) and have a good idea how to quickly find the documentation. BTW, it wasn't info mode. Use the source, Luke. :-) You definitely can't be ranked as an emacs power user until you are intimate with all the .elc's. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Norman Vine [EMAIL PROTECTED] said: FWIW for vertical virtual panel added 3 lines to Panel.cxx to get and multiply panel matrix by gui_quat_ matrix added 5 lines to viewer.cxx add gui_quat_matrix and a get function removed line from viewer_rph.cxx and viewer_lookat.cxx that declared gui_quat_matrix external changed 5 lines in the GUI code to use the viewer-gui_quat_matrix instead of the local one. Can we hold off on this? I'm totally reorganizing the viewer code and really don't need to deal with these kind of changes. It'll functionally be the same so there shouldn't be any problem making this change later. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Andy Ross writes: Norman Vine wrote: FWIW for vertical virtual panel added 3 lines to Panel.cxx to get and multiply panel matrix by gui_quat_ matrix added 5 lines to viewer.cxx add gui_quat_matrix and a get function removed line from viewer_rph.cxx and viewer_lookat.cxx that declared gui_quat_matrix external changed 5 lines in the GUI code to use the viewer-gui_quat_matrix instead of the local one. Note that this isn't enough. The panel already works fine (heh) vertically, but only when directed by the euler properties. I use a hat switch, and not the mouse, to control view direction. This modification will fix mouse support but break the eulers. The right fix, here, is to control the eulers from the mouse code and move the GuiQuat stuff somewhere unified. Having completely separate GuiQuat matrix and euler angle control over view direction is a Bad Thing, and must be fixed. I am not so sure that we don't want both an pulsed 'euler' angle setter 'keypoard and hat' AND a separate mouse controller. I mean after all you don't have to go into Mouse View mode and this way I can use the keyboard to set the default viewin offsets and I the mouse can be used for 'quick look arounds'. As good old Dr Pangloss would say Best of Both Worlds :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Curtis L. Olson [EMAIL PROTECTED] writes: You definitely can't be ranked as an emacs power user until you are intimate with all the .elc's. :-) Heh. Well, in days passed, I was able to write PDP-11 code with: cat a.out (back in college when I had nothing better to spend my time playing with). I guess I'll be a real emacs power user when I can write bytecode with: cat fgfs.elc :-) Derrell ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Updated test code @ http://www.vso.cape.com/~nhv/files/fgfs/nhv_obvious.tgz This is against CVS files as of ~18:00 GMT today Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Curtis L. Olson writes: You definitely can't be ranked as an emacs power user until you are intimate with all the .elc's. :-) No, you're not an Emacs power user until RMS has forced you to have your boss sign one of those disclaimers before he puts your code in the main elisp distribution. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Jim Wilson writes: Can we hold off on this? I'm totally reorganizing the viewer code and really don't need to deal with these kind of changes. It'll functionally be the same so there shouldn't be any problem making this change later. I agree that we need to hold off on any viewer changes, at least for a day or two, to see if Jim has any success finishing his rewrite. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Norman Vine writes: I am not so sure that we don't want both an pulsed 'euler' angle setter 'keypoard and hat' AND a separate mouse controller. I mean after all you don't have to go into Mouse View mode and this way I can use the keyboard to set the default viewin offsets and I the mouse can be used for 'quick look arounds'. I don't think this is a good architectural choice -- having two (or more) different ways of doing the same thing makes life hard for all the rest of the programmers, as we've seen over the past few weeks with the viewer code. Obviously, the final say will be Curt's, but I'm going to insist as hard as I can that we have the mouse code provide Euler angles like all the other input sources. If we did decide to support Norm's scenario, I think the right approach would be to push the current viewer state then pop it out again. That would be a good, general solution that would work for anything (mouse, keyboard, joystick, graphic tablet, head-mounted thingy, or what-have-you). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Norman Vine writes: http://www.vso.cape.com/~nhv/files/fgfs/nhv_obvious.tgz Are the main.cxx changes atomic? I'd like to apply just them, for now. Thanks, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
David Megginson writes: Curtis L. Olson writes: You definitely can't be ranked as an emacs power user until you are intimate with all the .elc's. :-) No, you're not an Emacs power user until RMS has forced you to have your boss sign one of those disclaimers before he puts your code in the main elisp distribution. Oh well, I've only been flamed by RMS (but that should at least count for something, right?) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Curtis L. Olson writes: Oh well, I've only been flamed by RMS (but that should at least count for something, right?) You get one point for every 12 flames. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
On Tue, 19 Mar 2002 15:17:20 -0600 (CST) Curtis L. Olson [EMAIL PROTECTED] wrote: Oh well, I've only been flamed by RMS (but that should at least count for something, right?) Are you kidding? If not, you can't get away with stopping there. What's the story? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
David Megginson writes: Norman Vine writes: I am not so sure that we don't want both an pulsed 'euler' angle setter 'keypoard and hat' AND a separate mouse controller. I mean after all you don't have to go into Mouse View mode and this way I can use the keyboard to set the default viewin offsets and I the mouse can be used for 'quick look arounds'. I don't think this is a good architectural choice -- having two (or more) different ways of doing the same thing makes life hard for all the rest of the programmers, as we've seen over the past few weeks with the viewer code. Why -- all you need to do is document it Consider this scenario I want my normal view down 20% slightly to the left I can set these with the keys or whatever I can now use the mouse to spin about do what ever in mouse mode when I leave mouse mode I am back at my normal position If we did decide to support Norm's scenario, I think the right approach would be to push the current viewer state then pop it out again. That would be a good, general solution that would work for anything (mouse, keyboard, joystick, graphic tablet, head-mounted thingy, or what-have-you). I have been pushing for a 'stack based approach' for all User Input Modes for years good to see I might finally be getting a little support for this :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
David Megginson writes: http://www.vso.cape.com/~nhv/files/fgfs/nhv_obvious.tgz Are the main.cxx changes atomic? I'd like to apply just them, for now. If by that you mean can you just try the new main.cxx YES FWIW I notice about a 10% decrease in fps after applying the new simgear code from this morning What happened ? Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Norman Vine wrote: FWIW I notice about a 10% decrease in fps after applying the new simgear code from this morning What happened ? My bad I had a orphaned background process running FWIW According to my records at normal startup hud no panel frozen my records show that I was getting 71 fps quite consistantly I am now getting 76 fps same exact scenario Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Norman Vine writes: True -- but then again I have sped the program up ~15% even more if you consider the model view, within the last month. Heck I replaced five matrix multiplies with one for every moving part in the model display code alone :-)) Norm -- I am very grateful for your contributions. Most noticably, they reduced the stutter at the start of the model animation for some audio hardware and made the model code cleaner. How did you arrive at the 15% figure, though? My framerate hasn't changed at all for a long time. Perhaps it has something to do with the combination of graphics hardware and CPU people are using -- I have a relatively fast CPU (c.a. 900MHZ) but only a slow-to-middle-range GPU (GeForce2), so I may be more GPU- than CPU-limited. Perhaps someone running with, say, a GeForce3 and a 400MHZ CPU will see the framerate changes I'm missing. So I think we can afford to use one here, where there actually is a reason for it ! We're not worried about the processing cost of a matrix multiply. I would be shocked if adding an extra 100 matrix multiplies changed the frame rate by more than a fraction of a frame per second. We're worried about the simplicity and consistency of the interface and the maintainability of the code. The Viewer ( please lets come up with a better name code should only be concerned with the orientations ect that are 'inherent' in the world 'situation' and the GUI module should handle user interactions or am I missing something 'obvious' :-) The user input (GUI or otherwise) tells the viewer *what* it wants, and the viewer figures out *how* to do it. I shouldn't have to add quats or matrices into the network, keyboard or joystick handling code, and by analogy, they don't belong in the mouse code either. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
David Megginson writes: Norman Vine writes: Updated test code @ http://www.vso.cape.com/~nhv/files/fgfs/nhv_obvious.tgz This is against CVS files as of ~18:00 GMT today I tried it sitting still on the runway with the panel hidden and the ground filling more than half the screen. Before Norm's patch, I got 41 fps, and after, I got a flicker between 41 and 42. I simply cannot reproduce the dramatic change that Norm saw; perhaps my graphics hardware optimizes something that Norm's doesn't. Can other people try this? I've put Norm's new main.cxx at http://www.megginson.com/flightsim/main.cxx Did you have the panel displayed ? Did you have a model displayed ? Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
David Megginson writes: Norman Vine writes: True -- but then again I have sped the program up ~15% even more if you consider the model view, within the last month. Heck I replaced five matrix multiplies with one for every moving part in the model display code alone :-)) Norm -- I am very grateful for your contributions. Most noticably, they reduced the stutter at the start of the model animation for some audio hardware and made the model code cleaner. How did you arrive at the 15% figure, though? My framerate hasn't changed at all for a long time. Perhaps it has something to do with the combination of graphics hardware and CPU people are using -- I have a relatively fast CPU (c.a. 900MHZ) but only a slow-to-middle-range GPU (GeForce2), so I may be more GPU- than CPU-limited. Perhaps someone running with, say, a GeForce3 and a 400MHZ CPU will see the framerate changes I'm missing. I am running a PIII 733 Geforce2GTS in game-mode I bet you are making your measurements with both a Panel and a model displayed. My figures are for the terrain rendering only. maybe the minimal HUD. As soon as you display the Panel you are 'Fill Bound' never mind all the GL state changes. On my machine I have gone from mid 60's to mid 70's fps reported on startup at default location ie ~15% or so. The speedup is also much more dramatic when at altitude looking down as reported by EricH. I am often seeing over 100 fps in these conditions where I was in the 50-60 range before ! Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
David Megginson writes: Norman Vine writes: Old binary (about 2 days old, pre-property changes) --- From 4,000 ft: 45-46 fps From 8,000 ft: 29-30 fps Current CVS --- From 4,000 ft: 49-50 fps From 8,000 ft: 35-36 fps This speedup is most likely my new hitlist code 8-10% Current CVS with Norm's main.cxx patch added From 4,000 ft: 49 fps From 8,000 ft: 35 fps Hmm... My guess is that this has something todo with your running in a wIndow and glut is doing stuff behind the scenes that is not necessary on a windows box in game mode or perhaps my stuff gets a fast path on a GTS that a MX doesn't as I get a good boost everywhere simplistic example the best fps I ever saw while looking essentiallly straght down just west of KSFO was 162 prior to my latest patch and I reliably clock 173-5 every time I go through that area now .. also use to get 137-8 over the water and am now getting 151-2 as I go offshore on the same heading go figure Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
