* picomodel: do some guessings about shader paths to handle more cases out of the box; ones are based on material and diffuse map names:
name w/o path: assume textures are in the folder, where model file is
absolute path or with ..: try to cut at "/models/" or "/textures/" (as if leading to game folders); do previous case, if not
strip extensions and turn slashes to forward ones anytime
* picomodel::obj: fix diffuse map paths loading from .mtl
Thomas Debesse [Wed, 7 Apr 2021 04:44:00 +0000 (06:44 +0200)]
q3map2/image: also look for images path without extension but with dot in their name
make sure that if a shader contains path to textures/directory/some.thing
q3map2 also look for textures/directory/some.thing.tga
instead of only looking for textures/directory/some.tga
Antoine Fontaine [Tue, 23 Mar 2021 02:35:37 +0000 (03:35 +0100)]
radiant/preferences: fix memory issue when saving pref
Valgrind:
```
==80929== Invalid read of size 2
==80929== at 0x4842B30: memmove (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==80929== by 0x43618E: char* std::__copy_move<false, true, std::random_access_iterator_tag>::__copy_m<char>(char const*, char const*, char*) (stl_algobase.h:386)
==80929== by 0x435ABC: char* std::__copy_move_a<false, char const*, char*>(char const*, char const*, char*) (stl_algobase.h:404)
==80929== by 0x436131: char* std::__copy_move_a2<false, char const*, char*>(char const*, char const*, char*) (stl_algobase.h:440)
==80929== by 0x4359BF: char* std::copy<char const*, char*>(char const*, char const*, char*) (stl_algobase.h:474)
==80929== by 0x59F28C: Array<char, DefaultAllocator<char> >::Array<char const*>(char const*, char const*) (array.h:86)
==80929== by 0x59A2A0: Preferences_Save_Safe(PreferenceDictionary&, char const*) (preferences.cpp:207)
==80929== by 0x59C7A2: Preferences_Save() (preferences.cpp:919)
==80929== by 0x524500: Radiant_Shutdown() (mainframe.cpp:798)
==80929== by 0x5223FB: main (main.cpp:654)
==80929== Address 0xba88510 is 0 bytes after a block of size 64 alloc'd
==80929== at 0x483B723: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==80929== by 0x483E017: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==80929== by 0x5272F3F: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==80929== by 0x5290003: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==80929== by 0x5290066: g_string_sized_new (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==80929== by 0x52905BA: g_string_new (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==80929== by 0x59B65A: PrefsDlg::Init() (preferences.cpp:551)
==80929== by 0x5222A1: main (main.cpp:595)
```
The default value for gtk_gl_area_set_auto_render is true…
So removing the call setting it to true has no effect.
The ui::process() call was reported to improve performance
when using a multi-window layout and GL texture binds fail
because of no sharing mechanism accross GL contexts. So it's
just dark magic and we may better fix that sharing thing first.
Thomas Debesse [Wed, 10 Mar 2021 06:25:34 +0000 (07:25 +0100)]
macos: workaround the laggy XY/Camera window mouse pointer recentering
On macOS, a huge lag occurs when the pointer is recentered.
This happens when calling GTK functions to set the pointer
at the center of the widget so it looks to be a lag in GTK
or in underlayer macOS technology GTK relies on.
When that mouse pointer recenter is disabled, one can drag
infinitely without lag BUT then comes weird bugs because
the “released right mouse button” event is only read when
the mouse is over the widget, so if one releases over
another widget, the mouse pointer is not released
and if one do another right mouse click on another XY widget,
the internal state becomes corrupted and a crash is
expected to happen soon.
So the idea of that workaround is to only reposition
the pointer when an edge of the XY/Camera window is reached,
so the user does not experience lag for the whole size
of the XY window, experiencing the lag only when a
whole dimension is moved. To optimize the distance
the user can move without lag, when an edge is reached
the pointer is repositioned on the opposite edge.
It was noticed the pointer is not hidden on macOS when
moving the map, so the pointer being visible during
all the move operation is not restored to the initial
position when it is released, but keep the position
currently seen by the user at right mouse button release
time.
Note: It was noticed it is possible to esscape the capturing
widnow when the render is slow and framerate is low, it
may also occurs with touch screens (like virtual machines has)
to move the pointer out of the XY/Camera widget and get the
internal state corruption problem.
Thomas Debesse [Mon, 8 Mar 2021 08:31:53 +0000 (09:31 +0100)]
easy-builder: always sync before doing serious things to prevent issues happening with slow I/O on macOS
errors like that:
> CMakeFiles/gtktheme-mojave.dir/build.make:73: CMakeFiles/gtkglext.dir/build.make:73: CMakeFiles/gtktheme-mojave.dir/progress.make: No such file or directory
> ginstall: cannot change permissions of 'netradiant/build/lib/gtkglext-1.0/include/gdkglext-config.h': No such file or directory
> mkdir: netradiant/build/registry: Operation not permitted
> clang: error: no such file or directory: '../../libs/libcm.a'
projects / xonotic / netradiant.git / log