Frogcomposband: sound?

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • anselmus
    replied
    Originally posted by backwardsEric
    The GCU and X11 front ends aren't using sound.cfg; I didn't check the other front ends. They use the name associated with the sound ("hit" for instance) with ".wav" appended as the name of the file to load. Modifying the source code - probably something shared that each front end can call to do the initialization (parsing of sound.cfg) and to query for the sound file to play on a specific event - is the cleanest solution.

    An alternative would be to hack it so for instance, hit.wav, is a placeholder (either a symbolic link to one of other "hit" sound files or a copy) and the script to play the sound randomly swaps in one of the other files (by changing the link or copying over) based on what's in sound.cfg before playing the sound. That would avoid having to change the .c files. It wouldn't work well in a multi-user environment (more than one game running using the same shared game configuration directory) without extra care taken when doing the file swaps.
    Thanks!

    I have found "a solution" (more or less of the second type you have proposed, I think). I don't know how good (very "clean" of course not), but it seems to work. The script would be the following:

    #!/bin/sh

    if [ "$1" != "" ]; then
    RANDOM=$$
    for i in 'seq 1'
    do
    R=$(($RANDOM%5))
    done
    aplay -q $1.repo/$R.wav
    fi

    Then, what I have done is create a series of folders in './lib/xtra/sound/' called 'shutdown.wav.repo', 'opendoor.wav.repo', 'hit.wav.repo' etc., and within those folders, the audio files, renamed: '1.wav', '2.wav', '3.wav' etc. It works well. Surely from there you can improve the method, but, for now, there it is! XD

    Leave a comment:


  • backwardsEric
    replied
    The GCU and X11 front ends aren't using sound.cfg; I didn't check the other front ends. They use the name associated with the sound ("hit" for instance) with ".wav" appended as the name of the file to load. Modifying the source code - probably something shared that each front end can call to do the initialization (parsing of sound.cfg) and to query for the sound file to play on a specific event - is the cleanest solution.

    An alternative would be to hack it so for instance, hit.wav, is a placeholder (either a symbolic link to one of other "hit" sound files or a copy) and the script to play the sound randomly swaps in one of the other files (by changing the link or copying over) based on what's in sound.cfg before playing the sound. That would avoid having to change the .c files. It wouldn't work well in a multi-user environment (more than one game running using the same shared game configuration directory) without extra care taken when doing the file swaps.

    Leave a comment:


  • anselmus
    replied
    I'm making an "easy to install" sound-pack for Frogcomposband. The sound scripts (thanks to Sideways and backwardsEric) works pretty well. By the way: running the game with gcu the 'aplay' command needs to be executed with '-q' option, otherwise you get the 'aplay' output messages on the game mainscreen, so, my gcusound.sh (in ./src) looks like this:

    #!/bin/sh

    if test X"$1" != X ; then
    exec aplay "$1" -q
    fi
    exit 1

    The "sound engine" of the game seems to be very limited, but I'm trying to get the most out of it. The delay problem is not, in fact, such a problem: when you attack monsters, for example, each blow result (e.g.: You miss. You miss. You hit.) is printed synchronously (in ordinal/chronological order) with the sound, which is, for my taste at least, interesting, because this way you know at all times, by ear, when your character has impacted and when failed, and it is more difficult to miss relevant information.

    Now, according to sound.cfg and readme file, it's possible to assign more than one sound sample for each sound event (e.g.: hit = hit.wav hit1.wav hit2.wav), so I understand that the game triggers randomly one sound sample from the avaibles/defined samples when any of the defined events happens, but I'm not getting the expected result. I have assign different sounds for the same event, but the game plays only the first one defined for each event. That is to say: I've, for example, five different sounds for 'hit' event (hit.wav, hit1.wav, hit2.wav, hit3.wav, hit4.wav) defined on Makefile and sound.cfg files, I compile the game with no errors, but in game, when my character hits, only sounds hit.wav.

    Any clue about this?

    Thanks you very much in advance

    Leave a comment:


  • Sideways
    replied
    Thanks to backwardsEric for bringing actual knowledge to the table

    Unfortunately, fixing all the problems with the sound system (for every platform no less) would likely require rewriting it from scratch with proper code.

    Leave a comment:


  • backwardsEric
    replied
    Originally posted by anselmus
    Thanks backwardsEric. I just read now your message. With this script I get an error:

    ./playwave.sh: 3: ./playwave.sh: text: not found
    There was a typo in my reply; replace "text" with "test" and that script should work.

    For your question about why the modified Makefile worked and the original did not, the answer is likely that the original did not install the sound files (*.wav). If the game checks if the sound file exists before trying to run the playwave.sh script, then you wouldn't see the message about the script. The modified version installs the sound files.

    Leave a comment:


  • anselmus
    replied
    I discovered something. Trying to compile again the game, suddenly the sound doesn't work again, even with the script, but there is no error calling to playwave.sh.

    The problem seems to be with the 'Makefile' file, in "./lib/xtra/sound/". It seems that last time I've overwrite by mistake with other 'Makefile'. The script works (and the error 'sh: 1: ./playwave.sh: not found' happens again) with this 'Makefile':
    MKPATH=../../../mk/
    include $(MKPATH)buildsys.mk

    LIBDATA = sound.cfg breath.wav clunk.wav death.wav destroy.wav \
    drop.wav eat.wav flee.wav hallu.wav hit.wav hit1.wav kill.wav \
    kill1.wav level.wav miss.wav miss1.wav money.wav opendoor.wav \
    shutdoor.wav thump.wav vomit.wav \

    PACKAGE = xtra/sound
    but doesn't work with the "original" 'Makefile' from Frogcomposband 7.1.liquorice, that is:

    MKPATH=../../../mk/
    include $(MKPATH)buildsys.mk

    DATA = sound.cfg
    PACKAGE = xtra/sound

    Leave a comment:


  • anselmus
    replied
    Originally posted by backwardsEric
    Sideways' script looks pretty good. I'd use

    Code:
    #!/bin/sh
    
    if text X"$1" != X ; then
        exec aplay "$1"
    fi
    exit 1
    Put that in playwave.sh in the same directory as the frogcomposband executable and run

    Code:
    chmod a+x playwave.sh
    on it to make it executable.
    Thanks backwardsEric. I just read now your message. With this script I get an error:

    ./playwave.sh: 3: ./playwave.sh: text: not found

    Leave a comment:


  • anselmus
    replied
    Originally posted by Sideways
    That sounds like an X11-specific problem, I can see what the problem is (it's telling the system to run a non-existent shell script) and the solution presumably involves fixing its nonexistence, unfortunately I'm a fake programmer who don't speak .sh. How do you normally play .wav files from the command line?

    My instinct is that a playwave.sh that looked about like this should work:

    Code:
    #!/bin/sh
    
    if [ "$1" != "" ]; then
    aplay $1
    fi
    But we probably have dozens of people here who know how it's actually done, hopefully this horror-movie script will induce some input from them.
    Thanks you very much for your time, Sideways. Your horror-movie script is magic! Works!

    I usually play wav files from terminal with 'play' command (from 'sox' package), but the script works with 'aplay' too.

    For gcu the game calls to gcusound.sh, so I've done two scripts, gcusound.sh and playwave.sh with your entry.

    However, this "script method" has a drawback: graphics are refreshed at the end of the sound, not at the beginning: I mean: when my @ open's a door, I can hear the sound but the door doesn't open until the sound is over, so the animations looks with delay.

    Maybe you have another horror-movie instinct to fix this... Anyways, I'll do some research. Thanks again.

    Leave a comment:


  • backwardsEric
    replied
    Sideways' script looks pretty good. I'd use

    Code:
    #!/bin/sh
    
    if test X"$1" != X ; then
        exec aplay "$1"
    fi
    exit 1
    Put that in playwave.sh in the same directory as the frogcomposband executable and run

    Code:
    chmod a+x playwave.sh
    on it to make it executable.
    Last edited by backwardsEric; April 16, 2020, 02:05. Reason: typo; text instead of intended test

    Leave a comment:


  • Sideways
    replied
    That sounds like an X11-specific problem, I can see what the problem is (it's telling the system to run a non-existent shell script) and the solution presumably involves fixing its nonexistence, unfortunately I'm a fake programmer who don't speak .sh. How do you normally play .wav files from the command line?

    My instinct is that a playwave.sh that looked about like this should work:

    Code:
    #!/bin/sh
    
    if [ "$1" != "" ]; then
    aplay $1
    fi
    But we probably have dozens of people here who know how it's actually done, hopefully this horror-movie script will induce some input from them.

    Leave a comment:


  • anselmus
    replied
    Originally posted by Sideways
    The .o files are created when you compile, of course there are 1000s of differences between FrogComposband and PosChengband, but the ones that concern use_sound specifically will disappear after you (successfully) compile with USE_SOUND defined in z-config.h. (If they don't, that means the compile itself was flawed, try compiling with "make clean" or manually delete all .o files before compiling.)
    My mistake: yes, .o files that I checked were made after compiling.

    Now: I try with 'make clean' but it's the same. But I noticed something new: if I launch the game with './frogcomposband -v', there is an ouput on the terminal each time the game should trigger a sound:

    sh: 1: ./playwave.sh: not found

    Maybe I'm doing something wrong on compile process (or maybe have I to define something like default paths somewhere?). I'm following this steps:
    $ sh ./autogen.sh
    $ ./configure --with-no-install [I've tried with --enable-sdl-mixer too]
    $ make

    and then I launch the game from /src folder with

    $ ./frogcomposband -mgcu [or -mx11]

    Leave a comment:


  • Sideways
    replied
    The .o files are created when you compile, of course there are 1000s of differences between FrogComposband and PosChengband, but the ones that concern use_sound specifically will disappear after you (successfully) compile with USE_SOUND defined in z-config.h. (If they don't, that means the compile itself was flawed, try compiling with "make clean" or manually delete all .o files before compiling.)

    Leave a comment:


  • anselmus
    replied
    Originally posted by Sideways
    "#define USE_SOUND" is already commented out. You have to make it not be commented out - remove the /* and */ around #define USE_SOUND in z-config.h, then compile. (PosChengband 7.2.1 has made this exact change, that's the reason you're seeing different behavior there.)
    Yes, sorry, this is what I'm doing. Removing the /* and */ around. Like this:

    ...

    #ifdef USE_SPECIAL

    /*
    * OPTION: Allow the use of "sound" in various places.
    */
    #define USE_SOUND

    /*
    * OPTION: Allow the use of "graphics" in various places
    */
    #define USE_GRAPHICS

    ...

    Edit: Oh, another thing: I don't know if it's relevant, but differences I noticed between *.o files on Frogcomposband and PosChengband are checked before compile process
    Last edited by anselmus; April 15, 2020, 19:28.

    Leave a comment:


  • Sideways
    replied
    "#define USE_SOUND" is already commented out. You have to make it not be commented out - remove the /* and */ around #define USE_SOUND in z-config.h, then compile. (PosChengband 7.2.1 has made this exact change, that's the reason you're seeing different behavior there.)
    Last edited by Sideways; April 15, 2020, 19:02.

    Leave a comment:


  • anselmus
    replied
    Originally posted by Sideways
    You are the second player in the last few days, and also the second in the last few years, to ask about the sounds Are sounds the latest in thing?

    The only sound in the game "as is" is an audible error bell which you can turn on in the disturbance options, there are no other sounds. However, the game can theoretically support a large variety of other sounds, it's just that there are no actual sound files and USE_SOUND is commented out in the source code.

    What you should be able to do is get the FrogComposband source (any version, but the latest dev version on github is the most up-to-date), locate the bit in z-config.h where "#define USE_SOUND" is commented out, move it out of the comment, recompile, then add your own .wav files and map them to game events in sound.cfg. (As you can probably guess, this hasn't been tested very extensively... but it ought to not break the game.)

    Thanks a lot, Sideways.

    About make the sound work on Frogcomposband:

    maybe I'm doing something wrong: I have tried commenting out 'define USE_SOUND' but it seems does not work (no errors output when 'make'). Looking the source files (stating that my programming skills are very basic) and doing some test (by trial/error method) I've noticed some ¿strange things?: Frogcomposband (v. 7.0 and 7.1 at least) has very similar code than Poschengband v7.2.1, but there are some differences on the use of 'use_sound' term that might be in relation with this question. If I do a search with 'grep' command for 'use_sound', I have the same results with Frogcomposband code and Poschengband code (the term 'use_sound' appears on same files and is commented by default in the same lines), but, in Poschengband case, grep says that 'use_sound' is present on some binary files and in Frogcomposband case not: specificaly, 'use_sound' appears (in Poschengband 7.1), in 'main-x11.o', 'poschengband.exe', 'util.o', 'variable.o', and 'main-gcu.o', but in Frogcomposband, in these files is not present 'use_sound'. Sounds works with Poschengband v.7.2.1, on Windows version at least, but I'm not able to make it work when I compile Linux version. I guess sound it's possible to make it work on Linux because on most vanilla versions of Angband it is working. I've check the dependencies, but my system seems to have installed all of them. I'm pretty sure that I'm leaving out something obvious, but I don't know what!

    Any clues?

    About the interest of sounds themself (and specially for ascii games):

    In short: I think/feel that "hearing" it's "touching" in no different meaning than touching "with hands". It depends, obviously, on the fidelity/quality of the sounds sources/medias. Graphics are less important, in my opinion, for this: the interest about ascii graphics is that, when you start seeing things, not the symbols of things, you have a very wide range for feel/imagine (automatically; I mean: subconscious) the surrounding world of the game, but, in the other hand, this range is too wide in terms of immersion. So, yes: I think/feel that reasonable quality sounds + ascii graphics it's "the latest in things"!! XD (at least "the latest in videogame things"). Less abstract graphics than ascii are better for a fast immersion (they are symbols too, but more "usual", so better for selling huge copies of the same old crap), but these kind of graphics narrow the range for feel/imagine worlds too much, and good quality sounds can't do nothing to counter it (it's more difficult expand limits than cut them). It's an opinion, just my experience. Anyway, if you try Cataclysm DDA, for example, with ascii and a decent soundpack, it's brutal: very hard to forget the impression of this experience.

    Leave a comment:

Working...
😀
😂
🥰
😘
🤢
😎
😞
😡
👍
👎