Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add antichamber, an humble (indie!) bundle game #14

Merged
merged 1 commit into from
Jul 28, 2017

Conversation

layus
Copy link
Contributor

@layus layus commented Mar 10, 2017

This game uses 32bit libs.
Nixos users, do not forget to enable hardware.opengl.driSupport32Bit

@Profpatsch
Copy link
Member

On my machine it builds, but doesn’t run:

> result/bin/antichamber 
[S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.
[S_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.dll.
Loading library: libPhysXCooking.so
Result of loading library libPhysXCooking.so: 0xa744c80
Loading library: PhysXUpdateLoader.so
ERROR: PhysXUpdateLoader.so: cannot open shared object file: No such file or directory
Result of loading library PhysXUpdateLoader.so: 0x0
Loading library: libPhysXCore.so
Result of loading library libPhysXCore.so: 0xa744a00

@layus
Copy link
Contributor Author

layus commented Mar 13, 2017

@Profpatsch I got the same error. This is not an error actually. This means that the application failed before printing its last error (killed with non-emtpy error buffers). I solved it by enabling hardware.opengl.driSupport32Bit

@Profpatsch
Copy link
Member

Profpatsch commented Mar 14, 2017

I solved it by enabling hardware.opengl.driSupport32Bit

It’s enabled here, doesn’t work.

Update: Ah, it starts with a black screen, after a while that screen closes but the music starts. So the game is running, but no image.

chmod 755 $out/bin/antichamber
'';

meta.platforms = lib.platforms.linux32;
Copy link
Member

@aszlig aszlig Jul 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the package only works on i686-linux but doesn't work on x86_64-linux?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's indeed a mistake.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please drop this then?


# Unpack binaries and data into $dest
mkdir -p "$dest"
${unzip}/bin/unzip $src "data/*" -d $dest && [ $? -le 2 ]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about unpackCmd = "${unzip}/bin/unzip -d \"$name\" \"$curSrc\" 'data/*'"; instead of throwing everything into installPhase?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even better: just unzip the data folder, so no -d is needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's an habit I started with archlinux & AUR. I want to unzip in $dest because it is in the nix store partition, while $CWD will be on a temporary partition. For big binary/data archives, this is faster because it remains on the same partition, and mv operations are mostly immediate.

This could however go in the unpackPhase, but the generic build script requires the unpack phase to unpack into the temporary directory used for the build.
It is truly an install phase, unpack is only needed for sources before compilation. There is no such thing here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, fair enough, for very large files this would take ages.

cat > $out/bin/antichamber <<EOF
#!${stdenv_32bit.shell}
cd $dest/Binaries/Linux/
exec ./UDKGame-Linux "$@"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does this game place its save files or similar state? I've found that most games are trying to use the current directory as the base directory. In this case it's a store path, which will be read-only on NixOS.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It uses $HOME, probably via XDG. Setting $CWD is recquired for the game to find data files with a relative path.

# Unpack binaries and data into $dest
mkdir -p "$dest"
${unzip}/bin/unzip $src "data/*" -d $dest && [ $? -le 2 ]
mv $dest/data/*/* $dest
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd assume here that data/* is just a single directory, right? If yes, see the above comment about unzip, which in this case would make even more sense to pass that subdirectory to unzip.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it's directories + files, but I only want the directories (no readme and installer stuffs)

@layus
Copy link
Contributor Author

layus commented Jul 24, 2017

Apparently this was merged as-is in 1fcecd0 by @Profpatsch (with wrong attribution to @aszlig). Forget all the comments here then.

@Profpatsch If you still have issues with this game, you should definitely try to start it on its own Xephyr instance. This is often sufficient for me to access the menu and disable fullscreen. Then I can start is normally. I used to think it was related to i3. Wath is your window manager ?

@layus layus closed this Jul 24, 2017
Profpatsch added a commit that referenced this pull request Jul 24, 2017
This reverts commit 1fcecd0.
It was written by @layus and the code came from PR #14.
@Profpatsch
Copy link
Member

Ah, right. I still had it lying in my working directory and thought it was an old code snippet from @aszlig.
I reverted the commit in b44d56e, so we can merge this.

@Profpatsch Profpatsch reopened this Jul 24, 2017
Copy link
Member

@aszlig aszlig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, was going to merge this, but I found a few issues left. Can you please address them? Thanks in advance :-)

chmod 755 $out/bin/antichamber
'';

meta.platforms = lib.platforms.linux32;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please drop this then?

@@ -0,0 +1,58 @@
{ stdenv, stdenv_32bit, lib, pkgsi686Linux, fetchHumbleBundle, unzip}:

stdenv_32bit.mkDerivation rec {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you using stdenv_32bit here? You're already using callPackage_i686 which already passes pkgsi686Linux function arguments. Thus stdenv_32bit is equal to stdenv (if no callPackage_i686 was used, it would use multilib).

Copy link
Contributor Author

@layus layus Jul 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the correct way to handle this then ? What is the purpose of "callPackage_i686" ?
Is multilib not what we want on 64bit arch ?

libpulseaudio
libvorbis
libogg
mesa
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add these dependencies to the package function arguments explicitly.

@layus
Copy link
Contributor Author

layus commented Jul 24, 2017

@aszlig Updated, thanks :-)

@aszlig aszlig self-assigned this Jul 28, 2017
@aszlig aszlig merged commit 78eb977 into openlab-aux:master Jul 28, 2017
aszlig added a commit that referenced this pull request Jul 28, 2017
Pull request is from @layus and I haven't tested the game, because I
don't own it myself, but apparently @Profpatsch seems to got it working
to the point of having a black screen, but that could be a rendering
issue.

So I'm merging this anyway, because even if only one person (@layus) is
going to play it, it won't hurt and if multiple people using the
expressions we probably get bug reports :-)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants