Messages

1

General / Re: Why anything after "while (window.pollEvent(Event))" kills framerate ?

« on: April 17, 2024, 07:40:36 pm »

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!

2

General / Re: Why anything after "while (window.pollEvent(Event))" kills framerate ?

« on: April 16, 2024, 07:25:16 pm »

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?

3

General / Re: Why anything after "while (window.pollEvent(Event))" kills framerate ?

« on: April 09, 2024, 07:57:40 pm »

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;
    }
}

4

General / Re: Why anything after "while (window.pollEvent(Event))" kills framerate ?

« on: April 08, 2024, 10:14:16 am »

How are you measuring FPS?

I am using MSI Afterburner

5

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

« on: April 07, 2024, 11:07:28 pm »

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]

6

Graphics / Re: texture.update(pixels): is it normal to be so slow? [Full working code inside]

« on: June 27, 2023, 10:57:49 pm »

540fps is neither slow in an absolute nor relative sense, that's 1.85ms per frame!
There's no display that can even show you that many frames per second.

Don't forget that FPS is non-linear. So the framerate will drop a faster rate than the frametime.

Using texture.update is the fastest way SFML can update pixel data. I don't know if OpenGL offers any other methods, but again, at 540fps you're not having any performance issue and shouldn't try to find faster ways.
The results you get aren't even representative and can be influenced by any kind of background work.

If you want fast pixel manipulation, then that's what fragment shaders were created for. Your math and manipulation is directly executed on the GPU in a vectorized manner.

I may agree with you, is a lot more fps than needed for pretty much everything, but comparing to  sf::RectangleShape, which, perform a lot better makes me doubt about the "general correctness" of the method presented in the code provided for what i want to achieve (pixel per pixel "hand painting", for something like a raycaster wolfenstein-like engine for example, so 60 complete windows update per second).. but, if you assure me that the code method is foundamentally right i will use it.
Unfortunately i don't know about fragment shader (or any shader)..

Thank you both for your reply!

7

Graphics / texture.update(pixels): is it normal to be so slow? [Full working code inside]

« on: June 26, 2023, 10:34:17 pm »

Hi everyone,
the code provided goes at 540fps on 960x540 with an i5-10400; is not slow in an absolute way but considering what i am doing.. it is, and, most triggering to me is that therefore it is too unoptimized.
Drawing a genering monochrome rectangle with same dimensions goes up to 2500ish fps.

I compromise on go slower because i'm using CPU rather than GPU but it seems a bit too bad to me.

I want to draw the game screen pixel per pixel, i find it funny to come up with al graphic tweaks and have the power to intervent arbitrarily on any pixel i want: there is a way to do what i do in my code but more correctly/optimixed? There are other ways to do what i want to do?

Thak you very much in advance!

#include <SFML/Graphics.hpp>

using namespace std;

const int H = 1080/2; //Window height
const int W = 1920/2; //Window width

sf::Uint8* pixels = new sf::Uint8[W * 800 * 4]; //Array for the pixels (R,G,B,Alpha)


//Fill pixel array with values (all 100 for simplicity's sake)
void CreateImage(int nCol, int row_0, int row_1)
{
    for (int ir = row_0; ir < row_1; ir++)
    {
        for (int ic = 0; ic < W; ic++)
        {
            pixels[(ir * W + ic) * 4] = 100;        //red
            pixels[(ir * W + ic) * 4 + 1] = 100;    //green
            pixels[(ir * W + ic) * 4 + 2] = 100;    //blue
        }
    }
}



int main()
{
    sf::RenderWindow window(sf::VideoMode(W, H), "SFML works!"); //Create window
    window.setFramerateLimit(0); //No limit to framerate

    //Stuff used to generate final screen image (found online)
    sf::Texture texture;    texture.create(W, H);   sf::Sprite sprite(texture);
   

    for (int ir = 0; ir < W * H * 4; ir++) //Set Alpha=255
        pixels[ir] = 255;

    for (int ix = 0; ix < W; ix++) //Generate any image
        CreateImage(ix, 0, 720);




    while (window.isOpen())
    {
        //Again, stuff used to draw image on screen (found online)
        //Why this part is so slow??
        //Is possible to speed up things mantaining the "pixel array"?
        //(i like have the single pixle draw control)
        texture.update(pixels);
        window.draw(sprite);
        window.display();
    }
    return 0;
}

