ZSNES 1.51b Experimental Linux Binaries

General area for talk about ZSNES. The best place to ask for related questions as well as troubleshooting.

Moderator: ZSNES Mods

odditude
Official tech support dood
Posts: 2118
Joined: Wed Jan 25, 2006 7:57 am

Re: ZSNES 1.51b Experimental Linux Binaries

Post by odditude »

~ refers to the home directory; therefore, ~/.zsnes is a directory named .zsnes which is located in the home directory.

~/.zsnes is marked as hidden because of its name - in *nix-based systems, filenames preceded by a period are hidden. zsnes the application is well aware of and capable of accessing ~/.zsnes; that is not your problem.

as has been reiterated many times, check your capitalization (usage of uppercase/lowercase letters). in *nix-based systems, filenames are case-sensitive (.ZSNES is NOT the same as .zsnes, or .Zsnes, or .zSnes, etc).
Why yes, my shift key *IS* broken.
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Re: ZSNES 1.51b Experimental Linux Binaries

Post by Deathlike2 »

Learning how your OS works is key to learning how things work...

Files are created, read, modified in hidden folders all the time.

You can define a cheat folder if you want to via the paths section... although it is best to manually to edit ~/.zsnes/zsnes.cfg (or was it zsnesl.cfg) and edit the path there (with a text editor). Case sensitivity (folder "ZSNES" is different from folder "zsnes" in Linux) is better dealt with via the cfg file as the GUI cannot differentiate for you (the path will always appears in caps in that menu).
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
oldschool_BR

Re: ZSNES 1.51b Experimental Linux Binaries

Post by oldschool_BR »

Hey. Here is my experience with the beta code there, and the original one.

I am using Slackware 31.1, with multilib support. The processor is an Intel i5 and the card is a nVidia GeForce GTS 450, with nVidia drivers installed.

I started trying the release code (1.51), and got warnings and errors due to using a more recent GCC version. After getting it sorted out (sort of!), I have realized I was missing libao. Thanks for this topic here. So I had downloaded them and proceeded to installing them the way it seemed it should work for multilib slackware: 1) ./configure, make, make install, . /etc/profile.d/32dev.sh, ./configure, make, make install. In the process, I had noticed the 64 arch libraries were being installed in the wrong directories: multilib Slackware has all 64-bit libraries on /lib64 (lib64, /usr/lib64, etc.) and the 32-bit ones on the usual /lib ones. I moved them to the proper places and proceeded with the 32-bit installation.

After libao was installed, I have tried the Zsnes binary from here, but got a segfault immediately. Then I have tried compiling it with the sources and got segfault still. Then I have tried editing the base Makefiles from both libao and ZSnes to make sure things would get compiled with 32-bit only (and 64-bit only for the 64-bit libao installation). And I still got a segfault: there were other Makefiles further directories and those hadn't been fixed. That was yesterday and as soon as I realized the problem, I gave up. Today, with a bit more motivation, I decided to try it all over again and see if I could find issues that would generate the segfaults, which probably were different library versions (64 and 32). I sarted with libao (version 1.0.0). Only today I have learned I should edit the base config.status files, not the Makefiles individually. So I have first installed libao 64 and made sure all libs would be sent bit64 directories and the ones being read were also from lib64 ones. For whatever reason, I have also changed x86_64-unknown-linux-gnu to x86_64-slackware-linux-gnu. Installed it, then used the 32dev.sh script for getting Slack ready for 32-bit compilations and did the same, this time ensuring only lib directories would be used. This was done in a similar way: opening config.status changing lib64s to lib. There were a directory which would not exist in the search path if I changed it from lib64 to lib, which was /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/32. I have left it this way but moved it to the far right so as to be the last directory to be searched. One must notice the should remain 64-bit, though: x86_64 must be left that way. If it is not, then it must be changed.

I then went for ZSNES, and did similar steps: configured the directory for the Makefiles and config.status to appear and edited the config.status file to ensure lib directories only and x86_64 CPU architecture. Installed, and sort of success: the file ran. I could play some Japanese Castlevania, even. There is, however, still a problem: if I switch to full screen mode and do not get back to normal screen before closing the program, I will get a full black screen but by a mouse pointer. I got no idea how to fix that, if I even can.

