Does CreateTextureFromSurface imply SDL_TEXTUREACCESS_STATIC

Also, why is the documentation so limited at present (No example code, missing items eg. SDL_RenderSetLogicalSize).?

SDL_TEXTUREACCESS_STATIC
Message-ID: <1380517109.m2f.39472 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Also, why is the documentation so limited at present (No example code,
missing items eg. SDL_RenderSetLogicalSize).?

There’s a couple of reasons, that all inter-play with each other.
No-one is being paid (at least as far as I know) to maintain the
documentation, until recently the API was occasionally changing, and
priorities have mostly revolved around squashing bugs and adding
needed features. Thus, the documentation has mostly been of the “when
convenient” sort. In fact, I think that it probably has mostly been
done by people who got annoyed with the particular bits that they
fixed. If you’d like to help on the documentation, then by all means,
let Sam or Ryan know. Help on the documentation & tutorial front is
always desirable.> Date: Mon, 30 Sep 2013 04:58:29 +0000

From: “mattbentley”
To: sdl at lists.libsdl.org
Subject: [SDL] Does CreateTextureFromSurface imply

Jared Maddox wrote:

There’s a couple of reasons, that all inter-play with each other.
No-one is being paid (at least as far as I know) to maintain the
documentation, until recently the API was occasionally changing, and
priorities have mostly revolved around squashing bugs and adding
needed features. Thus, the documentation has mostly been of the “when
convenient” sort. In fact, I think that it probably has mostly been
done by people who got annoyed with the particular bits that they
fixed. If you’d like to help on the documentation, then by all means,
let Sam or Ryan know. Help on the documentation & tutorial front is
always desirable.


I’d love to help, but I’m still learning, as is everyone else, so it’s a catch22 - either people are able to learn and then document it, or the documentation to allow them to learn won’t exist.

And the answer to the question in the subject line is “Yes” - SDL_CreateTextureFromSurface() calls SDL_CreateTexture() with the access parameter set to “SDL_TEXTUREACCESS_STATIC”

Not sure why there isn’t a “SDL_UpdateTextureFromSurface()” function to allow you to copy a surface to an existing texture (with whatever access you set for it). At first glance, it looks like it would be easy enough to do. But then, I’m a newbie at SDL too… :slight_smile:

Assuming there isn’t one just because nobody thought of that use case.

2013/10/1, lloyd_b :> And the answer to the question in the subject line is “Yes” -

SDL_CreateTextureFromSurface() calls SDL_CreateTexture() with the access
parameter set to “SDL_TEXTUREACCESS_STATIC”

Not sure why there isn’t a “SDL_UpdateTextureFromSurface()” function to
allow you to copy a surface to an existing texture (with whatever access you
set for it). At first glance, it looks like it would be easy enough to do.
But then, I’m a newbie at SDL too… :slight_smile:

I use SDL_UpdateTexture() with a texture and surface of the same dimensions
and bit depth:
SDL_UpdateTexture(dest_texture, NULL, source_surface->pixels,
source_surface->pitch);

Is that what you were looking for?

Jonny DOn Wed, Oct 2, 2013 at 1:55 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:

Assuming there isn’t one just because nobody thought of that use case.

2013/10/1, lloyd_b :

And the answer to the question in the subject line is “Yes” -
SDL_CreateTextureFromSurface() calls SDL_CreateTexture() with the access
parameter set to “SDL_TEXTUREACCESS_STATIC”

Not sure why there isn’t a “SDL_UpdateTextureFromSurface()” function to
allow you to copy a surface to an existing texture (with whatever access
you
set for it). At first glance, it looks like it would be easy enough to
do.
But then, I’m a newbie at SDL too… :slight_smile:


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

Jonny D wrote:

I use SDL_UpdateTexture() with a texture and surface of the same dimensions and bit depth:
SDL_UpdateTexture(dest_texture, NULL, source_surface->pixels, source_surface->pitch);

Is that what you were looking for?

Jonny D