8

Graphics / Re: Any way to optimize 'pixelsArray to GPU' process?

« on: September 21, 2022, 11:45:46 pm »

Probably your overload is faster if only part of the screen/image needs to be updated but, let's say a sidescrolling scenario, like having a larger than screen resolution image, it will not speed anything up because its needed to update all the texture so it's not different from my method, am i right??

Thw fact is that if i use the sfml function to draw a 640x480 pixels rectangle it is fast as light, but if i pass a fixed pixelsArray to texture etc (method in OP) it slow down like 95%!

I just need a fast (the fastest possible) way to display a pixelsArray, pixelsArray that i could modify during execution.

Thanks for the overload btw, surely will experiment with it!

9

Graphics / Any way to optimize 'pixelsArray to GPU' process?

« on: September 21, 2022, 10:22:56 pm »

Hi everyone,
for my small projects i'm using a  "sf::Uint8* pixelsArray = new sf::Uint8[640 * 480 * 4];" that gives me the possibility to manipulate every pixel as i want but feels kinda slow..

Here's a pseudocode of what i'm currently doing. is there any way to speed things up?
I've the feel that the last 3 rows are slowing everthing because i have to pass my 'pixelsArray' to GPU (right?) every "new updated frame".

Is there a way to modify my 'pixelsArray' somehow directly in the GPU (to avoid the continuous texture update)?

Code: [Select]

sf::RenderWindow window(sf::VideoMode(640, 480));
sf::Texture texture;
texture.create(640, 480);
sf::Sprite sprite(texture);

sf::Uint8* pixelsArray = new sf::Uint8[640 * 480 * 4];

//UPDATING PIXELS ARRAY
pixelsArray [x + y*640 * i] = 0-256;
so on..

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


BONUS QUESTION:
Suppose i have a large pixelsArray [4096x4096] but want to draw (fast) just a rectangular portion of it?
(like as map scrolling as seen in Age of Empires or Commandos [supposed paused for semplicity])

PS I'm sure i got something wrong but i'm not really into technicals of SFML/OGL.. just need something to draw.

10

Graphics / Re: Is my pixel-by-pixel drawing method right enough?

« on: April 20, 2022, 10:41:30 am »

Another approach is to use graphical objects rather than updating a texture every frame.

For example, you can simply draw a vertex for each pixel you want to colour. All of them if you wish. To do this, you could use a vector of vertices - one for each pixel - and either draw them all each frame, or draw them all to a render texture and then draw that as a sprite/quad; this reduces the number of vertices needed to draw if they don't constantly change.

Another example is to to cover the window with a tile-like object that you can colour each tile individually. If those tiles are pixel sized, you have your pixel control. If they are larger, than the "resolution" appears lower. e.g. if the tiles are 2x2, the "resolution" could seem slightly pixelated but if they are 16x16, they definitely will.

If you decide to try out the latter suggest I gave, you could also try out Selba Ward's Pixel Display, designed to simplify this sort of thing. It's technically designed for lower resolution/colour-paletted display emulation but it's up to you whether or not it's a good approach for actual pixel-by-pixel manipulation.

But what do you think about my method? Is it enough right? Is somehow wrong and sloppy or inefficient (slow)?

I'm intersted in both of your methods, do they speed up a little the rendering confronted to mine?
If you can please provide a simple code to test them it would be great!

Uh you've made your own function library, nice!

11

Graphics / (Full code inside!) Is my pixel-by-pixel drawing method right enough?

« on: April 15, 2022, 09:49:58 am »

