vladislavbelov

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.

Probably we'll find an open-source library that converts OpenGL calls into Metal calls. That'd be really helpful for the developing. It also may limit some old versions of Windows, because of no drivers with VK.

I hope we'll find a way to fix the macOS build. Also you always can run older versions

I have macOS (I said it some time ago), but I can't bundle the game, because it has a different framework.

As Stan said, for most lagging moments the rendering doesn't spend much time in comparison with the pathfinder. LOD can be supported on the engine side, but the instancing already has prototype. LOD is best when all models are different/some models are highpoly, Instancing is best when all models are the same. I.e. LOD would be better for buildings like CC or Wonder with many polygons. instancing - for many similar trees. But again quoting Stan, LOD requires an artist work. That's the good idea, reusing may save memory and performance.

I'm here now, I was at vacation I'll try to answer to all messages, sorry for delay.

It could be FreeType too, it just requires some refactoring for the GUI code (we already have a lot of patches for refactorings). I hope we'll try to make a solution for the next release.