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
1
General discussions / Rendering only oriented window wrapper?
« on: December 11, 2021, 09:06:44 pm »
Hi,
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.

2
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

3
Window / WaitEvent loop but with some timed updates
« on: December 22, 2020, 02:39:08 pm »
Hi,
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.

4
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 :|

5
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

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

7
General / Compiling for android with visual studio
« on: August 28, 2019, 01:31:53 pm »
Greetings,
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?

8
General / Getting accurate fps reading out of a fixed timestep loop
« on: August 17, 2019, 12:55:31 pm »
Hi
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;
#ifdef ENGINE_SHOW_FPS
    size_t frames_count = 0;
    sf::Time fps_t = sf::seconds(0.f);
#endif

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

    while (window.isOpen())
        {
        elapsed = clock.getElapsedTime();
#ifdef ENGINE_SHOW_FPS
        frames_count++;
        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);
            }
#endif
        lag += elapsed;
        clock.restart();

        while (lag >= seconds_per_step)
            {
            events();
            networking();
            step();
            lag -= seconds_per_step;
            }
        draw();

        }
    }

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

10
Graphics / Scaling Sprite to integer sizes
« on: May 13, 2019, 06:42:15 pm »
Hi,
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...

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

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

14
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


15
SFML development / Re: C++ standards
« on: September 07, 2018, 03:10:04 am »
it's more about the features that we need.
That's a good point about something i noticed eXpl0it3r wrote: "Code simplification: smart pointers".
Do we really need that?
I might not be an expert about programming, but if the existing codebase is working internally with good old pointers AND without memory leak issues (i'm supposing it does), which means dynamic memory is properly managed, then what's the point of replacing them with smart pointers?
In my point of view smart pointers can help to make quick code, can allow the programmer to be more lazy, but they take this small amount of resources more than normal pointers to, which in the case of an already robust code seems just a waste to me.
Am i missing something?

Sorry for the bad english, i've been awake since more than 48 hours  ::)

Pages: [1] 2 3 4
anything