Suddenly low framerate again

[Panjoo]

I think it was after updating to mingw 3a40290 that my framerate suddenly dropped to unacceptable low numbers. First I thought it was the cap (r_vsync) but it felt choppy overall, even on small maps like Torn and Tokays. Disabling weather didn't help.

Normally with r_vsync 0 I would get over 250 fps easily on simple maps like Tokays, but now the game's stuggling when there's some action. I have no idea what's changed again but big performance drops like these always get me worried about what will become of this game for people with older systems. I always put performance first.

Here, 74fps tops and the water also looks different, less transparent or something. This shot was taken with vsync off;

[kaadmy]

Try disabling r_caustics if you haven't already, it might cause slowdowns at times if there's water in the map.

On Jul 17, 2017 3:43 PM, "Panjoo" notifications@github.com wrote:

I think it was after updating to mingw 3a40290 https://github.com/jdolan/quetoo/commit/3a40290d09bcc71fefaa4ed74e0654c206f0bc23 that my framerate suddenly dropped to unacceptable low numbers. First I thought it was the cap (r_vsync) but it felt choppy overall, even on small maps like Torn and Tokays. Disabling weather didn't help.

Normally with r_vsync 0 I would get over 250 fps easily on simple maps like Tokays, but now the game's stuggling when there's some action. I have no idea what's changed again but big performance drops like these always get me worried about what will become of this game for people with older systems. I always put performance first.

Here, 74fps tops and the water also looks different, less transparent or something. This shot was taken with vsync off; [image: fpsdrop] https://user-images.githubusercontent.com/10857572/28292678-68aee52c-6b50-11e7-9ec5-4c2f25b3ae22.jpg

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jdolan/quetoo/issues/489, or mute the thread https://github.com/notifications/unsubscribe-auth/ANbJucE8l3Pn9TMJWeILWP4o3zz0Fa6Mks5sO-OkgaJpZM4OaoSx .

[Panjoo]

Well, r_caustics never made a noticable frame drop before.

