If this is a MMO, then preventing speed hacks should be done with server side checks. If this is a multiplayer game, then you should probably just implement a vote to kick player for cheating. If this is a single player game, then why are you even bothering?
Really simply question, really. Is it worth declaring a temporary (float) variable to reduce an operation from 2 to 1 multiplies?
x = a * b / c;
y = a * b / d;
float ab = a * b;
x = ab / c;
y = ab / d;
I'm not very familiar with assembly language, or how everything breaks down when its compiled, so that's why I'm asking. I'm not trying to optimize (really), I'm actually hoping to do the opposite (avoid the temporaries). If the function wasn't part of my math library, I probably wouldn't even bother worrying about it. The method I'm writing generates the (matrix-like) direction vectors of a quaternion. In the method, there are 2 of 9 unique multiplies, which means I could either multiply 18 times, or declare 9 variables and multiply 9 times.
I originally wrote the function by declaring the temporary variables, but it would look a lot nicer to simply do the math twice, as long as the difference is negligible.
I had also the same idea about the custom file extension but that is not enough
Why not? What are you trying to prevent?
The reality check is that no matter how much effort you put into it, people will be able to undo whatever it is you come up with, so you might as well not waste much of your time with it. I'm sure it could be better spent improving other, more important aspects of your game.
Why should I use floats for internal representation then? say instead of increasing 4 per tick, I increased 4.5, it would be truncated to 4 always, and if rounded, to 5 always, so I can't really see why would you want use floating point values.
Because if you use floats internally then you will get 4.5 + 4.5 = 9 instead of 4.5 + 4.5 = 8. You are accumulating error.
As you see, first and last results are almost the same. So, my question is why we need sRGB backbuffers plus modifying final output pixel shader if we can simply use non-sRGB texture? The result is almost the same:
I'd like to point out that that only your second image is "correct", that is because your performed the "manual" conversion incorrectly. Maybe an older post of mine can clear up any lingering confusion. It's not complicated, but it trips people up often. To answer the question, the advantage of a sRGB renderbuffer is that it performs the actual linear to sRGB conversion, not a gamma approximation, and by using it instead of a pow() instruction you are less likely to make a mistake as you did.
Erm, if the backbuffer is sRGB then you shouldn't be providing ANY changes to the values you are writing out; you should be writing linear values and allowing the hardware to do the conversion to sRGB space when it writes the data.
The correct versions are either;
linear maths in shader => sRGB buffer
linear maths in shader => pow(2.2) => non-sRGB buffer 8bit/channel image
Anything else is wrong.
(Also, keep in mind sRGB isn't just a pow(2.2) curve, it has a toe at the low end to 'boost' the dark colours).
That should be:
linear maths in shader => pow(1 / 2.2) => non-sRGB buffer 8bit/channel image
And that is only correct insofar that it is a close-ish approximation to sRGB.
After a quick search online I'm left with the impression that double-checked locking is not an issue for x86 or x86-64 and that it can be implemented safely (at a high level) in C++11
Right, if you *assume* that your high-level double-checked locking pattern code will never be compiled for a weakly-ordered system, it should work. But of coarse the trouble with high-level code is that any fool can unknowingly do just that, and then be subjected to strange and intermittent bugs. That's why its an anti-pattern.
Each transistor on a processor consumes power while it's active -- a certain amount while open, less while closed. There's also energy consumed in switching, but even when not in use they are draining some power.
Are you sure about that? I though transistors in a CMOS configuration use negligible energy when in a stable state.