Jump to content

s0600204

WFG Programming Team
  • Posts

    261
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by s0600204

  1. (./source/ps/VideoMode.cpp, line 247)

    Error appears self inflicted - this is the same code block as it appears in our code repository:

    	u16 ramp[256];
    	SDL_CalculateGammaRamp(g_Gamma, ramp);
    	if (SDL_SetWindowGammaRamp(m_Window, ramp, ramp, ramp) < 0)
    		LOGWARNING("SDL_SetWindowGammaRamp failed");

    Looking at the history of the file, the line in question has never read SDL_CalculateRamp. Thus, this error appears to be caused by local modification by user.

    Neither SDL_CalculateGammaRamp nor SDL_CalculateRamp appear anywhere else in the source files.

  2. The change is now live in our code repository. To use, simply add the appropriate argument:

    ./update-workspaces.sh --prefer-local-libs

    Then run make as usual. You will also need a file in /etc/ld.so.d.conf with the contents /usr/local/lib so that the runtime linker can locate the local libraries. (If you're compiling and using local libs on a regular basis, there may already be such a file present.)

    The build instructions on the wiki have also been updated.

    • Thanks 1
  3. Considering how we currently use fonts, it does seem odd that the source files are bundled with the game. I guess they're only there because they're in the "binaries" folder, and that folder is bundled almost in its entirety.

    23 hours ago, Itms said:

    There is no guarantee the fonts will be present in all Linux distributions.

    As a loose idea as to how many distributions have the fonts available in their package repositories (stats courtesy of Repology):

    And for the eastern Asian languages:

    • Hanazono : 48 packages (across 10 "families")
      • Japanese Kanji
    • Source-Han-Sans : 92 packages (across 13 "families")
      • Pan-CJK characters

    (Repology groups distributions by "family", e.g. Ubuntu, Debian, SteamOS, LinuxMint are one "family". If you're running LinuxMint, then as LinuxMint is derived from Ubuntu, then the repositories for the appropriate version of Ubuntu are mostly compatible with your LinuxMint system. It's not a perfect categorisation, but as a rough guide it works.)

    Alternatively, here's something I threw together to more easily compare some of the commonly used distributionsCentOS, Fedora, OpenSUSE, OpenMandriva, and Slackware are the ones that are noticeably problematic.

    On 2/3/2019 at 9:44 PM, stanislas69 said:

    Not sure about crossplatform compatibility.

    Yes, Windows and OSX would most likely still need the fonts bundled with the game.

    The way I see it, we have three possibilities:

    1. We change nothing, but tell the packagers to exclude the "binaries/tools/fontbuilder" when packaging the "0ad-data" package for their repositories.
    2. We remove the font files entirely, make the files' respective packages a build-time-only dependency, and write instructions on where to download the files for systems that don't have a package repository or do but lack the specific packages. (The caveat is that we don't use them at build-time either...)
    3. We relocate the font files somewhere else within our repository, such as into a subdirectory under "libraries/source/".

    I think I personally favour a combination of the second and third: move the files and then, when we get in-game rendering working we add package dependencies and use the new location as a fallback (whether that be as the source of a 0ad-fonts package, auto-bundling of the fonts by build-osx-bundle.sh, and/or some other solution).

    22 hours ago, vladislavbelov said:

    [...] But it doesn't work always for custom designed applications like the 0 A.D. game. A new version of a font could look worse with the current in-game background. [...]

    I think the fonts we use are reasonably stable (LinuxLibertine and FreeFont haven't had any releases since 2012, and DejaVu since 2016. TeX Gyre is the most recently updated at 2018, but the release before that appears to have been 2016).

    I would imagine that if the typeface anatomy of fonts change too much between versions, then the font's creators would possibly get complaints from their user-base. Also, some of the fonts we use claim to be a like-for-like replacement (Gyre Pagella for Palatino), or to have the same appearance as - but a wider character range than - another font family  (DejaVu for Vera), and so in theory shouldn't deviate too much from their "inspiration".

    I get what you mean though: having two users with what should be the same font but - due to changes between versions - are visually different could disrupt our established visual style (such as it is), or make for an inconsistent experience between users.

    It is true that many games get bundled with their own fonts, even on Linux systems (eg. SuperTux, SuperTuxKart).That might be down to simplicity: they have to bundle the fonts for Windows and OSX systems, so it's easiest to just do the same for Linux as well.


    Huh, this turned into a longer post than I anticipated. Apologies, and congratulations if you got this far without glazing over. :P

    • Like 7
  4. On 12/21/2018 at 4:49 AM, skaiware said:
    On 12/17/2018 at 9:57 AM, s0600204 said:

    You might have a point. I'm not familiar enough with other software projects to know how they handle this in their respective build systems.

    Well I guess the majority of projects today uses cmake and ExternalProject_Add()

    After a bit of research (and playing around a little with both build systems), it appears that projects that use CMake don't have to handle this because CMake handles it for them.

    Comparing how premake and CMake specify which libraries should be included: premake tells the linker to include a certain library but leaves it up to the linker to locate it. CMake, on the other hand, locates the library itself and, should the library not be in /usr/lib, adds the non-standard path via -rpath (an approach that might get them in trouble with certain OSes) so that both the compile-time linker (ld) and the run-time linker (ld.so) can find it.

    Anyhow.

    Taking your suggestion of adding an option to our build system: https://code.wildfiregames.com/D1747

  5. Ach, my apologies, I mean ./build/premake/extern_libs5.lua. (Was getting late and tired.) The simplest change that should work is:

    --- a/build/premake/extern_libs5.lua
    +++ b/build/premake/extern_libs5.lua
    @@ -197,6 +197,8 @@ extern_lib_defs = {
     		link_settings = function()
     			if os.istarget("windows") or os.istarget("macosx") then
     				add_default_lib_paths("boost")
    +			else
    +				syslibdirs { "/usr/local/lib" }
     			end
     			add_default_links({
     				-- The following are not strictly link dependencies on all systems, but

     

    8 hours ago, skaiware said:

    Any needed third parties should be installed in /usr/local/lib, not in the OS system.  

    Looks like the 0ad build system is missing an option to prefer the libs in /usr/local/lib, not the OS ones.

    Would nt such an option (for instance "--prefer-usr-local-libs", adding -L/usr/local/lib to linking commands) resolves this and upcoming linking issues ? 

    You might have a point. I'm not familiar enough with other software projects to know how they handle this in their respective build systems. If you wish to look into it and create a patch for review (more general than the diff above), better minds than I can - and no doubt will - pass comment on it. (See here for how we accept patches.)

    I'm afraid real life commitments (eg. work) are going to take my focus for the next couple of days, so good luck.

  6. 1 hour ago, skaiware said:

    Should nt update-workspaces.sh  add -L/usr/local/lib  to the linking commands ?

    Why should it? That path is already included for search by default. The problem is that it is searched after /usr/lib64, /usr/local/lib64 in that order (plus a couple of distro-specific paths). That's fine for the vast majority of users and systems, it's just problematic in this case.

    What's really annoying is that the gcc search path (for include headers) goes (by default*) /usr/local/include, /usr/include (eg. locally-generated then repo-provided); whilst the compile-time linker searches for libraries in the other direction (repo-provided then locally-generated). (Then you have the run-time linker which doesn't search /usr/local/lib{64} at all. Which does make a sort-of sense, I guess.)

    You could modify ./premake/external_libraries5.lua to append that to the start of the search path (so the linker searches there first - unlike gcc, ld claims not to mind paths appearing more than once); but unless you've told b2 to name the 1.68 libs with the -mt suffix, you'll also have to tell ./premake/external_libraries5.lua to stop preferring files with the suffix -mt over files without.

    * - 0 A.D. messes this up, hence revision.

  7. Do you happen to have another version of boost installed on your system? Perhaps version 1.53?

    Edit: Yeah, that appears to be it. I'm guessing at some point you've installed the boost-devel package from the CentOS repos. Unless you need this for compiling something else, I recommend you remove it. (If you do need it for compiling something else, then will that something compile with Boost 1.68, and if not - well, that's when things get interesting...)

  8. Hi @skaiware, I'm having difficulty replicating your issue with my VM. I wonder if you could run a few things and report back the results?

    1. What is the output when the following command is run?
      ld --verbose | grep SEARCH_DIR | tr -s '; ' '\n;
    2. Could you provide the file pyrogenesis.make (from the folder ./build/workspaces/gcc/)?
    3. Are you trying to compile A23 or the current svn head?
  9. 48 minutes ago, Servo said:

    hummnn seems like the new dmg is not working for MP. I went to a lobby without players and only wfg bots and user1 there.

    Not to worry, this is to be expected. Due to work on resolving various multiplayer issues, there is a possibility that the A23 original-release and the A23 re-release is not fully 100% compatible. Thus, a new lobby instance has been created for the A23 re-release, which is what you're seeing... which has no players in it because we haven't released the re-release yet. Once we do, everyone who updates to the re-release will migrate over.

     

    14 hours ago, Servo said:

    I am pc novice and couldn’t tell if my sound card is internal or external.

    An internal soundcard is one that is internal or built-in to the computer. An external soundcard is one that is connected externally to your computer via a USB, Firewire, Thunderbolt or Lightning (very, very frightening me! Galileo!... sorry) cable. If your headphones or speakers plug directly into your computer, you have an internal soundcard. If your headphones or speakers plug in to a box separate from your computer but connected by a data cable, then you might have an external soundcard. (If connected via an audio cable, then the box is more likely to be an amplifier of some description.)

    • Like 2
  10. (The crash with no soundcard present or available was #4786 / r19877, fixed as of r21097 (by Itms, not me)) I don't recall doing anything else regards to audio problems. Sorry. (Imarok has D1481, but that hides the messages if --nosound is passed.)

    As to @Servo, I think we'd need to know more. Built-in soundcard or external? Version of OpenAL being used? What programs do you have running in the background (anything that might interfere, cause the system to reset the audio connection, or take up a lot of memory)? What happens if you have some music playing in a media player (Quicktime, VLC, or other) in the background - do the errors still occur, does the music cut-out when 0AD loses audio, or something else? If we can find another program that plays ogg files through OpenAL, then we could see if that also suffers from the same problem.

    • Like 3
  11. Huh. On my VM, I was able to successfully compile the game with the provided gcc 4.8.5. And I did not have a package by the name of devtoolset-7-gcc (or similar) installed at all.

    But if you're telling me that it is required for someone using a physical machine, then so be it.

  12. EPEL provides wxGTK3-devel which should do the trick.

    You may have to explicitly tell the build system to use version 3.0. The easiest way to do this is to open ./build/premake/external_libs5.lua and replace the two instances of wx-config with wx-config-3.0

    Re-run update-workspaces.sh and then make in the appropriate folders.

  13. Unless you specified an alternate install path, ./b2 install places the library under /usr/local/ (with the headers in ./include/boost and the compiled bits in ./lib)

    (If you simply ran ./b2, then the compiled bits are in ./stage/lib respective to the b2 script, and you''ll have to copy things manually. It's probably best to use ./b2 install)

    You might need to re-run update-workspaces.sh to register the correct files. The -mt suffix on the library names means that the libraries were compiled with multi-threading support. This appears to not be the default. Either way, update-workspaces.sh should find and link in the correct ones.

×
×
  • Create New...