SDL_UpdateTexture vs SDL_LockTexture*SDL_UnlockTexture

Not sure if this is a problem with SDL or if my expectations are just
too high. I was trying to do the following:

  1. Load a PNG into a texture.
  2. Get the texture pixel data to mirror the image
  3. Update the texture from the image data

To do number 1 and 3, I originally have the following code

void surface_sdl::set_data(void * data, u_int16 l, u_int16 h,

u_int8 bytes_per_pixel, u_int32 red_mask, u_int32 green_mask, u_int32
blue_mask, u_int32 alpha_mask)
{
if (Surface) SDL_DestroyTexture(Surface);

    u_int32 format = SDL_MasksToPixelFormatEnum (bytes_per_pixel *

8, red_mask, green_mask, blue_mask, alpha_mask);
Surface = SDL_CreateTexture (display->Renderer, format,
SDL_TEXTUREACCESS_STREAMING, l, h);
SDL_UpdateTexture(Surface, NULL, data, bytes_per_pixel * l);
free(data);
}

For number 2, there’s a complimentary method that uses SDL_LockTexture
to get hold of the pixel data.

To my dismay, I noticed that SDL_UpdateTexture does not update the
internal texture->pixels, even though a streaming texture is used. So
SDL_LockTexture returns garbage, while the original texture displays
fine on screen.

The question is, is this an oversight on the side of SDL, or is my
expectation unreasonable?

For now I worked around this issue by using SDL_LockTexture and
SDL_UnlockTexture instead of SDL_UpdateTexture, but that requires 11
lines of code instead of 1.

Somewhat unrelated, but something I would find useful:

  • Allow to specify the texture access mode in SDL_CreateTextureFromSurface.
  • Allow to change the access mode of an existing texture (although I
    guess that can be had with a few lines of client code, but not without
    recreating the whole texture).

Kai

Try this:

SDL_Surface * pngSurface = IMG_Load( “myimage.png” );

if ( SDL_MUSTLOCK(pngSurface) )

{

  SDL_LockSurface(pngSurface);

}

unsigned char *imageData = pngSurface->pixels;

// Do your Horizontal Flip code here

if ( SDL_MUSTLOCK(pngSurface) )

{

  SDL_UnlockSurface(pngSurface);

}

SDL_Texture *pngTexture = SDL_CreateTextureFromSurface( 0, pngSurface );

I hope that helps.

Ken> ----- Original Message -----

From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Kai Sterker
Sent: Sunday, February 06, 2011 11:16 AM
To: sdl at lists.libsdl.org
Subject: [SDL] SDL_UpdateTexture vs SDL_LockTexture*SDL_UnlockTexture

Not sure if this is a problem with SDL or if my expectations are just

too high. I was trying to do the following:

  1. Load a PNG into a texture.

  2. Get the texture pixel data to mirror the image

  3. Update the texture from the image data

To do number 1 and 3, I originally have the following code

void surface_sdl::set_data(void * data, u_int16 l, u_int16 h,

u_int8 bytes_per_pixel, u_int32 red_mask, u_int32 green_mask, u_int32

blue_mask, u_int32 alpha_mask)

{

    if (Surface) SDL_DestroyTexture(Surface);



    u_int32 format = SDL_MasksToPixelFormatEnum (bytes_per_pixel *

8, red_mask, green_mask, blue_mask, alpha_mask);

    Surface = SDL_CreateTexture (display->Renderer, format,

SDL_TEXTUREACCESS_STREAMING, l, h);

    SDL_UpdateTexture(Surface, NULL, data, bytes_per_pixel * l);

    free(data);

}

For number 2, there’s a complimentary method that uses SDL_LockTexture

to get hold of the pixel data.

To my dismay, I noticed that SDL_UpdateTexture does not update the

internal texture->pixels, even though a streaming texture is used. So

SDL_LockTexture returns garbage, while the original texture displays

fine on screen.

The question is, is this an oversight on the side of SDL, or is my

expectation unreasonable?

For now I worked around this issue by using SDL_LockTexture and

SDL_UnlockTexture instead of SDL_UpdateTexture, but that requires 11

lines of code instead of 1.

