vladislavbelov

I don't have an implemented solution yet.

Because somethings else is broken I might have a good solution, but not in priority at the moment.

It's incorrect to replace 2.0 by 1.5 because it should convert [0, 1] range to [-1, 1] range, not [-0.75, 0.75].

By the way if the exit button is not so important, is it VIM? I suppose it's not so stretched. It's aligned to the left (right if RTL) with a fixed padding. Which a bit different type of layout in UX. Blender: Office: Browser: The problem with your approach is that you need to skip by eyes a lot of empty spaces to find the each next visual anchor (button text). macOS users I agree that the grouping is a good thing. Though I believe that it needs to be grouped in a more natural way, without a lot of empty space.

Seems like designed for mobiles, not PC displays. Eyes have to walk for a long distance to find important buttons. Which leads to Brownian motion of eyes.

Fixed in rP26229.

What's the map?

Could you attach logs and system_info?

No promises, but I'm working on that

We have some old but relevant (because of our audience and we don't have LODs) rules about polycount: https://trac.wildfiregames.com/wiki/ArtPolyCountGuidelines, but sadly some new models broke them in a bad manner

Have you ran update-workspaces.bat?

Are there some numbers? (Just wondering, I've met various approaches) I suppose it may not tell about Git, but products like Plastic/Perforce. Because they are commercial and companies might pay for their integration.

It means you have never tried to make a signal decoder or a simple calculator with red stone

You just need to look inside the projectile manager

You can draw it by popping a scaled X model. And it's already done (without scaling) in the projectile manager. You don't need shader for that.

Doesn't matter, some gameplay stuff that generates beams and accounts damage.

So it's the question to the projectile manager, not the graphics one, at least for now

Why not replace arrows by the X model and move them by a straight line?

That's why I mentioned static

I mean not effect but the X model. The popular and old trick for grass to use 2 quads (or more sometimes) perpendicular to each other.

We don't have a ready-made solution to create a laser. Currently we can have only static lasers with a X model (like for grass).

"It's not stupid if it works" So now you understand why we can use a plain archive instead of raw files.

It might be hard to believe but it can It's true, but it has a tiny detail. Even the most powerful general filesystem is general, which means it has own tradeoffs. And it can't fit for all possible cases. The same for archives. So the trick is that when we load a mod in pyrogenesis we cache a list of its files and store an offset for each of them. Which means we don't need to do an expensive system call for each file. I might only assume that in your case tar has a worse index.

4MiB are read in both cases: a) for unpacked they are read in a random order file by file with 480 bytes each b) for packed they are read in a random order from a ZIP archive file by file 480 bytes each. All tests have multiple prewarms (they read total size multiple times), so in theory I should have warm HDD caches. Ideally I expect if I read multiple files with a total size less than a cache size then it should have similar time for unpacked and packed mods. But as I mentioned a file system has own meta information and alignment which might increase a "reading cost" of small files.