vladislavbelov

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!

I can suggest to add a new tab (like "Advanced Graphics"), if we can't increase the size of options window. If it was accepted, it'll be mostly about low level problems, like Intel crashes, backward compatibility. Because the Graphics Room is more low level oriented.

As far as I see reShade has own modification (or implementation) of the SMAA: https://github.com/crosire/reshade-shaders/blob/master/Shaders/SMAA.fx But the original one is present there as well: https://github.com/crosire/reshade-shaders/blob/master/Shaders/SMAA.fxh

If you'll select many units, artifacts would be noticed well. Also reshade touches our texts, so they became blurry. About image quality: on high density display I don't see the aliasing at all, on low density display I see both (aliasing and SMAA artifacts). So the image quality is pretty subjective. It'd be good to give a choice in options. That's good. To use any line of its code they should have a compatible license, and it has BSD 3-Clause license. So, probably it's compatible.

I see a strange artifact there: AA is good thing, but it requires a precise work to not add new artifacts (e.g. artifacts on textures with thin lines). Time will tell.

Hello and welcome to the forum! Unfortunately I suppose that we can't allocate more than 4GB of memory per game. Because we compile the game and depended libraries (among them SpiderMonkey) as a 32bit application. There're few ways to allocate more, but it costs more and requires low level changes in the game/SpiderMonkey. I think there is a limit of 1 million elements for standard arrays, because usually an element costs at least 4 bytes (standard int32), it means 4GB of memory. You could allocate up to 4 million elements by Int8Array, but it won't solve your problem in common case. I can suggest to try compile the game in 64bit mode (but I don't know, would it work or not), or to manage AI by a separate 64bit process, or try to optimize your algorithm to fit into 4GB of memory.

Hello! The error means that the game used all free video memory. It may happen because of shadows, try to choose a lower shadow quality (size of a shadow map depends on a window size). I don't speak Spanish, so, if someone could translate it.

I like these autumn landscapes (both of them). No way!

You could describe the solution to help someone who'll repeat the problem

I think you don't need the full Visual Studio pack, I compile pyrogenesis autotests with the MSBUILD console tool, without Visual Studio running. Perhaps it's possible to connect it to the CodeBlocks.

I'll try, I don't have the callstack currently.

I have it too on 10.12. There is a patch for this problem.

On the feedback server, because by GDPR we need a transparent control of data. So this all is going in bounds of GDPR following.

Thank you for reporting. Technical reason of the error: we automatically redirect HTTP request to HTTPS during mirgating, and 301 is the number of HTTP error.

Yeah, it'd be good.

Yeah, it may crash, because OpenGL driver won't allocate the buffer, he will return the invalid ID and we will try to use it. Also we wanna use 16 bit indices, so we try to fit into 64KB of memory. Memory cost is equal to: numberOfVertices * sizeOfOneVertexStruct. So it may take a place here too.

As far as I remember we don't have this hardcoded number, but usually we limited by Vertex Buffer Object size. And different videocards have different constraints. So 32768 is an approximated minimum. Feedback should give us more exact limits.

It's the falling star P.S. It's the known problem, but we need the replay to check it after fix. Does it reproduce the bug for you and could you attach the replay?

Did we fix it in SVN?

We'd get no spaghetti code, If we correctly split our code. Pure Vulkan is much more volumetric. So we need some time to make this way easier. Also there's MoltenGL, but I don't, is there a free version for open-source projects.