Somewhat unrelated, but something I would find useful:

  • Allow to specify the texture access mode in SDL_CreateTextureFromSurface.

  • Allow to change the access mode of an existing texture (although I

guess that can be had with a few lines of client code, but not without

recreating the whole texture).

Kai


SDL mailing list

SDL at lists.libsdl.org

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Don’t forget to add a call to:

SDL_FreeSurface( pngSurface );

After the call the CreateTextureFromSurface()From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Ken Rogoway
Sent: Sunday, February 06, 2011 12:41 PM
To: kai.sterker at gmail.com; 'SDL Development List’
Subject: Re: [SDL] SDL_UpdateTexture vs SDL_LockTexture*SDL_UnlockTexture

Try this:

SDL_Surface * pngSurface = IMG_Load( “myimage.png” );

if ( SDL_MUSTLOCK(pngSurface) )

{

  SDL_LockSurface(pngSurface);

}

unsigned char *imageData = pngSurface->pixels;

// Do your Horizontal Flip code here

if ( SDL_MUSTLOCK(pngSurface) )

{

  SDL_UnlockSurface(pngSurface);

}

SDL_Texture *pngTexture = SDL_CreateTextureFromSurface( 0, pngSurface );

I hope that helps.

Ken

----- Original Message -----
From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Kai Sterker
Sent: Sunday, February 06, 2011 11:16 AM
To: sdl at lists.libsdl.org
Subject: [SDL] SDL_UpdateTexture vs SDL_LockTexture*SDL_UnlockTexture

Not sure if this is a problem with SDL or if my expectations are just

too high. I was trying to do the following:

  1. Load a PNG into a texture.

  2. Get the texture pixel data to mirror the image

  3. Update the texture from the image data

To do number 1 and 3, I originally have the following code

void surface_sdl::set_data(void * data, u_int16 l, u_int16 h,

u_int8 bytes_per_pixel, u_int32 red_mask, u_int32 green_mask, u_int32

blue_mask, u_int32 alpha_mask)

{

    if (Surface) SDL_DestroyTexture(Surface);



    u_int32 format = SDL_MasksToPixelFormatEnum (bytes_per_pixel *

8, red_mask, green_mask, blue_mask, alpha_mask);

    Surface = SDL_CreateTexture (display->Renderer, format,

SDL_TEXTUREACCESS_STREAMING, l, h);

    SDL_UpdateTexture(Surface, NULL, data, bytes_per_pixel * l);

    free(data);

}

For number 2, there’s a complimentary method that uses SDL_LockTexture

to get hold of the pixel data.

To my dismay, I noticed that SDL_UpdateTexture does not update the

internal texture->pixels, even though a streaming texture is used. So

SDL_LockTexture returns garbage, while the original texture displays

fine on screen.

The question is, is this an oversight on the side of SDL, or is my

expectation unreasonable?

For now I worked around this issue by using SDL_LockTexture and

SDL_UnlockTexture instead of SDL_UpdateTexture, but that requires 11

lines of code instead of 1.

Somewhat unrelated, but something I would find useful:

  • Allow to specify the texture access mode in SDL_CreateTextureFromSurface.

  • Allow to change the access mode of an existing texture (although I

guess that can be had with a few lines of client code, but not without

recreating the whole texture).

Kai


SDL mailing list

SDL at lists.libsdl.org

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That’s a performance optimization. The assumption is that you’ll
either use SDL_UpdateTexture() or SDL_LockTexture(), but not both.On Sun, Feb 6, 2011 at 9:16 AM, Kai Sterker <kai.sterker at gmail.com> wrote:

Not sure if this is a problem with SDL or if my expectations are just
too high. I was trying to do the following:

  1. Load a PNG into a texture.
  2. Get the texture pixel data to mirror the image
  3. Update the texture from the image data

To do number 1 and 3, I originally have the following code

