view docs/man3/SDL_BlitSurface.3 @ 1260:80f8c94b5199

Date: 10 Jun 2003 15:30:59 -0400 From: Mike Shal Subject: [SDL] Bug in SDL_wave.c? Hey everyone, I'm not sure if this is a bug in SDL, or if I just have incorrect WAV files. The problem I'm having is loading multiple concatenated WAVs from SDL_LoadWAV_RW. Some WAV files put comments at the end of the file (which may be bad form), and SDL doesn't skip past them when reading from the RWops. So the next WAV I try to load will start at the comment section of the previous WAV, which obviously doesn't work. If anyone else is having this problem, one quick fix you can do is run sox on the bad WAVs, which strips out all of the comment sections. Eg: $ sox sound.wav tmp.wav $ mv -f tmp.wav sound.wav The other fix is to patch SDL_wave.c, which is included with this email. (Assuming I made the patch correctly :). All it does is calculate how much remaining space there is in the WAV file after the data chunk, and does SDL_RWseek to skip it. I don't think it should interfere with anything else, but if someone could check it that would be nice :). If the bug is really with SDL and not with my WAVs, can someone work this into the next version of SDL? Thanks, -Mike Shal
author Sam Lantinga <slouken@libsdl.org>
date Tue, 24 Jan 2006 07:20:18 +0000
parents e5bc29de3f0a
children 546f7c1eb755
line wrap: on
line source

.TH "SDL_BlitSurface" "3" "Tue 11 Sep 2001, 23:01" "SDL" "SDL API Reference" 
.SH "NAME"
SDL_BlitSurface\- This performs a fast blit from the source surface to the destination surface\&.
.SH "SYNOPSIS"
.PP
\fB#include "SDL\&.h"
.sp
\fBint \fBSDL_BlitSurface\fP\fR(\fBSDL_Surface *src, SDL_Rect *srcrect, SDL_Surface *dst, SDL_Rect *dstrect\fR);
.SH "DESCRIPTION"
.PP
This performs a fast blit from the source surface to the destination surface\&.
.PP
Only the position is used in the \fBdstrect\fR (the width and height are ignored)\&.
.PP
If either \fBsrcrect\fR or \fBdstrect\fR are \fBNULL\fP, the entire surface (\fBsrc\fR or \fBdst\fR) is copied\&.
.PP
The final blit rectangle is saved in \fBdstrect\fR after all clipping is performed (\fBsrcrect\fR is not modified)\&.
.PP
The blit function should not be called on a locked surface\&.
.PP
The results of blitting operations vary greatly depending on whether \fBSDL_SRCAPLHA\fP is set or not\&. See \fISDL_SetAlpha\fR for an explaination of how this affects your results\&. Colorkeying and alpha attributes also interact with surface blitting, as the following pseudo-code should hopefully explain\&. 
.PP
.nf
\f(CWif (source surface has SDL_SRCALPHA set) {
    if (source surface has alpha channel (that is, format->Amask != 0))
        blit using per-pixel alpha, ignoring any colour key
    else {
        if (source surface has SDL_SRCCOLORKEY set)
            blit using the colour key AND the per-surface alpha value
        else
            blit using the per-surface alpha value
    }
} else {
    if (source surface has SDL_SRCCOLORKEY set)
        blit using the colour key
    else
        ordinary opaque rectangular blit
}\fR
.fi
.PP
.SH "RETURN VALUE"
.PP
If the blit is successful, it returns \fB0\fR, otherwise it returns \fB-1\fR\&.
.PP
If either of the surfaces were in video memory, and the blit returns \fB-2\fR, the video memory was lost, so it should be reloaded with artwork and re-blitted: 
.PP
.nf
\f(CW        while ( SDL_BlitSurface(image, imgrect, screen, dstrect) == -2 ) {
                while ( SDL_LockSurface(image)) < 0 )
                        Sleep(10);
                -- Write image pixels to image->pixels --
                SDL_UnlockSurface(image);
        }\fR
.fi
.PP
 This happens under DirectX 5\&.0 when the system switches away from your fullscreen application\&. Locking the surface will also fail until you have access to the video memory again\&.
.SH "SEE ALSO"
.PP
\fI\fBSDL_LockSurface\fP\fR, \fI\fBSDL_FillRect\fP\fR, \fI\fBSDL_Surface\fR\fR, \fI\fBSDL_Rect\fR\fR
...\" created by instant / docbook-to-man, Tue 11 Sep 2001, 23:01