This is with caustics off, still low fps (this is the max I'm getting..) and look how different the water looks.

But as I mentioned it's not just a water thing, the whole game runs terrible.

Doing r_materials 0 makes it somewhat better (gaining ~35 fps) but it's still much lower than it once was.

[jdolan]

Weird. It almost looks like a state leak or something. But I'm not sure. Nothing's changed in over 2 months.

[kaadmy]

Wasn't OpenAL pretty recent?

On Jul 17, 2017 6:34 PM, "Jay Dolan" notifications@github.com wrote:

Weird. It almost looks like a state leak or something. But I'm not sure. Nothing's changed in over 2 months.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jdolan/quetoo/issues/489#issuecomment-315932429, or mute the thread https://github.com/notifications/unsubscribe-auth/ANbJuTJ2cKq-gNkO_YVeZNuVMEhnh_qgks5sPAujgaJpZM4OaoSx .

[jdolan]

Like, May. And I don't think OpenAL would explain the weird blend he's seeing with water.

However, Paril did change the particle blends around. I don't even recall if he finished correcting them or if he reverted that change. If that got in, maybe there's a blend function state leak.

[kaadmy]

I just remembered an issue I had a while ago with 2d blending that state leaked out of a draw function in Cl_UpdateScreen I think. Possibly related?

On Jul 18, 2017 4:40 AM, "Jay Dolan" notifications@github.com wrote:

Like, May. And I don't think OpenAL would explain the weird blend he's seeing with water.

However, Paril did change the particle blends around. I don't even recall if he finished correcting them or if he reverted that change. If that got in, maybe there's a blend function state leak.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jdolan/quetoo/issues/489#issuecomment-316038353, or mute the thread https://github.com/notifications/unsubscribe-auth/ANbJuVhCKOKbHeyaHQafMrjwBBYX7bRRks5sPJmsgaJpZM4OaoSx .

[Paril]

The blend stuff was reverted, yeah. Without being able to reproduce it ourselves we're stuck asking Pan to keep toggling bits until something pops out at us :(

[jdolan]

@Panjoo Does this happen on all maps? Only maps with liquids? Only maps with transparent surfaces? Only maps with inline models? Only maps with animated material stages?

Basically, if we can whittle down what renderer feature(s) are causing this, we can hone in on a fix.

[jdolan]

Does fog have any effect?

Another thing we can try is: if you happen to remember a revision number that worked for you, I can start building older revisions in Jenkins from that rev forward, to 3a40290, until we find the rev that actually breaks.

I just enabled build artifact archiving on Jenkins for this purpose. So basically, if you give me a known-good revision to start at, I can start cutting snapshots for you to try. You'll download each one as a .zip from a URL like this:

http://ci.quetoo.org/job/Quetoo-MinGW-i686/1110/artifact/mingw-cross/target/Quetoo-BETA-i686-w64-mingw32.zip

Where 1110 is the build number (not the revision number, sadly), extract it over your install, and see if it works.

[Panjoo]

@jdolan It happens on all maps as far as I can tell. It's hard to say if it's worse on maps with liquids because on a small map like Torn with no liquids the fps can drop below 50. I've disabled fog and weather but it just stays bad. (Doing r_materials 0 gains around ~35 fps.)

I'm afraid I can't remember any revision number that worked for me. I usually make a backup of the game folder before running the updater, but the backup that I labeled quetoo5-4 (april 5th) also seems to be the 3a40290 version. I think I also tried updating on april 1st but that one wouldn't start, something about libObjectivelyMVC-0.dll error. I get these error messages in version 3a40290 and also in 993052c (see screenshot):

So I think it has to be somewhere before April that it started getting worse. Since the new menus and stuff?

[kaadmy]

Sounds like different GLSL versions? @Paril did the geometry shaders, I'm not sure how they work.

[Panjoo]

^I've tried the i868 build that you linked Jay, but it's not making a difference. Got any other snapshots I can try?

What is odd to me is that even on the low fps (up to ~60 with v_sync off) it should still be enough to not feel this jerky when I'm moving around. If I wouldn't know any bettter I'd think the game struggles to get 10 fps, that's what it feels like.

Maybe I'm just imagining things and it's hard to explain but it looks as if it's more fluid for like half a second once I fire the railgun (while moving) and the railtrail is visible. I noticed this while doing the classic left-right dodging (quickly strafing left and right on the spot). The view jerks but once I shoot with railgun while moving it feels less jerky for a brief moment. I don't see it back in the fps though, that stays the same, probably because it doesn't last long.

[jdolan]

@Panjoo That build is the latest. I would have to manually run the build against older revisions, and then the snapshots would show up in that place that I linked. I won't have time to do that in the near future, because I'm not home -- we were forced to evacuate our house to get away from Irma. If the 3-6ft of storm surge they are forecasting does hit my house, I won't really be online for weeks.

@Paril based on what he's describing, and based on the shader linkage warnings he posted above, it really does sound like a geometry shader issue. Is this something he can toggle with a cvar?

[Panjoo]

@jdolan Okay I must be going crazy, now suddenly it runs okay again. I'm just compiling and testing a map and haven't changed any settings. I usually press the arrowkeys to browse the console history when loading the same map over and over. I noticed there was a r_supersample in the history which I didn't type, or not that I can remember. Vsync was also set back to 1. I checked r_materials again and it displayed some vertexdata warnings but it did toggle the materials, previously it had almost no effect. The main difference is that now when I toggle materials it does make a much bigger difference than when I first opened this issue. In fact I can leave materials at 1 now and the fps stays up. Whatevah!

Anyway I can still work on maps and stuff and make progress so it's not a big issue for now, it's just very weird how this just fixed itself(?)

I can imagine you have other things on your mind right now, like evacuation! Did you try cg_add_weather "0" yet to disable Irma? No seriously, that's pretty fucked up, sorry to hear that. There's always a luck factor involved so who knows most of your house will stay intact, I hope it's just Irma and not more of those things, this one seems devastating enough.

[jdolan]

Good news and a laugh! I needed that today. Thanks buddy.

[Panjoo]

After some more testing it seems that switching r_vsync on/off is causing or triggering something to go wonky. Here's what happens; the game was running okay-ish (still much less fps than I got with older builds but at least it felt smooth). I turn on vsync and do a r_restart and the game becomes totally jerky and sluggish. Turning it off again doesn't make it better:( I turn r_materials off and r_restart again and fps goes up a little and it feels smoother. Then turn materials back on without r_restart.

More things are not right, the glow_skins on the weapons are not pulsating but always "on". Also my stupid water won't blend correctly in the map I'm testing. No matter which blend flags I set, it stays opaque. Checked other maps and same problem, this is from the Pits:

I'll keep the ticket open for now and if I happen to find out more on this issue I'll post it here.

[Paril]

He can toggle the geometry shaders with r_geometry_shaders I believe. It might be part of rparticle* too, can't recall.

I think your second issue is material-related, but I don't understand how vsync could come into it at all. Vsync is literally just a 0/1/2 toggle we send to SDL and it does everything else. I'm not even sure we have a software limiter that would cause it.

Try setting "threads" to "1" and see what that does. (I think 0 or -1 will reset it back to # of cores). We should probably work on adding profiling timers in a build so that we can have Panjoo figure out where the most time is spent. If vsync is the problem, then it would say EndFrame is the culprit.

[Panjoo]

All I know is that as soon as I enable r_vsync the whole thing feels shitty. Even without vsync I now seem to have lost like half of my total fps on these newer builds. Toggling materials has the biggest effect on my fps and r_geometry_shaders doesn't seem to change much in terms of frames.

https://open.gl/geometry : (...) The real power of geometry shader lies in the ability to generate a varying amount of primitives (...) (...)Geometry shaders may not have as many real world use cases as things like framebuffers and textures have, but they can definitely help with creating content on the GPU as shown here. If you need to repeat a single mesh many times, like a cube in a voxel game, you could create a geometry shader that generates cubes from points in a similar fashion. However, for these cases where each generated mesh is exactly the same, there are more efficient methods like instancing.

I don't even know what they are needed for in quetoo, for stain fx or weather or something like that?

Threads 1 - honestly I can't say if this has any effect because how am I supposed to see it? What the fps counter displays also depends on what else my system is doing in the backgound and on where I'm standing in a map. It's not a very reliable number.

(Something I still miss in quetoo is an accurate way to test the performance of maps. If I pick a spot to measure the fps on a map and then make changes, I have no way of telling if the difference in fps is really due to the change I just made or that my system happens to be busier with background stuff than the first time I measured. Q2 had a r_speeds that measured the number of visible wpolys and epolys in the map itself. So no matter how busy your cpu is, that number is always a trustworthy sign of what's going on with the map's performance.)

[kaadmy]

Currently geometry shaders are used for particles; each particle is a quad, but sent to the GPU as a single vertex and the mesh is generated on the GPU.

[Panjoo]

@Paril

... the glow_skins on the weapons are not pulsating but are always "on" ... No matter which blend flags I set, textures stay opaque.

^ it's not only this but I think there's also some problem regarding entity models. I was noclipping though a map and once I flew out and above the map the fps increased... lol. Normally, if you do this the fps will be at its lowest because then it draws the wireframe of the entire map. But for some reason the entity models mess something up and the soon as they disappear from view the frames increase.

... r_geometry_shaders doesn't seem to change much in terms of frames.

So, I guess in spite of the console error messages I doubt this is the reason for the frameloss.

... as soon as I enable r_vsync the whole thing feels shitty

So yeah, just tried this again by doing vsync 1 while in a test map without entities this time. After r_restart the frames get locked at 60 as expected but the result is just really the opposite of fluid.

Perhaps nothing to do with it but could this be related to a monitor's refreshrate, mine seems to be stuck at 59Hz. Microsoft info: In Windows 7, when a user selects 60Hz, the OS stores a value of 59.94Hz. However, 59Hz is shown in the Screen refresh rate in Control Panel, even though the user selected 60Hz.

Microsoft info: Certain monitors report a TV-compatibility timing of 59.94Hz. Therefore, Windows 7 exposes two frequencies, 59Hz and 60Hz, for every resolution that is supported at that timing. The 59Hz setting makes sure that a TV-compatible timing is always available for an application such as Windows Media Center. The 60Hz setting maintains compatibility for applications that expect 60Hz.

https://www.reddit.com/r/GrandTheftAutoV_PC/comments/32o2o9/i_found_a_fix_for_the_59hz_issue_and_potentially/ Haven't tried this yet and don't know if I will.

[jdolan]

If there are cvars you can tweak in the game that affect the performance dramatically (other than r_vsync / r_swap_interval), then it's probably not refresh rate related. If disabling inline BSP model entities alleviates the performance issue, then we have some bad state management happening. That's the most logical explanation.

I can try to see if I see much difference with an un-capped framerate while toggling cg_add_entities as well. Is there a particular map or location where this is really evident for you?

[jdolan]

Also your comment about water blending.. yea, we definitely have some blend state leakage to contend with.

Last week, I was noticing in the player setup menu that QForcer's visor was incorrectly blended unless you were also in-game and viewing the menu over the game. When going straight into the menu from launching Quetoo, it was busted.

Here's what I propose to narrow this down for Pan: we should introduce an r_blend developer / locked cvar that completely disables all glBlend functions, and see how turning blend off affects Pan's framerate.

EDIT Aw shit. I think I may have found something. Just in testing this locally, I noticed that with all of R_EnableBlend disabled, the full-screen blend effect from cg_draw_blend was ALWAYS ON. Here's a screenshot some 10 seconds after picking up an item:

I think what might be happening, is that once you pick up a single item, you're forever dealing with a full-screen alpha blend effect (even if the alpha value is 0.0). @Panjoo does this issue go away for you with cg_draw_blend 0?

Either way, we should absolutely be skipping the draw call for the blend effect if the alpha value is 0.0.

[jdolan]

Yup, that's exactly what's happening. We were unconditionally drawing all blend images (pickup, damage, underwater, etc) regardless if they are visible for the current frame. CC @kaadmy

https://github.com/jdolan/quetoo/blob/master/src/cgame/default/cg_hud.c#L862 https://github.com/jdolan/quetoo/blob/master/src/cgame/default/cg_hud.c#L869 https://github.com/jdolan/quetoo/blob/master/src/cgame/default/cg_hud.c#L882

I monkey-patched this with 137c0bf0a01decab39f57f6a02fcad2957a963cc. @Panjoo you can also now disable all alpha blending by setting r_blend 0 with sv_max_clients 0 while in-game to investigate further, if need be.

[jdolan]

My guess is that Pan's driver doesn't optimize the zero-alpha blend operation, while many of ours do.

[kaadmy]

@jdolan the blend flashes are already not drawn with <=0 alpha https://github.com/jdolan/quetoo/blob/master/src/cgame/default/cg_hud.c#L811

Edit: you just added that, oops

[jdolan]

:)

[Panjoo]

jdolan: - Just in testing this locally, I noticed that with all of R_EnableBlend disabled, the full-screen blend effect from cg_draw_blend was ALWAYS ON

jdolan: - I think what might be happening, is that once you pick up a single item, you're forever dealing with a full-screen alpha blend effect (even if the alpha value is 0.0). Panjoo does this issue go away for you with cg_draw_blend 0?

I'm not sure what you mean. I'm not seeing anything strange when I pick up items. R_EnableBlend is not recognized and I don't see anything different with cg_draw_blend 0 Everything looks the same, the water doesn't change and the weapon glow stays on.

On avarage I can say that toggling cg_add_entities makes a difference of 60-70 frames on most maps. But not in Tokays, then it only increases by ~25. So it runs better without entities but I get like 100 fps less on a lot of maps with these builds.

I monkey-patched this with 137c0bf. You can also now disable all alpha blending by setting r_blend 0 with sv_max_clients 0 while in-game to investigate further, if need be.

Will try this out tomorrow and play around with some of those settings.

[jdolan]

Hi Pan,

Sorry for my stream of consciousness update this morning. It was rambling, and I was trying things as I thought through the problem.

R_EnableBlend is our C function, not a console variable. Before putting the r_blend cvar in there for you, I experimented with just commenting out the entire function. That's when I noticed what was happening with the pickup / underwater / damage screen blend effect. It was definitely a bug, but perhaps not the bug that is bugging you.

I'm disappointed that this fix didn't yield any improvements for you. But maybe disabling r_blend tomorrow will shed some new light on another path.

[Panjoo]

I was about to do some more testing but even after just a couple minutes I'm already having enough of it. Also getting frustrated trying to bughunt in my limited English so I'm keeping it as short as possible.

I updated (to 43b8d8c), I have no idea if this the correct one but it does allow me to use r_blend. The startscreen and menu look a lot better btw. I load up a map with water and I noticed that it looked as it should, so that's good. At least I think it does because at this point I don't know for sure anymore how it was supposed to look. My waters had a soft blended layer that didn't move and then 2 scrolling layers ontop. Now it looks as if it's just the 2 scrolling layers. But I'm not sure. When underwater it also looks as if the items & players that are visible are not affected by the water blend effect. (That's been like this for a long time, so this isn't something that just started hapenning.)

Cg_draw_blend 1 and picking up items seems to work okay, (I sized down the view so you can see the green blend better, r_materials was off).

I do r_blend 0 and see the unblended particles as squares as expected but I don't really know what to look for.

Tried to change some settings and set Multisample to 2 (was off). Hit Apply and then after that I tried to switch on vsync again via the menu but after the r_restart the menu buttons were broken. Then the game crashes with 'sys_signal: received signal 11' and something with SDL. The menu worked fine till I hit the Apply button in Settings..

Disabled r_materials and it instantly feels better when I actually get some frames to move around.

[jdolan]

The menus are very much a work in progress still, so yes, some r_restart issues (among others) are known and will be addressed in the coming weeks.

So there's still something going horribly wrong with GL blend operations for you. Full-screen blend would explain both poor performance AND materials not working AND water looking dumb.

@Paril Do you have any ideas we could try to debug this further? It sounds to me like Pan was sitting on an older build for a while, and this all cropped up when he updated to the GL3 builds. I can't say for sure, and I'm not calling your code out, but I'm just wondering if you have specific ideas around ways we could debug this further to confirm or rule out culprits.

[jdolan]

Well, @Panjoo you are in luck. Over the holiday, I bought an external GPU enclosure and an 8GB RX 580 for my MacBook Pro. In Windows 10, I get 400+ FPS in Quetoo. In OS X, I get 60. Disabling r_materials brings it to a whopping 90. So something is definitely going on with some AMD drivers here, and I can now reproduce it. What's comical, is that the discrete GPU in my MacBook (which is also AMD) performs better in Quetoo than the external one. Objectively speaking, the RX 580 is twice as fast as the built-in card. So this is clearly a bug in Quetoo that most drivers are allowing us to get away with, but some are not.

I need to remain focused on wrapping up the ObjectivelyMVC and menu work first, but this will be the next thing that I look at after that.

[jdolan]

(Side note, upgrading to Win 10 might solve your issue, as my rig performs as expected there.)

[jdolan]

Two apparent state leaks need to be addressed at least:

• [x] Fog is leaking at least in the PlayerModelViewController. You can see this by loading a map with fog on it (like Torn Glory) and then visiting the Player menu:

Disabling r_fog makes this leak go away, but doesn't do much for framerate.

• [x] The console background image is not being drawn correctly. It's too dark. I'm not sure when this broke. It used to look fine for me on NVidia. Is this a blend func or a color state thing? Not sure.

You can barely make out the console background at all. Something's up here. This could explain Pan's water appearing incorrectly too.

[jdolan]

CC @Paril @void-995

[jdolan]

Fox state leak fixed both the menu and console background. Framerate still sucks.

[jdolan]

Ok, this is fixable! Here is a screenshot on my Radeon 580 using a build from April 9th. 400fps.

On master, I get 55fps in this spot with r_materials 1. So clearly, something went horribly wrong. The good news is that this build is using GL 3.3, so we're not fundamentally screwed here. I'll continue to bisect until I can pin the issue on the revision.

[jdolan]

Hm. This might be death-by-1000-papercuts. In bisecting this, I jumped ahead one month to May 9th. Framerate dropped to 350. A 100fps drop. Not the catastrophic drop of 400fps that I was hoping to find. So there's something between April 9 and May 9 that cost us 100fps, and then there's still another 300fps I need to hunt down.

Fun fun!

[Paril]

So it's not data-related and not GL 3.3 related, that's good news at least.

[jdolan]

@Panjoo We've identified the the bad commit, it's here: 470a25158f10d6323e860797a3abd9adeafab4ea

I went from 330fps to 61fps in the spot pictured above due to this commit. The date also coincides with when you noticed the problem. @Paril had some reservations about this code anyway, and I was able to revert it. Framerate is right back up to a respectable figure. Please let me know if this works for you as well!

[jdolan]

And before you yell at me -- yes, I know colors and alpha are messed up after reverting this. Working on it ;)

[jdolan]

Adding @Paril to assignees. The revert mostly worked, but there is a GL state issue where I think we're not properly handling the global color uniform in the default program. This leads to entity lighting, material stages and transparent brushes all rendering incorrectly (or seemingly not at all). Let's get this buttoned up this weekend if possible :)

