| 01:42.38 | Delusional | itâs collision detection, not rendering, that slows you down. |
| 04:09.48 | JeffM | Yeah, thatâs the culling |
| 07:02.36 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-zgufhqtrwnrontyo) |
| 09:12.15 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 10:05.10 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-edzvhtjlbmozjlom) |
| 10:50.44 | *** join/#bzflag zuii (~cauchy@BC9C5B1F.mobile.pool.telekom.hu) |
| 15:31.26 | tupone | I would like to merge https://github.com/atupone/bzflag/tree/GL1.5 but I need test |
| 15:43.56 | blast007 | is it OpenGL 1.5 or 2.0? one of the commits says 2.0 |
| 15:44.09 | JeffM | did you add any files? |
| 15:48.01 | tupone | it is 1.5, the ogl part is only interface to 2.0. But I guess is not required |
| 15:48.15 | tupone | No file added |
| 15:48.28 | tupone | I changed the interfaces to add more GL primitives |
| 15:48.56 | tupone | and changed for now only where glDrawArray was used (Mesh, Flag, radar and shadow) |
| 15:50.00 | tupone | for the interface part I can reduce to vbo related changes |
| 15:51.26 | JeffM | builds and runs fine on windows |
| 15:51.38 | tupone | with or without SDL2 ? |
| 15:51.46 | JeffM | whatever the default is |
| 15:51.51 | JeffM | I belive that's with SDL2 |
| 15:51.58 | JeffM | all platforms do the same thing now IIRC |
| 15:52.12 | JeffM | there are no build options on windows |
| 15:52.36 | tupone | the genBuffers primitive is explicitly set only on SDL2. |
| 15:53.14 | tupone | I don't know how it work on other platform. Maybe is in the include file |
| 15:53.26 | JeffM | there are no other platforms |
| 15:53.40 | JeffM | linxux and OSX should all use SDL 2 |
| 15:54.10 | tupone | so it is now a kind of required ? |
| 15:54.30 | JeffM | yes |
| 15:54.37 | tupone | ahh. ok |
| 15:54.46 | JeffM | there are no plans to support anything other than SDL2 |
| 15:55.07 | JeffM | if someone wants to try to build with SDL1, they can try, but it's up to them to fix issues that come up. |
| 16:04.46 | blast007 | linux can still use SDL1 |
| 16:04.59 | JeffM | why? |
| 16:06.13 | blast007 | BulletCatcher has had issues with SDL2 working, specifically it being unable to properly create a fullscreen window - I think it hangs |
| 16:06.35 | blast007 | I was never able to reproduce the problem |
| 16:07.36 | blast007 | we do some weird stuff with resolution changes, though, so perhaps a good refactoring of our setup code would fix something |
| 16:08.13 | JeffM | with this modern age of NOT CRT displays, is there any good reason to change resultions at all? |
| 16:08.20 | JeffM | ether runn fullscreen or in a window. |
| 16:09.03 | blast007 | because you have a mac with a retina display and weak OpenGL performance? ;) |
| 16:09.19 | JeffM | so they do half res? |
| 16:09.33 | JeffM | then make that a mac platform switch |
| 16:09.37 | JeffM | it doesn't need to be general |
| 16:09.45 | blast007 | I don't see a reason to get rid of resolution changes |
| 16:09.53 | blast007 | we should just make it non-garbage |
| 16:09.54 | JeffM | "run half res" as a config option for mac builds. |
| 16:10.33 | blast007 | iirc, we repeatedly create and destroy the window at startup |
| 16:10.59 | tupone | The only problem that I see is that when I go from full screen to windowed I loose mesh drawing |
| 16:11.07 | tupone | Context are rebuilt |
| 16:11.14 | tupone | I need to fix that |
| 16:29.58 | JeffM | that will happen on windows when it Alt-Tab's to a different program too |
| 16:30.16 | JeffM | you need to rebuild all the stuff when the window is activated or deactivated. |
| 17:26.32 | tupone | yeah. I discovered that I removed too much |
| 18:04.40 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 18:04.40 | *** mode/#bzflag [+v spldart] by ChanServ |
| 18:40.45 | *** join/#bzflag alfa1 (~alfa1@host47.190-30-54.telecom.net.ar) |
| 18:43.36 | tupone | I fixed and pushed again. |
| 18:44.33 | tupone | I don't have the same problem for flags but that were no callback there to fix the gl list :( |
| 18:59.24 | tupone | hmm, actually there is a problem with the flag and context rebuilding. Some artefacts. That is why the list for the flag was setted to no by default :/ |
| 18:59.46 | tupone | I will remove the flag from my commit and see |
| 19:20.16 | tupone | Commited and seems good |
| 19:43.11 | *** part/#bzflag alfa1 (~alfa1@host47.190-30-54.telecom.net.ar) |
| 20:59.21 | macsforme | macs run bz just fine at full retina resolution... I don't believe the driver issues we've seen are related to retina displays |
| 21:05.37 | blast007 | macsforme: I was just assuming that if those driver issues occured, they'd be even worse if you were forced to run at native resolution :P |
| 21:11.18 | macsforme | I think ideally we would get rid of the modeset entirely, and allow rendering to a lower-resolution framebuffer if needed for performance reasons |
| 21:16.28 | macsforme | why do we need to query function pointers for GL 1.5 functions? is that because Windows doesn't give us those? |
| 21:18.21 | JeffM | windows only includes gl 1.1 |
| 21:19.01 | JeffM | unless you use glext.h or wglext.h |
| 21:21.47 | JeffM | or GLEE |
| 21:27.12 | blast007 | GLEW? |
| 21:28.17 | macsforme | okay, so as others have said, this change would officially marry us to SDL |
| 21:30.16 | JeffM | if you are going to keep building your own engine, it's not a bad baseline to stick with |
| 21:33.31 | macsforme | tupone: I think you want to check the return result of SDL_GL_GetProcAddress()... this is how I did it for the GL_ARB_framebuffer_object extension: https://github.com/BZFlag-Dev/bzflag/blob/2.4/src/ogl/OpenGLGState.cxx#L1314-L1336 |
| 21:34.29 | macsforme | in this case though, I don't think there will be any fallback, other then to exit the program |
| 21:36.46 | macsforme | also, it doesn't seem to have the code to load the function pointers in SDL 1.2, which we still support |
| 21:37.12 | macsforme | and bzfgl.h needs an updated version check to OpenGL 1.5 |
| 21:38.57 | blast007 | I'm unclear what's going on... when I'm setting a lower-than-native resolution on my PC in BZFlag, my display still says it's running at the native resolution, even though I have nVidia's drivers set to do scaling on the display |
| 21:42.37 | macsforme | tupone: also, you listed the functions in bzfgl.h under the section that's labeled // GL_ARB_framebuffer_object functions, so maybe make a new section with a new label for those? |
| 21:55.59 | JeffM | blast007: hence why res changing in the modern are is kind of silly |
| 21:59.49 | blast007 | I just can't tell if my display OSD is lying to me |
| 22:01.29 | macsforme | if we want to transition to using VBOs, I already converted all of the vertex specification code to use one unified class (using vertex arrays) for my embedded fork: https://github.com/macsforme/bzflag-embedded/blob/embedded/src/ogl/DrawArrays.cxx |
| 22:02.12 | blast007 | even changing the desktop resolution still shows the native resolution in the OSD... but with a different 1080p TV, the OSD reflects the resolution changes |
| 22:02.16 | macsforme | that could be adapted pretty easily to use VBOs instead, and the rest of the work throughout the whole client is done |
| 22:02.23 | blast007 | maybe that's some silly g-sync thing |
| 22:05.46 | blast007 | seems the display attached to DisplayPort always show the native resolution on the OSD, but the one on HDMI reflects the actual resolution |
| 22:06.03 | blast007 | shows* |
| 23:26.55 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-kkrfustpwiwxepky) |
| 23:30.01 | *** join/#bzflag macs4me (~macsforme@2604:a880:400:d0::e61:a001) |
| 23:30.01 | *** join/#bzflag macs4me (~macsforme@bzflag/developer/Constitution) |
| 23:30.01 | *** mode/#bzflag [+o macs4me] by ChanServ |