vladislavbelov

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.

As Stan said we support only prerendered fonts. So an additional language requires an additional font textures, like for Chinese languages. Cairo is pretty complex, so it requires a lot of time to replace our GUI rendering. I think it'd be better to use a smaller library, because it'd be much easier and it'd still easy to replace it by Cairo.

+1. Especially from this studio, it seems they discovered design and UX just now.

I'd call it an additional option, because we have some custom things. Brew can be an alternative option in case we remove these custom things.

Could you disable all effects and try again?

If you try to build the game with a different build system, you'd need to know which dependencies are needed. Because it seems, that you didn't install SpiderMonkey. Old != invalid. Also we can't use brew yet, because brew supports well only 10.11+, 10.5–10.10 are supported on a best-effort basis (https://docs.brew.sh/Installation), but we support 10.9+ (for bundles 10.7+). I don't think that the brew can fully replace the script, because we need to use custom compilation options and to patch some libraries anyway.