How low-level can SFML be?

[TriKri]

Hi, I've been using SDL for a while now, and I really like that it's low level so you can get direct access to the pixel data of a buffer, if you would like to write you own functions for manipulating the buffers. I'm considering changing from SDL to SFML, but can I get direct access to the pixel data in SFML? How low-level can SFML be? I read in another thread where one wrote that all the low level stuff was hidden from him, and that he didn't feel powerful using something that hid things from him, so he stuck with SDL. Is this how I would feel too if I switched to SFML, or is this simply not true?

[Kingdom of Fish]

The thing is that SFML is based on OpenGL, so you can't get much more lowlevel then what OpenGL allows.

[TriKri]

Okay, then is there any way to reach the data of the buffers that OpenGL uses? I mean, there must be some way to software manipulate a buffer (reading/writing from/to the memory allocated for pixel data), isn't there?

[Kingdom of Fish]

Okay, then is there any way to reach the data of the buffers that OpenGL uses? I mean, there must be some way to software manipulate a buffer (reading/writing from/to the memory allocated for pixel data), isn't there?

There is the possibility to copy all the pixels of the buffer to an image and manipulate those and then redraw. But that would be horribly slow I think.

[TriKri]

Where are the buffers located? Are they located somewhere else than on the primary memory, like directly on the graphics card?

The way you suggested I could do it in, you said it would probably be very slow; as slow as it would be in SDL, or maybe even slower? Would the code be messy? What I'd like to use a graphics library for is mainly to get a way to render pixel data to the screen; I mustn't loose access to the pixel data doing that since that is what I'm working with.

Doesn't SFML have any support for that? If it doesn't yet, I really think it should be implemented (which I trust it will be), and I will simply wait until it has been, and in the meantime use SDL. I really like though, the fact that SFML is in C++, and that it is much nicer to work with than SDL (or so I've heard), and that it's faster when you don't have as high requirements as I do

[Laurent]

You can reach the pixel data, but it's stored in video memory and optimized by the driver, so you can't do whatever you want with it, like you do with SDL.

A good strategy is to keep your own copy of the pixel buffer (in system memory), manipulate it with the CPU, and send it back to video memory when you're done (using sf::Image::LoadFromPixels). But of course it depends on what you want to do exactly.

SFML 2 will probably have more functions for manipulating pixel data. It already has sf::Image::UpdatePixels, which has less overhead than sf::Image::LoadFromPixels.

[TriKri]

A good strategy is to keep your own copy of the pixel buffer (in system memory), manipulate it with the CPU, and send it back to video memory when you're done (using sf::Image::LoadFromPixels).

Okay, I could try that!

SFML 2 will probably have more functions for manipulating pixel data.

I'm looking forward to it!

[Recruit0]

And actually, IIRC, messing with video memory is (usually) slow, unless your using the GPU. It's supposed to be faster to manipulate the images, yourself, in RAM then push it back out to the video buffer (unless your DBing). This makes sense (to me anyway) because normally manipulating video memory falls under the GPU, but not all computers come with GPUs. So for low sys req it's better to copy into RAM first then blit result to the video buffer rather than flooding the sys BUS with pixel commands (i.e. faster to dump data to the video buffer than doing pixel by pixel at a time).

I'm no expert in graphics (rendering) but I am familiar with a lot of it (i.e. I may be wrong).

[bullno1]

If you are trying to do effects like HDR or motion blur and image data does not need to be persisted on hard-drive, I suggest using shader and Render-To-Texture. All manipulations will be done on the GPU so it is faster because you don't have to do the RAM <-> VRAM transfer.

You have to learn GLSL though. It is pretty similar to C and you can really manipulate individual pixels.