artlog

I couldn't answer to you since i am new on this forum and did use my 4 posts what i was not aware of beforehand. yep this is working now using nvtt shipped within 0ad sources what is default behavior with using ./update-workspaces.sh I cleaned everything to fully rebuild, because my previous tentatives to only rebuild parts didn't succeed. I did test --without-nvtt but that was a terrible idea, it does not work at all since this does fully remove nvtt, i doubt even this option has still an interest. Then i got a working configuration, i wanted to move my binary somewhere else to keep this as a reference, and learnt the hard way it is compiled with RUNPATH $ORIGIN meaning dynamic libraries should be copied within the same path and that a data directory populated with assets should exists in parent else it crashes badly with segfault. I think i lost lots of time due to this https://trac.wildfiregames.com/wiki/BuildInstructions#Linux Debian / Ubuntu "With these dependencies you have to run: ./update-workspaces.sh --with-system-nvtt" remark : for system nvtt under debian unstable there is debian bug open on libnvtt2 for which 0ad was one of the main trigger : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916909 but this is unclear if it came from a messed environement or from libnvtt2 itself, i won't go further...

well, how do i proceed, my tentative with : ./update-workspaces.sh cd gcc; make -j2 fails with usr/bin/ld : ../../../binaries/system/libgraphics.a(TextureConverter.o) : dans la fonction « CTextureConverter::ConvertTexture(std::shared_ptr<CTexture> const&, Path const&, Path const&, CTextureConverter::Settings const&) » : /extmounts/var/develp/games/0ad/0ad/build/workspaces/gcc/../../../source/graphics/TextureConverter.cpp:436 : référence indéfinie vers « nvtt::InputOptions::setTextureLayout(nvtt::TextureType, int, int, int) » collect2: error: ld returned 1 exit status make[1]: *** [test.make:331: ../../../binaries/system/test] Error 1 make: *** [Makefile:189: test] Error 2 I have to make clean ? If i do it this is a full long build to do ... is there a shortcut ? seems rm ./gcc/obj/graphics_Release/TextureManager.o ./gcc/obj/graphics_Release/TexturedLineRData.o ./gcc/obj/graphics_Release/TextureConverter.o allowed to recompile only needed things ... will see well not enough, same problem, doing the full clean rebuild...

