code Q - SDL pset function not working
category: general [glöplog]
Fixed!!! It WAS because I was drawing outside of my bitmap! Here is the fixed pset function.
Code:
void pset(SDL_Surface * img, int x, int y, Uint8 R, Uint8 G, Uint8 B){
Uint32 color = SDL_MapRGB(img->format, R, G, B);
if(x <= defXres && y <= defYres && x >= 0 && y >= 0){
switch(img->format->BytesPerPixel)
{
case 1: //8bpp
{
Uint8 *bufp;
bufp = (Uint8 *)img->pixels + y*img->pitch + x;
*bufp = color;
}
break;
case 2: //16bpp
{
Uint16 *bufp;
bufp = ( Uint16 *)img->pixels + y*img->pitch/2+x;
*bufp = color;
}
break;
case 3: //24bpp (slow)
{
Uint8 *bufp;
bufp = (Uint8 * )img->pixels + y*img->pitch + x * 3;
if(SDL_BYTEORDER == SDL_LIL_ENDIAN)
{
bufp[0] = color;
bufp[1] = color >> 8;
bufp[2] = color >> 16;
} else {
bufp[2] = color;
bufp[1] = color >> 8;
bufp[0] = color >> 16;
}
}
break;
case 4: //32bpp
{
Uint32 *bufp;
bufp = (Uint32 *)img->pixels + y*img->pitch/4 + x;
*bufp = color;
}
break;
}
}
}
...you have a switch/case inside your setpixel function...? O_O
Not anymore, it was just there to see if the problem was a bpp problem. ;)
So now you're getting colors as wanted?
Code:
case 3: //24bpp (slow)
lol. that's definitely the bottleneck in your code :)
Considering the block of cases, yes 24bpp would be a major bottleneck! =D
j/k ofc
Colors aren't working right, but at least its not crashing anymore. Looking into the color problems in a bit.
j/k ofc
Colors aren't working right, but at least its not crashing anymore. Looking into the color problems in a bit.
Fixed the color problem. Just before I begin manipulating individual pixels, I do this...
gbmp is the surface I am drawing to. Now it works perfect!
Code:
gbmp = SDL_CreateRGBSurface(0, 1024, 768, 32, 0, 0, 0, 0);
gbmp is the surface I am drawing to. Now it works perfect!
To elaborate on Gargaj's point a bit: You've got a SETPIXEL FUNCTION?
YO DAWG I HEARD U LIKE SETPIXEL FUNCTION SO I PUT A SETPIXEL FUNCTION CALL INSIDE UR SETPIXEL FUNCTION CALL SO U CAN OVERFLOW UR STACK WHILE U PLOT!
What is wrong with a set pixel function? What could I be doing better?
Calling functions in an inner loop that renders lot's of pixel every frame is never a good idea :)
![[self-ban]](https://content.pouet.net/avatars/zulthoofd.gif)
*lots
*pixels
I blame the beer.
I blame the beer.
b0b0t:
In essence you do the following:
This warrants the overhead of a function call, accessing the img object properties and worst of all calling ANOTHER function (SDL_MapRGB) HOW exactly?
(I'll save getting rid of the multiplication for Part Two of this very informative tutorial)
In essence you do the following:
Code:
Uint32 *ptr = (Uint32*) img->pixels;
const int pitch=img->pitch;
[inner loop begins...]
ptr[y*pitch+x]=color;
[inner loop ends]
This warrants the overhead of a function call, accessing the img object properties and worst of all calling ANOTHER function (SDL_MapRGB) HOW exactly?
(I'll save getting rid of the multiplication for Part Two of this very informative tutorial)
(Part Three will be about why in 99.99% of cases you'll never have to set single pixels anyway, low-res dot effects notwithstanding)
he's using SDL, he's fucked already anyway :)
part 4 shall be about typing 'pixeltoaster' in the google searchbar!
kb_: full ack.
Gargaj: ah, c'mon! SDL ain't so bad. Works quite well for Linux/Windows platform stuff in my experience. Nice API, many supported platforms and not much bloat because they keep the optional stuff in separate libraries.
(well..most of it..I personally don't use the 2D surface stuff very much..SDL also plays well with OpenGL)
Gargaj: ah, c'mon! SDL ain't so bad. Works quite well for Linux/Windows platform stuff in my experience. Nice API, many supported platforms and not much bloat because they keep the optional stuff in separate libraries.
(well..most of it..I personally don't use the 2D surface stuff very much..SDL also plays well with OpenGL)
If SDL sucks, please, what is your recommendation?
you failed part 4 of the tutorial, dear sir!
So instead of calling SDL_MapRGB() 300.000+ in one loop one could just
assuming one just want a hex triplet and not some nearest matching indexed color lookup??
Code:
color = r << 16;
color = color | (g << 8);
color = color | b;
assuming one just want a hex triplet and not some nearest matching indexed color lookup??
El Topo: SDL_MapRGB is yet another "supposedly simple but yet contains a switch to pick a fucking value" kind of function from the lovely SDL. Seriously, use PixelToaster.
But SDL is ported to everyone and his aunt and it seems pretty much standard on Linux which PixelToaster isn't atm. It sounds nice though.
I've looked at PixelToaster, it's cool, but... why not use OpenGL or straight DirectX? I know that in OpenGL, it's also possible to set individual pixels, and as the Windows version of PixelToaster is based on DirectX, it is obviously possible there, too. OpenGL or DirectX will make your life very easy if you want to do 3D graphics.