Hello,
I want a sprite to always be where the mouse is (like a cursor I supose), but just assigning the x and y of the mouse when a movement is made to the sprites rect doesn’t work… the sprite hangs around the top corner of the screen and moves out of view in the opposite direction of the mouse movement.
Second to just at least get something moving around I switched to controlling the sprites position with the arrow keys. This too produces very strange behaviour. I’ll hit left once and it will go left but if I hit right after that it goes left a few more times and then starts going right. On top of that the sprite eventually disapears. I’m not sure whats making the sprite get clipped but as for the weird movement with the keyboard…should I call SDL_PumpEvents() or something?
Thanks,
Chip
I want a sprite to always be where the mouse is (like a cursor I supose),
but just assigning the x and y of the mouse when a movement is made to the
sprites rect doesn’t work… the sprite hangs around the top corner of the
screen and moves out of view in the opposite direction of the mouse
movement.
Second to just at least get something moving around I switched to
controlling the sprites position with the arrow keys. This too produces
very strange behaviour. I’ll hit left once and it will go left but if I
hit right after that it goes left a few more times and then starts going
right. On top of that the sprite eventually disapears. I’m not sure whats
making the sprite get clipped but as for the weird movement with the
keyboard…should I call SDL_PumpEvents() or something?
Without seeing your code I can’t determine where you’re going wrong. As a
hint I’ve written a small demo program that does both the above - moves a
picture with the mouse, and lets you move it with the keyboard too. Hopefully
it’ll help you work out what you may have done wrong.
Just to make it extra challenging, there aren’t any helpful comments in the
program, so you’ll have to work it out yourself. 
You’ll need to put the blob.bmp (or any other bitmap you want) in the same
directory as the program for it to run…
(Sorry for sending this to the list, but it’s sooo small)On Mon, 14 Jan 2002, Chip Collier wrote:
Mike.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: sprite.c
Type: text/x-csrc
Size: 3291 bytes
Desc: Test program
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020114/7890effc/attachment.c
-------------- next part --------------
A non-text attachment was scrubbed…
Name: blob.bmp
Type: image/bitmap
Size: 7654 bytes
Desc: Debian logo
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020114/7890effc/attachment.bin
Thanks!
I just compiled the program and it’s exactly what I was trying to do. I was handling event much differently than your program does and I wasn’t updating *.w or *.h info like you program does. I wasn’t doing it at all.
Thanks again,
Chip
I just compiled the program and it’s exactly what I was trying to do. I
was handling event much differently than your program does and I wasn’t
updating *.w or *.h info like you program does. I wasn’t doing it at all.
No problem. The reason I set the .w and .h on each blit is that if your
blitting is clipped (by the edge of the screen, for example) the values are
changed - if you only set them once before entering the loop, it works fine
until the blob hits the side of the screen. Of course, it can’t actually go
outside of the screen, but that’s not the point 
Incidentally, you can get a very significant increase in speed by two simple
changes. I modified it a little to make the blob bounce of each edge of the
screen, and run this for 10,000 frames. The code I gave you takes 55
seconds to run on my system, which is about 181 fps (Celeron 600, XFree86
4.1.0, 3dFX Banshee)
a) only update the changed part of the screen. This helps a heck of a lot.
Replace the SDL_UpdateRect (screen, 0,0,0,0) call with:
SDL_UpdateRects (screen, 1, &poslast);
SDL_UpdateRects (screen, 1, &posnow);
Result: 10000 frames in 6409 ticks, 1560.3058fps.
b) convert the blob to the video surface’s format when it’s loaded.
See the attached code for this.
Result: 10000 frames in 52587 ticks, 190.1611fps.
Okay, so that one isn’t all that impressive; but if you do both a) and b) then
things start looking good:
Result: 10000 frames in 4236 ticks, 2360.7177fps.
Attached is the updated code. All the changes above are incorporated, with
simple #if 1’s that you can change to #if 0 so you can see the effect it
has. Also, if you #define BENCHMARK it’ll run the benchmark thing.
I think that’s as much life as I’m gonna squeeze out of this little demo :-)On Mon, 14 Jan 2002, Chip Collier wrote:
Mike.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: sprite2.c
Type: text/x-csrc
Size: 4889 bytes
Desc: Sprite test, version 2.0
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020114/4ac64f0a/attachment.c
a) only update the changed part of the screen. This helps a heck of a lot.
Replace the SDL_UpdateRect (screen, 0,0,0,0) call with:
SDL_UpdateRects (screen, 1, &poslast);
SDL_UpdateRects (screen, 1, &posnow);
Result: 10000 frames in 6409 ticks, 1560.3058fps.
b) convert the blob to the video surface’s format when it’s loaded.
See the attached code for this.
Result: 10000 frames in 52587 ticks, 190.1611fps.
Okay, so that one isn’t all that impressive; but if you do both a) and b) then
things start looking good:
Result: 10000 frames in 4236 ticks, 2360.7177fps.
Attached is the updated code. All the changes above are incorporated, with
simple #if 1’s that you can change to #if 0 so you can see the effect it
has. Also, if you #define BENCHMARK it’ll run the benchmark thing.
I think that’s as much life as I’m gonna squeeze out of this little demo
But wait! You can squeeze a tiny bit more performance out on some platforms
by combining the update rects calls:
SDL_Rect updates[2];
updates[0] = poslast
updates[1] = posnow
SDL_UpdateRects(screen, 2, updates)
This will also have a little less flicker.
Heheh…
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
But wait! You can squeeze a tiny bit more performance out on some platforms
by combining the update rects calls:SDL_Rect updates[2];
updates[0] = poslast
updates[1] = posnow
SDL_UpdateRects(screen, 2, updates)This will also have a little less flicker.
Gah! I had actually intended to try this but forgot about it half way thru.
Thanks for the reminder, Sam
Anyone with the code; you can do this just by changing the update code to
SDL_UpdateRects (screen, 2, rects);
My results?
10000 frames in 2786 ticks, 3589.3754fps.
That’s up from 2321fps, by only changing those two lines of code.
Of course, this isn’t exactly a real-world app… but that’s still a bit
more than I was expecting ;-)On Mon, 14 Jan 2002, Sam Lantinga wrote:
Mike.
Sam Lantinga wrote:
But wait! You can squeeze a tiny bit more performance out on some platforms
by combining the update rects calls:SDL_Rect updates[2];
updates[0] = poslast
updates[1] = posnow
SDL_UpdateRects(screen, 2, updates)
or even better, by coalescing the rectangles (since two subsequent sprite
positions are likely to overlap a great deal). Some analysis in
http://www.libsdl.org/pipermail/sdl/2000-September/030071.html