| 00:00.39 | blast007 | macsforme: do you know if the SDL2Window::create workaround for Mac was because we were recreating the window? I'm adjusting the code so it doesn't recreate and instead calls stuff like SDL_SetWindowFullscreen and SDL_SetWindowSize |
| 00:21.54 | *** join/#bzflag WhatsUpDanger (ac0d4a9c@gateway/web/cgi-irc/kiwiirc.com/ip.172.13.74.156) |
| 02:04.04 | *** join/#bzflag Delusional (~Delusiona@unaffiliated/delusional) |
| 02:58.38 | *** join/#bzflag WhatsUpDanger (ac0d4a9c@gateway/web/cgi-irc/kiwiirc.com/ip.172.13.74.156) |
| 04:25.22 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 04:25.23 | *** mode/#bzflag [+v spldart] by ChanServ |
| 08:07.08 | macsforme | blast007: it's been a few years so it's hard to recall, but my bug report suggests that it was indeed related to recreating the window |
| 08:07.56 | macsforme | should be really simple to test with and without the workaround once your adjustments are done |
| 08:09.58 | macsforme | does anyone have an actual count on how much video memory we use under typical conditions? maybe I should boot into Windows and try MSI Afterburner... |
| 10:52.21 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 11:58.34 | blast007 | macsforme: in 2.99.x when we were using FTGL, I'd regularly exceed the 64MB(I think?) memory of the Mac Mini's Radeon 9200 when bringing up the menu, as there was a delay each time I did so as it was re-rendering it, but only when I was running at 1920x1200. |
| 11:59.10 | blast007 | not even sure if I was in a server when that happened, though |
| 15:34.29 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 17:01.06 | *** join/#bzflag WhatsUpDanger (ac0d4a9c@gateway/web/cgi-irc/kiwiirc.com/ip.172.13.74.156) |
| 17:09.39 | *** join/#bzflag WhatsUpDanger30 (ac0d4a9c@gateway/web/cgi-irc/kiwiirc.com/ip.172.13.74.156) |
| 17:28.49 | *** join/#bzflag WhatsUpDanger (ac0d4a9c@gateway/web/cgi-irc/kiwiirc.com/ip.172.13.74.156) |
| 17:31.06 | The_Noah | I didn't know anything about the development of BZFlag a while back but what ever happened to 2.99? |
| 17:45.33 | blast007 | The_Noah: it suffered from feature creep and had at least one major bug that made it unplayable that didn't manifest unless there were several people playing on a server for a while (like at least 20 minutes, maybe an hour? I forget how long it took) |
| 17:47.15 | The_Noah | Oh :( |
| 17:47.24 | blast007 | there was a bunch of half-finished features |
| 17:49.07 | blast007 | think there was over 5 years of work put into it by the point we decided to abandon it. so we went back to the 2.0 branch, made that 2.3, backported some stuff from 2.99.x and had a clear(er) set of goals for the release and someone to hold us to those goals |
| 17:50.48 | The_Noah | What are some of those goals? (if they are not all completed) |
| 17:57.44 | blast007 | https://wiki.bzflag.org/DevelopmentPlans/2.3 |
| 17:58.42 | blast007 | oh yeah, that was the other part of it. We had target dates for stuff working, and if it didn't work, we'd revert the broken changes and release without them |
| 18:02.00 | blast007 | https://wiki.bzflag.org/Development_RoadMap note that is an old roadmap (last edited 2013) |
| 18:03.42 | blast007 | for instance, XFire is mentioned for 2.8, but that service shut down in 2015/2016 |
| 18:04.05 | blast007 | and OpenAL I have partially set up for 2.6 |
| 18:05.07 | *** join/#bzflag WhatsUpDanger (ac0d4a9c@gateway/web/cgi-irc/kiwiirc.com/ip.172.13.74.156) |
| 18:05.27 | blast007 | and IPv6 is a 2.6 goal now |
| 18:08.09 | *** join/#bzflag fanta1 (~fanta1@p200300F76BC99F00A8CCAF36515279D4.dip0.t-ipconnect.de) |
| 18:10.55 | The_Noah | Is "Useful MOTD" still a goal? ;) |
| 18:21.49 | blast007 | yes |
| 18:22.20 | blast007 | like, a proper news feed in the client, not some message that shows up in the chat console *under* the menu |
| 18:23.44 | The_Noah | Will someone add mouse support to menus? I already did (with a few bugs) but have been unable to complete it as my computer will no longer compile BZ. |
| 18:26.44 | blast007 | mouse support would be nice |
| 18:27.02 | blast007 | I'm hoping we can find a new GUI library to use |
| 18:27.27 | blast007 | I keep ended up considering CEGUI |
| 18:27.28 | The_Noah | I actually kinda like how BZ handles it, but a library would make things easy. |
| 18:28.16 | blast007 | our menu stuff is very basic and limited |
| 18:28.37 | blast007 | IIRC, we have a fixed limit in our text input fields because we don't support scrolling |
| 18:28.40 | The_Noah | Yes... but it's lightweight. |
| 18:28.43 | blast007 | something around 40 |
| 18:28.49 | blast007 | lightweight.. but hard to use |
| 18:29.01 | blast007 | each menu has it's own code for positioning everything |
| 18:29.06 | blast007 | there's no layout system |
| 18:29.15 | The_Noah | One could be made. |
| 18:29.30 | The_Noah | But a library would not be a bad idea. |
| 18:29.44 | blast007 | sure, but at what point does just using an existing system outweight the work of trying to make our own? |
| 18:31.04 | blast007 | another one I've looked at: https://github.com/Immediate-Mode-UI/Nuklear |
| 18:32.28 | blast007 | I think that one has more of the concepts of a GUI and then you hook on your own rendering and input handling |
| 19:20.00 | The_Noah | That looks pretty good. |
| 20:09.05 | BZNotify | bzflag: 03atupone 11synchronized pull request #232 "Vertex buffers object handling" (06https://git.io/Je9kl) |
| 21:04.17 | *** join/#bzflag WhatsUpDanger94 (ac0d4a9c@gateway/web/cgi-irc/kiwiirc.com/ip.172.13.74.156) |
| 21:17.22 | *** join/#bzflag _I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 21:22.15 | BZNotify | bzflag: 03atupone commented on pull request #232 "Vertex buffers object handling" (06https://git.io/JeQCl): I have restructured a little:... |
| 21:25.15 | BZNotify | bzflag: 03jwmelto commented on pull request #232 "Vertex buffers object handling" by 03atupone (06https://git.io/JeQC8): > I wonder if is better to cut the file in two and/or redo the Pull... |
| 21:30.30 | tupone | Flash: I'm little scared by the global variables that I have defined. When in the same file the execution order is defined, if I put in two different files no. I should resolve on how to drop them hopefully without creating singleton |
| 21:31.02 | Flash | there is a difference between declaration and definition |
| 21:31.14 | Flash | header files should only declare, never define |
| 21:32.33 | tupone | yes, the definition is in a cpp file |
| 21:33.28 | tupone | If I separate the header I suppose I should separate also the body (not mandatory though) |
| 21:33.49 | Flash | oh, I definitely would |
| 21:34.18 | Flash | but, you should be scared of global variables |
| 21:34.18 | tupone | and I don't have in mind where to put vboVTNC, vboManager .... |
| 21:34.39 | Flash | much better to let them be members of some singleton class and wrap access through some method |
| 21:34.56 | tupone | all of them ? |
| 21:36.12 | tupone | one to rule them all |
| 21:36.21 | tupone | is an idea |
| 21:36.27 | Flash | there can only be one :) |
| 21:37.08 | Flash | I always try to take a step back from "how" I'm doing something and ask "what am I doing?" |
| 21:37.17 | Flash | this often leads me to the proper encapsulation |
| 21:39.03 | tupone | I hope you soon have time to help. Some of your questions, the ones let open, need idea :) |
| 21:39.21 | Flash | the week of Christmas, I'll spend some time on this |
| 21:39.41 | tupone | ok thanks |
| 22:13.54 | *** join/#bzflag WhatsUpDanger29 (ac0d4a9c@gateway/web/cgi-irc/kiwiirc.com/ip.172.13.74.156) |