SDL Digest, Vol 30, Issue 58

First off, where did you get SDL 1.3 Pascal headers from? (Do you have
them? The old 1.2 versions won’t work, since the SDL_Surface struct has been
altered.) I’ve been working on extending the JEDI-SDL headers for 1.3. (I
assume that’s what you’re using.) Send me a
private email if you’d like a copy of my work.

we have our own bindings made from scratch – by far not complete – but
enough for our application
they are open source from the Hedgewars videogame: visit
www.hedgewars.orgto download the source
(I did not write them so if you use them just credit the author reported in
the file)

Your bug is very strange. There’s no reason that SDL_UpperBlit should
change the value of your surface pointer. That shouldn’t be possible if
your header’s set up right. Is it declared as a var parameter in the
function header? (It shouldn’t be.)

I agree that’s strange! actually tmpsurf is declared in the var section
because we need to assign an image source to it

procedure ColorizeLand(Surface: PSDL_Surface);

var tmpsurf: PSDL_Surface;
r, rr: TSDL_Rect;
x, yd, yu: LongInt;
begin

with this you have all the function

Is the function really changing the value to nil? Have you checked that out

in a debugger? Have you checked the return value of the blit function?
It’s more likely that you’re trying to dereference the .w location and
finding something at that memory address that you shouldn’t, because the
structure of SDL_Surface has been changed.

Yes i check this myself with gdb, after stepping out of SDL_UpperBlit it
reports TMPSURF = 0x0 and so when trying to access tmpsurf^.w it crashes

what is really strange is that this very function works flawless in sdl-1.2
why were you saying that tmpsurf should be const?

Vittorio>


From: Vittorio G. <vitto.giova at yahoo.it>
Subject: [SDL] SDL_UpperBlit returns a NULL pointer

hi
i’m experimenting SDL 1.3 with the iPhone and i found out this bug
after a texture is applied to the surface, the source surface is trashed
and when returning to the calling function it won’t be accessible anymore.

the code follows (it’s in pascal, but it’s simple)

tmpsurf:= LoadImage(Pathz[ptCurrTheme] + ‘/LandTex’, false, true, false);
r.y:= 0;
while r.y < LAND_HEIGHT do
begin
r.x:= 0;
while r.x < LAND_WIDTH do
begin
SDL_UpperBlit(tmpsurf, nil, Surface, @r);
inc(r.x, tmpsurf^.w)
end;
inc(r.y, tmpsurf^.h)
end;
SDL_FreeSurface(tmpsurf);
the program terminates when trying to access tmpsurf^.w with a
EXC_BAD_ADDRESS

the weird thing is that this very same function works with no problem when
compiled with SDL1.2 (any platform)

any pointers i could follow?
thanks for any advice
Vittorio

Samuel Goldwynhttp://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html

  • “I’m willing to admit that I may not always be right, but I am never
    wrong.”

Your bug is very strange. There’s no reason that SDL_UpperBlit should change the value of your surface pointer. That shouldn’t be possible if your header’s set up right. Is it declared as a var parameter in the function header? (It shouldn’t be.)

I agree that’s strange! actually tmpsurf is declared in the var section because we need to assign an image source to it

No, I meant the parameter you’re passing tmpsurf to in the header for the blit function. It should be declared like this:

function SDL_UpperBlit(src: PSDL_Surface; srcrect: PSDL_Rect; dst: PSDL_Surface; dstrect: PSDL_Rect): integer; cdecl;

It should be passing your pointer by value, so it can’t be changed. If “src” is declared as a var parameter there, it’s gonna pass by reference, which can corrupt the pointer.

Is the function really changing the value to nil? Have you checked that out in a debugger? Have you checked the return value of the blit function? It’s more likely that you’re trying to dereference the .w location and finding something at that memory address that you shouldn’t, because the structure of SDL_Surface has been changed.

Yes i check this myself with gdb, after stepping out of SDL_UpperBlit it reports TMPSURF = 0x0 and so when trying to access tmpsurf^.w it crashes

what is really strange is that this very function works flawless in sdl-1.2

Have you verified that you got a valid pointer out of LoadImage, BTW? If it’s not loading properly for whatever reason, it could be that you’ve got a nil from the very beginning.From: vitto.giova@yahoo.it (Vittorio Giovara)
To: sdl at lists.libsdl.org
Sent: Wednesday, June 17, 2009 1:46:54 PM
Subject: Re: [SDL] SDL Digest, Vol 30, Issue 58