duzenko

Added you to Biker's PM thread where he uploaded the test files. Was going to test this myself some day but have not had the time yet (and low self-expectations in the dmap area)

First mission be the New Job? From your description is sounds like model skinning might be the bottleneck.

Anyone having a problem with r_fboresolution please create a separate thread and post your .cfg in there. Please create a separate thread for cubemaps as well. Piling all my bugs in this thread got too messy.

Briarwood Manor is known to be slow due to unnecessary high-poly bushes. Anyone can make a map that is too slow. Goes without saying that all advice on improving performance/cpu bottleneck is appreciated. I don't use that particular map for performance testing for the reason above but e.g. Rightful Property bottleneck is AI calculation. Ideally we might want a separate thread for that but my last-year attempts crashed because AFAIR collision manager was not thread safe.

I guess, but then you would have to compare the fps from previous run which is tedious and not exact

Then wait for next beta BTW how projected lights are technically different from point lights? Can't you bake projection in the light cubemap?

@stgatilov found a bug in the cubemap light shader. Can you build from svn trunk?

Try quick save\load after switching to shadow maps to clear the shadow tri's

Just curious: are you still CPU-limited on your system? And with the new shadow maps option on? (r_shadows 2)

If you mean my idea about not changing the resolution at startup then it's still in the air.

All looks good now

Might also need the new scripts, depending on where the breaking change happened.

Errors in the frontend are OK. The problems are with the rest of the code. E.g. calling common->Error from idImage::ActuallyLoadImage results in an Unhandled exception ... Maybe check current thread != main thread?

No, it's missing glprocs

It's exactly what I had in mind. Does it show the error window in the end? If so, it's good for trunk.

Add common->error(...) to anywhere in frontend. It uses a SendMessage on Windows so it's very safe but requires the main thread to pump messages for this to happen.

Feature request: add message pump loop while waiting for the front end thread. Reason: front end might sometimes try to send messages to the error window -> freeze.

Trunk

There's the compilations instructions link on the TDM download page. Why not read it?

+1

I did not have time to look at the map yet due to RL issues but can you try this light: lights/mountain_sunset { ambientCubicLight lightFalloffCubeMap env/skyboxes/skybox_mountain_sunset/mountain_sunset { cameraCubeMap makeIrradiance(env/skyboxes/skybox_mountain_sunset/mountain_sunset) colored zeroClamp } } lightFalloffCubeMap is specular and cameraCubeMap is diffuse. Replace env/skyboxes/skybox_mountain_sunset/mountain_sunset with your cubemap here. Will only work with 2.06/svn.

On a second thought, mirrors show player's model by default. Not sure if it's a problem in this case though. If it is, we might want to add a noplayer flag or something.

It should work with the existing mirror function for single flat surfaces.

Let's start with that