Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - kojack

Pages: [1] 2 3 ... 21
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).

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.

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.

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

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

Internally, setFrameLimit uses sf::sleep anyway.
void Window::display()
    // Display the backbuffer on screen
    if (setActive())

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

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.

Graphics / Re: gluBuild2Dmipmaps indefined
« on: April 06, 2024, 07:03:13 pm »
It should be gluBuild2DMipmaps, not gluBuild2Dmipmaps.
(capital M)

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.

Audio / Re: Help with running the package
« on: April 06, 2024, 06:13:57 pm »
Neon is the ARM CPU equivalent of SSE.
Apparently at least the M1 does support Neon instructions, if they are enabled when building.

I have no idea why in the error listed the /proc/cpuinfo is failing to open though. A permission issue? (I don't do mac development)

General / Re: Mouse Movements
« on: April 06, 2024, 05:57:49 pm »
You could average (maybe weighted lerp) the mouse position and the sprite.

Or calculate the difference between the current and previous mouse positions as a vector, then if the magnitude of the vector is too long (so speed is too high) then rescale the vector. Use this vector (whether scaled or not) to move the sprite.

General discussions / Re: Can vlc work on SFML window?
« on: April 06, 2024, 01:07:16 pm »
I've used OpenCV with SFML, it was pretty easy to get it to do video playback into an SFML texture (only takes about 4 lines of code to get an OpenCV video frame into an SFML texture).

It's only good for video though, no audio.

I use Portable File Dialogs: https://github.com/samhocevar/portable-file-dialogs
It's a single header only library that supports windows, mac and linux.
It can do file open/save and folder selection dialogs, plus message boxes and notifications.

Graphics / Re: hello. a question about setTextureRect
« on: March 28, 2024, 04:11:45 am »
Clamp to edge does what you are seeing, the edge pixels are extended infinitely around the texture.
Clamp to border lets you specify a single colour (like black) to show around the texture.
Repeat makes the texture tile (so it repeats).

SFML however only supports repeat and clamp to edge. It doesn't have clamp to border. (At least in SFML 3, which I'm using).

I don't know if there's an easy way to trick it besides editing texture.cpp to add the border mode in.

General / Re: loading/initializing neighbors of a tile in a grid
« on: March 28, 2024, 03:55:16 am »
The problem here is something that a few languages (not just javascript) going to C++ can run into.
Javascript uses references for classes. C++ uses values by default, but can also use references or pointers.

In your Tile class you have: std::vector<Tile> neighbors;
A vector of Tile isn't just references to tiles, it's complete copies of the tiles. So each tile contains a copy of all adjacent tiles, each of which contains copies of their adjacent tiles, and so on. As you process over the map adding neighbors, each new tile is picking up larger amounts of data.

What you'll want to do is have the neighbors either as an index (1d or 2d) that can look up the specified tile, or pointers to tiles. (C++ references aren't like in other languages, they wouldn't fit here as well as a pointer would)

Window / Re: Texture error?
« on: March 15, 2024, 06:08:10 am »
When you call setTexture, try adding true as a second parameter. That will reset the texture rectangle used by the sprite (needed if the textures are different sizes).

General / Re: How to make a list with a dynamic length?
« on: March 15, 2024, 06:02:29 am »
std::vector is the class you want. It's a dynamic resizable array as part of the C++ standard.

Pages: [1] 2 3 ... 21