GCW-Zero port

[carstene1ns]

(This is a follow-up to issue #273)

Needed things:

• source code modifications (patch for sdl_listmodes, ...)
• toolchain file (provided by the gcw0-buildroot)
• .desktop launcher file (builds/gcw-zero/default.gcw0.desktop)
• opk build script (builds/gcw-zero/make_opk.sh)
• cmake target for the cdogs-sdl.opk generation (optional)
• documentation

[DavidKnight247]

I've released the gcw build. source is included in the opk. Link to release thread: http://boards.dingoonity.org/gcw-releases/c-dogs-sdl/
I need to tidy up the sourcecode as I have simply changed the values as required. Sorry for this!

1. Current modified files:
   src/mainmenu.c
   commented out redundant menu options:
   lines 412-433 (set res and set scale)

src/menu.c
Changed line 258 to correct for gcw keymap
"(use joystick or D pad + START + SELECT)", Vec2iZero(), opts);

src/cdogs/gamedata.c (commented out loadSongList as already noted)

src/cdogs/config.c
changed lines 401-2 to better suit gcw layout:
config->Input.PlayerKeys[0].Keys.button1 = SDLK_LCTRL;
config->Input.PlayerKeys[0].Keys.button2 = SDLK_LALT;

src/cdogs/grafx.c
Forced hwsurface and triplebuf line 318 (could also be set as flags earlier in the code of course). SWSURFACE causes tearing.
device->screen = SDL_SetVideoMode(rw, rh, 32, SDL_HWSURFACE|SDL_TRIPLEBUF);

2. I included a shell script to execute in the root directory:
   start.sh:
   #! /bin/sh
   cd src
   exec ./cdogs-sdl --screen=320x240 --scale=1

3)included Desktop file (icon location will need changing of course)
default.GCW0.desktop
[Desktop Entry]
Name=C-Dogs SDL
Type=Application
Exec=start.sh
Icon=cdogs-icon.32
Comment=The C-Dogs SDL Game
Terminal=false
Categories=games;
X-OD-Manual=readme_gcw.txt

4. included readme readme_gcw.txt

5)built opk:
mksquashfs cdogs cdogs.opk -all-root -noappend -no-exports -no-xattrs

[cxong]

I can make the code changes under an #ifdef __GCW0__; without the console myself I couldn't test this though so I'll need your help @DavidKnight247 . Also do you know if this build also works on dingoo?

[cxong]

@DavidKnight247 can you send a photo of the game running on a GCW Zero? would be fun to share 😉

[DavidKnight247]

No problem, I monitor this thread. Just tell me what to do ;)
In the past dingux builds worked with the gcw, but as the OS has developed compatibility between them has been broken to some degree. There is a chance it will work but I would no longer bank on it.

PS as of today the gcw0 now supports rumble. If it's ok with you I'd love to implement support when screen shake is called. That would be awesome!
http://boards.dingoonity.org/gcw-releases/opendingux-update-2014-08-20/
EDIT just looked, it uses the SDL2.0 command SDL_haptic. Would this rule it out of inclusion?
https://wiki.libsdl.org/CategoryForceFeedback

[cxong]

@DavidKnight247 Force feedback has been on the list #172 but as you've seen, it requires SDL 2 #169
I'd like to do these eventually anyway, but there are a few big tasks that are more important so it won't happen soon 😦

[carstene1ns]

About the hardware specific ifdef (for example ifdef __GCW0__): I do not know, if the toolchain provides something to identify this device. I checked the internal gcc defines and the cmake toolchain file. Some game ports do a define (-DOPENDINGUX) in the makefile themselves, but this will only work, if we add that to the cmakelists.txt or provide our own toolchain file.

[DavidKnight247]

default gcw toolchainfile.cmake is this, would it be better to provide a
modified version with -DGCWZERO flagset?

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_C_COMPILER
/opt/gcw0-toolchain/usr/bin/mipsel-gcw0-linux-uclibc-gcc)
set(CMAKE_CXX_COMPILER
/opt/gcw0-toolchain/usr/bin/mipsel-gcw0-linux-uclibc-g++)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -O2 " CACHE STRING
"Buildroot CFLAGS" FORCE)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -O2 " CACHE STRING
"Buildroot CXXFLAGS" FORCE)
set(CMAKE_INSTALL_SO_NO_EXE 0)
set(CMAKE_PROGRAM_PATH "/opt/gcw0-toolchain/usr/bin")
set(CMAKE_FIND_ROOT_PATH
"/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(ENV{PKG_CONFIG_SYSROOT_DIR}
"/opt/gcw0-toolchain/usr/mipsel-gcw0-linux-uclibc/sysroot")

On Thu, Aug 21, 2014 at 7:22 PM, carstene1ns notifications@github.com
wrote:

About the hardware specific ifdef (for example ifdef GCW0): I do not
know, if the toolchain provides something to identify this device. I
checked the internal gcc defines and the cmake toolchain file. Some game
ports do a define (-DOPENDINGUX) in the makefile themselves, but this
will only work, if we add that to the cmakelists.txt or provide our own
toolchain file.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[carstene1ns]

Well, this would break for example when the user installs the toolchain in another directory (though this is only valid when compiled from scratch).
What I came up with now is a snippet like this in the cmakelists.txt (untested):

# check for crosscompiling (defined when using a toolchain file)
if(CMAKE_CROSSCOMPILING)
  # check for gcw0
  if(CMAKE_C_COMPILER MATCHES ".*gcw0-linux.*")
    set(GCW0 true)
  endif()
endif()
[...]
if(GCW0)
  add_definitions(-DGCWZERO)
endif()

[cxong]

Source code changes made, need to set the __GCWZERO__ definition in the build (-D__GCWZERO__).

[carstene1ns]

Great! I have the toolchain available and will add the auxiliary stuff today...

[carstene1ns]

#294 should allow building the complete package for gcw0.
@DavidKnight247: I uploaded a cdogs.opk, would you mind testing it? Thanks!
http://f4ke.de/dev/cdogs-sdl/cdogs.opk

[DavidKnight247]

I removed the cdogs config directory and ran the opk. I crashes before the
menu. I can't copy and paste from putty but I'll create a debug build and
see what's happening. Did you remember to comment out the two loadSongList
lines in gamedata.c as this causes segfaults on the gcw at about this point
(I still haven't figured out why though). The final line before it crashes
is "Unable to open scores.dat" so it's probably the loadSongList issue as
that's the next section (from memory).
gdb reports [Inferior 1 (process 563) exited with code 013] if that's any
help.

On Tue, Aug 26, 2014 at 2:12 PM, Cong notifications@github.com wrote:

Closed #292 #292 via #294
#294.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[carstene1ns]

Well, I changed nothing in in the code at all, only how the project is built and packaged.
I thought @cxong made all required changes, but you are right that the loadSongList calls are left as-is. I guess we need to figure out why it is crashing there first.

[cxong]

oops; I forgot to mention that; fixed in latest revision.

Can you try removing all the music files from /music/game and /music/menu, and seeing if it works? There are ogg and mod files currently, and maybe GCW Zero is missing the libraries? Not sure about the situation on linux but I know that for Windows I need to also provide dlls of libmikmod, libogg, libvorbis and libvorbisfile.

[cxong]

What is the escape key mapped to on GCW0?

In the game it mentions pressing Esc to quit, which makes no sense here. It also makes no sense on android (where it's mapped to back) and if players are using joysticks. I think it should be a system-specific key name.

[carstene1ns]

After a bit of investigating, I found out GCW0 has mikmod, modplug and ogg libraries available. MP3 support is missing (i guess because of patent issues). Also, sdl_mixer should fail loading the files and error (This error is also catched by LoadSongList()) instead of crashing the whole game.

---

I agree on the system specific buttons. For most dedicated gaming devices there are only a few buttons to map, so we need a way to avoid double mappings. For example the START button on GCW0 could be ENTER in the main menu and ESC ingame.

[cxong]

@carstene1ns so still no idea why it would crash? I guess it's up to @DavidKnight247 or no music 😦

I'm not sure about having START mapped to ESC; C-Dogs uses ESC twice to exit from the game, but I imagine on most handhelds, people expect START to pause/unpause. I'd like to rework the pause functionality anyway, turning it into a menu #284 so maybe until then?

[carstene1ns]

Well, I am not sure how to do it, it just should feel "natural" when using on the device.
For example on the Wii, it is natural to map the HOME button to ESC as all homebrew and also commercial games return to the menu/loader when using that button.
I do not know how it is best on GCW0, but I think pressing START inside a game should pause, right. But how are you supposed to end the game then? I agree that using a pause menu will fix this.

[DavidKnight247]

SELECT acts as the escape key, START acts as the Return key, keymaps for
GCW are here: http://wiki.surkow.com/Tutorials:SDL#Buttons
Currently, SELECT acts as the pause button in game which I feel is fine
(displays "press ESC again to quit" dialogue with faded background). It's
the nearest flush button to the weapon controls so I would prefer it over
the START button for convenience.

I'm busy for the rest of the day but I'll take another look at the music
issue tonight, I've been working on a couple of other projects in the last
few days but they're now finished so I have a little more time now ;)
GCW definitely runs .ogg, during earlier testing with fprint statements it
didn't seem to run LoadSongLists at all.

On Wed, Aug 27, 2014 at 10:20 AM, Carsten Teibes notifications@github.com
wrote:

Well, I am not sure how to do it, it just should feel "natural" when
using on the device.
For example on the Wii, it is natural to map it to ESC as all homebrew
and also commercial games return to the menu/loader when using that button.
I do not know how it is best on GCW0, but I think pressing START inside a
game should pause, right. But how are you supposed to end the game then? I
agree that using a pause menu will fix this.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[DavidKnight247]

btw gcw plays the mod file during the "Distress call from Scientific
Outpost" Campaign so that at least has music.

On Wed, Aug 27, 2014 at 10:57 AM, David Knight djk.optometrist@gmail.com
wrote:

SELECT acts as the escape key, START acts as the Return key, keymaps for
GCW are here: http://wiki.surkow.com/Tutorials:SDL#Buttons
Currently, SELECT acts as the pause button in game which I feel is fine
(displays "press ESC again to quit" dialogue with faded background). It's
the nearest flush button to the weapon controls so I would prefer it over
the START button for convenience.

I'm busy for the rest of the day but I'll take another look at the music
issue tonight, I've been working on a couple of other projects in the last
few days but they're now finished so I have a little more time now ;)
GCW definitely runs .ogg, during earlier testing with fprint statements it
didn't seem to run LoadSongLists at all.

On Wed, Aug 27, 2014 at 10:20 AM, Carsten Teibes <notifications@github.com

wrote:

Well, I am not sure how to do it, it just should feel "natural" when
using on the device.
For example on the Wii, it is natural to map it to ESC as all homebrew
and also commercial games return to the menu/loader when using that button.
I do not know how it is best on GCW0, but I think pressing START inside
a game should pause, right. But how are you supposed to end the game then?
I agree that using a pause menu will fix this.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[DavidKnight247]

:sigh: it's so much easier to compile when you have instructions like these
;) Looking into LoadSongLists issue now.

On Wed, Aug 27, 2014 at 3:18 PM, Carsten Teibes notifications@github.com
wrote:

Btw. I just created a wiki page
https://github.com/cxong/cdogs-sdl/wiki/Developer-Getting-Started:-GCW-Zero
.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[carstene1ns]

Well, it did not make sense to add instructions before, as the build system was not ready yet… 😄
Anyways, how is it going? @cxong added a debug command line option recently (998bf83), that you can add to the .desktop file before packaging to a .opk filesystem.
Also note, that you need to disable optimizing for gdb to work reliably (the toolchain file sets -O2). You can overwrite that setting by adding -g -O0 to your CFLAGS (or CMAKE_C_FLAGS) or adding it to the CMakeLists.txt.
Finally, to check if the right flags are used, you can invoke make with verbose output: make VERBOSE=1.

[DavidKnight247]

No joy last night, I'm having trouble running the make_opk.sh script. It
fails at line 9 and 19. I am using BASH 4.3.8 from standard terminal with
latest ubuntu:

Building cdogs.opk...
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: 9:
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: [[: not found
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: 9:
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: -z: not found
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: 19:
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: Syntax error: "("
unexpected
make[2]: *** [src/cdogs-sdl] Error 2
make[1]: *** [src/CMakeFiles/cdogs-sdl.dir/all] Error 2
make: *** [all] Error 2

On Thu, Aug 28, 2014 at 4:30 PM, Carsten Teibes notifications@github.com
wrote:

Well, it did not make sense to add instructions before, as the build
system was not ready yet… [image: 😄]
Anyways, how is it going? @cxong https://github.com/cxong added a debug
command line option recently (998bf83
998bf83),
that you can add to the .desktop file before packaging to a .opk
filesystem.
Also note, that you need to disable optimizing for gdb to work reliably
(the toolchain file sets -O2). You can overwrite that setting by adding -g
-O0 to your CFLAGS (or CMAKE_C_FLAGS) or adding it to the CMakeLists.txt.
Finally, to check if the right flags are used, you can invoke make with
verbose output: make VERBOSE=1.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[DavidKnight247]

I should add that the compilation preceeding this runs fine and without
error.

On Thu, Aug 28, 2014 at 10:19 PM, David Knight djk.optometrist@gmail.com
wrote:

No joy last night, I'm having trouble running the make_opk.sh script. It
fails at line 9 and 19. I am using BASH 4.3.8 from standard terminal with
latest ubuntu:

Building cdogs.opk...
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: 9:
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: [[: not found
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: 9:
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: -z: not found
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: 19:
/home/david/cdogs-sdl/src/../build/gcw-zero/make_opk.sh: Syntax error: "("
unexpected
make[2]: *** [src/cdogs-sdl] Error 2
make[1]: *** [src/CMakeFiles/cdogs-sdl.dir/all] Error 2
make: *** [all] Error 2

On Thu, Aug 28, 2014 at 4:30 PM, Carsten Teibes notifications@github.com
wrote:

Well, it did not make sense to add instructions before, as the build
system was not ready yet… [image: 😄]
Anyways, how is it going? @cxong https://github.com/cxong added a
debug command line option recently (998bf83
998bf83),
that you can add to the .desktop file before packaging to a .opk
filesystem.
Also note, that you need to disable optimizing for gdb to work reliably
(the toolchain file sets -O2). You can overwrite that setting by adding -g
-O0 to your CFLAGS (or CMAKE_C_FLAGS) or adding it to the CMakeLists.txt.
Finally, to check if the right flags are used, you can invoke make with
verbose output: make VERBOSE=1.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[DavidKnight247]

Found the problem, the default shell in CMake is set to sh, not bash. I ran
cmake -Dgcwtoolchainblah .. from build directory then changed shell to bash
in gcwbuilddir/src/CMakeFiles/cdogs-sdl.dir/build.make
This allows use of bash extensions and runs make_opk successfully.
Sleep now, testing tomorrow ;)

On Thu, Aug 21, 2014 at 9:55 PM, carstene1ns notifications@github.com
wrote:

Well, this would break for example when the user installs the toolchain in
another directory (though this is only valid when compiled from scratch).
What I came up with now is a snippet like this in the cmakelists.txt
(untested):

check for crosscompiling (defined when using a toolchain file)

if(CMAKE_CROSSCOMPILING)

check for gcw0

if(CMAKE_C_COMPILER MATCHES ".gcw0-linux.)
set(GCW0 true)
endif()
endif()
[...]
if(GCW0)
add_definitions(-DGCWZERO)
endif()

—
Reply to this email directly or view it on GitHub
#292 (comment).

[carstene1ns]

Okay, when a script is executed with explicit interpreter set (e.g. sh ./make_opk.sh) it ignores the shebang and that will of course fail.
I could change the src/CMakeLists.txt to run it with bash instead, but that will fail if there is no bash available... So I guess it is better to rewrite the make_opk.sh without bash extensions (arrays, double braces) so it will run with all posix compatible shells.

[DavidKnight247]

:( sorry. I have tested the default gcw cdogs.opk without modification
today. It loads and plays fine, all settings seem to work. However whenever
I start a campaign it crashes. It correctly lists them, when you select it
it gives the intro script and you select weapons and it freezes on this
screen. On my original port this did not happen so I suspect it is either
linked to source code change since 17th August or gcw specific build issue.
So now I have 2 bugs to work on :sigh:

On Fri, Aug 29, 2014 at 7:52 PM, Carsten Teibes notifications@github.com
wrote:

Okay, when a script is executed with explicit interpreter set (e.g. sh
./make_opk.sh) it ignores the shebang and that will of course fail.
I could change the src/CMakeLists.txt to run it with bash instead, but
that will fail if there is no bash available... So I guess it is better to
rewrite the make_opk.sh without bash extensions (arrays, double braces) so
it will run with all posix compatible shells.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[DavidKnight247]

I ran a gdb session with LoadSongLists uncommented and -O0 -g compiler
settings, this is the output. This is the first time I've attempted
debugging and would welcome feedback! I ran 'run' followed by 'bt'. I'm
guessing from this it's a libSDL_mixer issue?

Starting program: /media/data/local/home/cdogsmusicbugenabled/cdogs-sdl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
#0 0x00000000 in ?? ()
#1 0x77db8450 in ?? () from /usr/lib/libSDL_mixer-1.2.so.0
warning: GDB can't find the start of the function at 0x77db844e.

GDB is unable to find the start of the function at 0x77db844e

and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x77db844e for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
A debugging session is active.

Inferior 1 [process 1093] will be killed.

Quit anyway? (y or n)

On Fri, Aug 29, 2014 at 9:33 PM, David Knight djk.optometrist@gmail.com
wrote:

:( sorry. I have tested the default gcw cdogs.opk without modification
today. It loads and plays fine, all settings seem to work. However whenever
I start a campaign it crashes. It correctly lists them, when you select it
it gives the intro script and you select weapons and it freezes on this
screen. On my original port this did not happen so I suspect it is either
linked to source code change since 17th August or gcw specific build issue.
So now I have 2 bugs to work on :sigh:

On Fri, Aug 29, 2014 at 7:52 PM, Carsten Teibes notifications@github.com
wrote:

Okay, when a script is executed with explicit interpreter set (e.g. sh
./make_opk.sh) it ignores the shebang and that will of course fail.
I could change the src/CMakeLists.txt to run it with bash instead, but
that will fail if there is no bash available... So I guess it is better to
rewrite the make_opk.sh without bash extensions (arrays, double braces) so
it will run with all posix compatible shells.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[cxong]

That looks like a crash in an SDL thread, and since it wasn't compiled with debugging symbols it's not very helpful. Try switching to the main thread (info threads, find the one that's from main(), most likely thread 1, switch using thread 1). It might be that it's crashing from trying to load a specific file, you can use print <var> to find out what it's loading.

I've also been working on network support but it may not work on GCW-Zero; in /CMakeLists.txt find the line with set(USE_NET 1) and comment it out with a #.

[DavidKnight247]

I have deleted my previous comments as they were confusing and did not describe the reasons why music was causing crashes. Music does work now but I'm trying to get to the root of the problem...

Actually can I propose a simple improvement for gcw users(and others?). Can we change the default music directory to $HOME/.config/sdl-dogs/music ? That way users can simply add their own .ogg files.

On Sat, Aug 30, 2014 at 2:24 AM, Cong notifications@github.com wrote:

That looks like a crash in an SDL thread, and since it wasn't compiled
with debugging symbols it's not very helpful. Try switching to the main
thread https://sourceware.org/gdb/current/onlinedocs/gdb/Threads.html (info
threads, find the one that's from main(), most likely thread 1, switch
using thread 1). It might be that it's crashing from trying to load a
specific file, you can use print to find out what it's loading.

I've also been working on network support but it may not work on GCW-Zero;
in /CMakeLists.txt find the line with set(USE_NET 1) and comment it out
with a #.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[cxong]

Hi @DavidKnight247 , I've found and fixed a crash that sometimes occurs after the briefing screen, it might be the other crash you were talking about. Please try again with the latest revision.

[DavidKnight247]

Thanks, I'll let you know.
I've narrowed the music bug down to the Load_MixMUS call in gamedata.c
On the GCW if the file is not recognised it crashes and doesn't return NULL.
I'm still not sure why but if the folder contains different music types the
same call crashes. It parses the first file (.ogg or .mod) succesfully but
fails at the second.
I'm not sure if ths is related but if the music folder contains 3 of the
same type of music it also fails.

For the gcw would it be better just to do a simple check for file extension?

On Sun, Aug 31, 2014 at 3:01 AM, Cong notifications@github.com wrote:

Hi @DavidKnight247 https://github.com/DavidKnight247 , I've found and
fixed a crash that sometimes occurs after the briefing screen, it might be
the other crash you were talking about. Please try again with the latest
revision
5ad34b6
.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[DavidKnight247]

I've further refined the bug conditions. It crashes when parsing the
rage.mod file or .txt files. The multiple files issue was because it
crashed at rage.mod.

On Sun, Aug 31, 2014 at 8:00 AM, David Knight djk.optometrist@gmail.com
wrote:

Thanks, I'll let you know.
I've narrowed the music bug down to the Load_MixMUS call in gamedata.c
On the GCW if the file is not recognised it crashes and doesn't return
NULL.
I'm still not sure why but if the folder contains different music types
the same call crashes. It parses the first file (.ogg or .mod) succesfully
but fails at the second.
I'm not sure if ths is related but if the music folder contains 3 of the
same type of music it also fails.

For the gcw would it be better just to do a simple check for file
extension?

On Sun, Aug 31, 2014 at 3:01 AM, Cong notifications@github.com wrote:

Hi @DavidKnight247 https://github.com/DavidKnight247 , I've found and
fixed a crash that sometimes occurs after the briefing screen, it might be
the other crash you were talking about. Please try again with the latest
revision
5ad34b6
.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[carstene1ns]

I guess we should test, if rage.mod crashes libmikmod under gcw0 and we should test, if other tracker modules work with cdogs under gcw0.
This player supports tracker modules on gcw0: http://boards.dingoonity.org/gcw-releases/gmu-music-player-for-gcw-zero/
Switch rage.mod in music folder with any other, for example this: http://modarchive.org/index.php?request=view_by_moduleid&query=57934

[DavidKnight247]

There appears to be a system issue with .mod files.

I just tested Rage.mod with GMU. It plays. I then tried molrevenge.mod and
the system immediately froze.I restarted and played molrevenge.mod fine. It
froze again when switching to rage.mod. It played all .ogg files I threw at
it no problem. GMU doesn't display non music files. I made an empty file
called crashtest.ogg. GMU sees this and does nothing when executed. However
when I create crashtest.mod the first time it does nothing, the second time
it crashes.

I have raised this as an opendingux bug.

On Sun, Aug 31, 2014 at 1:30 PM, Carsten Teibes notifications@github.com
wrote:

I guess we should test, if rage.mod crashes libmikmod under gcw0 and we
should test, if other tracker modules work with cdogs under gcw0.
This player supports tracker modules on gcw0:
http://boards.dingoonity.org/gcw-releases/gmu-music-player-for-gcw-zero/
Switch rage.mod in music folder with any other, for example this:
http://modarchive.org/index.php?request=view_by_moduleid&query=57934

—
Reply to this email directly or view it on GitHub
#292 (comment).

[cxong]

Good find! Although I don't expect this will be fixed soon. I'd like to replace the music anyway #301 so once that's done and I add a check to skip .txt files, that might fix this problem too.

[DavidKnight247]

I'm afraid my Gmu testing was flawed. The Gmu behaviour is already fixed in
the latest opendingux and appears unrelated to the issue with rage.mod and
.txt files. I had downgraded to the previous OS for testing and forgotten
to upgrade back.
mod files including rage.mod plays fine now repeatedly in Gmu. It still
fails as before with Mix_LoadMUS(path/to/rage.mod). I will do more testing
after work tonight with multiple mod files to see if this is a special case.

On Mon, Sep 1, 2014 at 3:54 AM, Cong notifications@github.com wrote:

Good find! Although I don't expect this will be fixed soon. I'd like to
replace the music anyway #301
#301 so once that's done and I
add a check to skip .txt files, that might fix this problem too.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[DavidKnight247]

I downloaded the top dozen or so .mod tracks from the mod archive. All were
tested in gmu and play the first few seconds fine. I then placed them in
the game folder and ran cdogs.

files passed successfully by Mix_LoadMUS(file) I've tried a few in games
and all seems to work fine:
aurora.mod
aurora-.mod
beyond_music.mod
cream_of_the_earth.mod
DOPE.MOD
enigma.mod
GSLINGER.MOD
monday.mod
scrambld.mod
spacedeb.mod
stardstm.mod

files that cause a crash (the same error is produced each time):
__is*{_1} (-128,0x4 {locale})

12TH.MOD
ELYSIUM.MOD
street_j.mod

This is puzzling as I can see no common difference between the files.

On Mon, Sep 1, 2014 at 9:01 AM, David Knight djk.optometrist@gmail.com
wrote:

I'm afraid my Gmu testing was flawed. The Gmu behaviour is already fixed
in the latest opendingux and appears unrelated to the issue with rage.mod
and .txt files. I had downgraded to the previous OS for testing and
forgotten to upgrade back.
mod files including rage.mod plays fine now repeatedly in Gmu. It still
fails as before with Mix_LoadMUS(path/to/rage.mod). I will do more testing
after work tonight with multiple mod files to see if this is a special case.

On Mon, Sep 1, 2014 at 3:54 AM, Cong notifications@github.com wrote:

Good find! Although I don't expect this will be fixed soon. I'd like to
replace the music anyway #301
#301 so once that's done and
I add a check to skip .txt files, that might fix this problem too.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[DavidKnight247]

I've just downloaded the latest git version and now cdogs.opk is built
successfully (thanks for unbashifying the script). It also now runs
campaigns great. I uncommented the LoadSongList calls and removed .txt and
the problematic .mod files from the music/game directories. It now works
fine, the only missing functionality is the lack of rage.mod (appropriately
named ;)).

The current build instructions for gcw is as follows:
1)clone repo
2) cmake -Dcmaketoolchainblah, mkdir gcwbuild and cd gcwbuild as per wiki

---

2.1)rm ../music/game/.txt; rm ../music/menu/.txt; rm
../music/game/rage.mod
2.2) nano ../src/cdogs/gamedata.c <--remove ifndef__gcw__ from
LoadSongLists as now no longer required

---

3)make

All features so far run fine. no crashes yet. I will give it an extensive
playtest tonight ;)

On Mon, Sep 1, 2014 at 9:29 PM, David Knight djk.optometrist@gmail.com
wrote:

I downloaded the top dozen or so .mod tracks from the mod archive. All
were tested in gmu and play the first few seconds fine. I then placed them
in the game folder and ran cdogs.

files passed successfully by Mix_LoadMUS(file) I've tried a few in games
and all seems to work fine:
aurora.mod
aurora-.mod
beyond_music.mod
cream_of_the_earth.mod
DOPE.MOD
enigma.mod
GSLINGER.MOD
monday.mod
scrambld.mod
spacedeb.mod
stardstm.mod

files that cause a crash (the same error is produced each time):
__is*{_1} (-128,0x4 {locale})

12TH.MOD
ELYSIUM.MOD
street_j.mod

This is puzzling as I can see no common difference between the files.

On Mon, Sep 1, 2014 at 9:01 AM, David Knight djk.optometrist@gmail.com
wrote:

I'm afraid my Gmu testing was flawed. The Gmu behaviour is already fixed
in the latest opendingux and appears unrelated to the issue with rage.mod
and .txt files. I had downgraded to the previous OS for testing and
forgotten to upgrade back.
mod files including rage.mod plays fine now repeatedly in Gmu. It still
fails as before with Mix_LoadMUS(path/to/rage.mod). I will do more testing
after work tonight with multiple mod files to see if this is a special case.

