GCW-Zero port

[carstene1ns]

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

Needed things:

• [x] source code modifications (patch for sdl_listmodes, ...)
• [x] toolchain file (provided by the gcw0-buildroot)
• [x] .desktop launcher file (builds/gcw-zero/default.gcw0.desktop)
• [x] opk build script (builds/gcw-zero/make_opk.sh)
• [x] cmake target for the cdogs-sdl.opk generation (optional)
• [x] 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 :wink:

[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 :frowning:

[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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-52961087.

[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 https://github.com/cxong/cdogs-sdl/issues/292 via #294 https://github.com/cxong/cdogs-sdl/pull/294.

— Reply to this email directly or view it on GitHub https://github.com/cxong/cdogs-sdl/issues/292#event-157289865.

[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 :frowning:

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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-53545380.

[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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-53545380.

[carstene1ns]

Btw. I just created a wiki page.

[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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-53578761.

[carstene1ns]

Well, it did not make sense to add instructions before, as the build system was not ready yet… :smile: Anyways, how is it going? @cxong added a debug command line option recently (998bf83c2432ea0e7eb74790fa42b3ffc7cebbd8), 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: :smile:] Anyways, how is it going? @cxong https://github.com/cxong added a debug command line option recently (998bf83 https://github.com/cxong/cdogs-sdl/commit/998bf83c2432ea0e7eb74790fa42b3ffc7cebbd8), 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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-53737492.

[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: :smile:] Anyways, how is it going? @cxong https://github.com/cxong added a debug command line option recently (998bf83 https://github.com/cxong/cdogs-sdl/commit/998bf83c2432ea0e7eb74790fa42b3ffc7cebbd8), 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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-53737492.

[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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-52983072.

[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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-53916148.

[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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-53916148.

[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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-53944963.

[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 https://github.com/cxong/cdogs-sdl/commit/5ad34b69265c08f72368ac74ee0476fdf8f28599 .

— Reply to this email directly or view it on GitHub https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-53975936.

[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 https://github.com/cxong/cdogs-sdl/commit/5ad34b69265c08f72368ac74ee0476fdf8f28599 .

— Reply to this email directly or view it on GitHub https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-53975936.

[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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-53986398.

[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 https://github.com/cxong/cdogs-sdl/issues/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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-54011001.

[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 https://github.com/cxong/cdogs-sdl/issues/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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-54011001.

[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 ifndefgcw 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 https://github.com/cxong/cdogs-sdl/issues/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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-54011001.

[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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-54094577.

[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... :smile:

[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 https://github.com/cxong/cdogs-sdl/issues/292#issuecomment-54163493.

[carstene1ns]

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