| 00:16.37 | *** join/#bzflag infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 00:16.37 | *** topic/#bzflag is https://BZFlag.org || https://www.openhub.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || Current version: 2.4.18 || New shiny website! https://forums.bzflag.org/viewtopic.php?f=8&t=20201 |
| 00:16.37 | *** mode/#bzflag [+v infobot] by ChanServ |
| 01:52.01 | *** join/#bzflag Sgeo (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 02:51.21 | macsforme | in master (where I bumped our macOS deployment target to 10.9), we're getting warnings for two deprecated functions in DirectoryNames.cxx in the game module, FSFindFolder and FSRefMakePath... there doesn't appear to be any updated method that's accessible from C++ code |
| 02:54.53 | macsforme | we could 1) ignore or silence the warning, 2) have an Objective-C++ file wraps it, or 3) move that out of the game module and into platform, where we can use SDL_GetPrefPath(), which will also incidentally work with sandboxing if we want to do that later, and/or on iOS |
| 02:56.54 | macsforme | since I think we took pains to make all of our files C++ only a while back, I thought there might be some hesitation to adding an Objective-C++ file, even if it would only be compiled on macOS |
| 03:52.45 | allejo | i'd be hesitant to introduce another language into the codebase |
| 03:53.30 | allejo | even if it's just for macos. still one more thing to maintain. option 3 sounds the most cross-platform friendly approach (with my limited knowledge of any of that works) |
| 03:53.43 | allejo | is option 3 more cross-platform friendly (for devs that is)? |
| 04:22.09 | Flash | macsforme: that's a bit of ugly platform-specific code |
| 04:22.11 | Flash | https://stackoverflow.com/questions/19404239/locating-mac-os-x-folders-using-urlfordirectory-instead-of-fsfindfolder |
| 04:22.15 | Flash | seems relevant |
| 04:25.22 | Flash | I'd think separating the platform-specific stuff into a "platform abstraction layer" is preferable to embedding it in various places |
| 04:25.41 | Flash | I had thought (with little digging) that's what SDL was for |
| 08:59.31 | macsforme | Flash: the proposed solutions in that link are for Objective-C code |
| 09:26.06 | *** join/#bzflag Dracos85 (~dracos85@24-119-188-49.cpe.cableone.net) |
| 12:11.27 | *** join/#bzflag Delusional_ (~Delusiona@unaffiliated/delusional) |
| 12:11.29 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 14:48.19 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 17:41.00 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 21:49.36 | blast007 | macsforme: the overall directory handling stuff could be revamped. For instance, on Windows, I'd like to store screenshots in the My Pictures folder, not a subfolder buried in a hidden configuration directory |
| 21:53.13 | blast007 | so, going in that direction, I wouldn't be against having objective-c added to the src/platform/ if it gets us a feature that we can't get through SDL2's abstraction layer. |
| 21:53.32 | blast007 | but if SDL2 can do what we need, we should use that |
| 21:54.15 | macsforme | is that what other games do? I only really play Overwatch on Windows, and it just puts a directory in the user's documents folder, and has the config, screenshots, and video highlights in there |
| 21:58.21 | macsforme | makes sense though, if our data is just config and screenshots, to have the config in appdata and the screenshots in the pictures folder |
| 22:03.07 | blast007 | config, cache, screenshots, world downloads |
| 22:03.36 | blast007 | on Windows, cache normally goes into c:\Users\Username\AppData\Local\AppName |
| 22:03.57 | blast007 | configuration would go into c:\Users\Username\AppData\Roaming\AppName |
| 22:05.47 | blast007 | for a game though, having configuration in Local is likely fine as well |
| 22:06.35 | blast007 | most people playing games aren't going to be using roaming profiles, and even if they were you'd have variations between computers such as screen resolution |
| 22:08.49 | macsforme | I know on macOS, Apple really wants you to only write to the sandbox container area... in fact, some developers skip the app store (which requires sandboxing) due to the overall restrictiveness |
| 22:10.50 | blast007 | nice.. needs a developer account to read the App Sandboxing FAQ.. |
| 22:12.35 | macsforme | lol |
| 22:14.41 | blast007 | I imagine we can store persistent configuration and cache within the sandbox, and if we want to write screenshots and world downloads to the user's Pictures or Downloads folder, we would enable the entitlement for those |
| 22:17.12 | blast007 | I've also briefly pondered a central hub for content (worlds, textures, sounds, scripts) that would be used instead of locally hosted map files. In such a situation, a "world download" could simply be launching a URL. |
| 22:18.04 | blast007 | there's plenty of things we could change about our map format |
| 22:20.31 | blast007 | we could adopt some standard such as GLTF for defining our 3D scene, which would open up support for more standard editors. |
| 22:21.06 | blast007 | though I guess I'm going off on a tangent now.. sorry :) |
| 22:27.00 | macsforme | well it's at least good to consider the directories issue from a cross-platform standpoint |
| 22:35.36 | The_Noah | A hub for worlds would be awesome, especially of BZFS could run worlds directly from it. |
| 23:03.45 | blast007 | The_Noah: one potential path I can see the game going is where game servers aren't set up for hosting specific maps, but instead are picked based on the location of players in a lobby and then the game server (and possibly the clients) load the desired world from the central hub |
| 23:04.12 | blast007 | allows the content creators to focus on making content instead of being a sysadmin as well |
| 23:25.18 | The_Noah | One problem I see is if a map needs a plugin that the server doesn't have. Although the server owner could just compile the plugins but that adds an extra step for some maps. (not a big issue though) |
| 23:34.05 | blast007 | that's why I'd like to see plugins move from compiled code to interpreted scripts |