That was what I meant by it appearing to be easy to make a SDL_UpdateTextureFromSurface() - SDL_UpdateTexture() is already used to do most of the work. But SDL_CreateTextureFromSurface() also has some other functionality, such as automatically handliing textures/surfaces with different pixel formats, as well as some stuff with alpha blending that I don’t entirely understand.

I think that if you’re careful to make sure that all your textures and surfaces use the same pixel format, then your solution works great. But functions like IMG_Load() don’t allow you to control the pixel format of the created surface - you get a surface in whatever pixel format the function decides to give you. So there may still be a use for an SDL_UpdateTextureFromSurface().

I agree, with the caveat that performance would suffer significantly
without feedback. As a workaround, you can blit whatever IMG_Load() gives
you onto a surface that you created for the purpose of fast uploads.

Jonny DOn Wed, Oct 2, 2013 at 2:41 PM, lloyd_b wrote:

**

Jonny D wrote:

I use SDL_UpdateTexture() with a texture and surface of the same
dimensions and bit depth:
SDL_UpdateTexture(dest_texture, NULL, source_surface->pixels,
source_surface->pitch);

Is that what you were looking for?

Jonny D

That was what I meant by it appearing to be easy to make a
SDL_UpdateTextureFromSurface() - SDL_UpdateTexture() is already used to do
most of the work. But SDL_CreateTextureFromSurface() also has some other
functionality, such as automatically handliing textures/surfaces with
different pixel formats, as well as some stuff with alpha blending that I
don’t entirely understand.

I think that if you’re careful to make sure that all your textures and
surfaces use the same pixel format, then your solution works great. But
functions like IMG_Load() don’t allow you to control the pixel format of
the created surface - you get a surface in whatever pixel format the
function decides to give you. So there may still be a use for an
SDL_UpdateTextureFromSurface().


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

lloyd_b wrote:

And the answer to the question in the subject line is “Yes” - SDL_CreateTextureFromSurface() calls SDL_CreateTexture() with the access parameter set to “SDL_TEXTUREACCESS_STATIC”

Not sure why there isn’t a “SDL_UpdateTextureFromSurface()” function to allow you to copy a surface to an existing texture (with whatever access you set for it). At first glance, it looks like it would be easy enough to do. But then, I’m a newbie at SDL too… :slight_smile:

Thanks lloyd :slight_smile:
Much appreciated.

ps. Is there a simpler way to get PNG support in SDL2 than the SDL_IMG library? Cause there’s no documentation for the v2 of SDL_IMG as far as I can tell (all documentation is for prev version), and like most people in games dev, I don’t need support for anything other than png.

There’s nothing outdated or wrong about the documentation at
http://www.libsdl.org/projects/SDL_image/ that I’ve encountered.

The API is ridiculously trivial:

IMG_Init(IMG_INIT_PNG);

// load sample.png into image
SDL_Surface *image;
image=IMG_Load(“sample.png”);
if(!image) {
printf(“IMG_Load: %s\n”, IMG_GetError());
// handle error
}

(this example is straight from the online docs)

Don’t get me wrong, there’s plenty to complain about with the satellite
libraries (>_> SDL_Mixer…), but SDL_image is pretty much the easiest of
the lot.

If you don’t want to use it, you can always look at using libpng directly,
eg.
http://www.piko3d.com/tutorials/libpng-tutorial-loading-png-files-from-streams

Or use STB:
http://nothings.org/stb_image.c~
Doug.

On Thu, Oct 3, 2013 at 8:46 AM, mattbentley wrote:

**
ps. Is there a simpler way to get PNG support in SDL2 than the SDL_IMG
library? Cause there’s no documentation for the v2 of SDL_IMG as far as I
can tell (all documentation is for prev version), and like most people in
games dev, I don’t need support for anything other than png.


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

Doug wrote:

There’s nothing outdated or wrong about the documentation at http://www.libsdl.org/projects/SDL_image/ (http://www.libsdl.org/projects/SDL_image/) that I’ve encountered.

“This document was generated on November, 3 2009”

There is no documentation for v2 of SDL_IMG.

2013/10/3 mattbentley

**

