Direct access to frame buffer pixels data

Question

I'm trying to develop a 3d graphics engine, i use a framebuffer class which is of my own creation but the fps is too low, and i think it's because i use putpixel() function from winbgim library,

my function to show framebuffer on screen is:

void framebuffer::showonscreen()   //from buffer to screen(space to space 1d to 2d)
{

    int i;
    for(int y=0; y < length; y++)
    {
        for(int x=0; x < width; x++)
        {
            i = x + screeny[y];
            putpixel(x, y, colbuf[i]);
        }
    }
}

Is there any alternative to this putpixel function or a technique to speed it up, or any other manual(without using libraries) way

I heard about giving a direct access to memory blocks, or using the vram

Would any one know how to help me in this problem?

Please, HELP is appreciated.

Answer 1

I do not have experience with the libraries you are using, but I know that with SDL you can easily access the video memory and reserve memory from the gpu for any sort of read/write tasks. Just keep in mind that reading from video memory is very inefficient, and you want to transfer data back and forth as little as possible.

The cpu is really badly designed for rendering graphics, while it's great for calculating tasks. Old games (pre-opengl/directx) used different speed-up techniques. One of the most common was to not update the whole screen once a frame, but update only the changed parts. Using this and sdl you should be able to improve your framerate a bit, but don't keep your hopes up for as fast rendering as rasterizing using the gpu gets you.

Answer 2

You don't get direct access to the framebuffer (or any other hardware resource) from user mode code on any modern OS - it just doesn't run at a high enough privilege level. So like it or not you're going to have to use some form of library to get there, because otherwise the option is to start writing your own device driver.

This needn't be too intrusive. For example, you could use OpenGL, create a context, disable all states and texturing, then your framebuffer::showonscreen method just needs to make a single glDrawPixels call.

Answer 3

An option you may choose to use is creating a buffer of the screen size and directly put the whole buffer to the context rather than doing it per pixel(As it is cheaper for it to be one call than 1,000's due to the amount of pixels you have).

I'm not familiar with the winbgim library, but I'm sure it has some optimized function to render a whole image, or something along those lines, to the screen. In this case you will do all the changes of the data to the buffer you created and then pass the buffer to this image function which will handle the displaying to the screen.

You'll have to look into how the buffer information is managed by the library.

If it doesn't have an option to pass in an array, or pointer, to a buffer you created then I suggest you probably look into using OpenGL rather than that library. I've done this same thing in OpenGL where I modify the buffer I make myself before passing it to the GPU to be rendered through the glDrawPixels() function available through GLEW.

But as Lasse has said you aren't going to get that much performance out of the CPU compared to a GPU implementation. Even my CPU based implementation with all of the stuff it needed to do was hitting the low end of 20 FPS.