Messages

31

Graphics / Re: Changes in RenderTextures/Texts?

« on: October 06, 2014, 09:23:06 pm »

I investigated a bit further and compiled new SFML dlls from the 2.1 tag. Using these the problem with the mirroring is gone, so I can attribute that to some change in SFML. Though I have doubts if the old or the new version is correct, as I vaguely remember having to re-sort the vertices back then.

To answer your questions, there is surely no mixing of debug and release, debug version uses debug dlls and release version uses release dlls and both had the same problems. 2 and 3 are completely single threaded.
1 is nearly single threaded, just to circumvent some other problem, only when a new texture is needed, it launches a new sf::Thread and immediately waits for that thread, inside it just creates a String, Text, RenderTexture, does a clear, draw, display, copies the internal texture into a newly created one.
Somehow the clear does not clear the RenderTexture, which causes the garbage pixels in both SFML versions I tested when normally running the program. I confirmed this by running it in the debugger and seeing the garbage replaced with a green color (debug memory fill I guess) while still having the text in the parts of the RenderTexture that got drawn to. That also causes some problems in the 3rd version that I forgot to mention.
I think the reason I did not have these problems earlier is because back then I still had a newer ATI card that I replaced with some ancient NVidia card that was laying around here when its stopped working reliably. That card does not support GL_EXT_framebuffer_object and I think there lies the problem, maybe the fallback implementation is bugged (I'm still looking for the root cause, could be some activation issue; code will therefore have to wait for later).

And lastly the text size, I'll adjust somehow to the change.

32

Graphics / Re: Issue using RenderTextures on full-screen window

« on: October 06, 2014, 08:36:03 pm »

There are two implementations of RenderTextures, one uses GL_EXT_framebuffer_object and should run smoothly, the other is a fallback which is creating a hidden window and contexts on that hidden window.
I suspect the fallback implementation of being buggy (I just saw how a clear had no effect in my program) and maybe some newer OS handles that window switching a bit differently then when that code was implemented. Nearly noone has a graphics card anymore that does not support framebuffer objects so it does not get tested much.
I would check if those 3 computers support that OpenGL extension (there exists an OpenGL extension viewer or you could use a debugger to see which implementation is selected at runtime) and they have current drivers. What could also go wrong is if some new card is only supporting GL_ARB_framebuffer_object and does not advertise the older, slightly different EXT extension anymore.

33

General / Re: understanding scene graph better?

« on: October 06, 2014, 03:33:00 pm »

There is a text you can read about them: http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D

34

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 06, 2014, 03:17:00 pm »

I think the least intrusive way would be to not hide the asynchronous nature of the clipboard.
- Have a RefreshClipboard method that just requests to set a variable in the class that handles events, if no request is already started.
- When the variable is set in that way the event handler requests the clipboard contents once, then remembers the status of the request.
- Then if more events are received later in the normal flow of the program they are additionally checked for if the clipboard contents are there, if yes it is remembered and so it can stop checking for more clipboard events.
- The user calls some GetClipboard method, this can return either "not ready" so that the user can check on next frame again, or it can give access to the data when its there.

That way no events need to be discarded or hold back and the program can continue without getting unresponsive from delays.
Maybe the 2 methods could be even combined and rerequests ignored until the data is there, if that looks like its easier to use.
On other OS it could just give success at first try if thats possible there.

35

Graphics / Changes in RenderTextures/Texts?

« on: October 05, 2014, 09:54:05 pm »

I just recompiled SFML from the git master version to continue on a GUI library I was writing a few months ago. I had made several versions of an example program for checking if everything looks correctly.
When I recompiled them with the new SFML version some new problems appeared:
1. One version of the program draws sf::Text strings on a sf::RenderTexture and later assembles some screens from them by drawing them onto a sf::Window using only OpenGL, but the text appears smaller now and on one part are some garbage pixels in same color as the text included.
2. Next version draws directly on a sf::RenderWindow using only SFML graphics. And this looks flawlessly, exactly like before.
3. Third version is like the second, but draws on a single screen-sized sf::RenderTexture and then draws that onto a sf::RenderWindow at once, but this appears mirrored along the horizontal axis.

I just want to know, have there been changes to these SFML classes recently, which could cause this? IIRC the smaller text could be from some recent bugfix I read about? And the mirroring, was that a deliberate change, too?
The garbage pixels, I think, may be from a new size mismatch between the changed text size and the same sized RenderTexture.

PS: No code, cause I'll fix that myself if I get the info that its needed.

36

SFML development / Re: SFML Context Management

« on: October 02, 2014, 03:09:45 pm »

I already said somewhere that I'm in favor of ripping out all those hidden contexts.

For a typical single threaded SFML program that beginners and intermediates produce it would be just:
- create (and maybe activate) the window before using any other object from the graphics part
- keep the window object alive (and activated) until you stop using any objects from the graphics part
(- it may or may not be needed for the user to create a context object after that and also keep it alive, depending on if windows continue to contain one, which only depends on how SFML implementers want it done)

For an advanced multithreaded program it would just require additionally to create a context object on each thread that needs to access graphics and keep that alive and active there until the thread is stopped or does not need to access graphics anymore.
Everything else could still be handled internally by SFML although it does not create any hidden contexts anymore.

Therefore, people would not need to be afraid of explicit context management, because it comes down to very simple requirements on the user, which all people are already following with Textures that need to stay alive while they are used for a Sprite and fonts that need to stay alive while used for text.

37

Window / Re: One action per isKeyPressed

« on: September 29, 2014, 08:19:26 pm »

I would not simulate Events that way, because it still can fail to register short temporary key presses and releases and its a waste of CPU time and programmer effort, when there are Events already produced by SFML.

38

General discussions / Re: Different implementation for setFramerateLimit

« on: September 29, 2014, 07:54:09 pm »

Coming from a different angle:
I once read that using sleep inside a realtime application is bad, because it is equivalent to telling the Windows scheduler "I wont have anything to do for a very long time and I dont care when exactly I get woken up, power down the CPU please" and that the right solution for doing a short wait would be to instead block on WaitMessage, GetMessage, WaitForSingleObject, MsgWaitForMultipleObjectsEx or similar function to signal the Windows scheduler "I have urgent work to do soon, but I'm temporarily blocked by this/these specific things, please wake me up asap when they are ready".
I think using SetTimer is a way to achieve this, but there may be some better way.

Btw., the same problem with sleep also exists in sf::Window::waitEvent method, because it does not use the native GetMessage, but instead does Peekmessage, checks Joystick data and sleeps in a loop. If the Event handling could unify handling of joystick and other messages it may be beneficial, even though it is a much less used method than pollEvent. Thats because if internally the joystick handling and message handling could be better combined, the wait from setFrameLimit may possibly be deferred and let intermediate message handling happen while not enough time has passed for that frame, through remembering frame change in display and some clever logic inside the *Event methods.

39

Graphics / Re: Main thread execution pauses waiting on opengl thread?

« on: September 28, 2014, 12:51:24 am »

It looks suspicious to me that you access the circle and the bool from 2 threads without a mutex.
Though if using threads, I would use the main thread only for event handling anyway and move clear, draw, display to the other thread where you access the drawn objects.

40

General / Re: Loading screen - help me understand loop better

« on: September 23, 2014, 04:30:38 pm »

You can improve that code a bit without multithreading, if you dont load all files at once. Just load one file (or even just a bit of a file), check for events, redraw, next ...

41

General / Re: Help with general design

« on: September 23, 2014, 04:21:14 pm »

A button shouldn't need to know anything besides how to check for a click onto it and how to draw itself. Then it returns that result and you can call some function to react if there was a click.
There is a tutorial on how to make a simple gui: http://iki.fi/sol/imgui/

42

Feature requests / Re: sf::Rect extension

« on: September 22, 2014, 12:58:11 pm »

A while ago I replaced a use of sf::Rect in my code with my own that contains 2 vectors. I think its more consistent that way, so there is no more need to manually access both x and y or to look if, for example, one y value was called top, up or height.

43

General discussions / Re: Do you use radians or degrees?

« on: September 22, 2014, 12:33:30 pm »

I think its best to try to avoid angles using vector math, because angles get nearly always fed to some trig. functions and only the result of these is needed. Doesn't apply here, but gimbal lock can be a problem sometimes.
If it cant be avoided then radians are better, because most libraries are using them (following one standard makes it less complicated and needs less unnecessary conversions or even double conversions that would reduce accuracy). They are also not any more difficult to understand than degrees for a programmer.

44

General discussions / Re: Replacement for OpenAL

« on: September 21, 2014, 11:53:15 am »

Why dont you stop arguing already Tex Killer? You painted yourself into a corner and by endlessly repeating the same disproven arguments you will make yourself only look worse without ever being able to convince people of doing unnecessary free work. Just change your own code to use YSE or whatever.

Btw., isn't YSE using JUCE and with JUCE beeing GPL your own code would be linking indirectly with GPL code instead of LGPL OpenAL soft? This would mean you would be "worse off" and need to open source your code, as GPL doesn't even have that dynamic linking exception.

45

Graphics / Re: Visible border around fullscreen window (retina)

« on: August 13, 2014, 11:20:45 am »

I dont know about Macs, but I think thats not a SFML problem, because normally there should be an option in the video driver to either have black bars or to resize when using a nonfitting resolution?