Apparently the C standard committee and Microsoft couldn't agree on how
swprintf should work.
We previously tried to work around the resulting breakage, but I just got
the following compilation error. It's really better to avoid that function
entirely. Since we only used it in windows-specific code, the
windows-specific _snwprintf is a nicely compiler-independent replacement.
src/platform/PlatformAbstraction.h: In function ‘int swprintf(wchar_t*, size_t, const wchar_t*, ...)’:
src/platform/PlatformAbstraction.h:243:12: error: redefinition of ‘int swprintf(wchar_t*, size_t, const wchar_t*, ...)’
/usr/lib/gcc/i686-w64-mingw32/4.6/../../../../i686-w64-mingw32/include/swprintf.inl:30:5: error: ‘int swprintf(wchar_t*, size_t, const wchar_t*, ...)’ previously defined here
A missing fixed conversion let the shape check happen at or around position 1/1 instead of at the actual object position.
Also removed a redundant contact check.
Technically this mark is incorrect; we do not handle things differently
on high DPI settings. On the other hand, marking OC DPI aware means that
Windows won't try to scale our drawing, clipping menus and rendering in
the process.
Somewhere in the future, OpenClonk should also add proper DPI awareness
and change the default zoom and menu scaling to match.
Instead, use the first connected output from the list of all outputs.
This happens on my computer, probably because the desktop environment
does not set the correct primary output.
Most of the processing was already done by C4MessageInput::ProcessInput and
C4MessageInput::ProcessCommand. Simply move the Lobby-only commands there,
too, and make them work without a Lobby MainDlg. This required almost only
cosmetic changes.
In practice, only the xrandr code path received any testing. Since Clonk
works fine without changing the resolution, this will not terribly
inconvenience anybody still stuck on old systems without xrandr.
Also only minimize the window when the resolution was changed.
The minimization is there to prevent accidental focus restoration
resulting in unwanted resolution switching.
OR'ing an enum value and a char with its highest bit set sign-extends the char.
On compilers with signed chars, this means you end up with a negative integer,
which can't be narrowed to uint8_t at initialization (which is what PacketHdr's
first member is).
This makes functions independent of their "Code Owner"s, which removes the
necessity to maintain that connection and carefully reset functions when
their scripthost is cleared.
Also set default to 8. This might be a pretty controversial change, but
the amounts of screenshots we have at zoom levels beyond 4 just calls for
a more high-res approach.
Pretty awkward compromise, but the array version seems to confuse a lot of
drivers, without causing an actual error. So this is probably better in
practice until better drivers are more common.
"Anon" referred to the fact that these proplists have neither a number,
like simple proplists, objects and effects, nor an ID like Definitions.
However, they now store the names of the global constant or property they
are in, so "Anon" is no longer appropriate.
There are now three classes of proplists:
- ordinary proplists (C4PropListScript) have a number only in the savegame
- objects and effects (C4PropListNumbered) always have a number
- proplists created during initialization (C4PropListStatic) have a path
So the function could be called NewNamed, but the source of the proplist
has been far more stable than the method used for serialization, and Static
somewhat describes the source.
Nicolas Hake