Messages

1

General / Re: Is SFML message-driven or event-driven?

« on: April 29, 2024, 04:49:10 pm »

Not really correct.
SFML apps are not specifically event driven. Usually the main application loop will do an inner event loop for some things like resizing the window or doing event based keyboard/mouse stuff, but the events are not used for game state or rendering (and input can also be done without events).
Events only happen when something like a key is pressed or something happens to the window, but a game needs to run continuously, faster than events come in. So it's not like an event based application like Winforms or similar.

2

General / Re: Smooth character movement with Arrow keys

« on: April 29, 2024, 02:31:05 pm »

The issue with the top post was that immediate key tests were being done only even events came in.

Imagine you press left arrow, hold it for 5 seconds, then release.
Also imaging you are running at 60fps.
There will be one key down event. 5 seconds later there will be a key up event. But for those 5 seconds in between, there are no events.
An immediate key check (sf::Keyboard::isKeyPressed) doesn't tell you when a key goes down or when it goes up, it tells you the current state. If you call it in the main loop, you'd be calling it 60 times a second and it would tell you the current state.
But in the top post it was only being called twice, not every frame, so the movement wasn't happening every frame.

Another way of structuring it would be to use the events only but get them to set a bool to say the key is currently down or not. Then you'd check the bool (instead of the key directly) outside of the events. So a key down event sets the bool to true, key up event sets it to false. You can now check it as often as you want.

(Actually there may be more events coming in from operating system key repeats when a key is held, but it won't be at 60fps)

3

General / Re: How can I use stbi writing functions?

« on: April 29, 2024, 09:20:04 am »

Basically stbi needs a single instance of some things that can't safely be done in a header. Those defines let it create the objects that it needs.
If you used the stbi headers in for example 5 cpp files, you need to do the defines in just one cpp, the other cpps would do the includes without defines. If you do the defines in more than one cpp, you'll get the multiple definition error.

4

General / Re: How can I use stbi writing functions?

« on: April 28, 2024, 11:04:39 pm »

In one (and only one) of your cpp files that includes the stbi headers, you need to do some defines before the includes:

#define STB_IMAGE_IMPLEMENTATION
#define STB_IMAGE_WRITE_IMPLEMENTATION
 

The first one is needed for the reading functions. The second one for the writing functions.

5

Audio / Re: Music not playing even though its loaded.

« on: April 24, 2024, 08:56:45 am »

I tried the same code (both global and local window) and music played fine in both cases. Although I'm using SFML 3 so maybe it doesn't have the issue.
I even tried playing the music without a window and it worked. (I replaced the while open loop with a Sleep(10000)).

But I see some bits of the audio system have changed since SFML 2.5 with how the global audio device is handled.

6

General / Re: Pass int/char array to sf::Uint8 array?

« on: April 21, 2024, 11:30:33 pm »

If we're dealing with 32bit colour (usually are), a char is only a quarter of the colour. But an int can hold an entire colour at once. So right now you are working with quarter pixels instead of whole pixels.

Having

unsigned int* pixels = new unsigned int [1280 * 720];

for (int i = 0; i < 1280 * 720; i++)
    pixels[i] = 0xff0080ff;  // that should be orange on an RGBA 32 bit pixel, which is what SFML uses

Means you are working one pixel at a time, and the for loop code does a quarter of the work.

7

General / Re: Pass int/char array to sf::Uint8 array?

« on: April 21, 2024, 02:23:39 pm »

One thing to be careful of is where that Array is created and which compiler you are using.
Local variables like arrays are created on the stack (whereas things made using "new" are on the heap). Visual Studio C++ only allocates 1MB for the stack by defaultr, but your array is using almost 4MB. So overflowing the stack could cause an issue.

Otherwise it should be fine.

8

General / Re: Pass int/char array to sf::Uint8 array?

« on: April 21, 2024, 03:03:00 am »

If you mean for passing to the texture update method, as long as the size is correct (and the data makes sense) you can pass in any kind of array if you cast the pointer type.

int *pixels = new int[WIDTH * HEIGHT];
texture.update((const std::uint8_t*) pixels);

9

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

« on: April 17, 2024, 01:23:22 am »

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).

10

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

« on: April 10, 2024, 12:10:34 am »

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.

11

Graphics / Re: [SOLVED] VertexBuffer caching for chunks rendering

« on: April 08, 2024, 12:40:35 am »

Cool that you solved it.

So, as I understood you render the screen tile and 8 nearest quads, if you move for example on left you will discard 3 tiles on the right and prepare other 3 tiles on left.

Yep.

But in your case, net of rendering issues, I assume that you don't load the entire map, but you load in different steps (a sort of "streaming"?)

Mine was a bit different, since my world data for each world chunk had several forms. The main data was a collection of 15 million road connections between GPS points. I loaded that for all of Australia at once (since I needed to do A* pat finding on it). It was less than 200MB of data for the whole country.
If I stored that area as small tiles I'd probably stream it in.

12

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

« on: April 08, 2024, 12:29:06 am »

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).

13

General discussions / Re: Is better sf::sleep(sf::milliseconds()); or window.setFramelimit(); ?

« on: April 07, 2024, 01:34:29 am »

Internally, setFrameLimit uses sf::sleep anyway.

void Window::display()
{
    // Display the backbuffer on screen
    if (setActive())
        m_context->display();

    // Limit the framerate if needed
    if (m_frameTimeLimit != Time::Zero)
    {
        sleep(m_frameTimeLimit - m_clock.getElapsedTime());
        m_clock.restart();
    }
}

The problem with either is sf::sleep uses the operating system sleep, which can be inaccurate. For example on windows the sleep will be at least what you specify, but may also be longer. So you may not get a consistent framerate. Vsync is more reliable since the drivers are waiting for a fixed rate hardware event.

A basic busy loop will use more cpu, but will be more reliable without vsync.

You could try a combo, check how long is remaining until the next frame, then sleep for a small amount (like 1ms) if the remaining is greater than maybe 2ms. Otherwise busy loop. So a sleep that's too short or long probably won't affect it.

14

Graphics / Re: gluBuild2Dmipmaps indefined

« on: April 06, 2024, 07:03:13 pm »

It should be gluBuild2DMipmaps, not gluBuild2Dmipmaps.
(capital M)

15

Graphics / Re: VertexBuffer caching for chunks rendering

« on: April 06, 2024, 07:00:37 pm »

I made a project a while ago (using SFML) that needed to display all of australia (in enough detail to watch a car driving).
I used a pool of 9 render texture tiles each as big as the screen. As the view centre crossed into a new tile, I reused 3 of the tiles to generate the next 3 tiles. If you don't cross the boundary, it's just rendering at most 4 sprites to do the ground.
For smaller tiles without a larger landblock, you could progressively render tiles into the render texture as you approach the edge, so its not rendering all of them in one hit (frame time spikes).

Although these days I'd use a tile shader. Technically a 16k x 16k world of tiles can be done with 1 triangle and a 16k x 16k tile index texture (to then look up a tile texture atlas). Moving around in the world is just sending a position to the shader.