Hi everyone!
I'm making a game and i'm questioning if my drawing method is right enough or can be improved.
I really like to draw a pixel at a time.

I pick the color of the pixel i want to draw from and image and than i transfer the RGB data on a 'pixels' array. Then i transfer this 'pixels' array into a Texture, then it into a Sprite and then i display the final Window, this last part (last 3 rows) are a mistery to me, i've seen it online ^^

CODE

(click to show/hide)

int main()
{
    //CREATING WINDOW
    sf::RenderWindow window(sf::VideoMode(windowWidth, windowHeight), "GAME");
    window.create(sf::VideoMode(WindowHeight, WindowWidth), "GAME", sf::Style::Fullscreen);
    window.setFramerateLimit(30); //i use this to impose the game speed

    //SEEN THIS ONLINE: i draw 'WindowTexture' in window to show render the game
    sf::Texture WindowTexture;
    WindowTexture.create(width, height);
    sf::Sprite WindowSprite(WindowTexture);

    sf::Image GameTextures; //Textures of the game
    sf::Uint8* pixels = new sf::Uint8[(WindowHeigh * WindowWidth * 4]; //All pixels of the window (4 =
    RGBA); This is a pseudo-2D array
    for (int i = 0; i < WindowHeigh*WindowWidth*4; i+=4){pixels[i+3] = 255;}  //SETTING ALPHA TO 255
    sf::Color SFcolor; //"Brush" used for draw a pixel


    //LOAD GAME TEXTURES
    GameTextures.loadFromFile("GameTextures.bmp"); //Pseudo-large image with all game textures (walls,
    floors, ceilings,..)


    //GAME LOGIC
    ...

    ///RENDERING///
    while (not every 'pixels' pixel is drawn)
    //SCROLLING TROUGH EVERY PIXEL AND COLORING THEM
    {
       //GET TARGETED PIXEL COLOR
       SFcolor = GameTextures.getPixel (xCoordinate, yCoordinate); //x and y is the coordinate of the big
        GameTextures image with all textures (walls,               floors,..)
   
       //PAINTING THAT COLOR IN 'pixels' ARRAY
       pixels[(Y*WindowWidth + X)*4]    = Sfcolor.r; //'Y*WindowWidth' is for the Pseudo-2D array
       pixels[(Y*WindowWidth + X)*4 +1] = SFcolor.g;
       pixels[(Y*WindowWidth + X)*4 +2] = SFcolor.b;
    }

   
    //DRAW ON SCREEN
    WindowTexture.update(pixels);
    window.draw(WindowSprite);
    window.display();
}

EDIT
What's 'better': use a pixel array and transfer to a Texture OR using an Image and then transfer it to a Texture?

I provide two full code which show that the PixelArray solution is faster but maybe is also stressful for the PC?

(click to show/hide)

//PIXEL ARRAY

#include <SFML/Graphics.hpp>

int main()
{
    const int H = 720;
    const int W = 1280;

    sf::RenderWindow window(sf::VideoMode(W, 800), "SFML works!");
    sf::RectangleShape shape(sf::Vector2f(W, 800));
    shape.setFillColor(sf::Color::Green);
    window.setFramerateLimit(0);

    sf::Texture texture;   
    texture.create(W, H);
    sf::Sprite sprite(texture);
    sf::Uint8* pixels = new sf::Uint8[W * 800 * 4];

    for (int ir = 0; ir < W*H * 4; ir++)
        pixels[ir] = 255;

    int ix = 0;
    while (window.isOpen())
    {
        for (int ir = 0; ir < H; ir++)
        {
            for (int ic = 0; ic < W; ic++)
            {
                pixels[(ir * W + ic) * 4] = ir%255+ix;         //red
                pixels[(ir * W + ic) * 4 + 1] = ic%255-ix;   //green
                pixels[(ir * W + ic) * 4 + 2] = ix;     //blue
            }
        }
        ix++;
        texture.update(pixels);
        window.draw(sprite);
        window.display();
    }

    return 0;
}



