Messages

1

Feature requests / Re: The Ability to Pass Floats To/From Shaders

« on: October 24, 2015, 02:17:32 am »

Please calm down and explain your problem.

I am calm, and I did explain the problem.  Gambit then told be about how the Shader interface was changing, and I was satisfied by his answer.

The float components of sf::Color was just another thing that was annoying to me because there was no interface to pass float Vectors in the API right now, and the pull request you just linked satisfies that feature request as well.

Also, I didn't know that GL_RGBA uses 8-bit components before I asked lol.. 

Edit: also yea my title was wrong/misleading, because I was specifically talking about array uniforms, not just float uniforms, sorry about that

2

Feature requests / Re: The Ability to Pass Floats To/From Shaders

« on: October 23, 2015, 02:24:02 am »

Word, thanks for the info, Gambit.   Yea that was what I was planning on doing.  Hopefully someone fixes sf::Color while they're at it.

3

Feature requests / The Ability to Pass Floats To/From Shaders

« on: October 23, 2015, 01:57:30 am »

Lol like... why is this not a feature?  I can't even pass an array of floats to my fragment shader...  What am I supposed to do?  Convert each float to a 32-bit integer via static_cast, and pass 4 pieces of that integer to the shader via the r-g-b-a components of each pixel of a texture, then convert it back somehow in the shader via the sampler2D?  Ridiculous. 

And if I want to use a shader to output something to a render texture, the reverse problem applies because SFML doesn't use floats for components of sf::Color, which is insane.  I mean, I know it's supposed to make it look cleaner or easier or whatever, but Uint8 components just don't make sense and form an unnecessary limitation on the developer.  Why not just store color components as floats in sf::Color, and give the user a better class interface to use either Uint8/float depending on their code?

Or maybe there is just some secret way of doing this in the API that I just haven't found yet.  Maybe someone can enlighten me?

4

General / Re: Is it possible to use SFML just as an OpenAL wrapper?

« on: August 28, 2015, 03:10:11 am »

@k6l2: So the problem is still there with the latest SFML commit?

At the time when I posted that reply that I updated to a fresh clone of the SFML repository, yes.

Also lol... Everyone keeps mentioning my inclusion of rand()... I now feel obligated to explain myself:  I did it to emphasize that it doesn't matter what value the vector supplied to sf::Listener::setPosition is, as long as it isn't zero.  I know full and well that rand() is bad, and I can assure you all that I don't actually use rand() in real code. Example code is supposed to be just that: an example.

It is worth mentioning though, that I am very glad the people here know their shit, and are willing to show newbs the proper path!  Carry on, sirs/madams.

5

General / Re: Is it possible to use SFML just as an OpenAL wrapper?

« on: August 26, 2015, 01:10:15 am »

I'm going to avoid commenting on your choice to use rand() but is it necessary for the minimal example? For instance, does you still have the error if you put a direct value there? If so, that's minimal, and you can leave off the other library 

Hahahah!  You know as well as I do that the rand() call has nothing to do with this..  Also you failed to "avoid commenting" on it   But for the record since you mentioned it, it happens even when I call "sf::Listener::setPosition(20.f, 0, 0);"

It still suspiciously looks like the bug I have linked to.

Which version of SFML are you using exactly? The SFML 2.3.1 release is not enough, I hightlighted that you'd need the latest GitHub revision of the 2.3.x branch

There's no need for workarounds like audio objects before the listener, as the bug has been fixed meanwhile.

Yeah I just checked out the link you sent me.  It does look very similar!  I did a fresh clone of SFML's repo, the version I tested on was on this commit (still version 2.3.1):

fe58971 Mario Liebisch 13 hours ago  (origin/bugfix/xperia-touch) Android: Accept touch events from "multiple" devices

Edit: apologies, I copied the wrong line in git log.  It was here:

c55b8c1 Ferdinand Thiessen 12 days ago  (HEAD, origin/master, origin/HEAD, master) Fixing #935: Secure function against random data return.

6

General / Re: Is it possible to use SFML just as an OpenAL wrapper?

« on: August 26, 2015, 12:04:08 am »

So even after I upgraded my version of SFML, the problem persists.  As requested, here is the minimal complete example:

#include <cstdlib>
#include <SFML/Audio.hpp>
int main(int argc, char** argv)
{
    sf::Listener::setPosition(rand()/(float)RAND_MAX*20.f, 0, 0);
    return EXIT_SUCCESS;
}
 

This results in the previously mentioned AL_INVALID_OPERATION.  I did some testing and found two interesting things about this.

• If I call setPosition(0,0,0) instead of some random value, the AL_INVALID_OPERATION does not occur.
• If I just create an instance of sf::Music (and do nothing with it) before the call to sf::Listener::setPosition, the AL_INVALID_OPERATION does not occur

Thoughts?

7

General / Re: Is it possible to use SFML just as an OpenAL wrapper?

« on: August 25, 2015, 11:10:56 pm »

Oh my bad, it seems I was using an out of date version...

#define SFML_VERSION_MAJOR 2
#define SFML_VERSION_MINOR 1

I will try with an up-to-date build and follow up on this when I get the chance!

8

General / Is it possible to use SFML just as an OpenAL wrapper?

« on: August 25, 2015, 10:48:56 pm »

I'm running an application using another library for drawing stuff to the window, but I really like the audio portion of SFML, as well as a few other parts of the library such as input handling and networking..  Is there some way to initialize just the OpenAL internals without creating a RenderWindow?

I tried just using the API in sf::Listener and I just get a bunch of OpenAL errors which I assume is because the internals are not being initialized properly.

More specifically, when I try calling sf::Listener::setPosition for example, I get a bunch of

An internal OpenAL call failed in AudioDevice.cpp (173) : AL_INVALID_OPERATION,
the specified operation is not allowed in the current state