Jump to content

s0600204

WFG Programming Team
  • Content Count

    205
  • Joined

  • Last visited

  • Days Won

    5

s0600204 last won the day on December 25 2014

s0600204 had the most liked content!

Community Reputation

289 Excellent

2 Followers

About s0600204

  • Rank
    Duplicarius

Contact Methods

  • Website URL
    http://s06eye.co.uk/0ad/

Profile Information

  • Gender
    Male

Recent Profile Visitors

1,888 profile views
  1. As Stan' points out, the wonder population aura provides an absolute bonus (+10, increasing to +50 with the research of "Glorious Expansion"), not a proportional one. It it really added a +10% bonus, then one wonder would raise the population limit to 330 (or 370 after researching "Glorious Expansion"). Thus, it is proven empirically.
  2. Bonuses are currently applied thusly: [base] * [proportional bonus] + [absolute bonus] Both +20% and +15% are proportional bonuses, so (at the point where a unit enters the overlap in the radius' of both auras, and assuming no other auras in effect) they are multiplied together to get a total +38% bonus, which is then cached. The caching allows the final calculation to be as above - which is relatively quick to calculate - rather than having to iterate through every aura active on the map, determine if they're in range, whether they should apply, etc... all several times a second. When a unit moves out of the radius of one of the auras, the cached proportional bonus is divided by the proportional bonus of the aura no longer in effect, and the result replaces the old cached value. Absolute bonuses work similarly, except they are added to (and subtracted from) one another, with the result cached: only recalculated when a unit passes in or out of another applicable aura. You might use an absolute bonus to add a given bonus regardless of the base stat (e.g. +5 resource carry capacity).
  3. @abc1: If both auras affect whatever units you're controlling, then yes the effects will combine. @sphyrth: you're asking if 0AD is doing: [base attack] +20% +15% (equivalent to: [base attack] * 1.2 * 1.15) or [base attack] +(20 + 15)% (equivalent to: [base attack] * 1.35) I believe it's the former, which in this theoretical scenario where both auras are in effect, amounts to +38% to unit attack. @Feldfeld: Whether or not an Ally's aura affects you depends on how the aura in question has been defined. It is also possible for an Enemy's aura to affect you if defined to do so. As an example: the Ptolemaic hero Cleopatra has an aura that increases the heath of allied Heroes, and a second aura that lowers the health of enemy Heroes.
  4. As requested, all posts off-topic (and those flaming and/or trolling) have been split elsewhere. Those with value in them may be restored in/as a different thread, later. However, to everyone who posted before the split, regardless of who they be: Be. Nice. It is acceptable to disagree with someone else. It is not acceptable to insult, to demean, or be overly aggressive in your posts. I hope that is clear to everyone. No exceptions. Oh, and please keep on-topic in future, thanks!
  5. (Split posts out of original thread as it was off-topic there.)
  6. For what it's worth, the warnings above for AtlasObjectXML.cpp concerning the implicit fallthroughs should no longer occur as the code has been rewritten to no longer need the break-less switch...case statements at all. @eecsninja, thank you for your patch. It is unfortunate that it wasn't included (due to it being superseded by work being undertaken pursuing another objective), but we appreciate the effort .
  7. (./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.
  8. Your old friend is busy. Please have patience. In the meantime, you can test the proposed fix here: https://code.wildfiregames.com/D1919. If it works, then we can include it. Edit: At 10:57 UTC today, the patch was committed. Your problem should now be fixed. Don't forget to update your local copy.
  9. 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.
  10. 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. As a loose idea as to how many distributions have the fonts available in their package repositories (stats courtesy of Repology): LinuxLibertine : 66 packages (across 20 "families") DejaVu : 145 packages (across 33 "families") FreeFont : 122 packages (across 26 "families") TeX Gyre : 37 packages (across two package names across 5 "families") 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 distributions. CentOS, Fedora, OpenSUSE, OpenMandriva, and Slackware are the ones that are noticeably problematic. Yes, Windows and OSX would most likely still need the fonts bundled with the game. The way I see it, we have three possibilities: We change nothing, but tell the packagers to exclude the "binaries/tools/fontbuilder" when packaging the "0ad-data" package for their repositories. 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...) 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). 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.
  11. 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
  12. @Angen sure. You can find slightly more up-to-date code here; and some more information/musings here, which includes links to where the civselect screen was first proposed and a ticket (that arguably went off-topic) that also uses the code.
  13. 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 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.
  14. The "View online" and "Decline" strings are in the "Mod Selector" resource on Transifex. "Publications" and "Terms" were translated after the RC was created.
  15. 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.
×
×
  • Create New...