[SDL] Blitting algos...

[Matt Bentley]

You're probably best off writing directly to a screen surface in 
hardware mode with double-buffering, if you can get it - either that or 
blit a software surface to a screen surface-
use the MapRGB function to convert to the desired RGB value-
you can set a separate pointer to the initial index of the screen 
surface: e.g:

SDL_Pixel *initial_pixel;
SDL_Surface *screen;
SDL_Color color;
SDL_CreateRGBSurface(screen, etc etc
initial_pixel = screen->pixels;
Then increment the screen pointer to get to the next pixel, within a 
couple of for loops:

for (y = 0; y < y_max; y++)
	for (x = 0; x < x_max; x++)
	{
			*screen->pixels = MapRGB(screen->format, r, g, b);
			screen->pixels++;
	}
}
then you can reset the screen->pixels back to initial_pixel.
And blit the surface to
Probably a few things I've forgotten here - but, oh well.
The x & y are unneeded unless you're plotting some function of x & y;
you could have for(a = 0; a < x_max * y_max; a++) instead-
Other's will come up with some good examples I'm sure-=
the downloadable documentation is worth looking at, but the online stuff 
is, well, old.
Oh, and for individual pixels just use the built-in putpixel function in 
SDL-
Cheers,
M

Simon wrote:
> Hi there,
>    first I'd like to apologize for my lack of understanding of the 
> blitting process with SDL.  Since I've been using SDL for a long time, 
> just to jump into opengl.  I've been using SDL only for window 
> management, user input and networking (using sdl_net).  Now, I got my 
> hands on some data I need to draw on screen, it consists of points of 
> colors, pixels if you like, but they may not be together, rather 
> randomly placed on the whole surface.  The result might remind one of 
> some falling snow, except that the snow of pixels will be coming in 
> waves and at a very high rate.  At this rate, opengl is not making it 
> into the competition, i need faster access and I know sdl can be much 
> better in some 2D circumtances.
> 
>    At every iteration some points will appear and others will disappear, 
> now, I'm wondering what is the best way to implement a refresh screen 
> algorythm.  The problem is that some of these algos will work better 
> than the other depending on the amount of changing pixels.
> 
>    The first algo i will use, which will probably be what I'll base 
> myself on when comparing other algorythms, the first one will be using 
> the putpixel function, one pixel at a time, then probably calling a 
> refresh on the whole screen for simplicity.
> 
>    For my next algo, I was thinking on pasting all that on a surface and 
> making a mask for this surface before blitting the surface on the screen 
> surface.   Now I've never done any of this and I'll probably have a hard 
> time to deal with my data.  Maybe I can have my function spit out the 
> pixels in the surface with the correct format already.  Right now it is 
> a one dimensional array of unsigned char[WIDTH * HEIGHT * 3], and the 
> colors are aligned as {RGBRGBRGB...} one byte per color, 3 bytes per pixel.
> 
>    Best would be to find a way to get this alignment for the pixels of 
> the screen surface, and then I can forget about blitting and simply 
> write the output of my calculation at the right place in the screen's 
> pixels.
> 
> I'll probably need a lot of help, so if you've got any experience of 
> this kind of process, please share what you think.
> 
> Thanks,
>    Simon
> 
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl
> 
>