On Mon, Sep 1, 2014 at 3:54 AM, Cong notifications@github.com wrote:

Good find! Although I don't expect this will be fixed soon. I'd like to
replace the music anyway #301
#301 so once that's done and
I add a check to skip .txt files, that might fix this problem too.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[carstene1ns]

I also do not understand why these files fail. Some of them are actually fast tracker files (.xm), but the others should play. Also, we do not know yet, if the crash happens in sdl_mixer, libmikmod or libmodplug. I guess it happens in modplug, as it takes precedence when available from sdl_mixer and GMU uses libmikmod directly.

[DavidKnight247]

I have updated the opk based on the above method, it plays smoother, is
much smaller as no sourcecode and of course has music enabled. Can you
update the gcw link on github?
https://drive.google.com/file/d/0BwYi4RGX-HSaY1RXc1RSUWIzUUE/edit?usp=sharing

I'll look further into the mod issue tomorrow, I can confirm I tried the
problem files again tonight with the new build and I get the same result as
before.
I have done a little googling. The previous gmu issue I found in the old
version of opendingux is related to libmikmod which now appears to have
been fixed.
Libmodplug now appears to be on github, I still need to find out which
version is used on the gcw. The library is called libmodplug.so.1.0.0 so
I'm thinking it hasn't been updated for a bit.
https://github.com/Konstanty/libmodplug

