SDL_Image .png with testsprite2.c not rende ring .png correctly in SDL 1.3

Hello group,

I’ve managed to get the testsprite2.c under Windows working under Visual
Studio with full hardward acceleration and everything works great, looks
great, runs really fast.

Now, the only thing I change is to import a .png instead of the default
icon.bmp of the same size. The .png image is a 24 bit .png file created from
Photoshop. I imported this using SDL_Image library.

Here’s the problem: Everything runs fast and is hw accelerated as expected
but the the actual rendering of the .png file shows up a solid rectangle
filled with blue. What I actually drew in it was a transparent orange orb
roughly the same size as the happy face in icon.bmp.

Again, the only thing I changed here was to load up a .png in testsprite2.c
vs. the traditional .bmp example.

Can anyone confirm if the SDL_Image lib works properly with the SDL 1.3
codebase? Any ideas of what I’m doing wrong? Could this be a bug?

Thank you in advance,

-Ralph

Since SDL 1.3 uses a different definition of a SDL_Surface, you have to
recompile SDL_Image.dll against the SDL 1.3 headers. Then it should
work fine.>----- Original Message ----

From: Ralph Caraveo
Subject: [SDL] SDL_Image .png with testsprite2.c not rendering .png correctly in SDL 1.3

Hello group,

I’ve managed to get the testsprite2.c under Windows working under Visual
Studio with full hardward acceleration and everything works great, looks
great, runs really fast.

Now, the only thing I change is to import a .png instead of the default
icon.bmp of the same size. The .png image is a 24 bit .png file created from
Photoshop. I imported this using SDL_Image library.

Here’s the problem: Everything runs fast and is hw accelerated as expected
but the the actual rendering of the .png file shows up a solid rectangle
filled with blue. What I actually drew in it was a transparent orange orb
roughly the same size as the happy face in icon.bmp.

Again, the only thing I changed here was to load up a .png in testsprite2.c
vs. the traditional .bmp example.

Can anyone confirm if the SDL_Image lib works properly with the SDL 1.3
codebase? Any ideas of what I’m doing wrong? Could this be a bug?

Thank you in advance,

Are you sure he is doing what you think he’s doing, Mason?

I think he’s doing something different.

Ralph: testsprite2 does not use SDL_image. SDL_image is separate
from SDL. Attach your code and your PNG and we’ll tell you what you’re
doing wrong.On Sun, Jun 7, 2009 at 7:29 PM, Mason Wheeler wrote:

Since SDL 1.3 uses a different definition of a SDL_Surface, you have to
recompile SDL_Image.dll against the SDL 1.3 headers. ?Then it should
work fine.

----- Original Message ----
From: Ralph Caraveo
Subject: [SDL] SDL_Image .png with testsprite2.c not rendering .png correctly in SDL 1.3

Hello group,

I’ve managed to get the testsprite2.c under Windows working under Visual
Studio with full hardward acceleration and everything works great, looks
great, runs really fast.

Now, the only thing I change is to import a .png instead of the default
icon.bmp of the same size. ?The .png image is a 24 bit .png file created from
Photoshop. ?I imported this using SDL_Image library.

Here’s the problem: ?Everything runs fast and is hw accelerated as expected
but the the actual rendering of the .png file shows up a solid rectangle
filled with blue. ?What I actually drew in it was a transparent orange orb
roughly the same size as the happy face in icon.bmp.

Again, the only thing I changed here was to load up a .png in testsprite2.c
vs. the traditional .bmp example.

Can anyone confirm if the SDL_Image lib works properly with the SDL 1.3
codebase? ?Any ideas of what I’m doing wrong? ?Could this be a bug?

Thank you in advance,


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


http://codebad.com/

Sure looks to me like he said he used SDL_Image to import a PNG to
display instead of the standard BMP used in testsprite2…>----- Original Message ----

From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] SDL_Image .png with testsprite2.c not rendering .png correctly in SDL 1.3

Are you sure he is doing what you think he’s doing, Mason?

I think he’s doing something different.

Ralph: testsprite2 does not use SDL_image. SDL_image is separate
from SDL. Attach your code and your PNG and we’ll tell you what you’re
doing wrong.

