vladislavbelov

It really depends on frame. Try to move the camera for some empty space. Or order all 1000+ units to move. Unfortunately we have only 56% of players who support the GL4+. Also I suppose in most cases GL4+ means Vulkan too. It also gives a lot of opportunities to optimize. We use a lot of space in our VBOs, we don't even use compressing. The most important thing I really want to know from Intel: why drivers crash? (We don't see so many of them for other vendors).

Hi @John and welcome to the forum! Could you post your system info? You can find it at the logs folder: https://trac.wildfiregames.com/wiki/GameDataPaths#Windows

You're absolutely right! I concentrated on the feedback results and politeness to our players and forgot about some entertainment, because we're the game. Thank you!

Thank you for your feedback! One of few means that I'm not alone I'd glad to hear more detailed presentation's fails from you. Anyway I'll try to improve it!

Yes, it's true, but it requires time. I could suggest to install another version of wxWidgets.

I told you about architecture in general, not a certain function. You're right, start point is the frame function. But a lot of details are hidden behind functions inside the frame. The first ticket doesn't look like the C++ part changes. I'm not sure about the second one. But the third one is definitely about C++. It doesn't have breakpoints in a usual understanding. It has assertions (ENSURE), that could be breakpoints for some implementations/configurations. So in this task you need to replace some relevant ENSURE to LOGERROR (not all): https://trac.wildfiregames.com/browser/ps/trunk/source/network/NetServer.cpp.

Have you run a match in the game? Does it work?

Hi @Kam, welcome to the forum! Actually you don't have to make an application for programming. There is a wiki page https://trac.wildfiregames.com/wiki/GettingStartedProgrammers to start. I suppose you already have seen it. Our engine has a popular single loop based architecture. You can follow it in the main.cpp, it looks like: while (gameIsRunning) { cleanupProfiler(); // Common stuff tryStepLoadSomethingIfPresent(); processEvents(); processNetwork(); updateGUI(); updateGameState(); // Including simulation // Rendering stuff prepareForRendering(); findAllVisibleActorsForSun(); renderSceneToShadowMap(); findAllVisibleActorsForCamera(); renderSceneToScreenBuffer(); doPostProcessingIfEnabled(); renderGUI(); swapBufferToRealScreen(); // End of the frame recordProfiler(); }

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.