On Mon, Sep 1, 2014 at 11:16 PM, Carsten Teibes notifications@github.com
wrote:

I also do not understand why these files fail. Some of them are actually
fast tracker files (.xm), but the others should play. Also, we do not know
yet, if the crash happens in sdl_mixer, libmikmod or libmodplug. I guess it
happens in modplug, as it takes precedence when available from sdl_mixer
and GMU uses libmikmod directly.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[carstene1ns]

It is the latest version: https://github.com/gcwnow/buildroot/blob/opendingux-2014.05/package/libmodplug/libmodplug.mk

Also, pinging @cxong for the gh-pages branch update... 😄

[carstene1ns]

Seems like we do not need to bother about tracker modules anymore, as all music is in ogg vorbis format now.
So the only thing missing is adding a check for the .txt files and removing the gcw0 ifdef.

[DavidKnight247]

Just followed official build instructions for gcw zero, all now works fine
:D

On Tue, Sep 2, 2014 at 3:53 PM, Carsten Teibes notifications@github.com
wrote:

Seems like we do not need to bother about tracker modules anymore, as all
music is in ogg vorbis format now.
So the only thing missing is adding a check for the .txt files and
removing the gcw0 ifdef.

—
Reply to this email directly or view it on GitHub
#292 (comment).

[carstene1ns]

Great! So we can provide official release opks with the next version.