| 00:25.29 | *** join/#bzflag infobot (ibot@208.53.50.136) |
| 00:25.29 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.14 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19953 |
| 00:25.29 | *** mode/#bzflag [+v infobot] by ChanServ |
| 00:57.41 | kierra | ~blast++ |
| 06:27.11 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@2605:e000:141f:c028:80fc:fb6c:4c35:be3a) |
| 06:27.11 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 06:27.11 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
| 11:39.45 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
| 15:55.18 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 20:23.36 | macsforme | how do we want to support multiple displays moving forward (if at all)? |
| 20:24.20 | macsforme | right now we have [-view {normal|stereo|stacked|three|anaglyph|interlaced}]... I'm not sure about the working state of each of those modes |
| 20:24.55 | macsforme | so I guess the critical question is, do we want to allow multiple 3D views, such as left + front + right? |
| 20:25.46 | macsforme | or should additional monitors only be used for moving UI elements over, such as the radar, chat console, etc.? |
| 20:31.12 | macsforme | I can see the option to move the radar over to a secondary monitor as being the most worthwhile investment of development effort... allowing multiple 3D views, while not practical for most people, seems like a significant advantage, and perhaps an unfair one |
| 20:35.30 | blast007 | the majority of those 3D modes are probably irrelevant for proper multi-display support |
| 20:37.42 | blast007 | anaglyph is probably the most useful of the alternative modes |
| 20:38.21 | blast007 | three was probably for rooms where you had three projectors filling a side of the room each and split the video signal up |
| 20:39.08 | macsforme | is "three" still just one view (the forward one), or does it show multiple angles? |
| 20:39.38 | blast007 | it shows three views, I think two of them are just 90 degree rotations to the left and right |
| 20:40.04 | blast007 | stereo fails to run here on Linux/Intel |
| 20:40.28 | blast007 | also fails on Windows/nVidia |
| 20:41.06 | blast007 | stacked was probably for some head mounted display where it showed the top/bottom for the left/right eye |
| 20:41.27 | blast007 | interlaced being similar except it was every other line |
| 20:42.01 | macsforme | stereo fails on macOS as well |
| 20:42.37 | blast007 | anaglyph should work with the old kind of 3D glasses you'd get in cereal boxes :) |
| 20:48.07 | macsforme | "-view three" doesn't seem to actually create multiple windows... I guess it assumes one window spanning multiple displays? |
| 20:48.22 | macsforme | and with a very specific layout, at that |
| 20:48.30 | blast007 | yeah, it's just one window split up into multiple viewports |
| 20:49.23 | blast007 | most of them are gonna be pretty specific purposes, probably from the era of SGI workstations and early HMDs / virtual reality |
| 20:49.39 | macsforme | I don't think that's very useful for modern players wanting to use their second or third monitors |
| 20:49.57 | blast007 | most certainly not |
| 20:51.22 | macsforme | we could, however, ask SDL for a list of displays and then create a window on each one, and allow the player to configure each monitor to show one of the 3D views, or just the radar, or whatever |
| 20:52.32 | blast007 | is that something better left for 2.8? I don't know if our GUI is going to improve/change much for 2.6. |
| 20:53.27 | blast007 | still need a team selection UI |
| 20:53.41 | macsforme | it would probably go along with the transition to OpenGL 3.2, whenever that is |
| 20:54.53 | macsforme | apparently you can use SDL_GetDisplayBounds() to query the layout of multiple monitors, so in theory we could support an automatic three-monitor layout if we wanted to |
| 20:55.20 | macsforme | do you think the OpenGL transition should go into 2.6, or wait? |
| 20:56.31 | macsforme | obviously it will open a lot of doors, but the first transition could aim to just be as much of a straight replacement as possible |
| 20:57.01 | macsforme | it would not take very complicated shaders to replicate what we do now :P |
| 21:19.57 | blast007 | I feel it would be nice to target 3.2 for 2.6 so that we can start building off that as soon as possible |
| 21:21.21 | blast007 | https://github.com/wjakob/nanogui that uses OpenGL 3.x, for instance. (Well, and also GLFW instead of SDL, so that may be a no-go without forking or getting upstream to add SDL2) |
| 21:25.58 | blast007 | https://github.com/vurtun/nuklear has GL 2 and 3 examples for SDL2 |
| 21:27.02 | blast007 | https://github.com/memononen/NanoVG (used for nanogui) mentions GL/GLES 2 and 3 |
| 21:27.40 | blast007 | nuklear also has a GLES 2 + SDL2 example |
| 21:28.53 | blast007 | https://github.com/ocornut/imgui has GL 2/3 demo for SDL2 |
| 21:30.02 | macsforme | are you of the mindset that we need an external library for our GUI? |
| 21:30.30 | blast007 | I'm of the mindset that either direction is beyond my skills :) |
| 21:34.00 | blast007 | MyGUI seems like it has GL1, GL3 and GLES3 |