mad_muppet I am trying to draw a mandelbrot set using c .. I can provide a x and y with a count number to provide a color but not sure how to apply that to the sdl screen?
rnx you can use fillrect

Tyrus_Perises mad_muppet: for that your going to want to write directly to video memory and draw pixels individually
Tyrus_Perises fillrect would be really slow in comparison
Tyrus_Perises    Uint32 bufp = (Uint32*)screen->pixels + y*800 + x;
Tyrus_Perises          Uint32 = SDL_MapRGB(SDL_PixelFormat *fmt, Uint8 r, Uint8 g, Uint8 b);
Tyrus_Perises          *bufp = color;
Tyrus_Perises also, fyi, maprgb is a somewhat expensive command, so you might want to replace that with something specific to your video format

rnx a putpixel function wouldnt be any more efficient than fillrect
Tyrus_Perises how could fillrect even remotely compete with a straight write to video?

rnx he just wants to plot a mandelbrot set to the screen ... dont make it more complicate than it needs to be 
Tyrus_Perises well yeah if you dont care about fps then fillrect would be fine

rnx writing straight to surface->pixels only buys you something if you have the data continuously in the same format
rnx which would be blit
Tyrus_Perises yeah, well unless you plan on switching rez's all the time it would be
rnx otherwise you are just doing what fillrect does 
rnx short of conversions or something like readpixel you wont need surface->pixels 

Tyrus_Perises fillrect can do clipping, and will at least need two for's in addition to the pixel write, so it will definately be slower
rnx to a pointless degree 
Tyrus_Perises very little is pointless when multiplied by the number of pixels on the screen
Tyrus_Perises well im going to make a little test app out of curiosity to find out

rnx sdl would be a horrible choice for single pixel drawing speed anyway 
rnx obviously needed for mandelbrot sets ... but certainly not what sdl was designed for

lilltiger opengl could speed it up i guess
rnx not exactly opengl's domain either
lilltiger nope, but drawing will be accelerated.. but then i dont think there is a graph lib that does this good
Tyrus_Perises unless you want to put it on a poly and spin it around :)
lilltiger hehe GL_QUAD and texture it! =D

Tyrus_Perises ok yeah anyway... drawing the full screen of one predetermined color pixel by pixel off the pointer gets me 170fps without a delay(1),  doing the same thing with fillrect gets me 23
Tyrus_Perises so yeah theres a difference
rnx well, i still think it's pointless
Tyrus_Perises 170 fps vs 23 fps isnt pointless,   it might be for him if hes just drawing something to the screen that wont move
rnx your numbers are likely skewed, it wouldnt factor in as much in a real app and the code you pasted before is also not correct afais

Tyrus_Perises how is my code incorrect? other than the fact I didnt complete the one line
Tyrus_Perises and my numbers arnt skewed its a simple test that demonstrates the speed between the two operations
Tyrus_Perises you can see the code if you want ill paste bin it

rnx as for the code snippet ... you should take bytes per pixel and pitch into account
Tyrus_Perises yeah you dont take that into account per pixel, thats slow
Tyrus_Perises make different functions
rnx per pitch ?
Tyrus_Perises no not that youd oviously mult that

Tyrus_Perises in terms of speed I think this test is pretty valid wouldnt you?
rnx it's probably meaningful for that environment, res, depth, ...