On Sun, Jun 7, 2009 at 7:29 PM, Mason Wheeler<@Mason_Wheeler> wrote:

Since SDL 1.3 uses a different definition of a SDL_Surface, you have to
recompile SDL_Image.dll against the SDL 1.3 headers. Then it should
work fine.

----- Original Message ----
From: Ralph Caraveo
Subject: [SDL] SDL_Image .png with testsprite2.c not rendering .png correctly in SDL 1.3

Hello group,

I’ve managed to get the testsprite2.c under Windows working under Visual
Studio with full hardward acceleration and everything works great, looks
great, runs really fast.

Now, the only thing I change is to import a .png instead of the default
icon.bmp of the same size. The .png image is a 24 bit .png file created from
Photoshop. I imported this using SDL_Image library.

Here’s the problem: Everything runs fast and is hw accelerated as expected
but the the actual rendering of the .png file shows up a solid rectangle
filled with blue. What I actually drew in it was a transparent orange orb
roughly the same size as the happy face in icon.bmp.

Again, the only thing I changed here was to load up a .png in testsprite2.c
vs. the traditional .bmp example.

Can anyone confirm if the SDL_Image lib works properly with the SDL 1.3
codebase? Any ideas of what I’m doing wrong? Could this be a bug?

Thank you in advance,

Donny Viszneki <donny.viszneki gmail.com> writes:

Are you sure he is doing what you think he’s doing, Mason?

I think he’s doing something different.

Ralph: testsprite2 does not use SDL_image. SDL_image is separate
from SDL. Attach your code and your PNG and we’ll tell you what you’re
doing wrong.

I understand that testsprite2 does not use SDL_Image but my intention to see
if it would work with SDL_Image the only difference using a .png file as the
test image.

I could post the code I’m using but honestly the only thing I changed in
testsprite2 was linking up to SDL_image, importing the SDL_image.h, then
replacing the SDL_LoadBitmap() routine with IMG_Load(). That’s it!

I will try doing what the previous post said about recompiling SDL_Image using
the SDL 1.3 headers because I did not try that.

I will try doing what the previous post said about recompiling SDL_Image using
the SDL 1.3 headers because I did not try that.

Yep, that’ll do it. SDL_Surface has been changed, and particularly the SDL_Rect
that holds the clip_rect data. It’s now made of 4 32-bit ints instead of 4 16-bit ints.
Pitch has similarly doubled in size. And since pitch comes before the pixels
pointer, your program’s looking at the wrong offset. I’m surprised it didn’t segfault
on you.>----- Original Message ----

From: Ralph Caraveo
Subject: Re: [SDL] SDL_Image .png with testsprite2.c not rendering .png correctly in SDL 1.3

Hello, Ralph!

RC> I will try doing what the previous post said about recompiling
RC> SDL_Image using the SDL 1.3 headers because I did not try that.

Ralph, could you update you local copy of SDL 1.3 from SVN and check it one
more ? Recently I’ve commited a small patch for SDL_video.c regarding
conversion from Surface to Texture. Now if surface is using color keying the
conversion routine tries to find out the best texture format with alpha. I
had similar problems using OpenGL ES renderer.

With best regards, Mike Gorchak. E-mail: mike at malva.ua

Mason Wheeler <masonwheeler yahoo.com> writes:

Yep, that’ll do it. SDL_Surface has been changed, and particularly the
SDL_Rect
that holds the clip_rect data. It’s now made of 4 32-bit ints instead of 4
16-bit ints.
Pitch has similarly doubled in size. And since pitch comes before the pixels
pointer, your program’s looking at the wrong offset. I’m surprised it
didn’t segfault
on you.

It turns out compiling SDL_image against the 1.3 codebase did absolutely
nothing to fix my problem. Are there any other suggestions I can try? I can
try to troubleshoot the problem myself but I don’t know nearly enough about
the SDL_image libs and the internals of SDL to figure this out just yet.

Anybody’s help is appreciated…I’ll keep on trying to figure this one out.

Thanks,

-Ralph

Mike Gorchak <mike malva.ua> writes:

Hello, Ralph!

