Hello,
First, many thanks for your kind support and for the quality of your
library, which is quite impressive.
I tested the 1.4 version from SVN (revision 8614) on Ubuntu Karmic Koala
with gcc version 4.4.1, arch is x86_64 (Core i7), having just run
.../configure --prefix=YYY with an environment set so that the appropriate
sdl-config is found.
There were only two small related issues:
- gui/window.c:92: error: 'NC_Result' undeclared, defined in
.../net/client.h, I guess we accept gui to depend on net only if NETWORK
is set?
- gui/window.c:126: error: 'AG_Window' has no member named 'nc': with my
setup, no NETWORK symbol was defined, so I guess AG_WindowNewRemote
should mostly return an error and #define-out the actual function body
See the corresponding attached patch that fixes both.
A check for gettext tools should be added, as otherwise, if they are not
installed, we have:
"""
xgettext --default-domain=agar --directory=.. --add-comments --keyword=_
--keyword=N_ --files-from=POTFILES --no-location --from-code=UTF-8 -o
agar.pot
/bin/sh: xgettext: not found
xgettext returned non-zero status
msgfmt -o fr.mo fr.po
/bin/sh: msgfmt: not found
make[1]: *** [fr.mo] Erreur 127
make[1]: quittant le répertoire « XXX/Agar-svn/agar14/po »
"""
'apt-get install gettext' solved that issue for me, but afterwards an
error was triggered:
"""
==> po
make[1]: entrant dans le répertoire « XXX/Agar-svn/agar14/po »
(cd .. && find . -name \*.c > POTFILES)
xgettext --default-domain=agar --directory=.. --add-comments --keyword=_
--keyword=N_ --files-from=POTFILES --no-location --from-code=UTF-8 -o
agar.pot
[: 13: !=: unexpected operator
make[1]: quittant le répertoire « XXX/Agar-svn/agar14/po »
"""
Error presumably in mk/build.po.mk, I did not investigate and just
disabled the build of po. Afterwards 'make' and 'make install' ran fine.
In the demos directory, it would be more convenient that, if a
sub-configure fails, the overall configure make target stops, ex: if
Agar is not found, all configures fail in a row. In that case, telling
the user that agar-config is expected to be in the PATH would help.
In the generated configure script, if more than one version of Agar
happens to be in the PATH (ex: 1.3.4/1.4), the latest one will be
selected, so at first I was using the 1.4 test cases against a 1.3.4
library; probably the 'for' loop should be replaced by a 'while' one in
the configure script, to stop on first, not on the last, agar-config
found (presumably the expected one), in:
"""
for path in `echo $PATH | sed 's/:/ /g'`; do
if [ -x "${path}/agar-config" ]; then
AGAR_VERSION=`${path}/agar-config --version`
fi
done
"""
All tests could then be successfully configured and built.
I do not think it is a big issue, but test cases are not linked with
rpath to the library they test (please see no reason to use the awful
libtool), so when I executed them, they happened to be initially
dynamically linked to the 1.3.4 library, due to LD_LIBRARY_PATH. However
at least in my case it could be detected: "./fixedres: Symbol `agColors'
has different size in shared object, consider re-linking".
After having updated accordingly LD_LIBRARY_PATH, now the execution of
tests, in SDL mode:
- fixedres: worked fine, although we do not know really what to expect
(maybe a text label could tell it to the user?)
- objsystem: can be reproducibly crashed when defining an animal and
moving around the Untitled window (could not make it crash without
defining an animal):
Starting program: YYY/Agar-svn/agar14/demos/objsystem/objsystem
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79110e4 in AG_GetPixel ()
from XXX/agar-1.4/lib/libag_gui.so.1
(gdb) where
#0 0x00007ffff79110e4 in AG_GetPixel ()
from XXX/agar-1.4/lib/libag_gui.so.1
#1 0x00007ffff7913e55 in AG_BlendPixelRGBA ()
from XXX/agar-1.4/lib/libag_gui.so.1
#2 0x00007ffff793bf5f in RectBlendedFB ()
from XXX/agar-1.4/lib/libag_gui.so.1
#3 0x00007ffff792210a in TreeSubnodeIndicator ()
from XXX/agar-1.4/lib/libag_gui.so.1
#4 0x00007ffff7941cc4 in Draw () from XXX/agar-1.4/lib/libag_gui.so.1
#5 0x00007ffff7919447 in AG_WidgetDraw ()
from XXX/agar-1.4/lib/libag_gui.so.1
#6 0x00007ffff7919497 in AG_WidgetDraw ()
from XXX/agar-1.4/lib/libag_gui.so.1
#7 0x00007ffff7919497 in AG_WidgetDraw ()
from XXX/agar-1.4/lib/libag_gui.so.1
#8 0x00007ffff7919497 in AG_WidgetDraw ()
from XXX/agar-1.4/lib/libag_gui.so.1
#9 0x00007ffff7914cbc in AG_EventLoop_FixedFPS ()
from XXX/agar-1.4/lib/libag_gui.so.1
#10 0x00000000004014c0 in main ()
(can be crashed with the -g flag as well, but I guess it is ignored)
- focusing: seems to work great
- loader: seems to work great, but tells me it cannot find SDL_image
library whereas I have one in my LD_LIBRARY_PATH
(XXX/SDL_image-1.2.10/lib). This is probably due to configure not
detecting it ("checking for SDL_image
(http://libsdl.org/projects/SDL_image)...no"), short of finding the
SDL_image header:
"""
checking for SDL_image
(http://libsdl.org/projects/SDL_image).../usr/bin/cc -Wall -Werror
-I/home/wondersye/Projects/LOAN
I-0.6/LOANI-installations/SDL-1.2.14/include/SDL -D_GNU_SOURCE=1
-D_REENTRANT -o ./conftest conftest.c -lSDL_image
conftest.c:5:23: error: SDL_image.h: Aucun fichier ou dossier de ce type
cc1: warnings being treated as errors
conftest.c: In function ‘main’:
conftest.c:11: error: implicit declaration of function ‘IMG_Load’
conftest.c:11: error: assignment makes pointer from integer without a cast
"""
However I cannot see how to tell configure to use a prefixed SDL_image
install? It is a bit of a problem for me, adding a --with-sdl-image
option or alike to the configure would help a lot
- table: seems to work great, unless we close the three windows, then:
"""
> ./table
*** glibc detected *** ./table: double free or corruption (!prev):
0x000000000085d5b0 ***
======= Backtrace: =========
/lib/libc.so.6[0x7f0bda7aedd6]
/lib/libc.so.6(cfree+0x6c)[0x7f0bda7b374c]
XXX/SDL-1.2.14/lib/libSDL-1.2.so.0(SDL_FreeSurface+0xdd)[0x7f0bdb6a612d]
XXX/agar-1.4/lib/libag_gui.so.1(AG_WidgetReplaceSurface+0x92)[0x7f0bdbb5752c]
XXX/agar-1.4/lib/libag_gui.so.1(AG_TableFreeCell+0x3b)[0x7f0bdbbb82ba]
XXX/agar-1.4/lib/libag_gui.so.1[0x7f0bdbbbb8ec]
XXX/agar-1.4/lib/libag_core.so.1(AG_ObjectDestroy+0xad)[0x7f0bdb91aaf2]
XXX/agar-1.4/lib/libag_core.so.1(AG_ObjectFreeChildren+0x56)[0x7f0bdb91a528]
XXX/agar-1.4/lib/libag_core.so.1(AG_ObjectDestroy+0x31)[0x7f0bdb91aa76]
XXX/agar-1.4/lib/libag_gui.so.1[0x7f0bdbb5321d]
XXX/agar-1.4/lib/libag_gui.so.1(AG_ProcessEvent+0x303)[0x7f0bdbb551e7]
XXX/agar-1.4/lib/libag_gui.so.1(AG_EventLoop_FixedFPS+0x270)[0x7f0bdbb54e4f]
.../table[0x40167d]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f0bda757abd]
.../table[0x400ed9]
"""
- textbox: seems to work great; maybe I misunderstood the meaning of the
buttons to force integer/float entries, but even if they are hit, I can
still enter letters in the textbox; in a prior testing of the 1.3.x, I
recall that the CPU consumption of this test was quite high compared to
the others, I cannot tell whether it is still the case ('top' remains
rather quiet, but this computer is a bit too powerful to determine
whether load is unexpectedly high)
- widgets: works great, still as impressive as before; tells me I am
using Agar 1.3.2 (Landscapes Turn To Ash) but luckily it does not seem true:
"""
> ldd ./widgets
linux-vdso.so.1 => (0x00007fff70f02000)
libag_dev.so.1 => XXX/agar-1.4/lib/libag_dev.so.1 (0x00007f0d355de000)
libag_gui.so.1 => XXX/agar-1.4/lib/libag_gui.so.1 (0x00007f0d35305000)
libag_core.so.1 => XXX/agar-1.4/lib/libag_core.so.1 (0x00007f0d350de000)
libSDL-1.2.so.0 => XXX/SDL-1.2.14/lib/libSDL-1.2.so.0 (0x00007f0d34e4a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f0d34c2e000)
libfreetype.so.6 => XXX/freetype-2.3.11/lib/libfreetype.so.6
(0x00007f0d349a3000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f0d34722000)
libm.so.6 => /lib/libm.so.6 (0x00007f0d3449e000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00007f0d34279000)
libc.so.6 => /lib/libc.so.6 (0x00007f0d33f0a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f0d33cf3000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f0d33aef000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0d357f0000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f0d337b9000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f0d335a7000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007f0d333a1000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f0d3319f000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f0d32f99000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007f0d32d8e000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f0d32b72000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f0d3296f000)
librt.so.1 => /lib/librt.so.1 (0x00007f0d32767000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f0d32562000)
"""
(SDL vs OpenGL status apparently correctly detected)
- maximized: works great
- objprops: works great; but no new object can be created apparently
- unitconv: works great
- sockets: works great, but there is one horizontal line just on top of
the socket area that is not refreshed (moving around the helmet adds
brown pixels in it); when the new location of an item is not valid, the
item appears immediately back to its original position, which is a bit
confusing, as the user might not notice its returns; showing that item
coming back quickly instead could help
- glview works great
- gunpowder works great
- cplusplus works great
- plotting works great
- scrollbar works great
- initvideosdl behaves like widgets
I then quickly tried the same test suite with the -g flag to use OpenGL
instead of SDL, tests seem to behave the same.
One useful feature would be to always specify (with a label or the
command-line) whether we are using SDL, or direct OpenGL, etc. (like in
the widgets test).
In the demos/Makefile, maybe adding these two targets (and ensuring all
tests try to switch to the correct back-end) could be useful:
"""
exec-sdl:
for D in ${SUBDIR}; do \
echo "==> executing $$D with SDL"; \
(cd $$D && ./$$D ); \
done
exec-gl:
for D in ${SUBDIR}; do \
echo "==> executing $$D with OpenGL"; \
(cd $$D && ./$$D -g ); \
done
""""
If it can help the debugging of tests, here are my graphic settings:
"""
* Hardware-accelerated rendering:
direct rendering: Yes
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.6
OpenGL shading language version string: 1.20
* Graphical controller:
02:00.0 VGA compatible controller: nVidia Corporation GT200 [GeForce GTX
260M] (rev a2)
* Installed GL libraries:
lrwxrwxrwx 1 root root 10 2010-01-09 12:17 /usr/lib/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root 12 2010-01-08 19:53 /usr/lib/libGL.so.1 ->
libGL.so.1.2
-rw-r--r-- 1 root root 527256 2009-10-14 00:17 /usr/lib/libGL.so.1.2
* AIGLX status:
(==) AIGLX enabled
(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable
(II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
"""
A while ago I think I had noticed that the procedure to use Agar in an
existing OpenGL application with a custom event loop and rendering step
(http://wiki.libagar.org/wiki/Custom_Event_Loop /
http://wiki.libagar.org/wiki/Integrating_Agar_in_an_existing_GL_application)
had changed in the 1.4, would it be possible, if not done already, to
document it in the wiki?
Later I will integrate Agar 1.4 into my little OpenGL C++
game-in-construction, as I use stricter compile flags I expect it to
trigger some warnings, I will then do my best to submit patch(es),
hopefully before the 1.4 is out.
Thanks again,
Best regards,
Olivier Boudeville.
Index: gui/window.c
===================================================================
--- gui/window.c (révision 8614)
+++ gui/window.c (copie de travail)
@@ -87,6 +87,9 @@
AG_Window *
AG_WindowNewRemote(Uint flags, const char *serverSpec)
{
+
+#ifdef NETWORK
+
char spec[128], *s = &spec[0], *host, *port;
AG_Window *win;
NC_Result *r;
@@ -140,6 +143,13 @@
AG_ObjectDestroy(win);
if (r != NULL) { NC_FreeResult(r); }
return (NULL);
+
+#else /* NETWORK */
+
+ return (NULL);
+
+#endif /* NETWORK */
+
}
/* Create a named window */
@@ -1678,6 +1688,8 @@
va_end(ap);
Strlcpy(win->caption, s, sizeof(win->caption));
+#ifdef NETWORK
+
if (win->nc != NULL) {
NC_Result *r;
@@ -1692,6 +1704,9 @@
NC_FreeResult(r);
}
}
+
+#endif /* NETWORK */
+
}
AG_ObjectUnlock(win);
}
_______________________________________________
Agar mailing list
[email protected]
http://libagar.org/lists.html