i get this on a build done on Debian sid from 0ad gitlab ( HEAD commit 6739e81b57c626735c531e4a6b5ebd5784734f76 Fri May 22 05:00:18 2020 +0200 ) but i didn't manage to fix it clearing cache is not enough : did rm -rf ~/.cache/0ad , content is recreated at restart. Here a small video : https://pire.artisanlogiciel.net/videos/watch/8b81e3ed-e9ec-46ae-b727-7bd230c660ad stack trace : #0 0x00007f87fa4f2ec5 in __GI___nanosleep (requested_time=requested_time@entry=0x7fffd17a83e0, remaining=remaining@entry=0x7fffd17a83e0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28 #1 0x00007f87fa4f2dca in __sleep (seconds=0, seconds@entry=3) at ../sysdeps/posix/sleep.c:55 #2 0x000055debf23c994 in udbg_launch_debugger () at ../../../source/lib/sysdep/os/unix/udbg.cpp:85 #3 0x000055debf23f875 in try_gui_display_error (no_continue=false, allow_suppress=true, manual_break=true, text=0x6582 <error: Cannot access memory at address 0x6582>) at ../../../source/lib/sysdep/os/unix/unix.cpp:175 #4 sys_display_error ( text=text@entry=0x7f87e8020000 L"Function call failed: return value was -120102 (Invalid/unsupported texture format)\r\nLocation: tex_dds.cpp:418 (decode_pf)\r\n\r\nCall stack:\r\n\r\n(0x55debf23bd45) binaries/system/pyrogenesis(+0x619d45) [0x"..., flags=flags@entry=6) at ../../../source/lib/sysdep/os/unix/unix.cpp:216 #5 0x000055debf1dc6fb in CallDisplayError (flags=<optimized out>, text=0x7f87e8020000 L"Function call failed: return value was -120102 (Invalid/unsupported texture format)\r\nLocation: tex_dds.cpp:418 (decode_pf)\r\n\r\nCall stack:\r\n\r\n(0x55debf23bd45) binaries/system/pyrogenesis(+0x619d45) [0x"...) at ../../../source/lib/debug.cpp:383 #6 debug_DisplayError (description=<optimized out>, flags=<optimized out>, context=0x7fffd17a9140, lastFuncToSkip=0x55debf334eb8 L"debug_OnError", pathname=<optimized out>, line=418, func=<optimized out>, suppress=0x55debf438368 <decode_pf(DDS_PIXELFORMAT const*, unsigned long&, unsigned long&)::suppress__>) at ../../../source/lib/debug.cpp:474 #7 0x000055debf1dc823 in debug_OnError (err=err@entry=-120102, suppress=suppress@entry=0x55debf438368 <decode_pf(DDS_PIXELFORMAT const*, unsigned long&, unsigned long&)::suppress__>, file=file@entry=0x55debf340ac0 L"../../../source/lib/tex/tex_dds.cpp", line=line@entry=418, func=func@entry=0x55debf340a8e "decode_pf") at ../../../source/lib/debug.cpp:551 #8 0x000055debf25c720 in decode_pf (flags=@0x7f87f5296a50: 0, bpp=@0x7f87f5296a48: 8, pf=0x55dec2f0204c) at ../../../source/lib/tex/tex_dds.cpp:418 #9 decode_sd (flags=@0x7f87f5296a50: 0, bpp=@0x7f87f5296a48: 8, h=@0x7f87f5296a40: 512, w=@0x7f87f5296a38: 1024, sd=0x55dec2f02004) at ../../../source/lib/tex/tex_dds.cpp:514 #10 TexCodecDds::decode (this=<optimized out>, data=0x55dec2f02000 "DDS |", t=0x7f87f5296a18) at ../../../source/lib/tex/tex_dds.cpp:610 #11 0x000055debf259703 in Tex::decode (this=this@entry=0x7f87f5296a18, Data=std::shared_ptr<unsigned char> (use count 2, weak count 0) = {...}, DataSize=524416) at ../../../source/lib/tex/tex.cpp:736 #12 0x000055debf22dff0 in OglTex_reload (ot=0x7f87f5296a18, vfs=..., pathname=..., h=917518) at ../../../source/lib/res/graphics/ogl_tex.cpp:472 #13 0x000055debf230a07 in call_init_and_reload (type=0x55debf430ae0 <V_OglTex>, type=0x55debf430ae0 <V_OglTex>, init_args=0x7fffd17a9b98, pathname=..., vfs=std::shared_ptr<struct IVFS> (use count 4, weak count 0) = {...}, hd=0x7f87f52969c0, h=<optimized out>) at ../../../source/lib/res/h_mgr.cpp:438 #14 alloc_new_handle (init_args=0x7fffd17a9b98, flags=140736707862800, key=4043432962, pathname=..., vfs=std::shared_ptr<struct IVFS> (use count 4, weak count 0) = {...}, type=0x55debf430ae0 <V_OglTex>) at ../../../source/lib/res/h_mgr.cpp:481 #15 h_alloc (type=type@entry=0x55debf430ae0 <V_OglTex>, vfs=std::shared_ptr<struct IVFS> (use count 4, weak count 0) = {...}, pathname=..., flags=flags@entry=17) at ../../../source/lib/res/h_mgr.cpp:518 #16 0x000055debf22c581 in ogl_tex_load (vfs=std::shared_ptr<struct IVFS> (use count 4, weak count 0) = {...}, pathname=..., flags=flags@entry=17) at ../../../source/lib/res/graphics/ogl_tex.cpp:544 #17 0x000055debf0298ae in CTextureManagerImpl::LoadTexture (this=this@entry=0x55debf6927d0, texture=std::shared_ptr<class CTexture> (use count 4, weak count 4) = {...}, path=...) at ../../../source/graphics/TextureManager.cpp:179 #18 0x000055debf033ffe in CTextureManagerImpl::TryLoadingCached (this=0x55debf6927d0, texture=std::shared_ptr<class CTexture> (use count 4, weak count 4) = {...}) at ../../../source/graphics/TextureManager.cpp:267 #19 0x000055debf028400 in CTexture::TryLoad (this=0x55dec2c2be00) at ../../../source/graphics/TextureManager.cpp:566 #20 CTexture::GetHandle (this=0x55dec2c2be00) at ../../../source/graphics/TextureManager.cpp:553 #21 0x000055debf007711 in CShaderProgram::BindTexture (this=0x55dec2623ef0, id=..., tex=...) at /usr/include/c++/9/bits/shared_ptr_base.h:1020 #22 0x000055debf024e42 in CTextRenderer::Render (this=this@entry=0x7fffd17aa5d0) at /usr/include/c++/9/ext/atomicity.h:96 #23 0x000055debf1cee78 in CGUIText::Draw (this=0x55dec1d4d870, pGUI=..., DefaultColor=..., pos=..., z=<optimized out>, clipping=...) at ../../../source/gui/CGUIText.cpp:462 #24 0x000055debf1c5282 in CText::Draw (this=0x55dec00ee370) at ../../../source/gui/ObjectTypes/CText.cpp:230 (gdb) frame 15 #15 h_alloc (type=type@entry=0x55bb8d5c7ae0 <V_OglTex>, vfs=std::shared_ptr<IVFS> (use count 4, weak count 0) = {...}, pathname=..., flags=flags@entry=17) at ../../../source/lib/res/h_mgr.cpp:518 518 h = alloc_new_handle(type, vfs, pathname, key, flags, &args); (gdb) print pathname $1 = (const VfsPath &) @0x7ffebb105730: {path = L"cache/mod/fonts/sans-16.png.5e0d34defe0a67d4.dds", separator = 47 L'/'}

