| View previous topic - View next topic |
| Author |
Message |
Nodtveidt
Demon Hunter
Joined: 11 Nov 2002
Posts: 786
Location: Camuy, PR
|
 Posted: Sat Sep 05, 2009 11:29 pm Post subject: Limitations of SDL? |
[quote] |
|
Hey, I'm wondering if anyone has any solid information on the limitations of SDL's video bitdepth. I read somewhere in passing that any modes not 8bpp or 32bpp were converted to those bitdepths. In one of my projects, I have allowed for 4bpp...will this work? Will it convert to 8bpp internally as the text suggested? And if so, how about 2bpp and 1bpp modes? Anyone know? Thanks.
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace
|
|
| Back to top |
|
 |
Rainer Deyke
Demon Hunter
Joined: 05 Jun 2002
Posts: 672
|
| Posted: Sun Sep 06, 2009 12:55 am Post subject: |
[quote] |
|
SDL fully supports 8bpp, 16bpp, 24bpp, and 32bpp. 8bpp uses a palette, the others are RGB or RGBA depending on the color masks used. All SDL surfaces must use one of those bit depths. 4bpp can be emulated through 8bpp by only using the lower 4 bits, but SDL never allows you to pack more than one pixel per byte.
SDL may or may not support loading image files of other bit depths by converting to a supported bit depth. I don't know if SDL_LoadBMP or any other the SDL_Image file loaders perform such a conversion.
SDL may or may not work on platforms with other native bit depths (e.g. a 4bpp screen). If supported, SDL would have to convert to the native bit depth when blitting the video surface to the screen.
|
|
| Back to top |
|
|
DeveloperX
202192397
Joined: 04 May 2003
Posts: 1626
Location: Decatur, IL, USA
|
| Posted: Sun Sep 06, 2009 2:46 pm Post subject: |
[quote] |
|
It wouldn't be difficult to just look at the source to SDL's image loading, conversion and rendering functions.
As far as I know though, it will not allow you to use oddball bit depths.
Why in the world do you need 4bpp though? And couldn't you just emulate it by writing a software abstraction layer between SDL and your needs?
_________________
Principal Software Architect
Rambling Indie Games, LLC
See my professional portfolio
|
|
| Back to top |
|
|
Nodtveidt
Demon Hunter
Joined: 11 Nov 2002
Posts: 786
Location: Camuy, PR
|
| Posted: Sun Sep 06, 2009 6:42 pm Post subject: |
[quote] |
|
The reason I ask is because I'm currently at work on a BASIC compiler that uses SDL for its default graphics library. So I was thinking about emulating some of the older BIOS modes. The SDL source code is a little too heavy to just go poring through; time is often very limited. I might just cut out 4 and 15 bit modes altogether anyways, limiting it to the modes that SDL handles natively...no sense in creating more work for myself.
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace
|
|
| Back to top |
|
|
Mattias Gustavsson
Mage
Joined: 10 Nov 2007
Posts: 457
Location: Royal Leamington Spa, UK
|
|
| Back to top |
|
|
Rainer Deyke
Demon Hunter
Joined: 05 Jun 2002
Posts: 672
|
| Posted: Mon Sep 07, 2009 2:01 am Post subject: |
[quote] |
|
|
Every 15 bit mode I've ever seen uses 2 bytes (16 bits) per pixel, with one of the bits unused. SDL does support 16bpp modes with unused bits, although there's no way to specify unused bits when setting the video mode.
|
|
| Back to top |
|
|
Nodtveidt
Demon Hunter
Joined: 11 Nov 2002
Posts: 786
Location: Camuy, PR
|
| Posted: Mon Sep 07, 2009 11:39 am Post subject: |
[quote] |
|
Normal 15 bit modes are simply 5-5-5, with 1 unused bit. Emulating that is not terribly hard; doubling up on the green element in a 16 bit mode is adequate.
Mattias: it's a BASIC compiler designed for FreeBSD. Here's the website, though it's outdated and very 1997:
http://www.bsdbasic.com/
OK I just updated the website's information, but it's still a 1997 design. :) Most open source/freeware app developers don't generally have impressive websites so I figured it was just fine as it is for now. :D Besides, if I made it too fancy, people would get the misconception that it was a commercial compiler...
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace
|
|
| Back to top |
|
|
Nodtveidt
Demon Hunter
Joined: 11 Nov 2002
Posts: 786
Location: Camuy, PR
|
| Posted: Sun Sep 13, 2009 1:55 pm Post subject: |
[quote] |
|
OK here's another issue...SDL_GetRGB and its ilk are horribly documented, and the example "getpixel()" function that has been listed thousands of times on sdldoc.csn.ul.ie no longer exists. How the fsck do you get the value of a pixel on a surface? Such a basic function is so terribly underdocumented and it seems everyone has trouble with this.
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace
|
|
| Back to top |
|
|
Mattias Gustavsson
Mage
Joined: 10 Nov 2007
Posts: 457
Location: Royal Leamington Spa, UK
|
| Posted: Sun Sep 13, 2009 6:29 pm Post subject: |
[quote] |
|
That's why I prefer using my own stuff (Pixie), where every surface is just a normal memory buffer, and I have direct access to everything and knows how it all works :D
_________________
www.mattiasgustavsson.com - My blog
www.rivtind.com - My Fantasy world and isometric RPG engine
www.pixieuniversity.com - Software 2D Game Engine
|
|
| Back to top |
|
|
DeveloperX
202192397
Joined: 04 May 2003
Posts: 1626
Location: Decatur, IL, USA
|
| Posted: Sun Sep 13, 2009 6:58 pm Post subject: |
[quote] |
|
| Nodtveidt wrote: | | OK here's another issue...SDL_GetRGB and its ilk are horribly documented, and the example "getpixel()" function that has been listed thousands of times on sdldoc.csn.ul.ie no longer exists. How the fsck do you get the value of a pixel on a surface? Such a basic function is so terribly underdocumented and it seems everyone has trouble with this. |
Hmm..it looks rather simple to me...
| Code: |
/*
* Return the pixel value at (x, y)
* NOTE: The surface must be locked before calling this!
*/
Uint32 getpixel(SDL_Surface *surface, int x, int y)
{
int bpp = surface->format->BytesPerPixel;
/* Here p is the address to the pixel we want to retrieve */
Uint8 *p = (Uint8 *)surface->pixels + y * surface->pitch + x * bpp;
switch(bpp) {
case 1:
return *p;
case 2:
return *(Uint16 *)p;
case 3:
if(SDL_BYTEORDER == SDL_BIG_ENDIAN)
return p[0] << 16 | p[1] << 8 | p[2];
else
return p[0] | p[1] << 8 | p[2] << 16;
case 4:
return *(Uint32 *)p;
default:
return 0; /* shouldn't happen, but avoids warnings */
}
}
|
_________________
Principal Software Architect
Rambling Indie Games, LLC
See my professional portfolio
|
|
| Back to top |
|
|
Rainer Deyke
Demon Hunter
Joined: 05 Jun 2002
Posts: 672
|
| Posted: Mon Sep 14, 2009 12:34 am Post subject: |
[quote] |
|
Normally, you wouldn't set individual pixels. Instead, use SDL_CreateRGBSurface to create a surface in your own preferred pixel format, write the pixel data directly to the surface, then call SDL_DisplayFormat (or SDL_DisplayFormatAlpha) to convert it to the screen format. You can even put the image data into your own memory buffer and use SDL_CreateRGBSurfaceFrom.
Writing individual pixels is terribly slow, especially if you want to support multiple pixel formats.
Edit: the same applies to reading pixels (although generally you should avoid should avoid reading video data). SDL_ConvertSurface (or SDL_CreateRGBSurface followed by SDL_BlitSurface) to get the pixel data into a format you can handle, then direct access. If you're trying to process the entire surface, this will be much faster than trying to read every pixel through a getpixel function.
|
|
| Back to top |
|
|
DeveloperX
202192397
Joined: 04 May 2003
Posts: 1626
Location: Decatur, IL, USA
|
|
| Back to top |
|
|
Mattias Gustavsson
Mage
Joined: 10 Nov 2007
Posts: 457
Location: Royal Leamington Spa, UK
|
| Posted: Mon Sep 14, 2009 8:05 am Post subject: |
[quote] |
|
| Rainer Deyke wrote: | Writing individual pixels is terribly slow, especially if you want to support multiple pixel formats.
Edit: the same applies to reading pixels (although generally you should avoid should avoid reading video data). |
True. And it's true for a lot of other 2D libs as well, especially ones which use 3D hardware for drawing.
Thing is though, sometimes it's much easier when you have fast access to all surfaces, and can do any kind of per-pixel processing with no extra overheads to it. I've found that it just makes it easier to do some things, but most 2D libs makes it either slow or awkward...
The way I got around it when I made Pixie, is by having all blitting done if software, and all surfaces as plain memory buffers in system memory. When all drawing for a frame is done, the whole thing is sent of at once to the hardware. With the speed of modern computers, software blitting is certainly a viable alternative, and things get much more straightforward.
For an example, look at my Jade Figurines game - it's got multiple layers of large sprites all with alpha channels, and it's all done in software. When I made Pixie, I opted for 16 bit color, which I personally think is fine for most uses, but even with 24 bit color you would get good performance with software blitting. (On a side note: all objects/sprites in jade figurines are stored in 8 bit (256 color) RLE format w. alpha, and decompressed on the fly when blitting - but that's mainly for saving memory. More about the RLE blitter here, for those interested.).
Maybe it is possible to do the same thing in SDL? Just use memory buffers and software blitting, and then once per frame transfer the backbuffer to an SDL buffer for blitting? I don't know how fast that would be in SDL though... my solution (for the DX9 implementation) is to have a dynamic texture which I lock and copy the backbuffer to, and then I use it for blitting onto the screen (the next frame, to avoid stalls. so I actually have two dynamic textures I alternate between).
_________________
www.mattiasgustavsson.com - My blog
www.rivtind.com - My Fantasy world and isometric RPG engine
www.pixieuniversity.com - Software 2D Game Engine
|
|
| Back to top |
|
|
