Can't start sdl version

Pajarico · Post by **Pajarico** » Fri Jan 28, 2005 5:53 pm

This is when i try to start r'n'd:

lxuser@localhost lxuser $ rocksndiamonds.sdl
rocksndiamonds.sdl: gadget incomplete (missing Bitmap)
rocksndiamonds.sdl: aborting

Post by **Holger** » Fri Jan 28, 2005 6:57 pm

Where does this file "rocksndiamonds.sdl" come from? (I ask because the pre-compiled as well as the compiled-from-source binary normally is "rocksndiamonds", so something non-standard seems to be involved here.)

Which version of R'n'D are you using? The "stable" version 3.1.0, or one of the "release-candidate" versions 3.2.0-rc1 or -rc2?

Pajarico · Post by **Pajarico** » Fri Jan 28, 2005 7:10 pm

Is compiled from source, version 3.1.0.

Actually there is no such 'rocksndiamonds' binary, the only executables produced are rocksndiamonds.sdl and rocksndiamonds.x11. Probably you have an alias for your bash or maybe a script called 'rocksndiamonds' that executes the real binary.
Do a "which rocksndiamonds" and see where it's pointing.

Flumminator · Post by **Flumminator** » Fri Jan 28, 2005 7:59 pm

the naming convention sounds a bit familiar to me.
Gentoo uses to compile both SDL and X11 versions and calls them rocksndiamonds.sdl and rocksndiamonds.x11 repectively.

But both work fine on my system.

Are you using Gentoo, or have you compiled it by hand?
Does the X11-version work?

Guest · Post by **Guest** » Fri Jan 28, 2005 11:40 pm

Yes, i'm using gentoo, and yes it does compile both X and sdl versions.
X works well, but for some reason (long to explain) i need the sdl version.

Post by **Holger** » Fri Jan 28, 2005 11:49 pm

> Probably you have an alias for your bash or maybe a script called 'rocksndiamonds' that
> executes the real binary. Do a "which rocksndiamonds" and see where it's pointing.

Well, no, I only have a file "rocksndiamonds". (I'm really sure here; after all, I'm the programmer of that thingie... =;-) )

> Yes, i'm using gentoo, and yes it does compile both X and sdl versions.

Interesting to know...

> X works well, but for some reason (long to explain) i need the sdl version.

In fact, the SDL version should more or less considered to be the "main" version now. (And if only for the fact that it is the only version that supports fullscreen and MOD music, which add a lot to the overall experience of the game.) The X11 version is expecially fine for exotic Unix systems and to get the maximum graphics performance possible (important for older, slower systems).

Even if Gentoo works fine for you otherwise, you might have better success in this case and might therefore try to get the original 3.1.0 source archive and rebuild from the unmodified sources. A simple "make clean; make sdl" should do the job. :-)

Guest · Post by **Guest** » Sat Jan 29, 2005 12:03 am

Even if Gentoo works fine for you otherwise, you might have better success in this case and might therefore try to get the original 3.1.0 source archive and rebuild from the unmodified sources. A simple "make clean; make sdl" should do the job.

Sorry, but why should i do that? As far as i know what gentoo does is exactly that.

Post by **Holger** » Sat Jan 29, 2005 12:49 am

> Sorry, but why should i do that? As far as i know what gentoo does is exactly that.

As I don't know what other things the Gentoo package maintainer for R'n'D might have changed besides adding the two different Makefile targets (with different resulting binary file names), it might just be worth trying to build it from the original source package in this case...

Guest · Post by **Guest** » Sat Jan 29, 2005 1:14 am

Checked the ebuild (the script that automatizes the compilation), and i don't see anything far from normal, just unpacks, cd into dir and make.

Code: Select all

src_unpack() {
        unpack ${P}.tar.gz
        cd ${S}
        unpack rockslevels-emc-1.0.tar.gz
        unpack rockslevels-sp-1.0.tar.gz
        unpack rockslevels-dx-1.0.tar.gz

        # make it parallel-friendly.
        sed -i \
                -e 's:\$(MAKE_CMD):$(MAKE) -C $(SRC_DIR):' \
                -e '/^MAKE/d' Makefile \
                || die "sed Makefile failed"

        cd levels
        unpack rnd_jue-v5.zip
        unpack BD2K3-1.0.0.zip
}

src_compile() {
        replace-cpu-flags k6 k6-1 k6-2 i586

        local makeopts="RO_GAME_DIR=${GAMES_DATADIR}/${PN} RW_GAME_DIR=${GAMES_STATEDIR}/${PN}"
        if use X || { ! use X && ! use sdl; } ; then
                make clean || die
                emake ${makeopts} OPTIONS="${CFLAGS}" x11 || die
                mv rocksndiamonds{,.x11}
        fi
        if use sdl ; then
                make clean || die
                emake ${makeopts} OPTIONS="${CFLAGS}" sdl || die
                mv rocksndiamonds{,.sdl}
        fi
}