? ?void surface_sdl::set_data(void * data, u_int16 l, u_int16 h,
u_int8 bytes_per_pixel, u_int32 red_mask, u_int32 green_mask, u_int32
blue_mask, u_int32 alpha_mask)
? ?{
? ? ? ?if (Surface) SDL_DestroyTexture(Surface);

? ? ? ?u_int32 format = SDL_MasksToPixelFormatEnum (bytes_per_pixel *
8, red_mask, green_mask, blue_mask, alpha_mask);
? ? ? ?Surface = SDL_CreateTexture (display->Renderer, format,
SDL_TEXTUREACCESS_STREAMING, l, h);
? ? ? ?SDL_UpdateTexture(Surface, NULL, data, bytes_per_pixel * l);
? ? ? ?free(data);
? ?}

For number 2, there’s a complimentary method that uses SDL_LockTexture
to get hold of the pixel data.

To my dismay, I noticed that SDL_UpdateTexture does not update the
internal texture->pixels, even though a streaming texture is used. So
SDL_LockTexture returns garbage, while the original texture displays
fine on screen.

The question is, is this an oversight on the side of SDL, or is my
expectation unreasonable?

For now I worked around this issue by using SDL_LockTexture and
SDL_UnlockTexture instead of SDL_UpdateTexture, but that requires 11
lines of code instead of 1.

Somewhat unrelated, but something I would find useful:

  • Allow to specify the texture access mode in SDL_CreateTextureFromSurface.
  • Allow to change the access mode of an existing texture (although I
    guess that can be had with a few lines of client code, but not without
    recreating the whole texture).

Kai


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

It’d be handy if someone could share it over here. It’d save some time.________________________________
From: slouken@libsdl.org (slouken)
To: kai.sterker at gmail.com; SDL Development List
Sent: Sun, February 6, 2011 4:05:00 PM
Subject: Re: [SDL] SDL_UpdateTexture vs SDL_LockTexture*SDL_UnlockTexture

That’s a performance optimization. The assumption is that you’ll
either use SDL_UpdateTexture() or SDL_LockTexture(), but not both.

On Sun, Feb 6, 2011 at 9:16 AM, Kai Sterker <kai.sterker at gmail.com> wrote:

Not sure if this is a problem with SDL or if my expectations are just
too high. I was trying to do the following:

  1. Load a PNG into a texture.
  2. Get the texture pixel data to mirror the image
  3. Update the texture from the image data

To do number 1 and 3, I originally have the following code

void surface_sdl::set_data(void * data, u_int16 l, u_int16 h,
u_int8 bytes_per_pixel, u_int32 red_mask, u_int32 green_mask, u_int32
blue_mask, u_int32 alpha_mask)
{
if (Surface) SDL_DestroyTexture(Surface);

   u_int32 format = SDL_MasksToPixelFormatEnum (bytes_per_pixel *

8, red_mask, green_mask, blue_mask, alpha_mask);
Surface = SDL_CreateTexture (display->Renderer, format,
SDL_TEXTUREACCESS_STREAMING, l, h);
SDL_UpdateTexture(Surface, NULL, data, bytes_per_pixel * l);
free(data);
}

For number 2, there’s a complimentary method that uses SDL_LockTexture
to get hold of the pixel data.

To my dismay, I noticed that SDL_UpdateTexture does not update the
internal texture->pixels, even though a streaming texture is used. So
SDL_LockTexture returns garbage, while the original texture displays
fine on screen.

The question is, is this an oversight on the side of SDL, or is my
expectation unreasonable?

For now I worked around this issue by using SDL_LockTexture and
SDL_UnlockTexture instead of SDL_UpdateTexture, but that requires 11
lines of code instead of 1.

Somewhat unrelated, but something I would find useful:

  • Allow to specify the texture access mode in SDL_CreateTextureFromSurface.
  • Allow to change the access mode of an existing texture (although I
    guess that can be had with a few lines of client code, but not without
    recreating the whole texture).

Kai


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and CEO, Galaxy Gameworks


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You can import the VS project. I believe it works right away.

Jonny DOn Sun, Feb 6, 2011 at 2:27 PM, Damian Paz wrote:

It’d be handy if someone could share it over here. It’d save some time.


From: Sam Lantinga
To: kai.sterker at gmail.com; SDL Development List
Sent: Sun, February 6, 2011 4:05:00 PM
Subject: Re: [SDL] SDL_UpdateTexture vs
SDL_LockTexture*SDL_UnlockTexture

