You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
referring to the variables present in the previous snippet, please detail the following in the documentation:
Assert the range of pfd->bytes_per_pixel: is it always one of 1, 2 and 4, or could it also be 0, 3 or 5?
I suppose it is always <= 4 because SDL_{Get,Set}RGB works with Uint32
Consequently, the range of pfd->bits_per_pixel is always <= 32 right?
pixels is never packed, right? that is, when pfd->bits_per_pixel is a non-multiple of 8, such as 15, can I be assured a sequence of pixels is NOT a sequence of 15 bits one after another? that there is some padding separating pixels, such that they are aligned with some byte boundary?
I have no experience with packed arrays. I have no idea how byte order interacts nor how to retrieve and set values at all
Say pfd->bytes_per_pixel is 3. Is the stride actually 4 bytes, or must I do some hackery using unsigned char * or some special-purpose struct {char a[3]; } in order to index in multiples of 3 bytes? Since uint24_t doesn't exist (unless using C23 _BitInt(24)). How painful is setting and retrieving pixels, also considering byte-order issues? Specially without overwriting neighbor pixels. Please, document
The following always holds, right? pitch >= w * next_highest_power_of_2(pfd->bytes_per_pixel)
1 == next_highest_power_of_2(1)
2 == next_highest_power_of_2(2)
4 == next_highest_power_of_2(3)
4 == next_highest_power_of_2(4)
Otherwise, detail one or more cases where pitch could be longer or smaller
If so, is the remainder of the SDL API prepared to behave correctly given such unusual pitches?
How all this pixel indexing interacts with C strict aliasing rules? Assert whether -fno-strict-aliasing is mandatory to compile translation units that deal with textures and surfaces
furthermore, I'm coming from SDL2. as I was writing this, I struggled to understand the replacement for https://wiki.libsdl.org/SDL2/SDL_RendererInfo. I now understand the new API using SDL_{Get,Set}{Pointer,String,Number,Float,Boolean}Property.
I think some information from surface stuff helps understand texture stuff, but I can never be sure every knowledge translates 1:1
my main worries can be summarized: packing, byte order, indexing and strict aliasing
I don't even want to think CHAR_BIT
The text was updated successfully, but these errors were encountered:
hi,
I'm a very wary person.
suppose this snippet runs infallibly:
referring to the variables present in the previous snippet, please detail the following in the documentation:
pfd->bytes_per_pixel
: is it always one of 1, 2 and 4, or could it also be 0, 3 or 5?SDL_{Get,Set}RGB
works withUint32
pfd->bits_per_pixel
is always <= 32 right?pixels
is never packed, right? that is, whenpfd->bits_per_pixel
is a non-multiple of 8, such as 15, can I be assured a sequence of pixels is NOT a sequence of 15 bits one after another? that there is some padding separating pixels, such that they are aligned with some byte boundary?pfd->bytes_per_pixel
is 3. Is the stride actually 4 bytes, or must I do some hackery usingunsigned char *
or some special-purposestruct {char a[3]; }
in order to index in multiples of 3 bytes? Sinceuint24_t
doesn't exist (unless using C23_BitInt(24)
). How painful is setting and retrieving pixels, also considering byte-order issues? Specially without overwriting neighbor pixels. Please, documentpitch >= w * next_highest_power_of_2(pfd->bytes_per_pixel)
1 == next_highest_power_of_2(1)
2 == next_highest_power_of_2(2)
4 == next_highest_power_of_2(3)
4 == next_highest_power_of_2(4)
-fno-strict-aliasing
is mandatory to compile translation units that deal with textures and surfacesfurthermore, I'm coming from SDL2. as I was writing this, I struggled to understand the replacement for https://wiki.libsdl.org/SDL2/SDL_RendererInfo. I now understand the new API using
SDL_{Get,Set}{Pointer,String,Number,Float,Boolean}Property
.for each of the following pages:
please:
Uint32
of each of the functions above must be the first parameter to this family of property functionsquick links:
final thoughts
I think some information from surface stuff helps understand texture stuff, but I can never be sure every knowledge translates 1:1
my main worries can be summarized: packing, byte order, indexing and strict aliasing
I don't even want to think
CHAR_BIT
The text was updated successfully, but these errors were encountered: