vladislavbelov

Only if you can't use it. Most of all modern games use it (i.e. GTA V, 16bit float per component, the pretty fast game). No, we don't have a "full" control yet in the pyrogenesis. Because in the first pass we render a scene into a simple RGBA buffer (8bit per component) and the "HDR" shaders works on the next pass with already clamped values. So the precision is low. I like changes, but there is a problem, we have many maps. And artists/modders may want to use different settings. So it'd be ideal to fully customise the shader.

You understood me incorrectly. I didn't said that my implementation is the correct Reinhard one, I only mentioned that the Reinhard is simple and can be used easily here too. Lets return to the HDR. I said, that I prefer HDR > LDR than LDR > LDR for not one-pass pipeline. Because a loosing of high color values, that stops artists/modders to change exposure/gamma freely. Please, look at the example that send above: http://marcinignac.com/blog/pragmatic-pbr-hdr/305-exposure-basic/. For disabled gamma (doesn't make sense what it means in this context) and some exposure values all dark or light areas are losing details. So my point is to use float textures for g-buffer like data when possible.

Yes. And I think we're talking from different sides and we don't understand each other. What I mean: Rendering scene into a float (i.e. RGB32F) buffer with original brightness (vec3 color) > selecting a gamma (by a pregame setting or on the fly) (float gamma) > a simple tone mapping (like the Reinhard one) (color = color / (color + vec3(1.0)); > a gamma correction (color = pow(color, vec3(1.0 / gamma)).

It's not correct. Just do a simple math: in case you have a very light color: (R:1e6, G:1e3, B:1e3), then with LDR it will be (R:255, G:255, B:255), but with HDR it will have a different distribution depended on the gamma. So you're missing a color itself with only LDR. (If you are using HDR/tone mapping as a separate step, not all things (model lighting, hdr, color correction, etc) together in a one shader).

I didn't mean the lighting from bloom, I mean a visual effect for players. HDR allows you to store a true brightness of each pixel, so on the HDR>LDR step you will get a more correct lightning.

Bloom simulates a very light things, but you still can see all details in shadows. It's wrong and looks weird. Obviously that a pixel color usually can't exceed the 255 limit. So HDR shouldn't be just rendered as is, it should be converted to LDR with a color correction. FYI: http://marcinignac.com/blog/pragmatic-pbr-hdr/

It's not art, it's a alight. We need to use PBR, AO and correct HDR to solve the problem. A shadow ref:

If you would look at these white roofs, you may notice, that you still see not black shadows. Our HDR doesn't work as HDR

Currenlty FXAA doesn't work perfect for the 0 A.D., but TXAA or MSAA may solve the problem. FXAA:

I agree, that the code isn't the best for CSM, but performance looks better in a comparison with the current one. Some AAA games like it (i.e. JS3). Also CSM has square/rectangle pixels, so it's more nice shape of the pixel. I like PSM, but it has a worse shape, and sometimes there are glitches. @stanislas69 already noticed visual errors with a rotating camera for the current algorithm. About performance, I suggest do not say much words without tests. I agree about errors. But, it's cheaper, and with clever packing it works good. I.e. JS3 mentioned above (I need to find a ref). I trust your results, but there're AAA examples. So, again, tests and tests. Some modders and artists wanted to have many lights (i.e. arrows, torchs). Deffered rendering allows you to use MSAA too, but with a different cost.

Shaders don't, but a video driver does. I.e. we still support Intel video cards, which can have a version 3.0 or lower, that doesn't have many nice features. I wanna change the current shadow mapping way, because for low angles we have a low resolution per terrain unit. I'd like to use PSM or CSM, and I'm more near to CSM, i.e. 2 cascades. I agree about HDR. Also we don't have deferred rendering yet. About formats RGB16F or RGB32F has enough precision, but it's expensive. So if R11G11B10F will be enough, then we have to use it. Because it's 4 times cheaper. FPS meter isn't enough, we need to use more strict tests. Because the FPS meter has a noticeable error.

It's not possible yet, because we don't drop GL2 yet. But it'd be good to have a switchable renderer in the future. What's broken? It doesn't run? You can make screenshots from the game. https://code.wildfiregames.com/D1402 The current postprocess isn't completed. I.e. we can't select multiple effects. Also HDR isn't actually HDR, it's usual LDR, but with color corrections. We need to use R10G10B10F or RGB32F for true HDR. Any filtering is noticeable under a low hardware. It'd be good to know you hardware and some charts to compare results. I'd like to see MSM.

If make the shadow more expensive, we can use moment shadow maps. That's good, but our blur is pretty simple (just a linear), it'd be good to replace it by the Gauss one. It's pretty hard to make the water realistic and beautiful at the same time, especially without real references (i.e. the contrast). Also did you use my patch for the water vertex shader fix? Because the current one is broken, so the specular light is calculated wrong for heights != 15. It'd be good to have screenshots to compare before/after states.

I agree, we definitely have to avoid "using namespace ..." (except very rare cases). Especially we have modern IDEs to autocomplete it. The "icu::" would be better, even for the patch reading.

Hi @gabewarr11 and welcome to the forum! It happens immediately after the start and you didn't see a main menu ever? Could you attach a crash dump and crash info from the game logs folder: https://trac.wildfiregames.com/wiki/GameDataPaths ? Files are called crashlog.dmp and crashlog.txt, also mainlog.html, system_info.txt files would be useful for us.

Which OS?

Did you test other LAN games/applications? Is it the first try to connect these 2 PCs?

I agree with @Lion.Kanzen about dark gradient, it needs to be lighter. Also how it looks for small border shapes? Like small rings? Because it's harder to make a nice border with wider sprite.

Helmets are too different by colors from the rest model, isn't it? I think they should be a little bit lighter.

Another way to get the callstack: as you're in the gdb on the crash, you can type bt to print the current callstack.

I think, the shortest way is to override the getBatchTrainingSize function: function getBatchTrainingSize() { return 5; }

You probably downloaded the .torrent file (it requires an additional program that can open and download such files). But you can download the installation file directly. There is a link under the big gray button. @Itms @implodedok May be we need to make the link more noticeable.

Also Revert all local changes and Cleanup the repository may help to make Update.

You can find information about hotkey/shortcuts in our wiki: https://trac.wildfiregames.com/wiki/Manual_Settings#KeyboardShortcuts.

Hi @MlemandPurrs! We needs more information about your system to detect a problem: Does music play in other applications? What operation system do you have? What audio configuration do you have: headphones or speakers, audio card? Do you use laptop or desktop?