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 - barnack

Pages: [1] 2 3 4
SFML development / Re: sf::WindowBase vs sf::Window vs sf::RenderWindow
« on: January 23, 2023, 09:24:51 pm »
Nice to see the windows are being argued about.
Imo the biggest problem is that the library's modularity is lost with the windowing system.
While we can have SFML's windowing without SFML's drawing, we can't have SFML's drawing without SFML's windowing. That I think should be addressed for SFML 3.

There needs to be a way to let the users provide their own window and NOT override the user's (or third party library) underlying windowing system management.

I can't speak for other OSs as I'm focused on Windows; on Windows if the user passes his own HWND, SFML will replace the user's window procedure with its own.

Instead a more generalized drawing framework could give an interface to which the user can pass OS level events to the windows so SFML can handle the messages it needs to handle.

In short, if I use SFML's drawing on my own non-SFML windows, I want SFML to deal with resizing events but not everything else.

For example I do have a more generalized windowing framework here (https://github.com/Sephirothbahamut/CPP_Utilities_MS), that lets the user add his own "modules" to the window, so you can write a "direct2d", and "sfml" or an "opengl" module that handle swapchain related stuff but let other modules handle other things.

A valid option would be a window-specific rendertarget type with an "on resize" method that takes the new window size. The user window is expected to call that method with the resize event, may it be from a WndProc on window, a callback on glfw, or the size event from sfml's own window.

Same for any other event that a window render target may need, although to be honest the resize event is the only one I can think about right now.

General discussions / Rendering only oriented window wrapper?
« on: December 11, 2021, 09:06:44 pm »
I've always liked how SFML makes its modules almost independent from one another. You can have SFML's event management on SFML's Window and do the rendering with a completely different library, you can use SFML's sound without even having a window, and so on.

But recently I've been exploring Windows window customization to a degree SFML doesn't allow, and on top of that I wanted to build my own event management system (closer to GLFW's than SFML's).

And here the truth hurt me: I couldn't find a single way to use only SFML's Graphics component onto an existing window without it being intrusive about the event system too.
As far as I could read from past topics, SFML creates its own context on windows, which is fine, but if the only way to do that is creating an sf::RenderWindow, that will force SFML's window management and event system as well, in particular replacing the window procedure and the data cointained in the user pointer on the Windows implementation.
That's a consequence of sf::RenderWindow inheriting from sf::Window, which exists for the purpose of adding SFML's event system to a window (if my understanding is correct)

Is there any way to achieve what I'm looking for (without rendering SFML stuff to a temporary rendertexture and copy that texture in opengl to the buffer)?

If there isn't, I'd move this topic in the feature requests section and I'd propose the addition of either
- an "sf::RenderContext" which is built by passing it a raw OpenGL context and exposes draw() and clear() on that. The construction should fail if the context is not created with settings expected by SFML (like double buffering).
- an "sf::RenderOnlyWindow" which sets up the required render context, exposes the drawing methods, but does NOT interfere with a window's event management.
Either should also expose a context resizing method to be called manually.

Window / Re: WaitEvent loop but with some timed updates
« on: December 22, 2020, 04:47:59 pm »
No need to deal with setActive if all graphics calls are done from the same thread (ie. the secondary one), you'll just have to call window.setActive(false) once before launching your thread. Then you'll just need one synchronization point to pass events from the primary thread to the secondary one.

Only issue with that is i need to re-draw on the resize event, besides the timed updates

Window / WaitEvent loop but with some timed updates
« on: December 22, 2020, 02:39:08 pm »
I'm not making a game, I'm making a desktop tool for monitoring performance (on top of LibreHardwareMonitor), in C#.
Ideally I'd update the metrics (and the window content) every 1 or more second. However if I add a sleep in a simple loop of one second, events dispatching is noticeably laggy.

Is there some straightforward way I'm not seeing to have a WaitEvent loop, but force it to get past the waiting every X seconds even if no event occurred?

I thought about having 2 threads, one looping with WaitEvent, the other updating every X seconds, but I'd rather avoid the mess of dealing with SetActive and synchronization.

General / Re: Compiling for android with visual studio
« on: August 31, 2019, 12:37:49 am »
I haven't tried it with SFML but I have managed to convert a few other android libraries to Visual Studio projects - the process should be somewhat similar I think. There's a run-down here: https://trederia.blogspot.com/2017/03/building-sdl2-for-android-with-visual.html
doesn't look like something that someone with 0 experience on android development should try with any hopes of succeeding :|

General / Re: Getting accurate fps reading out of a fixed timestep loop
« on: August 31, 2019, 12:27:16 am »
There is a small amount of time that passes between getting the elapsed time and restarting the clock.
Try the shortcut that cuts it as fine as possible:
elapsed = clock.restart();
sf::Clock's restart also returns the time elapsed time before restarting.

Everything else looks about right, without going into the details of what each separate external function does.

Also, sf::Time has a constant for zeroing the time, which can help with clarity:
fps_t = st::Time::Zero;
Sorry for the late reply. This actually solved the "issue", now i'm having readings between 60 and 61 fps exactly as with any other application. It feels weird that this small thing was eating so relatively much time though

General / Re: Compiling for android with visual studio
« on: August 28, 2019, 02:50:48 pm »
aw bad news, thanks for the answer though

General / Compiling for android with visual studio
« on: August 28, 2019, 01:31:53 pm »
i've been googling the title but i only either get way old results (even before sfml 2.0) or results in turkish. Is there any up to date tutorial i'm missing?

General / Getting accurate fps reading out of a fixed timestep loop
« on: August 17, 2019, 12:55:31 pm »
I tried to write a fixed timestep loop as explained in this article using SFML, and wanted to have an fps reading to check my engine's performance while i add stuff to it.
When i enable v-sync in various games i tend to get 60-61 FPS, while with the reading i'm doing here, enabling v-sync i get 58-59. I know it's very little but it looks weirdly inconsistent to me, so i thought maybe i'm doing something wrong in the loop.

size_t steps_per_second = 30;
sf::Time seconds_per_step = sf::seconds(1.f / steps_per_second);

Game cycle method:
void Game_engine::run()
    sf::Clock clock;
    sf::Time elapsed;
    sf::Time lag;
    size_t frames_count = 0;
    sf::Time fps_t = sf::seconds(0.f);

    lag = sf::seconds(0.f);

    while (window.isOpen())
        elapsed = clock.getElapsedTime();
        fps_t += elapsed;
        if (fps_t >= sf::seconds(1.f))
            float fps = frames_count / fps_t.asSeconds();
            text_debug_fps.setString("FPS: " + std::to_string(fps));
            frames_count = 0;
            fps_t = sf::seconds(0.f);
        lag += elapsed;

        while (lag >= seconds_per_step)
            lag -= seconds_per_step;


General discussions / Why isn't there a networking event?
« on: August 04, 2019, 05:24:27 pm »
Game Maker has it, and it makes sense to me honestly. Not as default, but as a feature the programmer can either enable or disable.

The idea is being able to receive and elaborate networking messages through the events system, without requiring the user to deal with async stuff.

Right now for what i'm working on i'll make a class that does exactly that, in a second thread it takes data from the network and fills a queue; the main cycle after handling events handles that queue's content as if it was another event. (well it's more complex than that for thread safety and actually uses two queues so you don't lock the main thread, but that's the idea.)

Graphics / Scaling Sprite to integer sizes
« on: May 13, 2019, 06:42:15 pm »
is there any way to force the size of a sprite to be rounded after scaling? I didn't find anything except a "setSize" that existed in previous SFML versions...

Graphics / (Windows-specific) render on wallpaper?
« on: May 12, 2019, 12:39:34 am »
Does anyone know how to (if it's even possible) get the handle (if it even has one) of Windows's wallpaper and use it as SFML graphics rendering surface? I've successfully done something similar with the taskbar, but i can't find out how the wallpaper works. The taskbar seems to act like a borderless fixed window with an on top priority, or at least i could retrive the handle to draw on as if it was a window. But i've no idea how the desktop works...

General / Re: smooth timed animation
« on: December 13, 2018, 09:06:40 pm »
well you're not using the timer as you thought i guess.You're using a timer relative to when the clock started, when what you need is the time elapsed since last step of the cycle.
You can either reset the clock at the end of the step or keep a separated delta time variable.

Or to make your life easier, make a fixed duration step game :)

General / Mouse coordinates on zoomed/unzoomed view are driving me crazy
« on: December 13, 2018, 08:04:10 pm »
I've a main view used to show a workspace (like paint for example), which can be zoomed/unzoomed and rotated.

The zoom is defined by a global multiplier: scrolling the wheel changes that multiplier, then the view size becomes equal to the window size times that multiplier. That way i can keep the zoom value when the window is resized.

My problem is, while mouse coordinates are mapped perfectly with a 1x zoom, any different value of the zoom screws the mapping (of course, mapping coordinates is a property of the window, not of the view); but i'm having quite an hard time understanding what maths should i apply to the mouse coordinates in order to have them be aware of the zoom.
if ((delta > 0 && graphics_zoom > 0.8) || (delta < 0 && graphics_zoom < 20))
        graphics_zoom += delta * -0.2;
        view_work_area.setSize(window.getSize().x * graphics_zoom, window.getSize().y * graphics_zoom);
where delta is the scrolling wheel value

Pages: [1] 2 3 4