I’m not sure if this is normal behavior, whenever I have a surface whose
coordinates are less than 0 in either direction, they are automatically pushed
back to zero, sometimes very slowly.
This causes problems, as sometimes sprites need to exit the screen at the top or
left. Any fix for this?
I’m not sure if this is normal behavior, whenever I have a surface
whose coordinates are less than 0 in either direction, they are
automatically pushed back to zero, sometimes very slowly.
Well, there is one feature that might cause confusion if you don’t
know about it:
"The final blit rectangle is saved in dstrect after
all clipping is performed (srcrect is not modified)."
This causes problems, as sometimes sprites need to exit the screen
at the top or left. Any fix for this?
Unless you’re seeing something that doesn’t match the documented
behavior:
Always use a temporary SDL_Rect for the destination coordinates. (If
you need clipped coordinates, you’ll find them in that rect after
each blit. Useful for smart updating with SDL_UpdateRects(), which
does not perform clipping.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 23 November 2005 04.32, Nick Stovall wrote:
I do use clipping and dst rects. All I can assume is that SDL_BlitSurface()
sets the dst rect’s y or x value to 0 if it’s less than 0. Is there
any way around this?
I do use clipping and dst rects. All I can assume is that SDL_BlitSurface()
sets the dst rect’s y or x value to 0 if it’s less than 0. Is there
any way around this?
Try rendering to an off screen surface that is larger than your screen,
and then copy a portion of this surface to the actual screen.
You can store the co-ordinates of your graphical items in screen based
co-ordinates as usual, and when they are rendered to the off screen
surface, you first translate them relative to the origin of the screen
on the offscreen surface.
So, for example if your screen is size 100x100 and you have a off screen
surface of size 150x150 this gives you a 25 pixel buffering zone all
round the edge of the screen.
You would translate any screen co-ordinates by (+25, +25) before drawing
to the off screen surface. Then you would blit the off screen surface
from 25,25 to 125,125 to the screen at screen position 0,0.
Hope this makes sense. I tend to ramble.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
/"
\ / ASCII Ribbon Campaign
X against HTML email & vCards
/ \
So, for example if your screen is size 100x100 and you have a off screen
surface of size 150x150 this gives you a 25 pixel buffering zone all
round the edge of the screen.You would translate any screen co-ordinates by (+25, +25) before drawing
to the off screen surface. Then you would blit the off screen surface
from 25,25 to 125,125 to the screen at screen position 0,0.Hope this makes sense. I tend to ramble.
- Tom
The problem with that is that when I blit the buffer to the screen,
its X- and Y- coordinates will still be set to 0, just like any other
surface.
I don’t really understand the problem, because I’ve barely been paying
attention, but is it that you’re trying to re-use the destination or
source SDL_Rect(s) for other bitmaps (or during another frame) without
re-initializing them?
e.g.:
dest.x = -4;
dest.y = -3;
do
{
SDL_BlitSurface(… &dest …);
}
while (!done);
???
If that’s the case, you simply need to remember to re-set the SDL_Rect(s)
at the appropriate time(s).
-bill!On Sat, Nov 26, 2005 at 10:06:39PM +0000, Nick Stovall wrote:
The problem with that is that when I blit the buffer to the screen,
its X- and Y- coordinates will still be set to 0, just like any other
surface.
If that’s the case, you simply need to remember to re-set the SDL_Rect(s)
at the appropriate time(s).-bill!
No, the problem is that if I try to blit a surface using a dest rect that has an
X or Y coordinate that is less than zero, they get set to zero when they get
blitted.
Exactly - that’s the result of the clipping operation, and that’s what
SDL writes back into the destination rectangle. w and/or h should
alse be affected in this case, and if you hit the right or bottom
edge of the target, clipping should affect only w and/or h.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 27 November 2005 03.25, Nick Stovall wrote:
If that’s the case, you simply need to remember to re-set the
SDL_Rect(s) at the appropriate time(s).-bill!
No, the problem is that if I try to blit a surface using a dest rect
that has an X or Y coordinate that is less than zero, they get set
to zero when they get blitted.
Nick Stovall wrote:
So, for example if your screen is size 100x100 and you have a off screen
surface of size 150x150 this gives you a 25 pixel buffering zone all
round the edge of the screen.You would translate any screen co-ordinates by (+25, +25) before drawing
to the off screen surface. Then you would blit the off screen surface
from 25,25 to 125,125 to the screen at screen position 0,0.Hope this makes sense. I tend to ramble.
- Tom
The problem with that is that when I blit the buffer to the screen,
its X- and Y- coordinates will still be set to 0, just like any other
surface.
You won’t be using -X and -Y co-ordinates to blit.
It will solve your problem.
You blit the offscreen surface from 25,25 to 125,125 to the screen
at 0,0
No negative co-ordinates are involved.
Exactly - that’s the result of the clipping operation, and that’s what
SDL writes back into the destination rectangle. w and/or h should
alse be affected in this case, and if you hit the right or bottom
edge of the target, clipping should affect only w and/or h.
Oops, I read the previous question wrong. In any case, it SHOULD only affect w
or h, I’m guess the problem is that it’s affecting the x- and y- coordinates as
well.
[…]
The problem with that is that when I blit the buffer to the
screen, its X- and Y- coordinates will still be set to 0, just
like any other surface.You won’t be using -X and -Y co-ordinates to blit.
It will solve your problem.
You blit the offscreen surface from 25,25 to 125,125 to the
screen at 0,0No negative co-ordinates are involved.
That does indeed avoid the “problem”, and it is the obvious way of
doing it in a few rare cases - but I can’t see the point in
reinventing clipping outside SDL, especially since SDL will do the
clipping tests either way. (Unless you bypass the official API, that
is.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 27 November 2005 19.20, Tom Wilson wrote:
It has to affect x and y as well, when clipping at the left and top
edges respectively. Otherwise, sprites going off the top and left
edges would be cut off on the opposite side instead, of appearing to
move outside the screen.
Anyway, I can’t see what the problem is here. Are we all failing to
understand what the question is about?
Here’s the relevant part of the documentation, and I think is pretty
clear:On Sunday 27 November 2005 19.27, Nick Stovall wrote:
Exactly - that’s the result of the clipping operation, and that’s
what
SDL writes back into the destination rectangle. w and/or h should
alse be affected in this case, and if you hit the right or bottom
edge of the target, clipping should affect only w and/or h.Oops, I read the previous question wrong. In any case, it SHOULD
only affect w or h, I’m guess the problem is that it’s affecting the
x- and y- coordinates as well.
int SDL_BlitSurface(SDL_Surface *src,
SDL_Rect *srcrect, SDL_Surface *dst,
SDL_Rect *dstrect);
DESCRIPTION
This performs a fast blit from the source surface
to the destination surface.
Only the position is used in the dstrect (the width
and height are ignored).
If either srcrect or dstrect are NULL, the entire
surface (src or dst) is copied.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —
David Olofson wrote:> On Sunday 27 November 2005 19.20, Tom Wilson wrote:
[…]
The problem with that is that when I blit the buffer to the
screen, its X- and Y- coordinates will still be set to 0, just
like any other surface.You won’t be using -X and -Y co-ordinates to blit.
It will solve your problem.
You blit the offscreen surface from 25,25 to 125,125 to the
screen at 0,0No negative co-ordinates are involved.
That does indeed avoid the “problem”, and it is the obvious way of
doing it in a few rare cases - but I can’t see the point in
reinventing clipping outside SDL, especially since SDL will do the
clipping tests either way. (Unless you bypass the official API, that
is.)
Fair point on clipping,
But I thought this guy said that if he feeds in a negative co-ordinate
for a destination blit, it [SDL] zero’s the co-ordinates. I assumed
this caused the blit to go to the wrong place on the screen?
–
/"
\ / ASCII Ribbon Campaign
X against HTML email & vCards
/ \