Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Dec 2000
Offline Last Active Today, 04:54 AM

Posts I've Made

In Topic: Approximate Average Brightness Of Rendered Image

01 August 2016 - 03:24 AM

Phuh... That's a complex thing. I don't know how to access mipmaps, I'm not such experienced. I just do some simple experiments.

Within a shader you can simply use textureLod (with a sufficiently high value for the lod) to access specific mipmap levels.

In Topic: Approximate Average Brightness Of Rendered Image

01 August 2016 - 01:05 AM

Yeah, you can do the dot product after mipping, or you can do it beforehand (into a single-channel texture) and then mip that.


If this is for HDR, the geometric mean is often more useful / representative. You can compute it by doing the dot first, then a log (into a single channel texture), then mipping down to 1x1, then an exp to undo the log.

But don't forget to add a black offset (you don't want to add any -infinity values into your average)

In Topic: Overall Strategy For Move-Semantics? [C++11]

28 July 2016 - 01:32 AM

My recommendation: Use the rule of zero wherever possible (should be 90% of your classes), i.e., don't define any of the special constructors/assignment operators but use the default generated ones instead. The few classes that do manage resources directly then get all five.

In Topic: When you realize how dumb a bug is...

11 July 2016 - 08:49 AM


I've had an SSD that was failing to be recognized for weeks, and before I shipped it back (Filled out the RMA and got a label), windows updates turned off my computer.


When I booted it up, the SSD was working fine. I just needed to power cycle the SSD to fix it, and i hadn't even turned off my computer in weeks.


Why would you leave your PC on for weeks continously anyway? ^^


Nightly backups and use as build slave/helper for distributed builds?

In Topic: Do you usually prefix your classes with the letter 'C' or something e...

08 June 2016 - 02:24 PM


Actually, m_ for members and g_ for globals helps quite a bit while reading a lot of unknown code.

The problem is that this kind of convention is brittle. It encodes information about scope into the variable name, but if you refactor to change scope the encoding is wrong and the variable must be renamed.  Forget or neglect to rename the variable and now you've got misleading information.


A far more robust convention is to require the use of this-> for members and to require full namespace naming for globals.  The compiler can then help you by catching incorrect usage.  In an ideal world C++ would have had these requirements from the outset.


this, a thousand times this (pun absolutely intended). I sometimes wish c++ had gone the same route as python or rust with an explicit self/this parameter. which could also enable things like templates based on the reference qualifiers of the object.