RC> I will try doing what the previous post said about recompiling
RC> SDL_Image using the SDL 1.3 headers because I did not try that.

Ralph, could you update you local copy of SDL 1.3 from SVN and check it one
more ? Recently I’ve commited a small patch for SDL_video.c regarding
conversion from Surface to Texture. Now if surface is using color keying the
conversion routine tries to find out the best texture format with alpha. I
had similar problems using OpenGL ES renderer.

With best regards, Mike Gorchak. E-mail: mike malva.ua

Hello Mike,

I just now saw this post and I’ll re-get latest on the SVN repository.
Hopefully this is what I need, I’ll let you know how this works out.

Thank you!

-Ralph

Mason Wheeler <masonwheeler yahoo.com> writes:

Yep, that’ll do it. SDL_Surface has been changed, and particularly the
SDL_Rect

that holds the clip_rect data. It’s now made of 4 32-bit ints instead of 4
16-bit ints.

Pitch has similarly doubled in size. And since pitch comes before the pixels
pointer, your program’s looking at the wrong offset. I’m surprised it
didn’t segfault

on you.

It turns out compiling SDL_image against the 1.3 codebase did absolutely
nothing to fix my problem. Are there any other suggestions I can try? I can
try to troubleshoot the problem myself but I don’t know nearly enough about
the SDL_image libs and the internals of SDL to figure this out just yet.

Anybody’s help is appreciated…I’ll keep on trying to figure this one out.

Strange. That worked for me. Try verifying the clip_rect of the surface it
returns, make sure it’s something reasonable.>----- Original Message ----

From: Ralph Caraveo
Subject: Re: [SDL] SDL_Image .png with testsprite2.c not rendering .png correctly in SDL 1.3

Mike Gorchak <mike malva.ua> writes:

Hello, Ralph!

RC> I will try doing what the previous post said about recompiling
RC> SDL_Image using the SDL 1.3 headers because I did not try that.

Ralph, could you update you local copy of SDL 1.3 from SVN and check it one
more ? Recently I’ve commited a small patch for SDL_video.c regarding
conversion from Surface to Texture. Now if surface is using color keying the
conversion routine tries to find out the best texture format with alpha. I
had similar problems using OpenGL ES renderer.

With best regards, Mike Gorchak. E-mail: mike malva.ua

Alright, I got .png’s working. It turns out I did have your latest change
specified in the SDL_video.c file but this post gave me a hint of something to
try.

Essentially I had to change the following line in testsprite2.c

SDL_CreateTextureFromSurface(0, temp);

to

SDL_CreateTextureFromSurface(SDL_PIXELFORMAT_ARGB8888, temp);

Apparently the pixel format had to be specified. I’m guessing the
SDL_CreateTextureFromSurface() method can guess the pixel format you are
working with if you don’t specify one yourself but this doesn’t work for me at
least on my Vista 64 bit box.

So I guess there is a bug in the routine that does the guess work on trying to
figure out the Pixel format of my .png.

I’m happy to give out further details or even post the .png if it helps anyone
to solve the problem. I still don’t know enough about SDL to confidently
supply a patch myself.

Thanks for the help!

Hello, Ralph!

RC>> I will try doing what the previous post said about recompiling
RC>> SDL_Image using the SDL 1.3 headers because I did not try that.

Ralph, could you update you local copy of SDL 1.3 from SVN and check it
one more ? Recently I’ve commited a small patch for SDL_video.c
regarding conversion from Surface to Texture. Now if surface is using
color keying the conversion routine tries to find out the best texture
format with alpha. I had similar problems using OpenGL ES renderer.

RC> So I guess there is a bug in the routine that does the guess work on
RC> trying to figure out the Pixel format of my .png.

I did few more changes, now conversion routine tries original format of
surface first, if it could not be found as supported by renderer, then code
cycles through the all known formats until the best will be found. All
changes are already in SVN.

RC> I’m happy to give out further details or even post the .png if it helps
RC> anyone to solve the problem. I still don’t know enough about SDL to
RC> confidently supply a patch myself.

Please e-mail me this .png file and I will check why it has been converted
in bad way.

With best regards, Mike Gorchak. E-mail: mike at malva.ua