Old problem

How can I create a black background without use a bmp image?
Without bmp is more fast than with bmp?
tnx

NighTiger wrote:

How can I create a black background without use a bmp image?
Without bmp is more fast than with bmp?
tnx


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

If you, as I expect, want to clear the screen, look up the
SDL_FillRect() function.

NighTiger wrote:

How can I create a black background without use a bmp image?
Without bmp is more fast than with bmp?

SDL_FillRect(screen, NULL, 0);

Or if you want to play safe:
SDL_FillRect(screen, NULL, SDL_MapRGB(screen->format, 0,0,0));

And yes, SDL_FillRect() is faster than the black bmp image.–
Mika Halttunen
@Mika_Halttunen

Tnx for your help, but I’ve another problem.

When I move a image and update the screen, remain the copy of image in
the old position!

why?
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20031009/d44e2c29/attachment.pgp

When I move a image and update the screen, remain the copy of image in
the old position!

You need to clear the framebuffer. Every time you start a new frame, the
contents of the last one remains.

Easiest way to do this (assuming your using a 2D surface and not OpenGL):

SDL_FillRect(SDL_GetVideoSurface(), NULL, 0);

This blanks the video surface to black…do this once every frame before
drawing anything to erase what was there last frame.

If this is OpenGL, use glClear(GL_COLOR_BUFFER_BIT) instead.

–ryan.

Because you didn’t clear the old position.

There are myriad ways to acheive this. The easiest idea conceptualy is
to clear the buffer every frame before you draw anything (If you have a
big background image that fills the entire screen then just blit that)
and re-draw everything every frame.

Alternatively, you can remember where your sprite was, erase it’s old
rectangle, then redraw it in it’s new position, but the logic for this
gets quite difficult when you’re using a double buffered display.

So, simply put something at the beginning of your main loop to clear
the screen, either use SDL_blit and a large background image, or
SDL_FillRect and a colour of your choice.

— NighTiger wrote: > Tnx for your help, but
I’ve another problem.>

When I move a image and update the screen, remain the copy of image
in
the old position!

why?

ATTACHMENT part 2 application/pgp-signature name=signature.asc


Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk

Or rather; why not? :wink:

You don’t really move a surface. You just move a virtual object in
some world defined by your code, and that has no effect on the
screen. Then you update the screen, one way or another, so that it
represents the current state of your virtual world.

The easiest and most straightforward way of doing this is to simply
render everything on every update - and here’s where your problem is:
That includes the background! Any pixels you don’t touch remain
unchanged(*), so if you’re currently only moving an image around, you
have to somehow define the background, so you can update that as
well.

Short version: Just do this before you render your image:

SDL_FillRect(screen, NULL, SDL_MapRGB(screen->format, 0,0,0));

(SDL_FillRect(screen, NULL, 0); will work as well, but only because 0
happens to mean black with any RGB(A) pixel format. The exception is
indexed color modes, where you get whatever is in index 0 of the
palette.)

(*) “Unchanged” is oversimplified. For now, you’re probably
better off assuming that any areas you don’t repaint before
you flip become garbage. At least, you’ll get annoying
flickering on some targets. It is possible to make use
of the fact that static areas don’t need to be updated every
frame, but “First learn stand. Then learn fly!” :wink:

//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.nethttp://www.reologica.se —On Thursday 09 October 2003 23.36, NighTiger wrote:

Tnx for your help, but I’ve another problem.

When I move a image and update the screen, remain the copy of image
in the old position!

why?

Tnx all for the help.

But I don’t understand a small thing.

Why SDL_UpdateRect(screen,0,0,0,0); is insufficient for clear the
buffer?

tnx

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20031010/d1701216/attachment.pgp

All it does is make sure the changes you’ve done are made visible.
If you’re on a s/w surface display, SDL_UpdateRect() blits the
requested part of the shadom surface (the one you’re rendering into)
to the actual screen. If you have a h/w display surface (that is, you
render directly into VRAM), SDL_UpdateRect() does nothing.

So, it doesn’t really make a difference; what you see is still
whatever you’ve rendered so far - and unless you repaint the whole
area every frame, that includes various old stuff you didn’t erase or
replace.

//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.nethttp://www.reologica.se —On Friday 10 October 2003 14.12, NighTiger wrote:

Tnx all for the help.

But I don’t understand a small thing.

Why SDL_UpdateRect(screen,0,0,0,0); is insufficient for clear the
buffer?

Why SDL_UpdateRect(screen,0,0,0,0); is insufficient for clear the
buffer?

Because it’s just copying the pixels from the SDL_Surface to the screen,
not clearing the framebuffer.

–ryan.