Doug wrote:

There’s nothing outdated or wrong about the documentation at
http://www.libsdl.org/projects/SDL_image/ that I’ve encountered.

“This document was generated on November, 3 2009”

There is no documentation for v2 of SDL_IMG.

Where did it say that the public API changed for the SDL2 transition?

Advice: Pick a chunk of code you are working to understand. Mine is
SDL’s new GameController API. Then spend some time in SDL’s source
code, learning how it does what it does. The tests directory is your
(very basic) documentation as code for how to do little things.

As you figure out something (and have time?that’s been my issue the
past week), figure out how to update the documentation. The feedback
link on the wiki pages will get it to somebody (Sam, where does that
go anyway? Right into your lap with everything else as usual?) :wink:

There’s a documentation list?you can also post stuff there, though
that has been awfully quiet lately. And, after writing a couple of
things and getting the hang of it, you might talk Sam into a wiki
account to update it yourself. That means learning MoinMoin if you
don’t already know it.

There’s a mirror of the old SDL 1.2 wiki out there which can serve as
a starting place, but a lot has changed.

JosephOn Mon, Sep 30, 2013 at 09:48:28PM +0000, mattbentley wrote:

I’d love to help, but I’m still learning, as is everyone else, so it’s a catch22 - either people are able to learn and then document it, or the documentation to allow them to learn won’t exist.

Wouldn’t that be a very slow path, doing all of that pixel format
conversion all the time?

JosephOn Wed, Oct 02, 2013 at 06:41:17PM +0000, lloyd_b wrote:

Jonny D wrote:

I use SDL_UpdateTexture() with a texture and surface of the same dimensions and bit depth:
SDL_UpdateTexture(dest_texture, NULL, source_surface->pixels, source_surface->pitch);

Is that what you were looking for?

That was what I meant by it appearing to be easy to make a SDL_UpdateTextureFromSurface() - SDL_UpdateTexture() is already used to do most of the work. But SDL_CreateTextureFromSurface() also has some other functionality, such as automatically handliing textures/surfaces with different pixel formats, as well as some stuff with alpha blending that I don’t entirely understand.

Yes, it would, which is why that path doesn’t exist. :)On Sat, Oct 5, 2013 at 9:18 AM, T. Joseph Carter < tjcarter at spiritsubstance.com> wrote:

On Wed, Oct 02, 2013 at 06:41:17PM +0000, lloyd_b wrote:

Jonny D wrote:

I use SDL_UpdateTexture() with a texture and surface of the same
dimensions and bit depth:
SDL_UpdateTexture(dest_**texture, NULL, source_surface->pixels,
source_surface->pitch);

Is that what you were looking for?

That was what I meant by it appearing to be easy to make a
SDL_UpdateTextureFromSurface() - SDL_UpdateTexture() is already used to do
most of the work. But SDL_CreateTextureFromSurface() also has some other
functionality, such as automatically handliing textures/surfaces with
different pixel formats, as well as some stuff with alpha blending that I
don’t entirely understand.

Wouldn’t that be a very slow path, doing all of that pixel format
conversion all the time?

Joseph

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

SDL_image hasn’t had changes the way SDL has, the documentation is from
2009 but as far as I know most of the changes from 1.2 to 2.0 have been
improvements and fixes.On Oct 2, 2013 11:23 PM, “Jonas Kulla” wrote:

2013/10/3 mattbentley

**

Doug wrote:

There’s nothing outdated or wrong about the documentation at
http://www.libsdl.org/projects/SDL_image/ that I’ve encountered.

“This document was generated on November, 3 2009”

There is no documentation for v2 of SDL_IMG.

Where did it say that the public API changed for the SDL2 transition?


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

Seems like what’s called for is some documentation then. A code
snippet to create a texture for streaming would do. Of course, that
code snippet already exists: SDL_CreateSurfaceFromTexture! One might
copy the function wholesale and make minor alterations, but looking
at it I see potential for some refactoring to give developers a few
helper functions:

