Based I've tried to compile from the CVs version. With CVS version of GLFW, it worked. The game is compiled on my computer. But :
[sam@localhost dark-oberon]$ ./dark-oberon
Crit: Could not create mutex
Info: Loading configuration from '/home/sam/.dark-oberon/config.cfg'
Info: Loading data
Info: Loading textures from 'dat/fonts.dat'
Info: Loading textures from 'dat/gui.dat'
Info: Loading textures from 'dat/cursors.dat'
terminate called after throwing an instance of 'TSAVE_LIST<TCALLBACK>::MutexException'
Abandon
(Abandon=failing, in french)
When I start the game, it makes me black screen (less than a second), and then crashes (bask to desktop wallpaper, with a lower resolution).
Hope this will help.
Good luck, and thanks for your amazing work :) .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This looks like a bug in GLFW library which privides system threads and mutexes. :( Could you please try to run 'mtbench' sample program? You can found it in examples folder of GLFW. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I resolved this issue, see the patch at the end of the post (from cvs version).
I also add a missing link library, -lXrandr, needed for compilation.
The main problem was you use a binary data format and you read it by using 'sizeof(xxx)' as length indicator, which is highly system-dependent. Because 'long' are 8 bytes long with gcc in x86_64 and only 4 bytes long on x86, it ran to a segfault. I just corrected this local problem but in fact, to be clean, you should rewrite all your read-data functions (define your data format in a .h and use macro when reading). Moreover, it is still endianness dependent. If you want, I may help you.
To finish, I corrected another bug, in doengine, 'strrchr' can return a NULL value, which if not tested can lead to a segfault. I just added this test.
With this, the game run well on a x86_64.
Otherwise it could be great if you translate the documentation in english.
if (!textures_seek) {
Error(LogMsg("Data file '%s' does not contain any textures", file_name));
Index: src/doengine.cpp
===================================================================
RCS file: /cvsroot/dark-oberon/dark-oberon/src/doengine.cpp,v
retrieving revision 1.385
diff -u -r1.385 doengine.cpp
--- src/doengine.cpp 13 Nov 2006 00:14:28 -0000 1.385
+++ src/doengine.cpp 6 Mar 2008 14:45:42 -0000
@@ -970,7 +970,7 @@
while (ok && next_file) { // loop over all files and directories id MAP_PATH diectory
extension = strrchr(file.name, '.');
- if (!(strcmp(extension, ".map"))) // filter in _findfirst is not correct (accepts files *.map*)
+ if (extension && !(strcmp(extension, ".map"))) // filter in _findfirst is not correct (accepts files *.map*)
ok = LoadMapInfo(true, file.name); // loads map info for each *.map file
next_file = (!_findnext(file_handler, &file));
}
@@ -988,7 +988,7 @@
{
extension = strrchr(entry->d_name, '.');
/** XXX: TU TO ASI MOZE SPADNUT, ked tam bude subor bez pripony **/
- if (!(strcmp(extension, ".map")))
+ if (extension && !(strcmp(extension, ".map")))
ok = LoadMapInfo(true, entry->d_name); // loads map info for each *.map file
}
}
"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for submitting the patch. The changes you have proposed have been commited into CVS. In fact I have modified the type of textures_seek from long to int. As you said, it would be best to rewrite all data-read functions, because now it still won't work when ILP64 data model will be used (where int is 64 bit). The best would be to use data types like uint32_t, etc.
Regards,
Marian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
Based I've tried to compile from the CVs version. With CVS version of GLFW, it worked. The game is compiled on my computer. But :
[sam@localhost dark-oberon]$ ./dark-oberon
Crit: Could not create mutex
Info: Loading configuration from '/home/sam/.dark-oberon/config.cfg'
Info: Loading data
Info: Loading textures from 'dat/fonts.dat'
Info: Loading textures from 'dat/gui.dat'
Info: Loading textures from 'dat/cursors.dat'
terminate called after throwing an instance of 'TSAVE_LIST<TCALLBACK>::MutexException'
Abandon
(Abandon=failing, in french)
When I start the game, it makes me black screen (less than a second), and then crashes (bask to desktop wallpaper, with a lower resolution).
Hope this will help.
Good luck, and thanks for your amazing work :) .
This looks like a bug in GLFW library which privides system threads and mutexes. :( Could you please try to run 'mtbench' sample program? You can found it in examples folder of GLFW. Thanks.
No problem:
[sam@localhost examples]$ ./mtbench
Multithreading benchmarking program
-----------------------------------
[some explanation about the benchmark]
Results:
--------
Number of CPUs: 1
Test 1: 0 context switches / second (inf us/switch)
Test 2: 1.032 ms / sleep (mean)
[sam@localhost examples]$
Nothing more.
Other examples works well.
Should I post on GLFW forums ?
>Should I post on GLFW forums ?
I am not sure. If examples works well, there can be some hidden bug in our code. And I haven't got x64 system to debug the code. :(
Hello,
I resolved this issue, see the patch at the end of the post (from cvs version).
I also add a missing link library, -lXrandr, needed for compilation.
The main problem was you use a binary data format and you read it by using 'sizeof(xxx)' as length indicator, which is highly system-dependent. Because 'long' are 8 bytes long with gcc in x86_64 and only 4 bytes long on x86, it ran to a segfault. I just corrected this local problem but in fact, to be clean, you should rewrite all your read-data functions (define your data format in a .h and use macro when reading). Moreover, it is still endianness dependent. If you want, I may help you.
To finish, I corrected another bug, in doengine, 'strrchr' can return a NULL value, which if not tested can lead to a segfault. I just added this test.
With this, the game run well on a x86_64.
Otherwise it could be great if you translate the documentation in english.
Thanks,
Sam
"
Index: src/create_makefile.sh
===================================================================
RCS file: /cvsroot/dark-oberon/dark-oberon/src/create_makefile.sh,v
retrieving revision 1.40
diff -u -r1.40 create_makefile.sh
--- src/create_makefile.sh 16 Aug 2005 22:25:55 -0000 1.40
+++ src/create_makefile.sh 6 Mar 2008 14:45:41 -0000
@@ -10,7 +10,7 @@
TARGETS='../dark-oberon'
INCLUDES='-I/usr/X11R6/include -I/usr/X11R6/include/GL -I../libs'
LIBPATHS='-L/usr/X11R6/lib -L/usr/lib -L/usr/local/lib -L../libs'
-LIBRARIES='-pthread -lglfw -lGL -lX11 -lGLU'
+LIBRARIES='-pthread -lglfw -lGL -lX11 -lGLU -lXrandr'
CPP='g++ $(CPPFLAGS) $(INCLUDES) $(DEFINES)'
DATA_DIR=''
Index: src/dodata.cpp
RCS file: /cvsroot/dark-oberon/dark-oberon/src/dodata.cpp,v
retrieving revision 1.66
diff -u -r1.66 dodata.cpp
--- src/dodata.cpp 11 Nov 2006 13:35:35 -0000 1.66
+++ src/dodata.cpp 6 Mar 2008 14:45:41 -0000
@@ -136,7 +136,7 @@
}
// seeks
- fread(&textures_seek, sizeof(textures_seek), 1, fr);
+ fread(&textures_seek, /*sizeof(textures_seek)*/4, 1, fr);
if (!textures_seek) {
Error(LogMsg("Data file '%s' does not contain any textures", file_name));
Index: src/doengine.cpp
===================================================================
RCS file: /cvsroot/dark-oberon/dark-oberon/src/doengine.cpp,v
retrieving revision 1.385
diff -u -r1.385 doengine.cpp
--- src/doengine.cpp 13 Nov 2006 00:14:28 -0000 1.385
+++ src/doengine.cpp 6 Mar 2008 14:45:42 -0000
@@ -970,7 +970,7 @@
while (ok && next_file) { // loop over all files and directories id MAP_PATH diectory
extension = strrchr(file.name, '.');
- if (!(strcmp(extension, ".map"))) // filter in _findfirst is not correct (accepts files *.map*)
+ if (extension && !(strcmp(extension, ".map"))) // filter in _findfirst is not correct (accepts files *.map*)
ok = LoadMapInfo(true, file.name); // loads map info for each *.map file
next_file = (!_findnext(file_handler, &file));
}
@@ -988,7 +988,7 @@
{
extension = strrchr(entry->d_name, '.');
/** XXX: TU TO ASI MOZE SPADNUT, ked tam bude subor bez pripony **/
- if (!(strcmp(extension, ".map")))
+ if (extension && !(strcmp(extension, ".map")))
ok = LoadMapInfo(true, entry->d_name); // loads map info for each *.map file
}
}
"
Samuel,
Thanks for submitting the patch. The changes you have proposed have been commited into CVS. In fact I have modified the type of textures_seek from long to int. As you said, it would be best to rewrite all data-read functions, because now it still won't work when ILP64 data model will be used (where int is 64 bit). The best would be to use data types like uint32_t, etc.
Regards,
Marian