So the steps on Slackware 64 would be
  • make the system multilib (see link above);
  • install the video card drivers from the manufacturer again and say yes for 32-bit support
  • download libao;
  • run configure and then edit config.status and change all lib directories to lib64 for 64-bit version; distclean, configure and edit it again with only lib directories for the 32-bit version;
  • get the 1.51b version from nach, ./configure and edit the config.status accordingly.
Unfortunately the multilib distributions have not agreed on a standard, and worse that some chosen to make it incompatible with previous binaries by placing 64-bit libraries in /lib and such. As Slackware (and I would suppose some other distro too) has them all on different directories under / with lib64 for 64-bit, it would be nice if the configures could detect these differences and set up the Makefiles and confs accordingly. Naturally, it is a hassle for the maintainer/developers, but I guess it will make the software installation more appealing to new Linux users.

Finally, thanks to zsKnight and _Demo_ for ZSNES (I have been a user for many years) and to pagefault, Nach and all others for keeping it alive.
nu1x
New Member
Posts: 2
Joined: Sat Oct 30, 2010 3:34 am

Re: ZSNES 1.51b Experimental Linux Binaries

Post by nu1x »

Some working 1.51b source modification grinvader made (with my minor cooperation, as in using my system).

IT IS FOR DEBIAN UNSTABLE FOR x86_64

What you need is

1. Have the necessary libraries, which are:
g++-multilib
gcc-multilib
ia32-libs
ia32-libs-dev
libncurses5-dev
libsdl1.2-dev
zlib1g-dev
libpng12-dev
xorg-dev
libgl1-mesa-dev

also

nasm, gcc4.4, g++4.4, autoconf, automake, autotools-dev

also, I think you need the ia32 versions of your graphics card drivers, if you're using fglrx or nvidia binaries.

This is part of my configure output:
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for nasm... nasm
checking for sdl-config... /usr/bin/sdl-config
checking for SDL - version >= 1.2.0... yes
checking for zlib - version >= 1.2.3... yes
checking for libpng - version >= 1.2.0... yes
checking if you want libao support... no
checking how to run the C preprocessor... gcc -E
checking for X... libraries , headers
checking for glGetError in -lGL... yes
checking for OpenGL... yes
checking if you want the zsnes Qt debugger... no
checking for JMA support... yes

2. Download zsnes 1.51b source.
2a. Extract the source.

3. Download the modified configure files zsnes151bsrc-debian-unstable-x86_64-configure.tar.bz2.
3a. tar jxvf zsnes151bsrc-debian-unstable-x86_64-configure.tar.bz2; place files in $your_zsnes_source/src folder.

4. cd $your_zsnes_source/src

5. ./autogen.sh --disable-qtd --disable-debugger
5a. You can also add --enable-release for better optimization.

6. make && make install
6a. Optionally sudo make install


That's it. It has no libao support though, I am not really sure what needs to be done under debian unstable to make it work.
The resulting binary works for me, while somewhat crashy at certain conditions; also, grinvader advised to change video modes in .zsnes/zsnesl.cfg, not by gui.

YMMV
Last edited by nu1x on Tue Dec 21, 2010 4:04 pm, edited 1 time in total.
dfreer
Lurker
Posts: 139
Joined: Fri May 11, 2007 5:28 am

Re: ZSNES 1.51b Experimental Linux Binaries

Post by dfreer »

aptitude install libao2-dev
./configure --enable-libao

My guess.
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Re: ZSNES 1.51b Experimental Linux Binaries

Post by grinvader »

The problem, dfreer, is to 1- grab the 32bits one (which should be in ia32-libs), and 2- more importantly, how to make them used at compile time (they're in a weird path apparently)
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
dfreer
Lurker
Posts: 139
Joined: Fri May 11, 2007 5:28 am

Re: ZSNES 1.51b Experimental Linux Binaries

Post by dfreer »

My bad grinvader, failure to read. Have you guys tried manually unpacking the i386 version of libao-dev and placing/sys linking the .a/.la files in /usr/lib/ao/plugins-4/? Guess I'll load up a virtual machine myself and give it a try.

EDIT: Ubuntu 10.10 doesn't like it, which for some reason I used first. Will give debian a go in a bit.
Post Reply