Messages

1

Feature requests / Re: Support for custom shader attributes

« on: October 09, 2015, 05:46:24 pm »

Since OpenGL 3.0 and thus GLSL 1.30, the built-in attributes and matrices aren't available any longer.

Exactly what I'm running into.  OpenGL 4+ (I think?) has the layout specifier, which may work with Shader as-is, but of course it requires OpenGL 4+.  glBindAttribLocation has been core since 2.0, as long as shaders themselves.

2

Feature requests / Support for custom shader attributes

« on: October 09, 2015, 04:58:21 pm »

Regarding this comment on the topic "Vertex Attributes on shaders":

This is not a bad idea, but I don't think that it fits in SFML.

Just wondering whether this stance has changed any, since it's quite an old topic, apparently pre-2.0, and in the meantime there's been discussion of several other enhancements to sf::Graphics, including shaders. 

I've made similar modifications myself and noticed that any decent implementation practically requires direct modification to the Shader class, because it needs the shader program name m_shaderProgram after it's created but before it gets compiled:

Active attributes that are not explicitly bound will be bound by the linker when glLinkProgram is called.

Binding them afterward has no effect until you relink the program, which sf::Shader doesn't support (compile() destroys any existing program), so subclassing Shader isn't really an option.  On the other hand, writing a new Shader class from scratch would duplicate a lot of code, and wouldn't integrate with the rest of SFML.

The commit is here pending a pull request.


TL;DR: Yes, it's not extremely useful outside of "wrapping OpenGL," but it enables the use of custom shader attributes where needed, while taking advantage of the existing class and features without duplicating code.

3

Audio / Re: Can't play short .OGG files

« on: March 26, 2015, 09:05:10 pm »

Thanks for the quick answer.  

EDIT: If the issue is in file handling, perhaps as a workaround I'll just add PhysicsFS to my project a little sooner than planned.  I never did like working with fstreams.

4

Audio / Can't play short .OGG files

« on: March 26, 2015, 07:04:30 pm »

I get the error "Failed to open Vorbis file for reading" whenever I try to play very short (3-4 seconds) .OGG files.  I can play them without issue in other software, and SFML is able to play longer tracks from the same set (encoded in the same batch as the shorter files, with the same software and settings, which is why I think it's to do with the length).

I'm using SFML revision 7b4610b55b from GitHub.  The specific files I'm having a problem with are attached if anyone wants to examine them (lightstroke.ogg and darkstroke.ogg), along with a slightly longer track (6 seconds) that does work (gameover.ogg).

Has anyone else noticed this problem, or have some ideas what might cause it?  I don't really want to go with WAV, but if it's necessary....

5

Feature requests / Re: Make Transform extensible with "protected"

« on: March 07, 2014, 09:57:59 pm »

We recently discussed the utility of sf::Transform for 3D: See here.

As far as I knew, you (collectively) wanted to leave that discussion to the Shader topic and start a new one for Transform.  It just took me a while to remember that and do it. 

And making variables protected is not really the way to go; it exposes implementation details and implies that the class is designed for inheritance, which it is not.

Well, the idea was that it's a header-only change, so it should still work with existing SOs/DLLs (unless you have a really funky compiler, I suppose).  Long-term, I think a new constructor/setter would be preferable.

What do you need it for?

The short version:  for 3D, of course.  But! before that turns you off to the idea, hear me out.

Yes, I know SFML is designed for 2D, and does a great job at it.  As it stands, however, with a few changes it could "support" (i.e. provide the means to use) 3D without fully having to "support" (i.e. provide library code for) it.  I'm just talking about a little more user control over what goes on; the majority of the graphics module shouldn't even need to change. 

The problem I find is that classes like Transform and View are integral parts of the pipeline to RenderTarget, but they're closed off to the point that you can't really hook into that pipeline.  They (especially Transform) could be modified to keep their normal behavior by default, preserving backward compatibility, but also let the user fine-tune them as needed.  (Using direct OpenGL calls is a possibility, but that has its own pitfalls interacting with a framework. )

I'm open to hearing other ideas, but I saw this as the "simple" solution.

6

Feature requests / Make Transform extensible with "protected"

« on: March 07, 2014, 08:20:31 pm »

I propose changing the "private" in sf::Transform to "protected":  this would let users extend Transform to access the matrix data for specialized purposes (3D, color effects, etc.), but shouldn't break the library's internal uses of it.