src_install() {
        dogamesbin rocksndiamonds.{sdl,x11} || die "dogamesbin failed"
        dodir "${GAMES_DATADIR}/${PN}"
        cp -R graphics levels music sounds ${D}/${GAMES_DATADIR}/${PN}/ \
                || die "cp failed"

        newman rocksndiamonds.{1,6}
        dodoc CHANGES CREDITS HARDWARE README TODO docs/elements/*.txt

        prepgamesdirs
}

Post by **Holger** » Sat Jan 29, 2005 1:50 am

Looks very interesting! Maybe I should also try Gentoo Linux instead of Debian (which I want to use for my next PC I plan to buy -- on my current system, I use a mixture of an old SuSE and a lot of self-compiled stuff). :-)

But you are right: I don't see what might have caused the SDL problem here that could be fixed by using the original package, as the original package *is* indeed used here. Until now, I thought that Gentoo would use some sort of modified package (like most if not all other distributions do), but it indeed just uses the original. That's very cool! (Although it does not solve your problem...)

Sorry that I have no idea at the moment why the SDL version fails while the X11 version works for you... :-(

Guest · Post by **Guest** » Sat Jan 29, 2005 11:39 am

Exactly, sometimes the script applies some patches and modifications to prevent security holes and fix bug, but this is not the case. The code downloaded is the same that you can get in your page.

So, how can i help you? is there some way to debug the program and send you a bug report?
The error message is not very helpful to me.

Post by **Holger** » Sat Jan 29, 2005 1:27 pm

> So, how can i help you? is there some way to debug the program and send you a bug report?
> The error message is not very helpful to me.

Unfortunately, to me neither. :-(

This error message indicates that some part of the program tried to initialize a "gadget" (button, scrollbar, etc.) and did not provide any bitmap for displaying it. This is usually only an internal error that might show up while developing (when I forgot to specify a bitmap for a new gadget); it should usually never show up later once it worked -- if a real graphic (PCX) file is missing, this gets caught earlier in the code.

What might help would be a stack trace when the error occurs -- this could be achieved by setting a break point with a debugger in line 992 of source file "src/libgame/gadgets.c" (or by adding a division by zero command directly before the call of 'Error(ERR_EXIT, "gadget incomplete (missing Bitmap)");', like adding "{ int x = 1 / 0; Error(...); }", and after the illegal statement was caught by the debugger, typing "bt" for a stack backtrace in "gdb" for example).

This stack trace might help localizing the error...

Pajarico · Post by **Pajarico** » Sat Jan 29, 2005 3:03 pm

Well, downloaded the source and edited line 992 of source file "src/libgame/gadgets.c" from this:

Code: Select all

Error(ERR_EXIT, "gadget incomplete (missing Bitmap)");

to this:

Code: Select all

{ int x = 1 / 0; Error(ERR_EXIT, "gadget incomplete (missing Bitmap)");

But when i do 'make' :

Code: Select all

lxuser@localhost rocksndiamonds-3.1.0 $ make
make[1]: Entering directory `/home/lxuser/COMPILATION/rocksndiamonds-3.1.0/src'
make[2]: Entering directory `/home/lxuser/COMPILATION/rocksndiamonds-3.1.0/src/libgame'
gcc   -Wall                      -DTARGET_SDL -I/usr/include/SDL -D_REENTRANT       -c system.c
gcc   -Wall                      -DTARGET_SDL -I/usr/include/SDL -D_REENTRANT       -c gadgets.c
gadgets.c: In function `HandleGadgetTags':
gadgets.c:992: warning: division by zero
gadgets.c:992: warning: unused variable `x'
gadgets.c:2009: error: parse error at end of input
make[2]: *** [gadgets.o] Error 1
make[2]: Leaving directory `/home/lxuser/COMPILATION/rocksndiamonds-3.1.0/src/libgame'
make[1]: *** [libgame_dir] Error 2
make[1]: Leaving directory `/home/lxuser/COMPILATION/rocksndiamonds-3.1.0/src'
make: *** [all] Error 2

So no binary is produced therefore i can't use gdb.
Am i doing something wrong?

Guest · Post by **Guest** » Wed Feb 02, 2005 11:22 pm

> Am i doing something wrong?

Argh. It seems that newer versions of gcc (I'm still using version 2.95.2) try to prevent the programmer from creating bad code. In my opinion, this should only generate a warning, but not an error. Oh well...

You could try to hide that statement a bit more to trick the compiler...

But I have another idea: Please start the game with the option "-v" (verbose) -- this should generate warnings that can give us a hint what went wrong. I've just had the same error when testing some things -- this error can happen when you try to use a level set with undefined artwork. Which one it is can hopefully be found out using "-v".

Flumminator · Post by **Flumminator** » Thu Feb 03, 2005 11:23 am

Obvious errors like this one can (and should) easily be detected during compilation.

Why not set a breakpoint on 'Error'?