yep, great, it look like to match this, my only remark would then to use "C" instead of "en_US" for default tests.

-Introduction / My life - I recently played 0ad alone and with my daughter, and i am very very pleased with that game. Beinig a developper i decided then to dig further into it, and to do so it built it under my debian 10 system. If built goes well, when i start game i get warning window popup and broken fonts, it seems to affect some fonts, so i did run test to see if my environment has something wrong - test - binaries/system/test Running cxxtest tests (336 tests).............................................................................................................................................................................................. In TestFmt::test_basic: /extmounts/var/develp/games/0ad/0ad/source/ps/tests/test_fmt.h:43: Error: Expected (fmt::sprintf("%f", 0.5f) == "0.500000"), found ("0,500000" != 0.500000) /extmounts/var/develp/games/0ad/0ad/source/ps/tests/test_fmt.h:44: Error: Expected (fmt::sprintf("%.1f", 0.1111f) == "0.1"), found ("0,1" != 0.1) So problem here is that "," is used to separate float part instead of '.' . this is clearly a problem of locale. Even with playing with LC_ALL, LC_NUMERIC or other LC_XXX variable, test can't pass. Here my supported locale : locale -a C C.UTF-8 POSIX fr_FR.utf8 i don"t support by default en_US.UTF8 this is the origin of my problem. So i dig into code to find that line within test_CStr.h that is run before char* old = setlocale(LC_NUMERIC, "fr_FR.UTF-8"); Then in test_fmt.h char* old = setlocale(LC_ALL, "en_US.UTF-8"); So here are my remarks : if locale is not supported by system then setlocale does nothing, return NULL and keep previous locale. it might be sufficient to use LC_NUMERIC for fmt whatever happen old will not be populated with previous locale but with the one currently set so setlocale(LC_ALL, old) won't reset it. terminology 'old' for variable name is then misleading. perhaps using setlocale(LC,NUMERIC,"") is good enough to reset numeric locale from environment "en_US.UTF-8" is not necessary supported, to be portable either "C" or "POSIX" could be used. This is a very long text for a very minor detail, but i wanted to talk about it since it took me thee hours to narrow it. now i can try to propose a fix, still i did get it from gitlab, can i propose a fix by forking on gitlab or should i use a svn account ? i am less used to svn that to git... is irc channel #oad a wy to get in touch or what is the best way ?