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.

Topics - barnack

Pages: [1] 2
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 / 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 / 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 / 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

General / having a time based loop within a blocking based program
« on: August 19, 2018, 03:14:12 am »
i was enjoying working more or less flawlessly in my project (not a game). Since its an utility and it doesnt have to eat resources as a game while not being used, i opted for waitEvent instead of pollEvent.
However working on workspace navigation i ended up with a "oh shit" situation.
I planned using both mouse-near-borders and arrow keys to navigate on the working zone in case it is bigger than the window.
And yeah i cant do that with waitEvent, because once the mouse gets to the border and the event triggers once, everything stops.

Indeed thinking later about that, programs like paint and paint.net, event notepad++ have keyboard navigation based on operating system simulated key repetition when the arrow is being held; which i could pretty much do as well.

The point is, is there any workaround you can suggest me to have it work with mouse-near-borders, like in rts games?

My only idea now was putting all the draw part in a function, and have my main loop looking like that (i know its ugly)

Code: [Select]
if waitEvent(event)
    //stuff happens
        case mouse on border:
            while pollEvent(tmp_event)
                if mouse on border
                    move screen
                    break out of poll event
        case other events:

Graphics / prevent last draw trail during resizing
« on: August 19, 2018, 02:37:04 am »
is there a way to prevent a window from creating a trail of what's in the borders during window resizing?
Just having it flat black would be better than this.
Note this is during resizing, not after left button is released. Windows blocks the window until resizing is complete afaik, but other programs i made with gamemaker dont have this behaviour during resizing.

Window / get events when window is not in focus
« on: August 07, 2018, 06:19:27 pm »
Is it possible to get events with waitEvent (or even pollEvent) without the window being in focus? Some (although not many) programs do that. For example you can play with PCSX2 while the window is not in focus.

An example would be making an on screen keyboard which highlights buttons pressed without being on focus, for making usage videos of another program.

General / waitEvent is not working as i expected
« on: July 28, 2018, 03:09:06 am »
I thought using waitEvent instead of Poll event in the exact same cycle would make my program block until an event is recived (like a mouse click). Instead whatever i do the program is stuck there and does nothing...
int window_mode()
        sf::RenderWindow window(sf::VideoMode(800, 600), "GraphMaker");
        while (window.isOpen())
                // Process events
                sf::Event event;
                //while (window.pollEvent(event))
                while (window.waitEvent(event))
                        // Close window: exit
                        switch (event.type)
                                case sf::Event::Closed:

                                case sf::Event::MouseButtonPressed:
                                        //do stuff
                                case sf::Event::MouseButtonReleased:
                                        //do stuff
                                case sf::Event::MouseMoved:
                                        //do stuff

                // CLS

                // DRAW
                //draw stuff

        return 0;

Compiling with visual studio, if that matters.
So i'm wrong thinking it should work this way or there's something else going wrong?

General / switch console mode-window mode
« on: July 27, 2018, 08:30:36 pm »
I'm planning to have my program be able to switch between two modes;
in console mode (already mostly done) it can be used as any command line program. Then a "window mode" command would open the sfml window, use fancy graphics etcc, and a button in the window would switch back to console mode. Now, i can perfectly do all that keeping the window back but blocked while the program is stuck in the window's main loop. But can i hide the console for the time the program is in window mode in a non-platform specific way?

General discussions / Rendering expression from latex syntax
« on: June 18, 2018, 09:14:32 am »
is anyone interested in working together on code that takes as input a latex math expression and gives as output the image of that expression, without relying on outside code?

I'd like to work on that but probably some help would benefit; still not sure if using lex/yacc for parsing or doing it manually, but i've always used such tools for simple (and sample) code at university, never used them for anything more serious.

General / Single loop vs 2 threads
« on: June 16, 2018, 02:04:41 pm »
    I'm working on a program (non game) which would have long times of non-interaction with the user. (think to some explorer windows for example, you maybe drag something and keep the window open there doing nothing.
    Since i'd not need a constant "game loop", but things happen only when the user does something i've use waitEvent instead of pollEvent. (it's not a game, i don't want it to suck computer resources, i want it to use as little as exactly needed).

    Now, let's suppose i want to add an animation in the background (some particles effect), which in NO way depend on user input. They're just there, do they thing with 0 interaction, they just update coordinates, create and destroy. Again since it's not a game supposed to get the most out of my resources, for this i'd use a fixed-time step with sleep (don't even need precise timing, just *some* timing). I don't want it to update 500 times per second really; 30 is already fine enough.

    Now my question is, since the particles are just a constantly flowing effect and have nothing to do with user interaction, should i:
    • Use poll event in the same fixed-time step loop that handles particles.
    • Use one thread for particles, which updates 30 times per second, and another thread for handling input.

    I'm more towards the second idea because of the following reasons:
    the two loops work with totally different things, it'd also help separating them logically. Since they don't affect each other in any way, i'd not even need to use mutex guards when performing calculations, because nothing is shared.

    But now comes my concern: how can i handle drawing? Particles should update the drawing 30 times per second, while the input loop should update the drawing only when the user does something. To do so each loop would have to access some of the other loop's data (for example if input loop is drawing i need to get particles coordinates as well, don't want them to disappear in between two frames). I'd have to use mutexes for the short time the drawing cycle is accessing coordinates from the other's cycle.

    When i came to that conclusion i started guessing… well maybe i should just smash everything in the same cycle and gg.
    But since i usually tend to prefer splitting things that have nothing to do with each other, i'd love to see suggestions about the second implementation...

Just thought a thing:
can i have the input loop draw in memory a "temporary image" and the particles loop draw that temporary image on screen with then the particles on top of it? That way all i'd have to do is protecting with a single mutex the access to said temporary image! Does it work in your mind?

Pages: [1] 2