RS 'Still Alive'

[laleksic]

By all means link to it, but you flatter me too much- it's not the definitive version: not really properly tested, Linux doesn't work yet obviously, and the repo is not presentable at all. I just remembered I didn't even upload the main branch, so the main page is just sitting empty. You should link to the same branch page I did and note that it's an extremely experimental WIP cross-platform port.

In any case, I don't want to take over or anything like that. I was hoping you would integrate these changes when you next find time to work on RS:SA. I can upload it on gitlab and open a pull request.

[MP]

Apologies if I embarrassed you, but it really does mean a lot to me. RS:SA holds a sweet spot in my heart even since I found it back in 2010. For example, nope, zaimoni and I are the oldest forum members still in residence, my tenure dating back to March of 2011. Plus, I've been working on my fork since 2017, so to see RS:SA reach the milestones that you've delivered is quite special to me. All good though, enough of the sentimentality

I am happy to do a merge request. I've never been the merger, only ever the initiator, and never done either across platforms (GitHub to GitLab), so forgive my ignorance regarding the process. My background in development started in the mid-90s, when source code was shared by floppy disk with version numbers appended to the end of file names, and then into the 2000s when Merant and PVCS ruled the roost. Git is still very new to me, and I though I used it in the corporate world until recently, it was only ever as the sole developer and maintainer of the repos, so Git collaboration is a whole new kettle of fish for me. If it's the path you prefer, please guide me and I'll give it my best shot.
Or better yet, if you're willing, I'm happy to make you a co-maintainer (or whatever the correct term is) of the GitLab repo, and you can merge your own changes (you would certainly have my blessing). It would be nice to collaborate in such a way, but I do understand if you'd rather remain a step back from it. The great thing about open source is that it not a competition, but a cooperation. I'm sure we can find an arrangement that suits.

[laleksic]

That sounds like an epic journey! Quite a bit longer than anything in my life that had any permanence, honestly. Though I strive to get there eventually. It's inspiring to hear that. No need for apologies, and you didn't embarrass me . I just feel that maybe my rough first draft port is too modest to be called the definitive edition in comparison.

I figured out what's up with the Linux build. It's not as self-contained as advertised. The .NET stuff has a dependency on glibc 2.16 (that's from 2012, so I think that's reasonable, not that there's much we can do about it). The SFML libraries actually do have system dependencies which may not be preinstalled on some distros (or may have a version mismatch). What I'll do is recompile SFML and all the dependencies on an older distro on VirtualBox (to avoid introducing a glibc dependency >2.16), and then ship the resulting .so files instead of the ones provided by the SFML.NET package. That should work.

As for the merging, no worries. The cross site issue is no problem, I can just upload to GitLab. Floppy disks, heh. I'm just barely old enough to remember them lying around when I was a kid, but young enough that git's the only version control I use, though I'm no expert. My background is working solo or with just a few people rather informally; no corporate experience. I did handle pull requests both ways, though. I have no preferences, and sure I'm willing to be co-maintainer, I'm just wary of screwing something up for you when you have time to continue working on the project. We can figure it out when I fix the issues found so far.

[MP]

To be a bit more specific about the glibc thing, I spoke too casually there. It was specifically the libstdc++ lib (libstdc++.so.6) and asking for CLIGCXX_3.4.29 (or thereabouts iirc). Debian Bullseye went into LTS just before the version of your RS:SA build, and thus only Bookworm had the requisite method version. However, I don't think that's related to the issues that I had on Debian Bookworm nor Manjaro in any case. The former I'm struggling to explain, although XFCE is notoriously slow-moving, especially on Debian, so an outdated library is very much a possibility. When it comes to Manjaro, the "System.DllNotFoundException: Unable to load shared library 'csfml-audio'" seems to be a common issue, if the number of search results is anything to go by. My suspicion was that RS:SA expected a very particular filename for the library (or sub-dependency), and perhaps in a particular location. As mentioned, I messed around with lots of different names and named simlinks to the library files, but nothing hit the mark. Some posts talked about particular SFML build versions, but I compiled a few myself and all gave the same error. One talked about compiling the game in Release mode rather than Debug, but I see that your Windows build was Release, so I assume the Linux build was too.
I wish I could be more help. All I can offer is to try whatever you have with the LD_DEBUG=all variable and give you the full output. Having said that, please don't bang your head on a brick wall over this. It could well be down to idiosyncrasies of my systems, and until I try your build in a couple of fresh vanilla VMs I feel bad about saying it isn't working for me.


Also, agreed re. next steps. Our repos aren't going anywhere, so we've got the time to get things smoothed out before we discuss next steps. Get it to a point that your happy with and then we'll tackle how to combine efforts down the track.

[laleksic]

Hey, fresh build available at: github.com/laleksic/StillAlive/releases/tag/v20230901

Tested on clean installs of Ubuntu 16.04 and Debian 10 on VM. Seems to work ok.

I recompiled SFML and all of it's dependencies for an old linux distro (Centos 6), configured each of the libraries to look for it's dependencies in the same folder rather than in the system library folders, and bundled those versions instead of the ones provided by SFML.NET. The sources and build script and instructions I all included in the repo. Though I also include the binaries in the repo, so rebuilding the dependencies shouldn't need to be repeated unless upgrading a dependency, or something like that. However the .NET runtime still has a requirement for a newer glibc/libstdc++, and there isn't much I can do about that short of recompiling the whole runtime for an old distro as well. 32 bit support for Linux would also seem to require compiling the runtime. That would I think be overkill, as everything should work now on a relatively recent Linux system.

Also added a dependency on NetBeauty which does some magic to clean up the structure of self contained builds, putting all the dlls into a separate directory. I included a launcher script for Linux, since the executable was getting detected as a shared library for reasons I'm not sure I can fix since it's .NET that actually produces the executable.

Haven't touched anything else we talked about yet though. Will do so next time around, if everything works confidently on Linux now .

[MP]

It's running perfectly on Manjaro now I'll test it on Debian Bookwork at some point too, but as you've already confirmed it, I'm sure it will be fine for me too.

It sounds like it was a bit of a headache to get it squared away, so thank you for going through all the effort.
I'm going to play a few rounds this weekend, and it'll be nice not to have to boot up Windows to do it.


PS. I've updated the first post of this thread to include a link to your repo for the release builds.

[laleksic]

Great !

It was a bit tedious yes, cause it turned out to be very convoluted to compile a portable Linux binary. I can get into it in more detail if you're interested or need the info.

[MP]

I'm happy to say that both your Windows and Linux (Manjaro and Debian 12) work like a charm. It was the first time in a long time that I've played the game without testing specific features or for particular bugs. It was nice just to cruise around and play the game like I used to. I was always a bit of a scaredy-cat, and despite all the meta knowledge I have of the game now, I am still just as much of a coward

The game runs smoothly, and launches so much faster. Saving is faster too, and loading a save game is immensely faster! The difference is huge.
The only very minor issue that I came across is that screenshots (Shift+N) always overwrite 'screenshot_000.png'. It's not incrementing +1 from the last screenshot filename. That happens on both Windows and Linux.

Though it was a pain, the work you put in to make it more portable for Linux really paid off. It launched first time without any troubles now, and speaking personally it was very satisfying to play it on Linux. Great job, Luka