Why anything after "while (window.pollEvent(Event))" kills framerate ?

[LakySimi1]

Hi everyone,
as for the title, anything, even empty brackets, kills framerate, from 1450ish to 250ish.. why this happen?

Moreover, maybe a dedicated topic could be better but, do you think that, for a pixel-per-pixel rendering, the code below is the right approach for a video game? Like a raycaster, or 2D rpg, or 2D platform..
I've already done a quite pretty raycaster time ago, with sprites and sliding doors, with the very approach in the code below, but i've stopped coding it because i was not sure if the approach was right.

Thank you very much!

PS There is a better way to put code in post, with the proper colorig of keywords etc.?

Code:

(click to show/hide)

#include <SFML/Graphics.hpp>

int main()
{
    //INITIALIZE WINDOW
    int W = 1280;   //Screen width
    int H = 720;    //Screen height
    sf::RenderWindow window(sf::VideoMode(W, H), "SFML Project");
   

    //INITIALIZE PIXELS ARRAY
    sf::Texture texture;
    texture.create(W, H);
    sf::Sprite sprite(texture);
   
    sf::Uint8* pixels = new sf::Uint8[W * H * 4];   //Array for the pixels (A,R,G,B)
    for (int ir = 0; ir < W * H * 4; ir++) pixels[ir] = 255;    //In particular to set Alpha channel to 1.
    int color_Red = 0;
    int color_Green = 0;
    int color_Blue = 0;

    ///MAIN LOOP
    sf::Event Event;
    while (window.isOpen())
    {
        //HARDWARE INPUTS
        while (window.pollEvent(Event))
        [glow=red,2,300]{[/glow]
             //if (Event.type == sf::Event::Closed)
             //   window.close();
        [glow=red,2,300]}[/glow]        

       
        //GAME LOGIC
        //The game logic also provide the color for the pixels, for this example all the screen will be..
        color_Red = 150;    
        color_Green = 120;
        color_Blue = 175;


        //FILL PIXELS ARRAY
        for (int ic = 0; ic < W; ic++)
            for (int ir = 0; ir < H; ir++)
            {
                  pixels[4*(ic + ir * W)] = color_Red;      //RED
                  pixels[4*(ic + ir * W) + 1] = color_Green;  //GREEN
                  pixels[4*(ic + ir * W) + 2] = color_Blue;  //BLUE
            }


        //DISPLAY
        texture.update(pixels);
        window.draw(sprite);
        window.display();
    }
}

[/size]

[kojack]

For code posting, on the post toolbar over on the right is a combo box that says Code. Click that and it gives you a list of languages to format code as.

Hmm, pollEvent is a non-blocking function, so if there's no events waiting, it should be near instant. The only way I'd imagine an empty event loop would tank performance would be if there were a LOT of events (like tens of thousands?) being generated for some reason.
I'd be surprised though if you were getting 1450fps while doing per pixel background filling every frame.

For a raycaster, per pixel is probably the way to go. But 2D rpgs and platformers are going to be a lot more efficient using sprites and such (since they are GPU rendered, rather than software).

[eXpl0it3r]

How are you measuring FPS?

[LakySimi1]

How are you measuring FPS?

I am using MSI Afterburner

[eXpl0it3r]

Can you count the amount of events produced per frame?

One thing we've seen in the past is that broken gamepad drivers can cause havoc on the event loop.
Make sure you don't have some weird gamepad plugged in or devices that somehow get registered as gamepads or virtual drivers that are hacked together.

There has also been issues with certain Corsair keyboard drivers causing massive lags. Check that your drivers are up to date.

And finally, don't forget that FPS isn't linear, so you might see faster drops for small changes processing times.

[Hapax]

Is it possible that you tested the rate of slightly different code? For example, without the "game logic" section.

The reason I ask is that if you don't have those braces (curly brackets) after the poll event loop, the very next line of code would be only executed whenever there is an event and, if the "game logic section" is not there, the next line would be the heavy-duty pixel-manipulating for loop.
This would mean that those pixel updates only got updated whenever there was an event but not when there weren't any so it would run faster without that for loop.

Adding the braces/brackets after the poll event would then make the pixel-updating for loop run on every single main loop and could be the cause of such a significant delay.

[LakySimi1]

Is it possible that you tested the rate of slightly different code? For example, without the "game logic" section.

The reason I ask is that if you don't have those braces (curly brackets) after the poll event loop, the very next line of code would be only executed whenever there is an event and, if the "game logic section" is not there, the next line would be the heavy-duty pixel-manipulating for loop.
This would mean that those pixel updates only got updated whenever there was an event but not when there weren't any so it would run faster without that for loop.

Adding the braces/brackets after the poll event would then make the pixel-updating for loop run on every single main loop and could be the cause of such a significant delay.

It is as you say! ..mine was such a silly question, i was surely distracted!.. thank you very much!

Well, that means that, fill an HDready resolution screen is reaaaally slow 250ish fps for substantially nothing! This was the main thing that made me doubt that my method was wrong..

Maybe a dedicated thread could be better as i said but.. do you think that my approach of fill a pixels array one by one pixel is right for a raycaster engine (such as The Elder Scrolls: Arena) ?

Code fully working (SFML 2.5.1):

(click to show/hide)

#include <SFML/Graphics.hpp>


int main()
{
    //INITIALIZE WINDOW
    int W = 1280;   //Screen width
    int H = 720;    //Screen height
    sf::RenderWindow window(sf::VideoMode(W, H), "SFML Project");
   

    //INITIALIZE PIXELS ARRAY
    sf::Texture texture;
    texture.create(W, H);
    sf::Sprite sprite(texture);
   
    sf::Uint8* pixels = new sf::Uint8[W * H * 4];   //Array for the pixels (A,R,G,B)
    for (int ir = 0; ir < W * H * 4; ir++) pixels[ir] = 255;    //In particular to set Alpha channel to 1.
    int color_Red = 0;
    int color_Green = 0;
    int color_Blue = 0;

   

    ///MAIN LOOP
    sf::Event Event;
    while (window.isOpen())
    {
        //HARDWARE INPUTS
        while (window.pollEvent(Event))
        {
            if (Event.type == sf::Event::Closed)
                window.close();
        }
       
       

        //GAME LOGIC
        //The game logic aso provide the color for the pixels, for this example all the screen will be..
        color_Red = 150;
        color_Green = 120;
        color_Blue = 175;

        //FILL PIXELS ARRAY: for simplicity one color for the whole screen..
        for (int ic = 0; ic < W; ic++)
            for (int ir = 0; ir < H; ir++)
            {
                pixels[4*(ic + ir * W)] = color_Red;      //RED
                pixels[4*(ic + ir * W) + 1] = color_Green;  //GREEN
                pixels[4*(ic + ir * W) + 2] = color_Blue;  //BLUE
            }


        //DISPLAY
        texture.update(pixels);
        window.draw(sprite);
        window.display();

        color_Red = 0;
        color_Green = 0;
        color_Blue = 0;
    }
}

[kojack]

A quick calculation shows 1280 x 720 x 250fps means each pixel has only 4ns to be rendered.
Considering a single cpu cycle on a 4GHz cpu is 0.25ns, there's not much head room.

[LakySimi1]

A quick calculation shows 1280 x 720 x 250fps means each pixel has only 4ns to be rendered.
Considering a single cpu cycle on a 4GHz cpu is 0.25ns, there's not much head room.

This calculation really makes sense to me, 17.4 cycles per pixel, this perspective help to understand.

Therefore, is a bad news, since i really like to draw pixel-per-pixel, maybe it is even foundamental for a raycasting engine.. any suggestion to achieve the single-pixel draw flexibility?

[kojack]

I like pixel rendering too, but mine tend to be slower (like raytracing) where even 1fps would be great.

A few possibilities:
- multithreading. My understanding is raycasters are usually pretty independent between columns, so dividing the screen into vertical stripes based on core count could help without too much complexity.
- compute shaders. SFML doesn't have them natively, but they let you write algorithms slightly closer to typical CPU style but with GPU backed performance (they don't have the same restrictions as regular shaders).

[LakySimi1]

I also want to make some raytracing experiment but, since the infinitely less complex raycasting is so slow on a 4GHz machine, and it may really means that the pixel-per-pixel approach is wrong, i give it up.. sadly.
I'll share a screenshot of my raycasting engine here:

(click to show/hide)

Multithreading may be an aid, but not a solution i think, since og Doom run flawlessy on a 100MHz 486.. how the heck does it achieve that? Surely it is also GPU based but still, i think it has a lot to do with single pixel drawing.. right?
I kinda know that i have to use the parallel computing o f the GPU.. but how? The only tutorial i find online seems to have the same approach of mine: fill and array and send it to graphic memory.

Compute shaders are totally new to me.. got to search!

[LakySimi1]

I made a gross mistake.. Hapax was right