vladislavbelov

Could you post your system details (OS, its version, CPU, GPU, etc)? Did you compile the Atlas or you use the packaged one? Which version of wxWidget do you have? From first look it seems that it's a problem with wxWidget.

It also requires a visual comparison. Are they visually equal for all distributions? I think we can just move fonts. Because currently we don't even need them on user machines. The important step is the font rendering - to use real fonts instead of prerendered pictures. And on this step we can decide how to distribute fonts.

It mostly works for software that tries to looks like the system one or with similar controls (the same design for the whole user system). 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. So we should account it too for the removing. Though we don't use fonts in real-time, but we plan.

Also could you attach here your system info from log paths: https://trac.wildfiregames.com/wiki/GameDataPaths?

Currently we have no such ticket. We can easily add additional layer of skybox, but there should be a smooth transition between sky layers and map. It's a problem with the additional layer. A possible solution is to use a big low-poly terrain that's scaled up, like it's done in Half-Life 2. It's easier to make a transition, but a simple model won't work for different sizes of random maps. Usually players don't see horizons at all. Only in cutscenes or trailers (where we can use some hacks to reach the goal). So it's in my list, but not on the first place.

You can do locally whatever you want to develop/test/understand the project If you want to add it to the game repo, I'm not sure, that it's needed. But some base stuff can be tested inside tests.

Hi, try to use existing projects, example of the "engine" solution: source_dirs = { "ps", "ps/scripting", "network/scripting", "ps/GameSetup", "ps/XML", "soundmanager", "soundmanager/data", "soundmanager/items", "soundmanager/scripting", "maths", "maths/scripting", "i18n", "i18n/scripting", "third_party/cppformat", } extern_libs = { "spidermonkey", "sdl", -- key definitions "libxml2", "opengl", "zlib", "boost", "enet", "libcurl", "tinygettext", "icu", "iconv", "libsodium", } if not _OPTIONS["without-audio"] then table.insert(extern_libs, "openal") table.insert(extern_libs, "vorbis") end setup_static_lib_project("engine", source_dirs, extern_libs, {}) Add your project near to these lines.

By this picture: The bottom curve of edge is the same direction as the top one. I think the bottom edge should be like this:

Hi @Pixma! As I said on Discord, #ifdef isn't needed if you use adapters. And vice versa. I know only few low-level libraries for that kind of things. The problem of abstractions (of libraries that I know), is that they mostly have only core things and sometimes visible performance differences. If you want to use some specific stuff (e.g. we use post-processing only if the render to texture is supported by driver), we need to modify the third-party library or do an ugly workaround. So if a library that fits in our requirements doesn't exist, then the adapter model is the best for us, I think. In that case we don't need many APIs. I'd prefer to support only OpenGL and Vulkan, it means less duplication of shader code and more compatible things (like many GLSL > SPIR-V translators). Why the performance is important? Because we support old machines (e.g. with GL 1 & 2), and it means we may don't notice some performance difference, that can be noticeable on slower machines.

That'd awesome, our logo well fits as a hood ornament

Did you run the profiler in these matches? It may tell us, what time was spending for.

Yes. Such big changes require a really precise and careful review, especially of threading + C++. I already see few suspicious places.

You're welcome!

Everything is simpler: you're building debug, but running release. To run debug you need to run the pyrogenesis_dbg

I removed unrelated things from your patch and tested it. And it works. I attached my version of the patch. changes_short.patch

We still have some limitations there. We need XML declaration for an attribute to use it in JS (like selected_column_order). Try to add scrollbar_percentage="0.0" to the replaySelection object: <object name="replaySelection" size="0 35 100% 100%-24" type="olist" style="ModernSortedList" sortable="true" selected_column="months" selected_column_order="-1" font="sans-stroke-13" auto_scroll="true" scrollbar="true" scrollbar_percentage="0.0" > Btw, I can suggest to try use an already existing implementation (ModIo) for the client. Also we put all server/utility stuff in the tools subfolder, because it's not a part of the game.

Exe was, but a script updating this revision wasn't run.

So currently the number means a revision of the pyrogenesis (game engine), not of the whole game.

Good interactive visualization tool: https://qiao.github.io/PathFinding.js/visual/

One-by-one to the same thread isn't equal to one-by-one to a different thread. AFAIK most messages are sent to the same thread.

Passing events one-by-one isn't a good idea, because it significantly decrease performance. At least they should be processed by enough big blocks. But, I suppose we don't need all these event messages on the pathfinder thread side at all. You only need a graph-data and requests. So it's possible to add an interface of the pathfinder worker thread to the main thread. This interface will aggregate all only needed events, convert them into a more compact data and pass to the worker thread. Then it'll receive batches of answers and convert to messages. I didn't look much at our pathfinder code, so I can be wrong somewhere. I think @wraitii could help much more here.

Yes, but in case of N requests you need to do Application > Driver > GPU synchronisation N times, and update all data too (both on CPU and GPU to calculate next request). That's what I'm talking about. That's good. I wish you a nice coding regardless of result you'll get

Unfortunately not all cards has standard floating point precision, e.g. sqrt on different cards may be different and even different from IEEE standard for it. But I don't think floating point is really needed for pathfinding. If needed - there is a problem, because we should have the same result for all users. There is DMA, it depends on drivers, but some middle cards support it. Example, we have the next simple field (0 - passable cell, 1 - wall): 0 1 0 0 0 0 0 1 0 Let's we have two units in (x=0, y=0) and (x=0, y=2), and they need to be in (x=2, y=1). How the parallelised algorithm will solve it? What would be an answer?

There're constraints when you try to move calculations to GPU. I.e. we have depended data (two units can't exist in the same position). The article you provided: I had only a fast look and I'm not sure, but it seems that they calculate all states independently. Correct me, if I'm wrong. I'd recommend to train on codeforces.com, if you're not there yet

It'd be good that they're the same. Anyway thanks for the links!