Re: [Flightgear-devel] Key Bindings
On 4 Mar 2013, at 07:43, Vic Marriott vic...@btinternet.com wrote: Hi James, Personally, I use 'ctrl' a lot when making my own shortcuts (outside FG). I'm sure I can't be the only Mac user to do this. An example: If you were to allocate 'ctrl+s' to a common FG function, using 'ctrl+s' sends my Mac to 'Sleep' wether I am using an application or not. Perhaps it would be better to go with the 'cmd' key on Macs. I think removing old, out of date functions to make room for up to date ones is a good idea though. Vic, I think you missed a key line in my original email. To be fair, it was parenthesised. On Mac, the relevant (system-wide, universally-accepted) modifier for the kind of shortcuts I'm discussing, it NOT *Ctrl* - it's the 'Command' key, formerly know as the 'Apple' key. I can take a strong bet you don't have lots of custom bindings on your Mac for 'Cmd-Q, Cmd-C, Cmd-Z' because you would find it quite hard to quit, copy or undo in 90% of applications you use, using the keyboard. The Ctrl key-binding space on Linux / Windows, and the equivalent Cmd/Apple space on Mac, are assumed by pretty much everybody to drive application specific shortcuts for GUI items - what I'm proposing would be to attempt to align FlightGear with that behaviour. James -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Key Bindings
The discussion reminded me of a blog post I once read: http://www.flightsim.com/vbfs/content.php?11603-Is-The-Default-Keyboard-Layout-Still-Relevant Might be worth reading, but also might be worth forgetting afterwards. Sometimes it's good to read someone else’s experience though. Erik -- http://www.adalin.com - Hardware accelerated AeonWave and OpenAL for Windows and Linux -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
On Sun, 03 Mar 2013 11:24:29 + James Turner wrote: My *personal* feeling is that unless it's something the 50% of users use *each flight*, it shouldn't be a keybinding. So flaps, trim, CDI/HSI heading, fine, but things to change view distance or FoV seem unnecessary to me. Just sticking in my 2p worth... I would say I use z/Z almost every flight. It can be useful for cheating, as Thorsten said, but more usually as a means of adjusting performance. Often airports are in or near very scenery-intensive areas and reducing visibility can help a lot in making the sim run usably for take-off, whereas once you're up and away it's nice to be able to open the view back up again for cross-country flying. Maybe if that happened automatically somehow this would become unimportant, but for now I think a lot of people rely on it. I can't believe you're suggesting removing the FoV keybinding though! I've used that for zoom in 3d cockpits for about as long as we've had the things, completely essential in my opinion. I know it's not strictly speaking zoom but it works, and is very quick and natural to use, too. Could it be a mouse/joystick binding? Yes - but these are much harder to remember and differ widely on different setups. Cheers, AJ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
On Sun, 03 Mar 2013 11:24:29 + James Turner wrote: What I'd like to see is the entire 'Ctrl' (Command on Mac) space reserved for GUI functions, like a normal application - Ctrl-Q for quit, Ctrl-M for map dialog, Ctrl-A for autopilot dialog, Ctrl-R for replay dialog (or radios dialog :) - then have a complete discussion about which key-bindings make sense on the main keyboard. This is basically a usability discussion, so everyone will have strong opinions :) Sorry, this should have been in my other email - I think this is a very sensible idea, though I still don't feel that zoom or FoV should require three keys to be pressed simultaneously (e.g. ctrl shift x) - or be restricted to a dialogue box slider for that matter... AJ -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
On Monday 04 March 2013 15:38:45 James Turner wrote: You're the third person to say the same thing. But again, you don't actually want to change the FoV at all. What you're doing (and everyone else) is using this feature to look around 3D cockpits, right? In other word, our cockpit navigation UI needs some improvement :) I do not only use FoV in 3D cockpits, but also as zoom in outside views. For example in the look from tower view. Though it's not essential, it's a use case. Stefan signature.asc Description: This is a digitally signed message part. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
On Mon, 04 Mar 2013 15:38:45 + James Turner wrote: Aha, and instantly we get a usability discussion: Right, you need the keys because you're working around a simulator bug (frame-rate drops badly) using manual interaction. The correct fix isn't to make the workaround-UI easier, it's fix the underlying issues, by making adaptive-LOD work so we can achieve a target frame-rate reliably. I do agree that would be the ideal... really I'm just saying that the fix ought to come and be proved satisfactory before the established workaround is removed. Hopefully nobody was really suggesting that, but I think there is a horrible tendency in open source projects for similar things to happen - because removing the workaround or cleaning up the UI is generally significantly easier than fixing the problem, it's only the former that gets done! You're the third person to say the same thing. But again, you don't actually want to change the FoV at all. What you're doing (and everyone else) is using this feature to look around 3D cockpits, right? In other word, our cockpit navigation UI needs some improvement :) Actually I think our cockpit navigation UI works better than anything else I've ever used in over twenty years of flying flight sims :-) It's not instantly intuitive, granted, and maybe there's room for improvement there, but I'd want to tread very carefully on this one as I think our method of interacting with the 3D cockpit using the mouse is generally very efficient indeed... Also, usability is hard :) It is... and partly because everyone has different ideas on what's good and what isn't! A lot of people seem to think that Apple's IOS UI approach is the greatest thing since sliced bread and I think it's one of the worst I've ever come across (Win8 is definitely worse, but not many people are insane enough to contest that view!) What I wouldn't like to see (and I'm sure isn't intended) is that we end up with a Gnome3 / Metro style UI revamp where we get what one or two people (who _are_ doing the work from best intentions) no doubt think is great and intuitive but most people find obtuse and retrogressive. At least we're having a discussion about this first - I'm hopefully being excessively paranoid but the sort of baby out with the bathwater scenario has been all too common in recent years! AJ -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
Just my 2 cents here. The primary reason I use the FoV/x binding is to see, read, and be able to use everything (or as much as I can) in my cockpit. Personally, I would rather scroll up/down, but that seems to have limits, as I can't zoom in as far as I want to by scrolling, but can using the key binding. There's also a limit for zooming out. Reaching the limit causes the FoV to be set back to the default. If the limit was removed, then I personally wouldn't mind having the key binding removed as well. Saikrishna Arcot On Mon 04 Mar 2013 10:23:25 AM CST, AJ MacLeod wrote: On Mon, 04 Mar 2013 15:38:45 + James Turner wrote: Aha, and instantly we get a usability discussion: Right, you need the keys because you're working around a simulator bug (frame-rate drops badly) using manual interaction. The correct fix isn't to make the workaround-UI easier, it's fix the underlying issues, by making adaptive-LOD work so we can achieve a target frame-rate reliably. I do agree that would be the ideal... really I'm just saying that the fix ought to come and be proved satisfactory before the established workaround is removed. Hopefully nobody was really suggesting that, but I think there is a horrible tendency in open source projects for similar things to happen - because removing the workaround or cleaning up the UI is generally significantly easier than fixing the problem, it's only the former that gets done! You're the third person to say the same thing. But again, you don't actually want to change the FoV at all. What you're doing (and everyone else) is using this feature to look around 3D cockpits, right? In other word, our cockpit navigation UI needs some improvement :) Actually I think our cockpit navigation UI works better than anything else I've ever used in over twenty years of flying flight sims :-) It's not instantly intuitive, granted, and maybe there's room for improvement there, but I'd want to tread very carefully on this one as I think our method of interacting with the 3D cockpit using the mouse is generally very efficient indeed... Also, usability is hard :) It is... and partly because everyone has different ideas on what's good and what isn't! A lot of people seem to think that Apple's IOS UI approach is the greatest thing since sliced bread and I think it's one of the worst I've ever come across (Win8 is definitely worse, but not many people are insane enough to contest that view!) What I wouldn't like to see (and I'm sure isn't intended) is that we end up with a Gnome3 / Metro style UI revamp where we get what one or two people (who _are_ doing the work from best intentions) no doubt think is great and intuitive but most people find obtuse and retrogressive. At least we're having a discussion about this first - I'm hopefully being excessively paranoid but the sort of baby out with the bathwater scenario has been all too common in recent years! AJ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
AJ wrote: On Mon, 04 Mar 2013 15:38:45 + James Turner wrote: Aha, and instantly we get a usability discussion: Right, you need the keys because you're working around a simulator bug (frame-rate drops badly) using manual interaction. The correct fix isn't to make the workaround-UI easier, it's fix the underlying issues, by making adaptive-LOD work so we can achieve a target frame-rate reliably. I do agree that would be the ideal... really I'm just saying that the fix ought to come and be proved satisfactory before the established workaround is removed. Hopefully nobody was really suggesting that, but I think there is a horrible tendency in open source projects for similar things to happen - because removing the workaround or cleaning up the UI is generally significantly easier than fixing the problem, it's only the former that gets done! You're the third person to say the same thing. But again, you don't actually want to change the FoV at all. What you're doing (and everyone else) is using this feature to look around 3D cockpits, right? In other word, our cockpit navigation UI needs some improvement :) Actually I think our cockpit navigation UI works better than anything else I've ever used in over twenty years of flying flight sims :-) It's not instantly intuitive, granted, and maybe there's room for improvement there, but I'd want to tread very carefully on this one as I think our method of interacting with the 3D cockpit using the mouse is generally very efficient indeed... Also, usability is hard :) It is... and partly because everyone has different ideas on what's good and what isn't! A lot of people seem to think that Apple's IOS UI approach is the greatest thing since sliced bread and I think it's one of the worst I've ever come across (Win8 is definitely worse, but not many people are insane enough to contest that view!) What I wouldn't like to see (and I'm sure isn't intended) is that we end up with a Gnome3 / Metro style UI revamp where we get what one or two people (who _are_ doing the work from best intentions) no doubt think is great and intuitive but most people find obtuse and retrogressive. At least we're having a discussion about this first - I'm hopefully being excessively paranoid but the sort of baby out with the bathwater scenario has been all too common in recent years! I think AJ has summed it all up pretty well. I almost never used zZ while using the normal scenery, but since I've been working on the detailed customised stuff I've needed it to try to keep performance within reasonable bounds. If we can solve the underlying problems, I would like to think I can go back to letting FG decide the vis for me. Let's put this discussion to one side, and see if we can do something about custom scenery/LOD/linear scenery etc. We might find zZ is redundant (I hope so) or we might need to retain it. It will argue for itself in the light of future developments. No need to discuss how many angels can dance on the head of a pin (no I don't know the answer either). Vivian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
Often airports are in or near very scenery-intensive areas and reducing visibility can help a lot in making the sim run usably for take-off, whereas once you're up and away it's nice to be able to open the view back up again for cross-country flying. This is applying a sledgehammer to a problem which asks for a screwdriver. Performance management with reducing visibility throws everything out - terrain mesh, static models, trees, random buildings,... As a result the load arriving at the vertex shader drops. First of all, this kind of performance management is bound to fail if you're not limited by the performance of the vertex shader - if the fragment shader is the bottleneck (as in the two more modern rendering schemes where we increasingly shift load to the more powerful fragment pipelines on modern GPUs) then you may change the number of vertices drastically, but the number of screen pixels covered by terrain and models changes insignificantly and the fragment load stays what it is. When I run Atmospheric Light Scattering on high detail, then my framerate is pretty much independent of visibility. I haven't tried it, but I am fairly sure the same is true for deferred rendering (Rembrandt) where the vertex stage of rendering is trivial and all the work is done per pixel. In fragment-dominated rendering schemes, the load of faraway models pretty much scales with the number of screen pixels they cover - so unloading them may free memory, but doesn't really change framerate. Also, if you're limited by cloud rendering performance (which unfortunately seems to be the case in many situations) changing visibility doesn't help you - only cloud draw range will do the trick. It may also be that the performance isn't limited by the GPU performance at all but by expensive Nasal (none of mine obviously :-) ) or terrain-probing features like a ground radar - in which case you can play with the visibility all day long and will not see any effect. So let's first note that performance management by visibility is only effective if certain conditions are met, likely to be ineffective in our modern rendering schemes and we should neither encourage it nor recommend it in general nowadays - performance scaling depends more often on the fine-print of what shaders you're running and what your GPU can do. If you nevertheless happen to be dominated by the vertex shader load, you'll notice that most of the load in scenery-heavy areas comes from models, not from the terrain. The fact that you need to get rid of models by drastically changing visibility indicates that the LOD range isn't configured properly, so what you actually need is a way to unload models at larger distance, not to increase visible fog and to unload terrain. I don't know if the LOD menu settings are honoured for static models and random objects (?) - but I'd give that a try before claiming that a visibility-changing key is needed for memory management. Of course, using a cheaper model shader may solve the trick equally well if models cause the main performance drain in the vertex shader. Before getting my current computer, I have had quite some performance limitations in the end and I've done a lot of tweaking of shaders and customizing my settings. The one thing I've never needed is adjusting visibility on the fly - it didn't ever help. All I needed is a safe limit to avoid going over the 32bit memory limit. whereas once you're up and away it's nice to be able to open the view back up again for cross-country flying. Well, but can't you do it from the menu (if you must do it at all) ? Maybe if that happened automatically somehow this would become unimportant, but for now I think a lot of people rely on it. Well, we can safely rule out all people running Advanced Weather (because the trick doesn't work), Atmospheric Light Scattering at high detail and possiby Rembrandt (because there the fragment shader gets the work and dropping vertex load is not really effective) and probably the majority of people using online weather (what's the point of using online weather if you cheat with the visibility later). I don't think that leaves a lot of people. I can't believe you're suggesting removing the FoV keybinding though! I've used that for zoom in 3d cockpits for about as long as we've had the things, completely essential in my opinion. I know it's not strictly speaking zoom but it works, and is very quick and natural to use, too. I actually agree with that, based on the reasoning that focusing on an instrument is something you can do in a real cockpit. Although personally I'm quite a fan of using the mouse wheel in view mode. * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: