vladislavbelov

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.

There is also a file system sector size which affects alignment of files (it's usually 4KiB on Windows). I've tested on Windows few file sizes with 2 mods with the same list of files: unpacked and packed. File size 480 bytes, unpacked costs +972% reading time than packed (total read ~4MiB). File size 2333 bytes, unpacked costs +690% reading time than packed (total read ~80MiB). File size 111333 bytes, unpacked costs +9.7% reading time than packed (total read ~1GiB). File size 521111 bytes, unpacked costs -32% reading time than packed (total read ~1GiB).

According to my very synthetic tests on WDC WD2005FBYZ random access to multiple files is about ~2.5% slower than random access inside a single file. I suppose on a older HDD it might be more noticeable.

It might be out of video memory. To check that you might enable GL errors checks (gl.checkerrorafterswap) in the config and try reproduce again.

It highly depends on HDD, some random access readings might trigger hundreds of milliseconds of delay. Though it should be measured for each particular HDD.

The crash doesn't seem related to VSync. Could you also attach logs?

Mmm? Maybe some JS code depends on FPS

Hi! Could you open settings and enable "Prefer GLSL"?

There is an important caveat: splitted repos should be in sync via some relation mechanism. Someone doubts?

Before A26 available in user.cfg.

We'd like to, but it's not true yet: https://feedback.wildfiregames.com/results/display/. Most popular resolutions are 1366x768 (19.2%) and 1920x1080 (38.7%), and we still have visible amount of 1280x720 (3.6%). There is GUI scale for that in game settings, though it requires improvements.

Could you make a screenshot via F2 in the game? To check that the renderer actually outputs a picture.

Kinda known issue. I have plans to improve it, but not the top priority.

I'd like to fix the glowing deep water and use a single color for absorption.

It's solvable, just enable the skybox for screenshots

The simplest approach is to render the skybox only for cinematics (sky reflection in water will present in both cases).

I doubt it will help. The skybox is attached to the camera.