i.e. if you really want to know, looking at SDL’s code would probably
enlighten us.
**
You’re right about the pitch member. Funny thing is I had an instance
where I was working with 8 bit surfaces and bitmaps. Upon loading one and
attempting to draw it with Direct Surface editing, I discovered that the
pitch member (even in a 1 byte pixel format) can be different than the
width. The image I loaded had a width of 147 pixels. After loading it into
a surface, the pitch member ended up being 148. Any idea why this
difference would occur? Regardless, I got into the habit of using that
pitch member instead of the surface width when directly accessing pixel
rows.
Jonny D wrote:
A recent post on the list reminded me that pitch includes the width,
duh. So, remove the width from my memcpy call.
Jonny D
On Sat, Dec 31, 2011 at 9:18 AM, Jonathan Dearborn <> wrote:
Quote:
What are you trying to do with this function? It takes care to mess
with the ‘pixels’ member of SDL_Surface. You should not have to do
anything to it unless you’re writing your own loader, blitter, or
primitives. SDL_Surfaces represent graphical buffers in SDL and are
typically manipulated with SDL_BlitSurface().
As for the things I notice here… You are assuming that the pixels are
arranged in a scr_w x scr_h rectangle. This might not be true depending on
the ‘pitch’ member. Also, you are assuming that the data is stored as
single bytes (unsigned char). You have not indicated that you know this
about your surface. The ‘format’ member has ‘BytesPerPixel’ that might not
be 1. In modern SDL, it is usually 24 or 32 bit (3 or 4 bytes) per pixel.
I haven’t ever tried using memcpy on a surface, but it might have to look
more like this:
memcpy(p, buffer, (scr_w + screen->pitch)*scr_h *
screen->format->BytesPerPixel);
Make sure ‘buffer’ has the right amount of space, of course.
I don’t know if this fixes anything, but good luck anyhow.
Jonny D
On Thu, Dec 29, 2011 at 11:07 PM, robhilly <> wrote:
Quote:
Hello all, first time poster but long time supporter and programmer of
SDL. I have been away from graphics programming for a while. But I came
back to SDL and after a few days or reacquainting myself with the library,
I feel I have a basic grasp of it.
My question for all you developers out there is in regards to a simple
game engine I just coded. As of now it is still error prone and not
perfect, but I am working on it. My main concern is that whenever I run my
program, it seems to work fine and even displays a bitmap image I loaded.
However, upon exiting I get a segmentation fault in my console. I didn’t
think this would affect my program, but when I try to move my bitmap
interactively (in response to keyboard presses), nothing happens. After
running the GNU debugger, I get this output:
Code:
Program received signal SIGSEGV, Segmentation fault.
0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
(gdb) where
#0 0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
#1 0x0015fbe1 in SDL_UpdateRect () from /usr/lib/libSDL-1.2.so.0
#2 0x08048cb4 in updateScreen ()
#3 0x08048eb7 in main ()
My code is quite long so for now I will post my screen update function. If
more is required I will be glad to post the whole code if that will help.
Quote:
Note that screen and buffer were previously initialized as SDL_Surface and
unsigned char*, respectively.
Code:
void updateScreen()
{
unsigned char *p;
/lock screen and copy buffer to it/
SDL_LockSurface(screen);
p = (unsigned char*)screen->pixels;
memcpy(p, buffer, scr_w * scr_h);
SDL_UnlockSurface(screen);
SDL_UpdateRect(screen, 0, 0, 0, 0);
}
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org