That’s a performance optimization. The assumption is that you’ll
either use SDL_UpdateTexture() or SDL_LockTexture(), but not both.

On Sun, Feb 6, 2011 at 9:16 AM, Kai Sterker <kai.sterker at gmail.com> wrote:

Not sure if this is a problem with SDL or if my expectations are just
too high. I was trying to do the following:

  1. Load a PNG into a texture.
  2. Get the texture pixel data to mirror the image
  3. Update the texture from the image data

To do number 1 and 3, I originally have the following code

void surface_sdl::set_data(void * data, u_int16 l, u_int16 h,
u_int8 bytes_per_pixel, u_int32 red_mask, u_int32 green_mask, u_int32
blue_mask, u_int32 alpha_mask)
{
if (Surface) SDL_DestroyTexture(Surface);

   u_int32 format = SDL_MasksToPixelFormatEnum (bytes_per_pixel *

8, red_mask, green_mask, blue_mask, alpha_mask);
Surface = SDL_CreateTexture (display->Renderer, format,
SDL_TEXTUREACCESS_STREAMING, l, h);
SDL_UpdateTexture(Surface, NULL, data, bytes_per_pixel * l);
free(data);
}

For number 2, there’s a complimentary method that uses SDL_LockTexture
to get hold of the pixel data.

To my dismay, I noticed that SDL_UpdateTexture does not update the
internal texture->pixels, even though a streaming texture is used. So
SDL_LockTexture returns garbage, while the original texture displays
fine on screen.

The question is, is this an oversight on the side of SDL, or is my
expectation unreasonable?

For now I worked around this issue by using SDL_LockTexture and
SDL_UnlockTexture instead of SDL_UpdateTexture, but that requires 11
lines of code instead of 1.

Somewhat unrelated, but something I would find useful:

  • Allow to specify the texture access mode in
    SDL_CreateTextureFromSurface.
  • Allow to change the access mode of an existing texture (although I
    guess that can be had with a few lines of client code, but not without
    recreating the whole texture).

Kai


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and CEO, Galaxy Gameworks


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Nope. It doesn’t even compile (for me) in VS2008 express. In CodeBlocks it fails
trying to run some pre-compile steps and if I remove them it throws an error at
some mingw header file. I could post the details if anyone is interested in
giving me hand.________________________________
From: grimfang4@gmail.com (Jonathan Dearborn)
To: SDL Development List
Sent: Sun, February 6, 2011 4:52:57 PM
Subject: Re: [SDL] Does anyone have the codeblocks project to compile SDL 1.3?

You can import the VS project. I believe it works right away.

Jonny D

On Sun, Feb 6, 2011 at 2:27 PM, Damian Paz <@Damian_Paz> wrote:

It’d be handy if someone could share it over here. It’d save some time.


From: slouken@libsdl.org (slouken)

To: kai.sterker at gmail.com; SDL Development List
Sent: Sun, February 6, 2011 4:05:00 PM
Subject: Re: [SDL] SDL_UpdateTexture vs SDL_LockTexture*SDL_UnlockTexture

That’s a performance optimization. The assumption is that you’ll
either use SDL_UpdateTexture() or SDL_LockTexture(), but not both.

On Sun, Feb 6, 2011 at 9:16 AM, Kai Sterker <kai.sterker at gmail.com> wrote:

Not sure if this is a problem with SDL or if my expectations are just
too high. I was trying to do the following:

  1. Load a PNG into a texture.
  2. Get the texture pixel data to mirror the image
  3. Update the texture from the image data

To do number 1 and 3, I originally have the following code

void surface_sdl::set_data(void * data, u_int16 l, u_int16 h,
u_int8 bytes_per_pixel, u_int32 red_mask, u_int32 green_mask, u_int32
blue_mask, u_int32 alpha_mask)
{
if (Surface) SDL_DestroyTexture(Surface);

   u_int32 format = SDL_MasksToPixelFormatEnum (bytes_per_pixel *

8, red_mask, green_mask, blue_mask, alpha_mask);
Surface = SDL_CreateTexture (display->Renderer, format,
SDL_TEXTUREACCESS_STREAMING, l, h);
SDL_UpdateTexture(Surface, NULL, data, bytes_per_pixel * l);
free(data);
}