[jdolan]

I think we've monkeypatched this one to the point that we're in good shape. Framerates are back up, and the materials and entity lighting issues are resolved. @Paril I'm leaving this one in your bucket for you to review the R_UseCurrentColor_default function, that I hacked to resolve the aforementioned bugs. Feel free to close this out when you're satisfied with it.

[jdolan]

@Paril fixed the last of the color issues, everything looks correct and framerates are back where they should be. Assigning back to @Panjoo for him to close out once he can confirm.

[jdolan]

@Panjoo mingw32 build is looking pretty good again. x86_64 is also coming along, tho there is still heap corruption from time to time. We'll continue to debug it as time allows. But please re-test the i686 build at your convenience and let us know :)

[Panjoo]

Framerates are back up, and the materials and entity lighting issues are resolved. ... fixed the last of the color issues, everything looks correct

I wouldn't say that everything looks correct, on the contrary. The framerates are up again, or at least much better than last time I checked, but there seems to be some issues with the entities and materials still. Now my weapon materials don't have any bump effect. The glowskins are okay but I don't see anything that indicates the use of a normal map. Looks bland and flat. So do almost all the textures in most of the maps. Probably because those texture materials need to be re-tweaked again, for the tenth time, FCOL.

(Prior to updating and r-testing the i686 build again I still had this https://github.com/jdolan/quetoo/issues/201 'backtick console bug' but I noticed this has now been fixed. It was a super annoying bug so this is good news.)

[jdolan]

Does your game not look like this, or are you saying these don't look correct? Notice the self-shadowing on the faces to the sides of the light.

This looks pretty good to me.

Check out the parallax occlusion mapping on Warehouse. Notice how realistic the creases between the floor tiles are.

Are you seeing something different, or does this look worse than before in your opinion?

[Panjoo]

Those pictures look good, but in-game the lighting doesn't quite feel like that for me, my first impression was, 'hmm...' Perhaps it's because of the overall higher brightness or exposure in places where lights are close to a surface. Also, I thought I was seeing shadowy artifacts (looks strange on the boulder brick wall texture in Chastity) but now that you mentioned 'self-shadowing' it makes more sense. It looks okay from a distance but if I move closer it looks kind of like z-fighting, but it doesn't flicker, it just looks somewhat jagged. Although I do like the idea for the effect.

Trying to take some screenshots but I can't: _Img_WritePNG: Failed to open to C:\Users\panj\Documents\My Games\Quetoo\default\screenshots\quetoo105.png R_Screenshot_fencode: Failed to write screenshots/quetoo105.png

Here, some printscreens: I noticed that this is also visible in your first picture if I zoom in, so this might be how it's supposed to look.

This wall definitely doesn't look better than it did before. I don't know, I guess it misses the hardness when viewed from certain angles. Like always, can't really describe it well.

[jdolan]

Gotcha. Agreed that those textures on Edge do look a little flat at a distance. @SpineyPete @void-995 thoughts?

The "jaggedness" or stippling on the self-shadowing is something we can tune with a cvar in the near future. The cut of self-shadowing that is in master right now is hard-coded to use a certain number of samples, and apply a certain amount of dithering. It's an okay balance between quality and performance. We can expose a couple sliders in the menus, and make the effect more configurable to achieve better looking results for folks who can spare the GPU, or disable it entirely for folks who can't or don't like it. I can take that on pretty soon, with a little help from @SpineyPete.

[SpineyPete]

The pixelation of the shadows can certainly be fixed, I preferred this look to a hard edge and it trades stair-stepping for noise. It does look ugly on those bricks, for sure. I did a "truly" smooth version that's perfectly smooth, sadly it's a lot more expensive, so I opted for this one. Truth be told I'm not entirely won over for the self-shadowing in it's current state, you can get movie quality shadows if you trace enough rays but it's just really expensive. I'll get around to doing the horizon mapping shader at some point which should give pixel perfect shadows for very modest cost, you can even do shadows from multiple dynamic lights with those. Btw, if you set r_parallax to -1 it'll disable the shadows but keep the parallax.

As for the textures looking washed out, that might be due to the tonemapping being applied at the end. It flattens highlights that approach maximum brightness. The upside is that you don't need to worry too much of highlights becoming too strong. A side effect of simply adding everything up like games used to do is that the highlights had a color shift on the highlights which despite being wrong could look nice and contrasty.

[jdolan]

We could always introduce r_tone_mapping and conditionalize the shader..