The Steam version was created by one guy, but the platform ports have a couple different authors. The Google Play and Xbox PC versions, for instance, have divergences.
I wonder how the ports influence the upstream and each other. How do they keep the codebases in sync, while also accounting for platform differences?
Can't say for sure how Balatro did it, but typically you do one shared core and any platforms basically use that core in their own suitable way. Considering it's lua, would feel very natural and be relatively simple for Balatro to do it this way too. Not much to keep in sync, just ensuring the core remains reusable in the ways the platforms need it.
The Android and Xbox PC versions look more like forks for a shared codebase. Most of the platform-specific code is abstracted to a bridge, but even the bridges aren't consistent across the codebases. (Android's save system uses different methods than Xbox 's.)
Out of curiosity is there a reason nobody seems to be trying it with factory.ai's Droid in these comments? Droid BYOK + GLM4.7 seems like a really cost effective backup in the little bit I have experimented with it.
I don't know, never heard of factory.ai, but out of other curiosity, is there a particular reason you haven't commented since 2018/2019 but suddenly you're the second comment in all of HNs history to mention factory.ai in a comment?
const secondStatements = [
"SELECT quote(root) from ft_segdir;",
"UPDATE ft_segdir SET root = X'0005616261636B03010200FFFFFFFF070266740302020003046E646F6E03030200';",
"SELECT * FROM ft WHERE ft MATCH 'abandon';"
];
Just saw the proof of concept page. Looks like they are building quite the usual string in hex... Starting with a null terminator? Mmmhmmm
Did you really find CouchDB that bad to work with? I never in the end settled on either couch or mongo for a project long term but when I setup couch to test it out a few years ago I had it up and running with functional replication quite quickly (i.e., one afternoon) from being a complete novice with the platform. It's built in web panel at the time basically handled everything from basic setup to replication quickly.
Funny to see this here, it's been ages since I've seen UPX mentioned. In the early 2000's I had written some software whose executable was around a megabytes or maybe several megabytes in size coming out of VB6. On one of mid 90's test laptops we used at the time to ensure it would run on even the crummiest of machines it launched NOTICEABLY faster when packed with UPX. The hard disk in that machine was so incredibly slow loading less off the disk and decompressing the executable in RAM was easily an order of magnitude faster.
reply