Messages

16

Feature requests / Re: sf::BlendMode::apply() function

« on: December 23, 2014, 06:17:02 am »

Back when the new system was being implemented, Laurent had suggested that we keep all the OpenGL calls in sf::RenderTarget.

Moreover, apply() should not be there. Let's keep all implementation details in RenderTarget.cpp and the BlendMode structure clean. People who use direct OpenGL calls will not use sf::BlendMode anyway, so I don't see any reason to leave a public apply() function, other than possibly breaking the implementation / state cache / whatever.

However, having a public apply() function would be rather useful, and with proper usage, it will not invalidate the cache, so maybe we should consider adding it back in. Anyone from the core team care to comment?

17

Window / Re: Issue with Retina Display and gl_FragCoord on OS X

« on: December 22, 2014, 09:15:42 pm »

So implementing that first solution was rather easy, so I went ahead and did it (here is the pull request), although you will definitely want to look over it to make sure I didn't do something stupid, as those 7 lines of code represent half of all my experience with Objective-C. I also updated the gist so that the problem and solution are more prominent.

As for supporting points vs pixels natively in SFML, do you think I should create an issue or thread to discuss it, or is it not something that is appropriate for SFML?

18

Window / Re: Issue with Retina Display and gl_FragCoord on OS X

« on: December 22, 2014, 04:32:24 am »

