How to play video from image-sequences (fast) onto the screen?

[tom64]

Just one more thing, is it possible to create a blank canvas in memory where I can manipulate the pixel data, and then draw that canvas (without having to write/load from HDD)?

Could you recommend an efficient way to do this (efficient enough to cover an entire screen with pixels)?

Sincerely,
Tom

[Ceylo]

You should have a look a sf::Image and sf::Texture documentation, and especially sf::Image::setPixel().

[Laurent]

Could you recommend an efficient way to do this

sf::Image::setPixel()

Allocate your pixel array in memory (an sf::Uint8 array of size width * height * 4), do whatever you want with it, and then upload it to video RAM with the sf::Texture::update function. Then draw this texture with a sprite, as usual.

[Ceylo]

I'm wondering what's worse between...
- loading an image with sf::Image, copying its data to a raw array, modifying the raw array and then uploading the data to a sf::Texture
and
- loading an image with sf::Image, using setPixel() and then loading the texture from the image

?

I agree setPixel is slower than raw array modification but it may depend on how much there is to modify. I guess the data copying isn't negligible, is it?

[Laurent]

Of course, it depends what he wants to do. I just answered to the question, since he didn't give more details.

[tom64]

(an sf::Uint8 array of size width * height * 4)

Is '* 4' due to RGBA? Would it be faster/possible to do just '*3' and not have an alpha channel (since there's nothing behind the frame)?

I'm wondering what's worse between...
- loading an image with sf::Image, copying its data to a raw array, modifying the raw array and then uploading the data to a sf::Texture
and
- loading an image with sf::Image, using setPixel() and then loading the texture from the image

Sorry Ceylo I may have confused you as I modified my previous post before you replied.
I'm either going to be loading images from file or I'm going to be drawing images to memory. I don't think I will need to setPixel on images that were loaded from file.

[eXpl0it3r]

Is '* 4' due to RGBA? Would it be faster/possible to do just '*3' and not have an alpha channel (since there's nothing behind the frame)?

Yes it's because of RGBA and no you can't just use 3 uint8 with SFML.

[tom64]

Yes it's because of RGBA and no you can't just use 3 uint8 with SFML.

I suppose thats okay since I won't be setting any alpha pixels (later) I won't need to send the entire thing, but only the changes I make to RGB - right?

By the way, when I make changes to the pixel array, am I making changes to the array in video memory directly, or do I just make changes to the array in RAM and then upload the entire thing to video memory before doing an update?

[eXpl0it3r]

I suppose thats okay since I won't be setting any alpha pixels (later) I won't need to send the entire thing, but only the changes I make to RGB - right?

What? No you'll always have to provide either the full 4*uint8 pixel array or just a 4*uint8 part. You can't pass in just a RGB array. SFML will otherwise mixup everything. (e.g. your input RBG(20, 30, 50) RBG(10, 100, 5) => what SFML would see RGBA(20, 30, 50, 10) RGBA(100, 5, MISSING=possible crash)).

By the way, where is that memory location (for the pixel array)? Is that in RAM or Video Memory?

The pixel array is managed by yourself, so you should know where to find it and it's thus in the CPU RAM. The texture itself is stored in GPU RAM, but you can't access it directly.

By the way, when I make changes to the pixel array, am I making changes to the array in video memory directly, or do I just make changes to the array in RAM and then upload the entire thing to video memory before doing an update?

You make changes in the CPU RAM, then upload (tex.update()) it to the GPU RAM. That's why it's a heavy operation. But it's also not possible to get access to the texture on the GPU, unless you use shaders.

[tom64]

You make changes in the CPU RAM, then upload (tex.update()) it to the GPU RAM. That's why it's a heavy operation. But it's also not possible to get access to the texture on the GPU, unless you use shaders.

Wouldn't it be more efficient though to unlock access to the video memory and just write whatever pixels changed then return access back to the GFX card, than writing it to CPU memory, and then transferring everything (including pixels that didn't change and alpha pixels) to the GFX?

[Laurent]

Wouldn't it be more efficient though to unlock access to the video memory and just write whatever pixels changed then return access back to the GFX card, than writing it to CPU memory, and then transferring everything (including pixels that didn't change and alpha pixels) to the GFX?

No. First, it's not possible to get a direct access to a texture's pixels in video RAM. Second, it would probably be more expensive, since the graphics card would be frozen until you finish to do whatever you need with the pixels. If you work on a pixel buffer located in system RAM, the transfer can be asynchronous, and the GPU & CPU can manage to work in parallel as much as possible, and to deliver the best execution flow.

The only thing that could be better than what SFML currently does, is to use Pixel Buffer Objects (PBO). But it's not supported by SFML, you'd have to use OpenGL directly.

You should read documents about pixel transfers, it's not a trivial task and you'll need to know exactly what happens if you really want maximum performances with your application.