Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Oct 2010
Offline Last Active Jul 24 2016 03:32 PM

#5169853 Make file unreadable by an external program

Posted by on 28 July 2014 - 02:57 PM

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.

#5167454 Smooth sprite movement

Posted by on 17 July 2014 - 12:49 PM

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.

#5166148 c++ function pointers

Posted by on 11 July 2014 - 01:57 AM

Or, without typedef or alias, C++11 allows trailing return types; the syntax may be somewhat clearer:


C++14 makes this even cleaner:


auto GiveMeFunctionPointer()
    return &AddOne;

#5165182 how to use or ||

Posted by on 06 July 2014 - 11:06 PM

It should be noted that performing your comparisons using multiple Boolean variables means that you cannot take advantage of short-circuit evaluation.

#5163649 sse and branching

Posted by on 29 June 2014 - 11:32 AM

Clang is very good at loop vectorization with SSE/AVX and it also has a nice vector extension that gives you math and logic operators as well as HLSL/GLSL like swizzling.

typedef float __attribute__((ext_vector_type(4))) float4;

#5160814 [DX11] Why we need sRGB back buffer

Posted by on 16 June 2014 - 04:40 AM



after reading a couple of resources in web about Gamma Correction I still feel confused.


In my experiment pixel shader simply outputs linear gradient to backbuffer.


 - First case: backbuffer format is not sRGB, value of linear gradient is outputted without any modifications:



 - Second case: backbuffer format is sRGB, value of linear gradient is outputted without any modifications:



 - Third case: backbuffer format is sRGB, value of linear gradient is outputted with correction of pow(u, 1/2.2):



 - Fourth case: backbuffer format is sRGB, value of linear gradient is outputted with correction of pow(u, 2.2):



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. wink.png


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.

#5160441 using static initialisation for paralelization?

Posted by on 14 June 2014 - 12:52 AM


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.



No, C++11 offers portable high-level double-checked locking as described here: http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/

#5159057 ANSI C - pixel perfect collision

Posted by on 08 June 2014 - 05:37 AM


It should if you specify -std=c99.


That's not ANSI C anymore though (admittedly GCC's default setting isn't either, but some gnu89 variant).



Why on earth would anyone be using strictly ANSI C in 2014? blink.png  Stuck with Turbo C 2.0 or something?

#5157712 Checking if a bit is set in a byte

Posted by on 02 June 2014 - 08:53 PM

Here is the results I get with Clang 3.3 with -O3:


IsBitSet(unsigned char, int):                          # @IsBitSet(unsigned char, int)
    btl    %esi, %edi
    setb    %al

is_bit_set(unsigned char, int):                       # @is_bit_set(unsigned char, int)
    btl    %esi, %edi
    setb    %al


and with GCC 4.9 with -O3:


IsBitSet(unsigned char, int):
    mov    ecx, esi
    mov    eax, 1
    movzx    edi, dil
    sal    eax, cl
    test    eax, edi
    setne    al
is_bit_set(unsigned char, int):
    movzx    eax, dil
    mov    ecx, esi
    sar    eax, cl
    and    eax, 1

#5157708 Checking if a bit is set in a byte

Posted by on 02 June 2014 - 08:31 PM

bool IsBitSet( unsigned char byte, int index )
  int mask = 1<<index;
  return (byte & index) != 0;


I think you meant to use mask and not index in your return statement.

#5157212 Why do graphic intensive game use a lot of energy

Posted by on 31 May 2014 - 02:59 PM

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.

#5155254 Can a bindless_sampler be mapped as normal UBO instead of using glProgramUnif...

Posted by on 22 May 2014 - 01:05 PM

The bindless_sampler qualifier is necessary for uniform samplers in the default block only. If you are going to use a UBO, then it would probably look something like this:

layout(binding = SAMPLERS, std140) uniform sampler_buffer
    sampler2D textures[MAX_TEX];

Binding points for bound textures and UBO/SSBOs are completely separate.


Edit: Fix'd

#5153786 OpenGL png transparency

Posted by on 15 May 2014 - 09:07 AM

Just an FYI, your are using texture2D which has been deprecated since GLSL 1.30. You should just use texture instead, which overloads based on the sampler type.

#5152948 Graphics baseline for a good-looking PC game?

Posted by on 11 May 2014 - 05:38 PM

Although something like 1368x768 is the average or most common screen resolution right now


My intuition would have been 1920x1080, and that is confirmed by Steam's hardware survey. More than a third of Steam users have a 1080p (or better) display. My guess is that the majority of the people with less than that fall into the category of casual gamers and are less likely to playing the "good-looking PC games". 1080p monitors are so cheap and ubiquitous today that if you were going to buy or build a computer with the intention of playing video games, there would be no sense in getting anything less.

#5151752 8x8 bitmap won't load with glBitmap?

Posted by on 05 May 2014 - 08:41 PM

Any book which is teaching you to use glBitmap is going to be quite outdated. I'd recommend finding newer resources to teach yourself OpenGL.


See: http://www.gamedev.net/topic/655948-nehe-37-model/