Request features in SDL 1.3

SDL Development
1

Hello,

I don’t know if it is possible to request new features in the SDL 1.3, i give it a try anyway for 2 new features :stuck_out_tongue:

  1. adding possibility to activate transprancy on keycolor on the main sdl surface (the main window) to be able to make custom sdl main surface windows

  2. adding possibility to make screen desktop capture (ms windows or what ever) using sdl function, options should allow to choose full screen or just x,y,x2,y2 part of the screen, or full screen inluding our main sdl window, or fullscreen excluding our main sdl window

if that can be added in SDL 1.3 so it can be used in an easy manner that would be great.

thanks :smiley:

2

2009/11/2 Xzod

  1. adding possibility to activate transprancy on keycolor on the main sdl
    surface (the main window) to be able to make custom sdl main surface windows

  2. adding possibility to make screen desktop capture (ms windows or what
    ever) using sdl function, options should allow to choose full screen or just
    x,y,x2,y2 part of the screen, or full screen inluding our main sdl window,
    or fullscreen excluding our main sdl window

#1 is a planned feature, but would be implemented with the newer video API,
not surfaces.
#2 is already possible through SDL_RenderReadPixels().

3
> 2) adding possibility to make screen desktop capture (ms windows or what > ever) using sdl function, options should allow to choose full screen or > just x,y,x2,y2 part of the screen, or full screen inluding our main sdl > window, or fullscreen excluding our main sdl window > #2 is already possible through SDL_RenderReadPixels().

…To read pixels external to the SDL window(s)? Really?

Sadly, the only ref I’ve found (w/o too much digging) is a wiki that
points to a broken page:
http://sdl.beuc.net/sdl.wiki/SDL-1.3/SDL_RenderReadPixelsOn Mon, Nov 02, 2009 at 11:40:39AM -0500, Kenneth Bull wrote:

–
-bill!
Sent from my computer

4

2009/11/2 Bill Kendrick :

? ?#2 is already possible through SDL_RenderReadPixels().

…To read pixels external to the SDL window(s)? ?Really?

Ahh, sorry. You can capture from an SDL window, not the root
window/desktop. Then again, SDL_CreateWindowFrom might be able to
help with that (though I kinda doubt it since SetupWindowData tries to
change the WndProc). I’d guess we need read-only windows first.

Sadly, the only ref I’ve found (w/o too much digging) is a wiki that
points to a broken page:
?http://sdl.beuc.net/sdl.wiki/SDL-1.3/SDL_RenderReadPixels

From Doxygen:

int SDL_RenderReadPixels (
const SDL_Rect *rect,
void * pixels,
int pitch
)
Read pixels from the current rendering target.

Parameters:
rect A pointer to the rectangle to read, or NULL for the entire render target.
pixels A pointer to be filled in with the pixel data in the rendering
target format.
pitch The pitch of the pixels parameter.
Returns:
0 on success, or -1 if pixel reading is not supported.
Warning:
This is a very slow operation, and should not be used frequently.

You can use SDL_RenderReadPixels to get the pixel data and
SDL_CreateRGBSurfaceFrom to convert it to a surface, then SDL_SaveBMP
to save it.

5

Kenneth Bull wrote:

#1 is a planned feature, but would be implemented with the newer video API, not surfaces.

so this newer video API will allow to create custom none square main window ? (and will be able to interact with surfaces ?)

Kenneth Bull wrote:

Ahh, sorry. You can capture from an SDL window, not the root
window/desktop. Then again, SDL_CreateWindowFrom might be able to
help with that (though I kinda doubt it since SetupWindowData tries to
change the WndProc). I’d guess we need read-only windows first.

hmmm this SDL_CreateWindowFrom isn’t in the wiki doc, how does it work to capture root desktop ?

6

2009/11/2 Xzod

#1 is a planned feature, but would be implemented with the newer video API, not surfaces.
so this newer video API will allow to create custom none square main window ? (and will be able to interact with surfaces ?)

The renderer API does not work with surfaces directly, but you can
convert surfaces to textures, which do work, and you can get raw pixel
data through SDL_RenderReadPixels, which can be converted to a
surface.

Non-square / transparent / translucent windows are a planned feature,
but I have no idea how Sam plans to implement it. It’s unlikely to
use surfaces though, since surfaces are kinda being phased out or at
least separated from the rest of the video API.

hmmm this SDL_CreateWindowFrom isn’t in the wiki doc, how does it work to capture root desktop ?

It probably doesn’t. SDL_CreateWindowFrom converts a native window to
an SDL window, so that you can embed an SDL window in a larger
application for example. You could call SDL_CreateWindowFrom on the
root window, but because part of the conversion process involves
changing the window procedure, this is probably a bad idea. If there
were an API to create a read only SDL window from an existing native
window (where you could use SDL_RenderReadPixels but could not use
SDL_RenderWritePixels for example or receive events), then you could
probably get away with it.

Here’s the documentation for SDL_CreateWindowFrom:

SDL_WindowID SDL_CreateWindowFrom (
const void * data
)
Create an SDL window struct from an existing native window.

Parameters:
data A pointer to driver-dependent window creation data

Returns:
The id of the window created, or zero if window creation failed.

Warning:
This function is NOT SUPPORTED, use at your own risk!

See also:
SDL_DestroyWindow()

Though it’s not immediately obvious from the documentation, on
Windows, data is the window handle (HWND) for the window you want to
convert.

7

Attached is what a program to capture from the desktop would probably
look like on Windows.

building like this …
$ g++ -o dontdothis.exe dontdothis.cpp sdl-config --cflags --libs
… it compiles fine, but doesn’t link since apparently
SDL_RenderReadPixels is never actually defined, though declared in
SDL_video.h. I’ve submitted a bug report on this (
http://bugzilla.libsdl.org/show_bug.cgi?id=874 ).

SDL_WindowID window = SDL_CreateWindowFrom(GetDesktopWindow());
does actually seem to work, without causing a BSOD, returning a
non-zero window ID. You can also create a renderer without any
errors. Actually drawing on this window does nothing. Getting the
dimensions of this window returns the dimensions of the current
display mode. The Windows XP desktop continues to behave normally,
including redrawing the background image and icons, showing a
selection rectangle if you click and drag across it, and showing a
context menu if you right click.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: dontdothis.cpp
Type: application/octet-stream
Size: 2914 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20091103/1549a377/attachment.obj

8

i’ve implemented transparency myself in sdl 1.3 before for a project only to find that the GDI driver didn’t want to support blending of any kind so had to abandon the idea. Any idea if GDI blending is all good now?

I would also like to see the command for accessing Window pixel data implemented, this would have allowed me to work around the GDI and also mix SDL 2D with custom rendering.