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

Pages: 1 2 [3] 4 5 ... 93
31
With https://github.com/binary1248/SFML/commit/ef593102ba730c300895109125860e5ab59d3c63 you can do what you want:
#include <SFML/Window.hpp>
#include <iostream>
#include <Windows.h>

LONG_PTR originalsfmlcallback = 0x0;

LRESULT CALLBACK mycallback(HWND handle, UINT message, WPARAM wParam, LPARAM lParam)
{
    if (message == WM_DROPFILES)
    {
        sf::Window& app = *reinterpret_cast<sf::Window*>(GetWindowLongPtrW(handle, GWLP_USERDATA));
        std::cout << "Window position: " << app.getPosition().x << ", " << app.getPosition().y << "\n";

        HDROP hdrop = reinterpret_cast<HDROP>(wParam);
        POINT p;
        p.x = 0;
        p.y = 0;
        if (DragQueryPoint(hdrop, &p))
            std::printf("Point is %d, %d\n", p.x, p.y);
        else
            std::cout << "Failed to get point" << std::endl;

        const UINT filescount = DragQueryFile(hdrop, 0xFFFFFFFF, NULL, 0);
        for (UINT i = 0; i < filescount; ++i)
        {
            const UINT bufsize = DragQueryFile(hdrop, i, NULL, 0);
            std::wstring str;
            str.resize(bufsize + 1);
            if (DragQueryFileW(hdrop, i, &str[0], bufsize + 1))
            {
                std::string stdstr;
                sf::Utf8::fromWide(str.begin(), str.end(), std::back_inserter(stdstr));
                std::cout << stdstr << std::endl;
            }
        }
        DragFinish(hdrop);
        std::cout << "-------------" << std::endl;
    }//if WM_DROPFILES
    return CallWindowProcW(reinterpret_cast<WNDPROC>(originalsfmlcallback), handle, message, wParam, lParam);
}

int main(int argc, char ** argv)
{
    sf::Window app(sf::VideoMode(640u, 480u), "Drag and Drop from USERLAND");
    HWND handle = app.getSystemHandle();

    DragAcceptFiles(handle, TRUE);
    SetWindowLongPtrW(handle, GWLP_USERDATA, reinterpret_cast<LONG_PTR>(&app));
    originalsfmlcallback = SetWindowLongPtrW(handle, GWLP_WNDPROC, reinterpret_cast<LONG_PTR>(mycallback));

    while (app.isOpen())
    {
        sf::Event eve;
        while (app.pollEvent(eve))
        {
            if (eve.type == sf::Event::Closed)
                app.close();

        }//while app poll event eve
        app.display();
    }//while app is open
}
 

The question is... should I open a pull request in the main repository for this... ::)

32
Audio / Re: using mini_al instead of openal
« on: January 25, 2019, 01:20:40 am »
https://github.com/jarikomppa/soloud
http://soloud-audio.com/

Seems to be a viable replacement for OpenAL, with nice license and even using the same 3D audio computation model as OpenAL. It's almost as if the author was looking for an OpenAL replacement themselves...

33
It is important that you "jail" the RenderTexture to that one context that you made for it whenever you do anything with the RenderTexture, this includes destroying it. We can't release the corresponding FBO while you are still working in a context other than the one you created it in, which is the case in your example. This leads to an accumulation of FBOs over time that can never get released because you are explicitly blocking us from doing so.

The corrected code would look like this:
#include <SFML/Graphics.hpp>

void main()
{
    // true - vram leak
    // false - ram leak, fps degradation over time, delay on exit ( comment setFrameLimit() )
    bool leak = true;

    sf::RenderWindow window(sf::VideoMode(800, 600), "");
    window.setFramerateLimit(30);
    sf::Context context;
    sf::RenderTexture *rtexture;

    if (!leak) rtexture = new sf::RenderTexture();

    sf::Event event;
    while (window.isOpen())
    {
        // jail begin
        context.setActive(true);

        if (leak) rtexture = new sf::RenderTexture();

        rtexture->create(rand() % 100 + 400, rand() % 100 + 400);
        rtexture->clear(sf::Color::Cyan);

        rtexture->setActive(true);
        //drawing OpenGL stuff here
        rtexture->setActive(false);

        rtexture->display();

        // jail end since window.clear() will activate another context
        window.clear();
        sf::Sprite sprite(rtexture->getTexture());
        window.draw(sprite);
        window.display();

        if (leak)
        {
            // jail begin since window's context is active
            context.setActive(true);
            delete rtexture;
            rtexture = NULL;
        }

        window.pollEvent(event);
        if (event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape)
        {
            if (!leak)
            {
                delete rtexture;
                rtexture = NULL;
            }
            window.close();
        }
    }
}

34
Since your code should take care of cleaning its own state up itself (if it doesn't... well...) having a single context for all instances should be adequate. Debug/Trace/Profile your code to see where all the time is being spent and if it is being spent in your own code you need to come up with a way to optimize it.

35
General / Re: gameSWF started corrupting the rendering since SFML 2.5.0
« on: November 06, 2018, 03:20:35 am »
The big difference between 2.4.x and 2.5.x is that OpenGL contexts are reused where it makes sense. Performance-wise, this saves a lot of time because context switching is an expensive operation. The problem that you have now is that you are no longer working in a sandboxed environment like you were before.

This is a common "problem" I have seen when different software libraries are combined that all make use of OpenGL. Because OpenGL relies on shared state, they all end up stepping on each other's toes. To make sure that they themselves keep working in such an environment, some libraries go through the extra effort to reset all state to whatever it is that they expect it to be before they start to do their stuff. This has the side-effect that you get abysmal performance because of the redundant state changes that are introduced because of this paranoia (and probably the cause of the "OpenGL is slower that D3D" myths in circulation).

In the case of SFML and gameswf, neither bothers to clean up after the other (in SFML's case for performance reasons) so they just end up clobbering the global OpenGL state. As I said, this was not a problem before because SFML isolated each RenderTexture into a sandbox. It was an implementation detail and never something people should rely on. pushGLStates() and popGLStates() only takes care of the OpenGL state that SFML cares about. If gameswf touches anything else it will also have to be reverted to whatever SFML is expecting it to be before continuing to render.

If this is too much to ask, you could try emulating the old sandbox behaviour by creating an explicit sf::Context and activating it before activating the sf::RenderTexture. You will suffer from performance degradation relative to the current implementation, but this should not be any slower than what it was like in 2.4.x.

36
Window / Re: glCheck() not available in window module
« on: August 16, 2018, 05:30:49 pm »
The glCheck macro is only active in non-release builds anyway. It's sole purpose is to help debug problems that might arise from wrong usage of OpenGL. This is significantly more likely to happen in sfml-graphics than in sfml-window because OpenGL is used to actually draw stuff there. There is almost no risk of anything going wrong with regards to that little bit of OpenGL in EaglContext.mm, so other than for pure development/debugging purposes (such as in your case now), glCheck isn't really needed there. With the exception of running on a broken system, there isn't really any way a user could even deliberately cause an OpenGL error in there.

37
Window / Re: glCheck() not available in window module
« on: August 15, 2018, 11:33:46 pm »
Well... look at it this way, glCheck is normally not needed in the window module since OpenGL calls are not made there. The fact that this is not the case in the EaglContext.mm is clearly an exception to the rule. If you want glCheck in there you will need to build it in yourself. Don't get your hopes up though, the bug you are trying to fix isn't the result of any OpenGL calls going wrong.

38
General / Re: Deprecated auto_ptr in AudioDevice and CMake configuration
« on: August 01, 2018, 11:51:27 pm »
If you ask me we should just add
Code: [Select]
set_target_properties(sfml-<module> PROPERTIES CXX_STANDARD 98 CXX_STANDARD_REQUIRED YES CXX_EXTENSIONS NO)to all the module target definitions as long as SFML is still a C++98 library. If the compiler knows we are compiling using the C++98 standard it is smart enough to ignore std::auto_ptr usage and anything else that might be/get deprecated.

39
SFML website / Re: Maintenance
« on: July 25, 2018, 04:21:52 pm »
We already have multiple mirrors that we use to load balance the downloads, one of which I provide. If anyone is willing to set up the infrastructure to balance the rest of the site as well I can provide the extra bandwidth. It is nothing compared to the downloads anyway.

40
Graphics / Re: Triple Buffering one more time
« on: July 17, 2018, 07:16:38 pm »
What can I say... I must admit, one of the big downsides to OpenGL is that its performance is really hard to predict in specific situations. In order to provide the abstraction it provides to us (which is still based on a long outdated model of the hardware) and at a reasonable speed, the specification leaves many things open to the implementers in order for them to be able to optimize better. This also means less guarantees for us and generally more guesswork. Unless you are someone like John Carmack, if you really need highly predictable performance characteristics you have to use either Direct3D or Vulkan (which was designed from the ground up to "fix" these kinds of problems). Maybe one day there will be a Vulkan implementation for SFML...

41
Graphics / Re: Triple Buffering one more time
« on: July 17, 2018, 02:29:43 am »
It's been said on the forums many times already: You need to be careful when measuring OpenGL so naively.

As said many times before, OpenGL is probably the most asynchronous API you will ever see. You need to be lucky (or just very knowledgeable) to run into a function that actually blocks CPU execution until all its effects are complete when writing your typical (not purposely stupid) OpenGL code. Timing specific functions and assuming that the corresponding OpenGL operation must be responsible for any delays is just wrong. Under the hood, nothing prevents the driver from doing something you previously requested only when calling another function in the future.

There are a few things that have to be stated:
  • Because you activated V-Sync and presumably are using a 60Hz monitor, the driver will try to target a 16ms frame.
  • Where/When the driver does the waiting is completely implementation defined. Typically it does the waiting in the buffer swap i.e. inside sf::Window::display(). However, there is nothing preventing it from waiting somewhere else if it has good reason to do so. Double/Triple buffering allows it to stretch time a little since queued frames are only sent out 1-2 frames later.
  • On my system, the delay when loading new textures doesn't occur consistently when loading the first texture. It jumps about between the first 4 textures. However, the delay is always the same.
  • If you time the .display() call and/or the whole frame you will notice that a) the .display() call will not block for the usual 16ms when one of the delays during texture loading occurs and b) the total frame time is 16ms, meaning that all the delay either comes from .display() or texture loading.

Now, we need to ask ourselves why we notice stuttering. Humans have a more or less good ability to perceive changes better than "absolute" values. This means in our case, we notice stuttering not because a frame is just "slow" in general but because it is "slower" than all the other frames. A jump from 16ms frame time to 33ms frame time might already be enough to cause this, even though funnily enough our brains would not consider something as "constantly stuttering" if it ran at a constant 30 FPS or 33ms frame. What is happening here however is a bit more severe than 33ms which means that in those "longer frames" there is suddenly time that is unaccounted for.

Just digging through the call chain of sf::Texture::loadFromFile I noticed that there are still a few places left where glFlush() is still being called. glFlush()/glFinish() and friends are all pretty meh. They belong to those functions that were conceived in a time where single core CPUs were still a thing and GPUs were still glorified co-processors. There is really no good reason any more why you would need to use glFinish() in this day and age, there are so many better performing alternatives to the scenarios that would make it necessary. glFlush() is really weird. If you ask me it is mainly there to overcome driver implementation quirks left over from the early days. It might still be necessary in some special cases, but in typical situations, it really isn't. Like I said, SFML still makes use of glFlush(), now only in sf::Texture and sf::Shader because I threw a bunch of glFlush() calls out from other places just a few months ago.

Commenting out the glFlush()es actually "fixed" the stuttering for me. From my experience, glFlush() is a mixed bag. Sometimes you don't notice it, other times it can be almost as bad performance-wise as a glFinish(). I guess it depends on the driver and whether it likes you/your application/your system. What many people don't know is that an implicit flush is performed when switching OpenGL contexts as well. Put another way, if you want good performance, don't switch contexts if you don't have to. I already improved this a little with my sf::RenderTexture optimization in SFML 2.5. What to do with the remaining explicit glFlush()es I haven't thought about yet. It will be hard to work around since sf::RenderTarget caches state really aggressively and you would need to rebind resources if you left out the glFlush()es.

If you feel brave and like to take risks, you can comment out the glFlush()es and see if it works out for you.

42
General / Re: SFGUI Multiple sfg::Desktop
« on: June 22, 2018, 04:34:47 pm »
This was answered on the now no-longer-existing SFGUI forum. :D

The de facto standard "solution" to this problem is to split your windows into multiple subsets that you store somewhere on your own. They should all be added to the same sfg::Desktop. All you do is hide and show each set to emulate having multiple distinct desktops when in fact you are only using one.

43
Graphics / Re: I need help handling custom OpenGL with SFML
« on: May 25, 2018, 01:33:09 am »
So... where do you unbind your VAO? SFML can't read your code to know exactly which states you touch and therefore has to clean up. You have to do this yourself at the end of every draw cycle.

44
There are already RenderTexture fixes pending for inclusion into a 2.5.1 release:

https://github.com/SFML/SFML/pull/1438
https://github.com/SFML/SFML/pull/1440
https://github.com/SFML/SFML/pull/1442

See if they help.

Also, don't refrain from posting your code anyway. Something is always better than nothing. I would rather install the dependencies and investigate than spend weeks trying to guess what the problem could be.

45
This issue should be fixed with PR #1437.

Pages: 1 2 [3] 4 5 ... 93