Jump to content

  • Log In with Google      Sign In   
  • Create Account


Chris_F

Member Since 04 Oct 2010
Offline Last Active Today, 09:27 AM
-----

#5167454 Smooth sprite movement

Posted by Chris_F 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 Chris_F 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 Chris_F 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 Chris_F 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 Chris_F on 16 June 2014 - 04:40 AM

Hi,

 

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:

attachicon.gifng.jpg

 

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

attachicon.gifg1.jpg

 

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

attachicon.gifg1div2.2.jpg

 

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

attachicon.gifg2.2.jpg

 

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:

attachicon.gifpixcmp.jpg

 

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
or
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 Chris_F 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 Chris_F 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 Chris_F 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
    ret

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

 

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
    ret
is_bit_set(unsigned char, int):
    movzx    eax, dil
    mov    ecx, esi
    sar    eax, cl
    and    eax, 1
    ret



#5157708 Checking if a bit is set in a byte

Posted by Chris_F 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 Chris_F 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 Chris_F 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 Chris_F 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 Chris_F 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 Chris_F 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/




#5150084 Texture2DArray

Posted by Chris_F on 28 April 2014 - 05:09 AM

I was playing around with sprite rendering a few weeks ago. I used OpenGL, but the same technique should be supported by DirectX 11.

 

Basically I have 32 different sprite images, all the same format and resolution, so I create a 128x128x32 2D texture array. You only have to create the texture array once, as it should contain all the sprites you may want to use during any frame. Next I create a shader storage buffer (think they are called UAVs in DX11, but a constant buffer could also work depending on the number of sprites.) This buffer contains a transformation matrix to handle the position, scale, and rotation of the sprite, it also contains an integer to act as an index into my texture array. All you have to do each frame is update this buffer. For rendering I use instancing, so that all the sprites can be drawn with a single draw call. In the shader you index into the memory buffer using the instance id.

Attached Thumbnails

  • sprites.jpg





PARTNERS