Jump to content

vladislavbelov

WFG Programming Team
  • Content Count

    630
  • Joined

  • Last visited

  • Days Won

    8

vladislavbelov last won the day on July 7 2018

vladislavbelov had the most liked content!

Community Reputation

475 Excellent

2 Followers

About vladislavbelov

  • Rank
    Centurio

Previous Fields

  • First Name
    Vladislav
  • Last Name
    Belov

Profile Information

  • Gender
    Male
  • Location
    Russia

Recent Profile Visitors

2,013 profile views
  1. It's a good tool. I'm using it for a while. But it still misses some good features from RenderDoc, which doesn't support our GL unfortunately. We mostly use 1 draw call per each GUI element. It'd be good to refactor it and to use only 1-2 draw call per all GUI.
  2. Also can it be the compatibility mode in Windows (where you can run an application with Windows XP compatibility)?
  3. I'm not sure that's in the case. But we have wrong Windows version detection. We can't detect Windows 10 correctly.
  4. It's possible, but much more expensive. I don't think that we will have that until we drop all GL versions less than 3.
  5. Hi, it's possible and it wouldn't be really hurt for performance. I'd prefer to add it with weather and sun. Brightness of clouds or objects really depends on environment brightness: (http://homo-creativus.info/wp-content/uploads/2014/06/IMG_5932.jpg)
  6. Yeah, every function that may invalidate the constant reference is potentially dangerous.
  7. We talked with @elexis about constant references and I gave an example why passing by value may be better than passing by constant reference. During todays refactoring I met another important things that you need to know about constant references. Aliasing Take a look at the following code. Do you see a problem? (It's our code from ps/Shapes.h). // Interface class CSize { public: // ... void operator/=(const float& a); // ... public: float cx, cy; } // Implementation void CSize::operator/=(const float& a) { cx /= a; cy /= a; } If not, would the following usage example help you? CSize size(2560, 1440); // Normalize the size. if (size.cx) size /= size.cx; debug_printf("%f %f", size.cx, size.cy); You'll get: 1.0 1440.0 Because the a references to cx, and the first line of the operator modifies the cx. And in the next we just divide the cy by 1. It may happen in each case where we get the same class. I fixed the problem in D1809. Lifetime Another important thing is a lifetime. Let's take another look at another example (fictional, because I didn't find more detailed example in our code yet): std::vector<Node> nodes; // ... duplicate(nodes[0], 10); // ... void duplicate(const Node& node, size_t times) { for (size_t i = 0; i < times; ++i) nodes.push_back(node); } From first look it seems ok. But, if you know how std::vector works then you know, that on each push_back std::vector can reallocate array to extend it. And then all iterators and raw pointers are invalid, including our constant reference. So after few duplication calls it may contain a trash. So, you need to be careful with such cases.
  8. Do you want to draw on terrain or only to place entities? I think sparse tree isn't bad to place entities, but I'm not sure. Also I already suggested many times to use brushes in JS and do not use heightmaps or direct modifications. I think processing brushes on C++ side may give a speedup. It depends on area. I think it's worse for our case .
  9. I suppose that the first OOM happens because of JS. Also I think you don't need to increase the heightmap resolution, but the texture map resolution. It's possible, but it requires a lot. Because you need to store this information, but the compression is limited. Possible solutions: Megatexture technique (Sparse Virtual Textures). It still requires to store the whole texture (on disk). Also modern OpenGL (3.3+) is needed for an efficient application. Mixture textures or blend textures (a more possible solution for us and similar to Oblivion AFAIK). It requires a space too. We may use our terrain patches and limit a max number of textures per patch to 4 and use an RGBA texture to mix them. Now a quality of paths depends on these textures sizes. For example: 1024 map = 64 x 64 patches, let assume that the resolution is 4 pixels per patch cell (pretty small for smooth details) = 64x64 pixels per patch, 64MB without compression in total for the whole map. A bigger resolution requires a lot more because of square. Also you’re able to store an additional texture as an interpolation configurator to decrease the main texture. Prepared patterns, it's similar to the previous one, but we don't allow a full flexibility of mixture textures. We suggest prepared mixture textures and map makers use them by their indices. Or they add some by themself (but it requires a bit more space). It allows to use 32x32 (1024 patterns per 1024x1024 texture) or 64x64 (256 patterns per 1024x1024 texture) pattern textures per cell. Paths (it's like vector for rasterized pictures), it's good until we have a lot of paths. Its performance depends on number of paths. 2D sparse voxel based terrain rendering, it's pretty similar to the megatexture but in terms of vertices and geometry instead of textures. So I think megatextures are preferred here. These solutions that I remember and shouldn't be hard to map makers. From a superficial look, the third solution looks pretty fine, not much space, not much performance losts. Very likely there're other solutions, but I need time to think and analyze them.
  10. Offtopic, but I have an idea: what if we add semi-supported languages as a mod?
  11. Which wxWidget version is in your Linux? Possible solutions: a) install newer version of wxWidget; b) run it with X.org, not with Wayland.
  12. Multithreading isn't a silver bullet. It requires a lot of stuff: you need to synchronise different threads, you need to pass data between threads and you need code it without races. It costs a lot of time for complex projects, so as Stan said we may not have a visible benefit at all. Or its cost would be really huge. So it should be analysed before introducing the multithreading in all stuff.
  13. <offtopic> Actually 0A.D. uses async/await during its development. For example some of my patches are waiting for other patches that are waiting for review (promises!). At the same time I may create async patches that are not related to the previous ones. </offtopic>
×
×
  • Create New...