------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


//IMAGE

#include <SFML/Graphics.hpp>
#include <stdlib.h>

int main()
{
    const int H = 720;
    const int W = 1280;
 
    sf::RenderWindow window(sf::VideoMode(W, H), "SFML works!");
    sf::RectangleShape shape(sf::Vector2f(W, H));
    shape.setFillColor(sf::Color::Green);
    window.setFramerateLimit(0);

    sf::Texture texture;   texture.create(W, H);
    sf::Image image; image.create(W, H);
    sf::Sprite sprite(texture);


    int ix = 0;
    while (window.isOpen())
    {
        for (int ir = 0; ir < H; ir++)
        {
            for (int ic = 0; ic < W; ic++)
            {
                image.setPixel(ic, ir, sf::Color(ir%255+ix, ic%255-ix, ix));
            }
        }
        ix++;

        texture.update(image);
        sprite.setTexture(texture);
        window.draw(sprite);
        window.display();
    }

    return 0;
}

12

General / Re: Fullscreen with low resolution is blurred!

« on: May 14, 2020, 06:31:14 pm »

You hit the point! I've tried to stretch the sprite with your method and i think we get hit !
In fact i can strentch it using a float value so i can fill the entire screen properly (for other screen resolutions i just have to change the stretch factor and the original 320x200 game resolution a little bit) and the CPU usage in a stressfull game condition (120 sprites rendered) for the process raises from 20% for a 320x200 windowed mode to 24% for sprite stretched and fullscreen mode, my previous method of stretch the pixels array pixel per pixel and then draw it uses 29%.. i think that's very good!

Thank you very much Hapax! 

13

General / Re: Fullscreen with low resolution is blurred!

« on: May 14, 2020, 05:40:30 pm »

///CREATE
sf::Texture texture;             texture.create(width, height);
sf::Sprite sprite(texture);

sf::Uint8* pixels = new sf::Uint8[width * height * 4];
window.create(sf::VideoMode(windowWidth, windowHeight), "RAY-CASTING", sf::Style::Fullscreen);

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

This is what i do, i draw pixel by pixel my 320x200(RGBA) array of pixels, and then copy into texture/sprite and eventually draw it. I think is similiar to your method.

I will try soon your method for stretch the sprite

PS
I've tried my game on a diferent PC with a different desktop resolution and the Style::fullscreen doesn't fill the monitor as it did on my laptop, so it was just luck :/

14

General / Re: Fullscreen with low resolution is blurred!

« on: May 13, 2020, 12:21:43 am »

What i was doing until now is take my 320x200 image, stretch it by a factor of 3 (1 pixel correspont to a 3x3 sqare of pixels) and then draw this last one in a 960x600 window; or render a 320x200 window and then enlarge it as you would do with a normal window; in both way the image remain well pixeled (like the right image). The problem is that boht these processes use too CPU.

To be clear, on the first scaleup method: i create a firstWindow 320x200 and on this one draw the game render, then i upscale this firstWindow copying each pixel 9 times (3x3) in a secondWindow (320x3)x(200x3) and then i draw this last one on the final window, it works well. Do you mean this method to stretch the original image? Is there a more CPU efficient way? I'm sorry i don't know well SFML..

15

General / Re: Fullscreen window and changing PC resolution?

« on: May 12, 2020, 01:20:50 pm »

Yes, i was already thinking about something like that, or change the FOV (field of view of game) to mantain the proper ratio in any resolution.

I partially solved the problem, i just set window(sf::Style::Fullscreen) (sorry for not checking this before) and it goes fullscreen, changing the desktop resolution to 320x200, with letterbox and original aspect ration, and most important keeping the original windowed CPU usage, that's great!!

But there is another little problem, in this way the image is blurry, i dont't know if is a SFML problem or maybe Microsoft Windows. What i want is a pixeled image, like the one on the RIGHT:

(click to show/hide)

If i'm not clear please ask me!