-
Posts
1.395 -
Joined
-
Last visited
-
Days Won
24
Everything posted by vladislavbelov
-
Frozen development
vladislavbelov replied to Nescio's topic in Game Development & Technical Discussion
I'll try, I don't have the callstack currently. -
Frozen development
vladislavbelov replied to Nescio's topic in Game Development & Technical Discussion
I have it too on 10.12. There is a patch for this problem. -
Automatic feedback not possible in snap (?)
vladislavbelov replied to nederbelg's topic in Bug reports
On the feedback server, because by GDPR we need a transparent control of data. So this all is going in bounds of GDPR following. -
Automatic feedback not possible in snap (?)
vladislavbelov replied to nederbelg's topic in Bug reports
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. -
13th Century Europe Mod - In Development
vladislavbelov replied to Bigtiger's topic in Game Modification
Yeah, it'd be good. -
13th Century Europe Mod - In Development
vladislavbelov replied to Bigtiger's topic in Game Modification
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. -
13th Century Europe Mod - In Development
vladislavbelov replied to Bigtiger's topic in Game Modification
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?
-
Frozen development
vladislavbelov replied to Nescio's topic in Game Development & Technical Discussion
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. -
Frozen development
vladislavbelov replied to Nescio's topic in Game Development & Technical Discussion
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. -
Frozen development
vladislavbelov replied to Nescio's topic in Game Development & Technical Discussion
I hope we'll find a way to fix the macOS build. Also you always can run older versions -
Frozen development
vladislavbelov replied to Nescio's topic in Game Development & Technical Discussion
I have macOS (I said it some time ago), but I can't bundle the game, because it has a different framework. -
The Implementation of LODS
vladislavbelov replied to Rolf Dew's topic in Game Development & Technical Discussion
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.- 7 replies
-
- 2
-
-
- lods
- development
-
(and 1 more)
Tagged with:
-
I'm here now, I was at vacation I'll try to answer to all messages, sorry for delay.
-
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.
-
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.
-
It's not so critical as it could be, but it's still UB and should be fixed. But how it may work: How usually (compiler depended) new[]/delete[] work: new[] allocates a block with a needed size + a space for size - a number of objects. delete[] extracts a size from the block and calls a destructor for each object and deallocates the block. But! u8 is a basic type, not an object. So a compiler may replace new[] by new for basic types or use another trick, especially in case all actions are in the same place and the compiler knows a storing object. Also we have own pool and arena for some cases. Not all, i.e. clang-802.0.42 doesn't detect it for basic types (for N5 too), only for objects, even without -O0+. Probably because of the trick above. We had an option for it sometime ago, if I'm not mistaken. It was called --enable-address-sanitizer. It'd good to add a regular (1 per week) build on Jenkins.
-
I already answered to your post on the habr. But thanks a lot again for helping to find errors. Only few of them are known, and patches are waiting for the end of FF. UPD. I will create tickets for missed bugs, when I'll be at home.