SDL_NearestTextureFormat to help choose the best SDL_PixelFormat for
a given renderer given an arbitrary surface. That’s actually a very
useful thing to be able to know if you’re going to be updating
textures from surfaces pretty much ever.

A black box function that makes a texture match the color/blend/alpha
modes of a surface. (It actually looks like this originally WAS a
separate function that got folded into SDL_CreateTextureFromSurface,
likely because someone said they couldn’t imagine where else it would
be useful. Answer: If you’re going to be setting up streaming
textures from surfaces, which SDL does not provide a direct path for
because it’s awfully slow!) :wink:

(Possibly) a function that actually just converts a surface to a
format suitable for SDL_UpdateTexture’ing. Given the (IMO more
generically useful) suggestion of a SDL_NearestTextureFormat which
allows you to kind of work both ways, this is trivial glue the dev
can provide if they need it.

By way of some quick documentation for the new developers here on the
list, the current SDL_CreateTextureFromSurface works like this:

  1. Determine the best texture format, given the surface
  2. Create a texture matching that format
  3. If the renderer uses the same format as the texture:
    1. Update the texture (locking the surface if necessary)
    Else:
    1. Create a temp surface from the old that matches the texture
    2. Update the texture with the new surface data
    3. Free the temp surface
  4. Update the texture render mode to match that of the surface.

To update a streaming texture from a surface, you would:

  1. Determine the best texture format, given the surface
  2. Create a texture matching that format
  3. If the texture format is DIFFERENT from the surface format:
    1. Create a new surface from the old that matches the texture
    2. Free the original surface
    3. Assign the original surface’s pointer to the new surface
  4. Update the texture (locking the surface if necessary)
  5. Update the texture render mode to match that of the surface.

I see no reason why the texture render mode couldn’t move to before
the conditional. In the existing function, it happens based on the
original surface mode, not the converted surface. I didn’t look, but
I’d expect the converted surface to retain those modes, and so I left
them here. If not, you’ll need to account for it.

In fact, I’d move that chunk of code to before the pixel data is
copied. The rendering mode seems to go with the texture more than
the pixel data does in my mind for some reason that probably only
makes sense in my own head. :slight_smile:

JosephOn Sat, Oct 05, 2013 at 12:40:07PM -0700, Sam Lantinga wrote:

Yes, it would, which is why that path doesn’t exist. :slight_smile:

On Sat, Oct 5, 2013 at 9:18 AM, T. Joseph Carter < @T_Joseph_Carter> wrote:

On Wed, Oct 02, 2013 at 06:41:17PM +0000, lloyd_b wrote:

Jonny D wrote:

I use SDL_UpdateTexture() with a texture and surface of the same
dimensions and bit depth:
SDL_UpdateTexture(dest_**texture, NULL, source_surface->pixels,
source_surface->pitch);

Is that what you were looking for?

That was what I meant by it appearing to be easy to make a
SDL_UpdateTextureFromSurface() - SDL_UpdateTexture() is already used to do
most of the work. But SDL_CreateTextureFromSurface() also has some other
functionality, such as automatically handliing textures/surfaces with
different pixel formats, as well as some stuff with alpha blending that I
don’t entirely understand.

Wouldn’t that be a very slow path, doing all of that pixel format
conversion all the time?

Alberto Corona wrote:

SDL_image hasn’t had changes the way SDL has, the documentation is from 2009 but as far as I know most of the changes from 1.2 to 2.0 have been improvements and fixes.

Maybe most of them have been, but that doesn’t mean the other changes don’t need thorough documentation
There are several new functions, for example, which load images directly into textures as opposed to surfaces. There is no documentation for these.

When in doubt, submit some! :wink:

JosephOn Tue, Oct 08, 2013 at 12:43:20AM +0000, mattbentley wrote:

SDL_image hasn’t had changes the way SDL has, the documentation is from 2009 but as far as I know most of the changes from 1.2 to 2.0 have been improvements and fixes.

Maybe most of them have been, but that doesn’t mean the other changes don’t need thorough documentation
There are several new functions, for example, which load images directly into textures as opposed to surfaces. There is no documentation for these.