Yes, this problem persists into 2.2, and the scaling factor is updated just fine. I believe I figured out what is causing this issue though. When a window is moved from a low-DPI display to a Retina display, the number of pixels doubles, but the number of "points" stays the same ([urlhttps://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html#//apple_ref/doc/uid/TP40012302-CH4-SW1]this[/url] explains the difference). However, since OpenGL only works with pixels, it thinks the rendering area has doubled and then adjusts gl_FragCoord and other values accordingly. In face, SFML itself has no concept of "points" either, as evident by the fact that value of window.getSize() also doubles once the window switches displays.

So, this seems not to be a bug after all, but rather just some subtleties in how OpenGL and SFML handle the situation. While everything is technically okay as it currently is, I would like to make two suggestion to improve this for the future:

• Trigger a resize event when the window changes scale factor, as that actually changes the size of the window measure in pixels
• Eventually, add full support in SFML for distinguishing between pixels and points. This may be overkill, especially if this only affects OS X (I'm not sure how other systems handle high-DPI displays), but this is needed for "complete" DPI independence.

Obviously, the second suggestion would have to wait until SFML 3.0 because of API changes, but the first one could be implemented now without any issues, and would allow the app to become aware of the change (whereas right now one has to constantly check window.setSize() to detect the change).

19

Window / Issue with Retina Display and gl_FragCoord on OS X

« on: December 21, 2014, 06:10:22 am »

So I was playing around with shaders and I encountered this bug. Basically, when a window is switched between a Retina display and a non-high DPI display, gl_FragCoord (in a fragment shader) begins reporting incorrect values. In this gist there is some example code that can be used to reproduce this issue. Here are some pictures that demonstrate this issue in action.

This first one is what the program looks like when launched on the non-DPI screen:


And this is what it looks like on the Retina display:


My guess as to what is occurring here is that when the application switches into "high-DPI" mode, the screen size doubles, but SFML attempts to hid this in its own API (see here, here, here, etc.), but OpenGL is still aware of the change and changes gl_FragCoord accordingly, so that they now differ from what SFML would report. This explains why above the range of values reported by gl_FragCoord double, as evident by the original gradient being shrunk down to a quarter of the size in the second image. Note that the problem is the opposite if the window is originally launched on the Retina display: then the image displays normally on the Retina display, but if the image is moved to the low-DPI display, then it appears "zoomed in" by a factor of 2.

I have narrowed down the bug to this commit (which makes sense, as it's the one that added support for high-DPI displays). I don't really know how to fix this issue, or if it is even possible. Any ideas?

20

General / Re: Is it possible to embed an SFML game on a site?

« on: August 14, 2014, 07:32:33 pm »

How much work do you think it would take to port SFML to emscripten? Would it require rewriting the entire rendering system or only a few minor changes?

21

General / Re: Still confused about retina support

« on: August 07, 2014, 06:43:13 pm »

Generally, the master branch is kept in a very stable state, so you shouldn't run into any problems while using it, and if you do, you can always recompile from an older commit.

22

Feature requests / Re: ability to use rotated images with setTextureRect

« on: August 07, 2014, 06:23:56 pm »

In my humble opinion, this feature already exists with sf::VextexArray.
What do you think ? Are you against using it ?

There are many cases where an sf::Sprite would be preferred because of the other functions provided by the class, especially the rotation/position/origin ones.

23

SFML game jam / Re: Game Submissions now open

« on: June 04, 2014, 09:51:33 pm »

I also feel that the jam came at a bad time: I was unable to participate because of end-of-the-school-year events. And as others stated, the theme did seem pretty weak. Compare it to a theme like "cold": the latter could be implemented many different ways because it is an anesthetic theme, whereas "puzzle" is a mechanic and naturally limits the kinds of games one can make with the theme.

24

Feature requests / Re: An Implementation for Generic Blend Modes

« on: March 03, 2014, 01:48:01 am »

Warning: Public history has been rewritten!
If you have cloned from my fork of SFML in order to try the new blending feature, you must run the following commands.

Code: [Select]

git reset --hard HEAD~4
git pull

Additionally, the commits are now located on the branch new_blending_api rather than on master. Sorry, about the history rewrite, but things will end up much cleaner this way.


So I have once again updated the code to reflect the discussion here. One important thing to note is that all of the blending changes have been moved to their own branch named new_blending_api. This means that any links to the code on Github should most likely be updated.

Inside the namespace sf, you can omit the sf:: prefixes.

If still applicable, where are these prefixes? If you were referring to the constant conversion functions (which have been moved to RenderTarget.cpp), should the anonymous namespace be put in the sf namespace?

2. We must have a fallback for systems without glBlendFuncSeparate.

Would it suffice if it were supported for the existing blend modes? Then we could adapt the SFML rendering such that if the GLEW extension is not supported, it will recognize those cases and use the old glBlendFunc().

But in general, it's not possible to map the new API with 6 parameters to the simplified one.

Is something more than this required for an adequate fallback?

By the way, are all the new constants really necessary? I didn't look deeply at them, so make sure they are all really relevant, and not just added "because now we can".

I'll investigate that. The question is whether you only want to provide the minimum number of enumerators that is necessary to implement the current blend modes, or at least a few more common ones? Where should we draw the border? It will be more or less arbitrary...

I can imagine a few scenarios where the reverse subtract could be useful, such as, for example, decreasing the amount of alpha in an render texture. If anything, min and max could be dropped as they serve little purpose from a graphical perspective and they also operate differently than the other equations (that is, they ignore the blending factors).

Maybe a

BlendMode(BlendFactor::Type source, BlendFactor::Type destination);

that could be extended by a BlendEquation::Type default parameter in the future?

Yep.

Shall I go ahead and implement this?

BlendMode(BlendFactor::Type source, BlendFactor::Type destination, BlendEquation::Type equation = BlendEquation::Add);

Finally, what is the preferred way of treating long lines in SFML? I didn't find any really long lines in other source files, so I just assumed a reasonable style with the long lines here, here, and here.

25

Graphics / Re: [2.1] Can't get PNG transparency to work

« on: March 02, 2014, 06:20:02 pm »

Code: [Select]

export LIBGL_ALWAYS_INDIRECT=1

That line is most likely the source of the problem. Doing a little research, it seems that it drops OpenGL support back to 1.4 (lots of information on it here), and I believe SFML needs at least OpenGL 2.0. Can you add the following line to your code and report back the results.

sf::ContextSettings settings = window.getSettings();
std::cout << "version:" << settings.majorVersion << "." << settings.minorVersion << std::endl;

26

Feature requests / Re: An Implementation for Generic Blend Modes

« on: February 28, 2014, 03:27:32 am »

I finally got some time to work on this, and I just pushed the code to Github. Does that look more like a proper SFML API, Nexus?

The only thing that concerns me is the type sf::BlendFactor::BlendFactor and sf::BlendEquation::BlendEquation. In your post you make is seam like they can somehow be shortened to f::BlendFactor and sf::BlendEquation:: respectively, but I don't know how to do that without remove the namespaces.

Also, I found quite a few tabs in other files, so I went ahead and changed those to spaces.

EDIT: Updated the test program to work with these changes.

27

General / Re: Bug found in thors ConcaveShape

« on: February 20, 2014, 03:09:22 am »

Can you provide a SSCCE so that others can test the code in question? Otherwise, it ends up just being guesswork...

28

SFML game jam / Re: SFML Game Jam 2 - Post Mortem

« on: February 07, 2014, 02:33:55 am »

I have been working my way through the games (it takes awhile because I need to compile everything from source), and I really have to say good job to all those that made games; it's been a blast playing each game and how they incorporated the theme. 

Personally, this is the first game jam I have ever participated in, and in fact the first game I have brought to a playable state (which is actually rather sad, I have been programming for years... ). Sorry to all of those who have use Windows, as I have never done any development for it and don't know how easy it would be to get my game working on it.

Thanks to the SFML community for this great event. I can hardly wait until May 30th. 

29

Feature requests / Re: An Implementation for Generic Blend Modes

« on: February 06, 2014, 12:31:16 am »

The functions equationToGlConstant() and factorToGlConstant() should be private (or even better: global in the .cpp file), apply() should cover the use cases in the SFML API.

They are already private. I guess they are actually better suited for file scope, though.

I'm not sure if we need all the encapsulation... A simple struct with public members is easier to handle. I doubt that we need to restrict read access or do sophisticated work in the setter methods, so that the encapsulation would pay off.

I always thought that if you have member functions, then you should make it into a class, although it really does seem like overkill in this case.

The members of the class should be of the corresponding enum types for type safety, and not Uint32.

I was using the same trick that sf::Style used to enforce scoping and avoid polluting the namespace. There appears to be no way enforce scoping and type safety in C+03 (if I'm wrong, please correct me). I can hardly wait until SFML moves to C++11 so we can get enum class, among other things.

Concerning the constructors, the user can have using namespace or namespace aliases to get rid of the long scope names. A 6-parameter constructor will be enough initially, it's still possible to add more constructors later. Providing constructors that take default parameters has two problems: Default values may not be obvious, and you can call the constructor with a number of parameters that is not meaningful (e.g. 4, specifying alpha src factor but not alpha dst factor). Named constructor idiom (i.e. static factory functions) are also a possibility in the long term, to make certain parameter combinations more expressive.

About the default constructor, it would mainly add a little convenience. SFML itself always initializes blend modes explicitly, and up to now every user had to do it (because enum variables are uninitialized otherwise). However, a default constructor is meaningful from the perspective that SFML always uses alpha blending unless specified otherwise.

I'll work on doing that.

• You sometimes use tabs, replace them with 4 spaces

Sorry, my editor's default is tabs (as that is what I use for my projects), and sometimes I forget to change it.  :-[

• The CMakeLists.txt file seems to contain whitespace changes... are those CR/LF? Did you make it more or less consistent? :)

I don't remember making those changes on purpose, but they appear to make it more consistent (they used to end in LF, now they end in CRLF). It appears that this is gedit's default behavior to change line endings to be consistent.

Well, I just realized that I definitely should have used a feature branch for this rather than committing straight to main. Any advice on how to fix this from those well versed in git (I already pushed to my GitHub SFML fork)?

30

SFML game jam / Re: Website Status

« on: February 03, 2014, 03:39:45 pm »

Yes the maximum length is 20 characters, . . .

I really liked the full name, but I guess I can settle for just simply "Shielding 114".

On another note, I have had some trouble formatting my description using BBCode tags. What "basic BBCode tags" are supported? Specifically I am interested in for the headings in my description, but it just doesn't seem to work (the tags aren't processed and [b">[/b"> is displayed instead).

By the way, thanks for creating the website. It really is great having it.