[Ohrrpgce] SVN: teeemcee/13231 Work around FB bug sf#826 with separate SavePropBool[Always] functions
teeemcee 2023-04-22 20:34:47 -0700 (Sat, 22 Apr 2023) 422 Work around FB bug sf#826 with separate SavePropBool[Always] functions Without this workaround I doubt that the code is compiled correctly, since the bug is that FB prefers function overloads for boolean rather than integer. But that's not all, it seems to allow defining functions for boolean overloads that haven't been declared, and which overload it picks seem to change after the point in the file that it's defined. --- U wip/slices.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: teeemcee/13230 Shrink Slice further by using boolean instead of bool
teeemcee 2023-04-22 20:34:41 -0700 (Sat, 22 Apr 2023) 236 Shrink Slice further by using boolean instead of bool Also rearranged a couple members to put the booleans closer together, reducing padding. And made EditorColor a ubyte. sizeof(Slice) reduction: 32-bit: 216 -> 184 64-bit: 296 -> 264 --- U wip/sliceedit.bas U wip/slices.bas U wip/slices.bi ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: teeemcee/13229 Shrink Slice memory usage by turning most enums into bytes
teeemcee 2023-04-22 20:34:35 -0700 (Sat, 22 Apr 2023) 306 Shrink Slice memory usage by turning most enums into bytes Unfortunately Enum is 4 bytes (32-bit) or 8 byte (64-bit). Also replaced TargResidue's 64-bit floats with 32-bit ones, which is still excessive, 16-bit fixed-point would be plenty. Reduces sizeof(Slice): 32-bit: 248 -> 216 64-bit: 376 -> 296 !! --- U wip/menuedit.bas U wip/sliceedit.bas U wip/slices.bas U wip/slices.bi U wip/util.bi ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: teeemcee/13228 sliceedit: Add byte editing, and allow default values for menu items oth
teeemcee 2023-04-22 20:34:27 -0700 (Sat, 22 Apr 2023) 222 sliceedit: Add byte editing, and allow default values for menu items other than enums (I split out sliceed_rule_set_default from sliceed_rule_enum) Also converted the helpkeys to a zstring ptr to reduce executable sizes. --- U wip/sliceedit.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: teeemcee/13227 Fix compiling commandline programs, broken by my reporterr change
teeemcee 2023-04-22 20:34:19 -0700 (Sat, 22 Apr 2023) 65 Fix compiling commandline programs, broken by my reporterr change --- U wip/common_base.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Steam Deck Walthros g_debug
We just had a report about the same slow battles and crashing bug from someone running (the False Skies demo) under Proton, but for the first time on a Linux desktop, so it's not Steam Deck specific afterall. But linux native builds (maybe?) not running on the Deck might still be. On Sat, 22 Apr 2023 at 22:21, Ralph Versteegen wrote: > Oh, good find. > > There are commandline flags we can run games with to get debug logs either > from Proton or from the Steam Runtime. Adam, I assume you suffer the battle > slowdown and memory leak bug when running games under Proton? If so, while > you have a Windows build, maybe you could run with Proton logging and see > whether it's useful? Set the game's launch options to `PROTON_LOG=1 > %command%` and then look for $HOME/steam-$APPID.log. > > It would be great if you or someone also tried a Linux OHR build again, by > using the "Steam Linux Runtime" compatibility tool setting as mentioned in > that Reddit post. The part in that post about needing to run the game in > desktop mode from the file browser might not be true for the OHR. But if it > is, that's exactly the problem we want to solve, by getting a debug log > from Steam Runtime. Run the game with `STEAM_LINUX_RUNTIME_LOG=1 > %command%` as the 'launch options', then look for > ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/slr-app-.log > > Paul: I guess you could submit a Steam Deck Compatibility Review request > as a way to get Steam to use Linux builds on the Deck. But first we should > find out whether they actually work. > > My own experiments: > > I tried running a few OHR games using "Steam Linux Runtime" (which means > Steam Runtime 2 specifically) as the prescribed Compatibility Tool instead > of the default way, because that should be much closer to running the game > on a Deck. (However it might be running "scout_on_soldier".) I think this > might be the reason the Deck defaults to running Windows rather than Linux > binaries: because Steam on Linux systems normally uses Steam Runtime 1 (aka > Scout) to run linux binaries (which is mostly just a set of standard > libraries on top of the user's OS; legacy but still the default for > compatibility reasons), while apparently the Deck uses Runtime v2 (aka > Soldier), which runs the game in a container. Eg.g I saw a issue saying > that all Electron (Chrome)-based games fail to run on Deck because Soldier > is missing a certain library for printing. > > But the OHR runs fine under Soldier, so that's not it. I also tried > running OHR games with Windows build using Proton 8.0-1 (which actually > uses Steam Runtime 3) but that works perfectly too. > > On Sat, 22 Apr 2023 at 14:03, Paul Harrington < > paulclementharring...@gmail.com> wrote: > >> It looks like this is a known issue with other games too: >> >> >> https://www.reddit.com/r/CrossCode/comments/x8kdqm/on_steam_decklinux_steam_is_defaulting_to_the/ >> >> On Fri, Apr 21, 2023, 8:44 PM Ralph Versteegen >> wrote: >> >>> If we want to force Steam to use a certain build (e.g. the Linux one) >>> for testing, one way to do it is to make it a private (passworded) beta. (I >>> don't know any other way.) >>> >>> On Sat, 22 Apr 2023 at 02:02, Adam Perry wrote: >>> Hmm... yep, sounds about right. On Fri, Apr 21, 2023 at 2:33 AM Ralph Versteegen wrote: > Alright so now that it's working... it's running the windows build, > which Steam has under its own volition decided to download instead of the > linux one? And you don't know whether it had a linux or windows build at > the time that it wasn't launching? > > On Fri, 21 Apr 2023 at 01:09, Adam Perry wrote: > >> Ah, we may have had some crossed wires here. I told Paul it wasn't >> launching on Deck, so he talked to you, I imagine. I'm not sure which >> distros are included when you download on Deck, but I only saw the one >> exe, >> and the failed starts didn't generate any log files. >> >> On Thu, Apr 20, 2023, 6:50 AM Ralph Versteegen >> wrote: >> >>> I'm confused. Yes, that log is definitely from a Windows build under >>> Proton. But wasn't the idea to get the Linux build running on the Deck? >>> Didn't you report that it didn't run? What build is it using now after >>> switching to Desktop mode and back? >>> >>> On Thu, 20 Apr 2023 at 01:10, Adam Perry wrote: >>> No, this one was definitely from the Proton run. I hadn't yet run it in desktop mode. On Wed, Apr 19, 2023, 4:49 AM Ralph Versteegen wrote: > Thanks. But that's a Windows build of the OHR running under > Proton, not the Linux one we're trying to get working (since the > Windows > one suffers from battle slowdowns). Maybe switching to Desktop mode > for > some reason caused Steam to switch to the Windows build? I've tried > searching the web but
Re: [Ohrrpgce] Steam Deck Walthros g_debug
Oh, good find. There are commandline flags we can run games with to get debug logs either from Proton or from the Steam Runtime. Adam, I assume you suffer the battle slowdown and memory leak bug when running games under Proton? If so, while you have a Windows build, maybe you could run with Proton logging and see whether it's useful? Set the game's launch options to `PROTON_LOG=1 %command%` and then look for $HOME/steam-$APPID.log. It would be great if you or someone also tried a Linux OHR build again, by using the "Steam Linux Runtime" compatibility tool setting as mentioned in that Reddit post. The part in that post about needing to run the game in desktop mode from the file browser might not be true for the OHR. But if it is, that's exactly the problem we want to solve, by getting a debug log from Steam Runtime. Run the game with `STEAM_LINUX_RUNTIME_LOG=1 %command%` as the 'launch options', then look for ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/slr-app-.log Paul: I guess you could submit a Steam Deck Compatibility Review request as a way to get Steam to use Linux builds on the Deck. But first we should find out whether they actually work. My own experiments: I tried running a few OHR games using "Steam Linux Runtime" (which means Steam Runtime 2 specifically) as the prescribed Compatibility Tool instead of the default way, because that should be much closer to running the game on a Deck. (However it might be running "scout_on_soldier".) I think this might be the reason the Deck defaults to running Windows rather than Linux binaries: because Steam on Linux systems normally uses Steam Runtime 1 (aka Scout) to run linux binaries (which is mostly just a set of standard libraries on top of the user's OS; legacy but still the default for compatibility reasons), while apparently the Deck uses Runtime v2 (aka Soldier), which runs the game in a container. Eg.g I saw a issue saying that all Electron (Chrome)-based games fail to run on Deck because Soldier is missing a certain library for printing. But the OHR runs fine under Soldier, so that's not it. I also tried running OHR games with Windows build using Proton 8.0-1 (which actually uses Steam Runtime 3) but that works perfectly too. On Sat, 22 Apr 2023 at 14:03, Paul Harrington < paulclementharring...@gmail.com> wrote: > It looks like this is a known issue with other games too: > > > https://www.reddit.com/r/CrossCode/comments/x8kdqm/on_steam_decklinux_steam_is_defaulting_to_the/ > > On Fri, Apr 21, 2023, 8:44 PM Ralph Versteegen wrote: > >> If we want to force Steam to use a certain build (e.g. the Linux one) for >> testing, one way to do it is to make it a private (passworded) beta. (I >> don't know any other way.) >> >> On Sat, 22 Apr 2023 at 02:02, Adam Perry wrote: >> >>> Hmm... yep, sounds about right. >>> >>> On Fri, Apr 21, 2023 at 2:33 AM Ralph Versteegen >>> wrote: >>> Alright so now that it's working... it's running the windows build, which Steam has under its own volition decided to download instead of the linux one? And you don't know whether it had a linux or windows build at the time that it wasn't launching? On Fri, 21 Apr 2023 at 01:09, Adam Perry wrote: > Ah, we may have had some crossed wires here. I told Paul it wasn't > launching on Deck, so he talked to you, I imagine. I'm not sure which > distros are included when you download on Deck, but I only saw the one > exe, > and the failed starts didn't generate any log files. > > On Thu, Apr 20, 2023, 6:50 AM Ralph Versteegen > wrote: > >> I'm confused. Yes, that log is definitely from a Windows build under >> Proton. But wasn't the idea to get the Linux build running on the Deck? >> Didn't you report that it didn't run? What build is it using now after >> switching to Desktop mode and back? >> >> On Thu, 20 Apr 2023 at 01:10, Adam Perry wrote: >> >>> No, this one was definitely from the Proton run. I hadn't yet run it >>> in desktop mode. >>> >>> On Wed, Apr 19, 2023, 4:49 AM Ralph Versteegen >>> wrote: >>> Thanks. But that's a Windows build of the OHR running under Proton, not the Linux one we're trying to get working (since the Windows one suffers from battle slowdowns). Maybe switching to Desktop mode for some reason caused Steam to switch to the Windows build? I've tried searching the web but have found no mention of it. Is there an option in the game properties to switch builds? I'd be happy to have any leads on the battle slowdown too, though. Recent nightlies can run CPU Usage debug mode in battles too, but that debug log is from version 20221207. But have a look for a g_debug_archive.txt, which should be preserved whenever Steam installs game updates (or reinstalls), so could