For number 2, there’s a complimentary method that uses SDL_LockTexture
to get hold of the pixel data.

To my dismay, I noticed that SDL_UpdateTexture does not update the
internal texture->pixels, even though a streaming texture is used. So
SDL_LockTexture returns garbage, while the original texture displays
fine on screen.

The question is, is this an oversight on the side of SDL, or is my
expectation unreasonable?

For now I worked around this issue by using SDL_LockTexture and
SDL_UnlockTexture instead of SDL_UpdateTexture, but that requires 11
lines of code instead of 1.

Somewhat unrelated, but something I would find useful:

  • Allow to specify the texture access mode in SDL_CreateTextureFromSurface.
  • Allow to change the access mode of an existing texture (although I
    guess that can be had with a few lines of client code, but not without
    recreating the whole texture).

Kai


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and CEO, Galaxy Gameworks


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That’s a performance optimization. ?The assumption is that you’ll
either use SDL_UpdateTexture() or SDL_LockTexture(), but not both.

I understand. But wasn’t really sure, so I had to ask :-).

As for Kens suggestion of using an SDL_Surface. I had implemented
something along those lines at first, until I found out that
SDL_CreateTextureFromSurface will only create static textures, while I
need to have streaming ones. But thanks!

I assume keeping a Surface and a static Texture around boils down to
the same memory overhead as using streaming textures, but it means
I’ll have to deal with the lifecycle of two objects, so I dismissed
that idea.

As you might guess, my requirements are a bit special. I am bound by
an interface that I want to implement with a hardware accelerated SDL
1.3 backend. (There’s also a SDL 1.2 and a Cairo implementation).
Having the render targets and a software renderer to resort to in
special cases will make that feasible, and hopefully faster than pure
software rendering or resorting to the compatibility layer.

KaiOn Sun, Feb 6, 2011 at 8:05 PM, Sam Lantinga wrote:

FYI, I updated the wiki with information on the behavior of this
function with streaming textures.
http://wiki.libsdl.org/moin.cgi/SDL_UpdateTexture

Thanks!On Sun, Feb 6, 2011 at 9:16 AM, Kai Sterker <kai.sterker at gmail.com> wrote:

Not sure if this is a problem with SDL or if my expectations are just
too high. I was trying to do the following:

  1. Load a PNG into a texture.
  2. Get the texture pixel data to mirror the image
  3. Update the texture from the image data

To do number 1 and 3, I originally have the following code

? ?void surface_sdl::set_data(void * data, u_int16 l, u_int16 h,
u_int8 bytes_per_pixel, u_int32 red_mask, u_int32 green_mask, u_int32
blue_mask, u_int32 alpha_mask)
? ?{
? ? ? ?if (Surface) SDL_DestroyTexture(Surface);

? ? ? ?u_int32 format = SDL_MasksToPixelFormatEnum (bytes_per_pixel *
8, red_mask, green_mask, blue_mask, alpha_mask);
? ? ? ?Surface = SDL_CreateTexture (display->Renderer, format,
SDL_TEXTUREACCESS_STREAMING, l, h);
? ? ? ?SDL_UpdateTexture(Surface, NULL, data, bytes_per_pixel * l);
? ? ? ?free(data);
? ?}

For number 2, there’s a complimentary method that uses SDL_LockTexture
to get hold of the pixel data.

To my dismay, I noticed that SDL_UpdateTexture does not update the
internal texture->pixels, even though a streaming texture is used. So
SDL_LockTexture returns garbage, while the original texture displays
fine on screen.

The question is, is this an oversight on the side of SDL, or is my
expectation unreasonable?

For now I worked around this issue by using SDL_LockTexture and
SDL_UnlockTexture instead of SDL_UpdateTexture, but that requires 11
lines of code instead of 1.

Somewhat unrelated, but something I would find useful:

  • Allow to specify the texture access mode in SDL_CreateTextureFromSurface.
  • Allow to change the access mode of an existing texture (although I
    guess that can be had with a few lines of client code, but not without
    recreating the whole texture).

Kai


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks