Messages

16

Audio / Re: getStatus() Waits for SF::Music to Load - Pauses Program 80ms

« on: November 10, 2014, 02:22:35 am »

Awesome! Works beautifully. Thank you very much!

I really need to brush up on my threading, its been a while.  I would love to be more useful. While digging around the source I passed right by there without a second thought.

17

Audio / Re: getStatus() Waits for SF::Music to Load - Pauses Program 80ms

« on: November 10, 2014, 12:28:46 am »

I understand it was 28ms here, I was getting 80ms in my actual project. Which seems pretty crazy to me which was I guess why I didn't think of it. 28ms-80ms for a cout statement!?

I think there may be some sort of weird conflict still going on here that shouldn't be? Some sort of threading issue? Check this example out, I still get a delay in getStatus:

#include <SFML/Audio.hpp>
#include <iostream>

int main(int argc, char *argv[])
{
        sf::Music music;
        music.openFromFile("test.ogg");
       
        sf::Clock clock;

        sf::Time a = clock.restart();
        music.play();
        std::cout<<"COUT STATEMENT\n";
        sf::Time b = clock.restart();
        music.getStatus();
        sf::Time c = clock.restart();

        std::cout << "openFromFile: " << a.asMicroseconds() << "\n";
        std::cout << "play:         " << b.asMicroseconds() << "\n";
        std::cout << "getStatus:    " << c.asMicroseconds() << "\n";

        int x = 0;
        std::cin>>x;

        return(0);
}

Results in:

openFromFile: 2
play:         700
getStatus:    27865

Removing the couts fixes it though... Why would pending couts cause such a large delay only in getStatus?

18

Audio / Re: getStatus() Waits for SF::Music to Load - Pauses Program 80ms

« on: November 09, 2014, 10:54:43 pm »

Ah that could be another useful symptom, I do get ~80ms in my main project so it is variable somehow. I will poke around.

Are you able to reproduce the delay at all? I worry it could be me doing something stupid in my dependencies.

19

Audio / Re: getStatus() Waits for SF::Music to Load - Pauses Program 80ms

« on: November 09, 2014, 09:57:05 pm »

So I was using a recent snapshot, but just built with the latest source (files time-stamped Nov 5 11:36) and the problem is still there. Key clue I figured out, the problem is not there when built against 2.1 libs, so it must have been introduced recently or I am doing something wrong with the new format that has not affected anything else.

#include <SFML/Audio.hpp>
#include <iostream>

int main(int argc, char *argv[])
{
        sf::Clock clock;
        sf::Music music;
        music.openFromFile("test.ogg");

        std::cout<<"TIME 1: "<<clock.getElapsedTime().asMilliseconds()<<'\n';
        music.play();
        std::cout<<"TIME 2: "<<clock.getElapsedTime().asMilliseconds()<<'\n';
        music.getStatus();
        std::cout<<"TIME 3: "<<clock.getElapsedTime().asMilliseconds()<<'\n';
        int x = 0;
        std::cin>>x;
        return(0);
}

Output:

TIME 1: 80
TIME 2: 80
TIME 3: 108

20

Audio / getStatus() Waits for SF::Music to Load - Pauses Program 80ms

« on: November 09, 2014, 12:16:30 am »

So I was trying to figure out why I was having a weird hiccup in my program and figured out it was from calling getStatus() on an SF::Music shortly after calling play(). It takes almost 80ms which is obviously noticeable.

Is there a best practice (single thread) work around for this? Delaying checking the status an arbitrary amount of time hoping the stream has loaded seems weird. Any other way to see if the file is loaded enough to be able to check it's status?

It would be nice if getStatus() returned -1 or something if the stream has not loaded yet instead of hanging.

Edit: Also noticed calling stop() takes about 5ms?! Is that the case for everyone? Is that much time really needed? Huge overhead there I never realized.

21

General / Re: Linking Error Building from Snapshot

« on: September 27, 2014, 02:35:54 am »

Ha not seconds after posting while trying to revert to my old properties I found I still was including the original source in one location. I should have given up earlier it would have saved me a bunch of head banging.

Sorry for the forum bloat! Feel free to deleting unless this might prevent someone else from adding more bloat in the future.

22

Audio / Re: Array of sf::Music Causes Crash?

« on: September 27, 2014, 02:35:27 am »

Ha not seconds after posting while trying to revert to my old properties I found I still was including the original source in one location. I should have given up earlier it would have saved me a bunch of head banging.

Sorry for the forum bloat! Feel free to deleting unless this might prevent someone else from adding more bloat in the future.

23

General / Linking Error Building from Snapshot

« on: September 27, 2014, 02:27:53 am »

So I built from the latest snapshot (Sept 24 2014) in cmake having only built from 2.1 or earlier previously. I am linking statically and edited GlxContext to give me a core profile. These are things I did with 2.1 and had working.  In my solution I updated the library folders to the new ones

I added the new dependencies that I understand are now needed as shown in the attached image and the library folder for the externals. I am doing something wrong and have exhausted all my ideas and searches.

Right now when I try to compile with this line:

sf::Image icon;

Causes the following:

sfml-graphics-s.lib(Image.obj) : error LNK2005: "public: __thiscall sf::Image::~Image(void)" (??1Image@sf@@QAE@XZ) already defined in windowFunctions.obj

If I comment it out it compiles and runs. I am stuck, can someone show me what I am doing wrong?

24

Audio / Array of sf::Music Causes Crash?

« on: September 27, 2014, 02:23:44 am »

So using the newest snapshot (24 Sept 2014) openFromFile() causes a crash when using an array of sf:Music:

sf::Music* testMusic = new sf::Music[10];
testMusic[0].openFromFile("test.ogg");

Where this does not crash:

sf::Music testMusic;
testMusic.openFromFile("test.ogg");

Previously the array of sf::Music was fine. Is this intended? I could not find anything about sf::Music changing. Was I just lucky my code worked previously?

25

Window / Re: SFML 2.1 getSize() Returns Incorrectly with Devices Using Autoscaling (Bug?)

« on: May 19, 2014, 04:30:01 am »

Ah! Good to know it is not just me. This issue will be more prevalent very shortly as 4k screens are hitting.

I think it should be straight forward to implement in the SFML code, not sure if we can do it without compiling our own version in the mean-time. Should probably wait a bit more to see if the devs have anything else to add about it before submitting anything but I guess it needs both a bug report and feature request for the misreporting of size and lack of ability to turn auto-scaling off.

26

Window / Re: SFML 2.1 getSize() Returns Incorrectly with Devices Using Autoscaling (Bug?)

« on: May 12, 2014, 10:50:58 pm »

Any other information I can provide?

Should I submit a report/request?

27

Window / Re: SFML 2.1 getSize() Returns Incorrectly with Devices Using Autoscaling (Bug?)

« on: May 08, 2014, 07:45:20 pm »

I really don't know much about it, but apparently it is a Windows form property as of Vista SP2:

http://msdn.microsoft.com/en-us/library/system.windows.forms.autoscalemode(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/system.windows.forms.containercontrol.autoscalemode(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/ms229605(v=vs.110).aspx

It seems like it tricks the program into drawing at half scale, then Windows scales it up when displaying. This "feature" apparently exists so that fonts/buttons/etc are large enough to see on new high density displays.

You can see the flag by right clicking on an exe or shortcut:

Properties -> Compatibility -> Disable display scaling on high DPI settings

Display scaling is apparently enabled by default, and when a device has high enough DPI that it is activated getSize() returns incorrectly/inconsistently. As a secondary issue I would prefer SFML disabled it by default and/or that there was some way to set the flag.

28

Window / SFML 2.1 getSize() Returns Incorrectly with Devices Using Autoscaling (Bug?)

« on: May 08, 2014, 03:49:43 am »

New high DPI Windows (possibly other platforms as well) devices incorporate an autoscaling feature which does not work properly with SFML's getSize().

getSize() returns actual display pixels with sf::VideoMode::getDesktopMode() and sf::Style::None but then autoscaling doubles it so 1 pixel is 4 I only see the center quarter of my draw call.

getSize() returns half the actual display pixels (width/2, height/2) with sf::VideoMode(width, height) and sf::Style::Default and it stretches everything to the full size (width, height). Again 1 pixel is 4, but at least I am not offscreen.

Disabling autoscaling in the programs properties menu resolves these issues.

Is this a bug or an un-requested feature? I feel like SFML's default setting should have AutoScaleMode set to None? Is there a reason it is not? Should I submit a bug report and or feature request? Is there an alternate resolution to this issue?

I have not found anything about this as it relates to SFML by searching. I am using SFML 2.1 so if it has been addressed already I apologize. I do not have regular access to a high DPI device so I may not be the best person to spearhead this if there is someone out there who owns one.

29

Window / Re: OpenGL Context Flashes on Screen when Created

« on: February 13, 2014, 04:32:06 pm »

Oh amazing! Definitely a big improvement thank you very much.

I still have a bunch of issues/questions, this is what I currently get. When I say OS event what happens is all monitors flash black then return to normal.

When creating a new window:

sf::Style::Fullscreen:
1) Fullscreen window appears with white background*
2) Background changes to black
3) OS event
4) Displays my draw call

sf::Style::Default:
1) Framed window appears with white background*
3) Displays my draw call

*White background stays long enough to see it even if next line is a display call.

sf::Style::None with size < Desktop:
1) Frameless window appears when I make my first draw call

sf::Style::None with size == Desktop:
1) OS event
1) Frameless window appears when I make my first draw call

When I close a sf::Style::None with size == Desktop or a Fullscreen window there are 2 OS events.

When exactly does the OS event occur?
Is it possible to use sf::Style::None with size == Desktop without the OS event, as it behaves when size < the desktop?
Is it possible to use sf::Style::Default without the white background appearing?

Anyone else have any insight on this?

30

Window / Re: OpenGL Context Flashes on Screen when Created

« on: February 10, 2014, 08:08:12 pm »

Clear() is an sf::RenderWindow function not am sf::Window function, but as I list in my last post with sf::Style::Default I get the white background and display() does clear to black but even if it is my next line the white is visible prior. With sf::Style::None I get an OS Event not a white background if the size = desktop.