Messages

61

Audio / Re: Bug in the Audio Module with listeners?

« on: March 09, 2014, 04:08:48 am »

That tweet.

Given the issue in the audio module I am not surprised at all. And I also agree that this shouldn't have been an issue in the first place. But oh well.

62

SFML projects / Re: Feather Kit - A C++ Game Framework

« on: March 06, 2014, 04:53:47 pm »

Ah, well there is decoupling.

In my system I call it attributes and components where attributes are data and components are logic.

So the attributes are completely detached from any logic and can be freely accessed with the .setAttribute and .getAttribute functions.

Then the logic is a system where you specialise behaviour by inheriting from one EntityComponent class which specifies which entities it should process.

There was before an AlignedEntityBackend which could be used by the entity system to get cache friendly iterable entity data, but that one was coded badly and has now been taken out. I plan however to in a future version rewrite it and incorporate it again. I made a blog post about how the inner workings worked here: http://blog.therocode.net/2013/04/insights-into-the-entity-manager-design-decisions/

Hope that answered your question! It is not on topic, discussion is always interesting!

63

SFML projects / Re: Feather Kit - A C++ Game Framework

« on: March 06, 2014, 04:56:13 am »

Thanks a lot!

Hmm what do you actually mean with "Systems" VS "components"? It seems to me like poeple use a lot of different terminology for these things haha.

Cheers!

64

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 05, 2014, 12:27:42 pm »

Using a listener for 2D space is not as simple as setting it to a position in the z=0 plane. You need 3D spatialization even for 2D games. See this article for more information.

The article only mentions that an additional parameter depth is needed. He always orients the listener to look right at the scene with the at vector being (0,0,1) so real orientation is not needed. However it would indeed be good to in that case add a depth parameter which imo would still make sense for the API.

I don't like having two classes if one does its job perfectly without a bloated interface or too many responsibilities, it only complicates the API. Furthermore, it introduces issues because there is only a single global listener.

Sure if it does its job perfectly without a bloated interface but it doesn't right now. The listener is broken due to the issue this thread is about, and IMO your suggested API which tries to mix the 3D and 2D case by using 3D input but still focussing on 2D-friendliness is not the way to go to have a clean design.

True with issues with a global listener but that is another issue in itself. I would personally scrap the global listener (and a lot of other global things in SFML like the problematic global rendering context) and make a listener class that can be set to be active, but this would need a lot of rework in many parts of the API/style of SFML. This won't of course happen.

This is also why I find it hard to partake in a discussion about an API with you guys, because many parts of SFML are designed with a "user friendly and simple" approach instead of approaches that I would take, so there are fundamental disagreements.

SFML should provide a simple API that provides enough functionality for complex scenarios, and this works well with the new API.

This is what imo my API proposal does as well.

Users that need specific features (such as a simplified 2D sound spatializer front-end) can write their own abstractions on top of SFML. It might even be a candidate for a future version of Thor.

So you are saying that it should _not_ have simplified 2D features now? I thought the whole deal with the standard 3D based API proposed before was that SFML focusses mainly on 2D and should hence aim to make it simple for 2D users?

But anyway, I am getting tired of discussing this and I don't think I can contribute to the discussion anyway due to aforementioned disagreements in how to design an API. Best of luck in fixing!

65

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 05, 2014, 09:23:02 am »

Ah right. Not sure.  Possibly:

Vector2f getPosition() //in Listener2D::
float getRotation() //in Listener2D::
Vector3f getPosition() //in Listener3D::
Vector3f getAtVector() //in Listener3D::
Vector3f getUpVector() //in Listener3D::

And if that is too inconsistent, having 2 getters for one setter, I would again propose having a struct Orientation for the 3D case, leaving the 2D case as proposed.

66

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 05, 2014, 08:48:38 am »

I still think that having an Orientation property should be considered. Even the OpenAL API treats it as a single property, which makes sense since that is how it was meant to be used. So if SFLM decides to _not_ treat it like a property there should be a good reason for separating it imo.

I also had a new idea on how the API could be which is quite different to what has been proposed. My idea is based on the fact that SFML seems to want to have a simple/consistent 2D API but also have 3D spatialisation capability, so why try to come with a weird compromise API instead of actually treating them differently? I got the idea from tank's void setOrientation( sf::Vector2f position ); overload.

What is actually needed for the listener on a 2D scene? Not much. Only positioning (i.e. walking around with the player) and rotating (i.e. the player flips upside down with the whole view). Positioning can be set with a vec2 overloaded setPosition and rotation only sets the angle of the upvector. the at-vector is always looking straight at the scene. This causes proper audio positioning in _all_ cases and there are no cases with undefined behaviour. The functions could be:

void setPosition(sf::Vector2f position);
void set2DRotation(float angle); //this internally sets the at-vector to 0,0,-1 and angles the upvector accordingly

Then for 3D users, there is simply another overload of the setPosition function with a 3D vector, and then a setOrientation(at, up) to set a standard 3D orientation and this one can have an assert for linear dependency. Then for the 3D case, the users get the expected functionality and have full control over the vectors. This group of users will also not be confused by 2 vectors since they are making a 3D application. The orientation function of course mentions which at/up values are forbidden. In other words:

void setPosition(sf::Vector3f position);
void set3DOrientation(sf::Vector3f at, sf::Vetor3f up);

Now there are no weird half-way inbetween functions and the 2D user can use the simple functions and be happy with a safe easy API whilst the 3D users get the expected functionality.

What about backwards compatibility?
Well, that is possible if SFML accepts deprecation. If it does, then the current Listener:: functions can all become deprecated and the new ones can be under Listener2D:: and Listener3D:: which even further emphasises the idea that there are two different ways to go about audio in SFML: 2D and 3D. Which would ease confusion even more, and this would mean that the fix would be fully backwards compatible and SFML could get this issue fixed pretty soon.

67

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 04, 2014, 04:18:04 pm »

Well the eye analogy doesn't really work since when you as a human "skew the coordinate system" by looking up with your eyes but not with your head, you don't hear sounds any different than if you would just look straight ahead do you? But in this case if you only tilt the at-vector upwards and keep the up-vector straight up, the sounds will change.

This is an undesired thing in most cases since you want the sound positioning to make sense, but it is true that there should be no measures to prevent it. It is fully legal as far as OpenAL Soft is concerned. The OpenAL specification however says that it "expects the vectors to be orthogonal" whatever that means.

But just to clarify (although you might already have gotten it) the issue right now makes it impossible to not have skewed audio positioning unless you look completely straight ahead like in Doom and such games.

68

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 04, 2014, 03:57:58 pm »

Yes, and that's a valid point. What I meant with "not clearly" is that both approaches have their advantages and disadvantages, it's not as if the compound blatantly outperformed separate methods. There are multiple design considerations which can have different weight depending on the library or context where they are used.

Yep this is true which is why it isn't the crucial part of the discussion for me. I could live with such an API even if i myself would have done it differently. The issue at hand with broken spatialisation is more important and as long as that is fixed, it would be enough for me.

You mentioned the skewed coordinate system. Out of curiosity, do you know what practical implications this has on sound? Will sounds simply appear in the "wrong" place?

The analogy to the human head sounds straightforward at first, because the front and top of our head point to different directions separated by 90°. But when you only consider the eyes that look at different heights without moving the head, a non-orthogonal system would make sense. I think the eyes are quite a good example: you cannot look straight up or down, so you'll never encounter the linear dependent vectors. Sorry for offtopic

Yeah, I am not sure how it works on the most detailed level, but as far as I've understood, the "listener" is mererely a coordinate system defined by these three vectors (at, up, right) where "right" is calculated to be orthogonal to the other two using a simple cross product. These vectors are analogous to how a normal coordinate system is defined by the vectors: (1,0,0) (0,1,0) (0,0,1). If you have done 3D rendering, these concepts will be familiar to you, it is how cameras work pretty much. Anyway, sound sources are calculated along this listener-space, which will make them be "oriented" after it. So if the space is skewed, the sounds' positions would end up skewed as well.

I am not sure if I managed to explain it well, but depending on how much the skew is (the skew is greater, the closer in angle these two vectors get) the sounds would be positioned a bit wrong. It would probably not be noticed in most cases since sound locations are hard to verify with 2 speakers, but they would be off none-theless. The equivalent in 3D graphics would be if you tried to render a straight square on a skewed 2D space, it would look something like this on the screen:

69

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 04, 2014, 03:15:23 pm »

Laurent's point was that the API with separate methods is simpler for 2D users because they don't need the up vector.

Ah right, well that is a more fair point, even though I personally would not take that approach.

And 3D users can still achieve the whole functionality in a straightforward way. It's not as if the API with a compound would clearly be the better approach even for a 3D sound spatialization library, or that the SFML API limits 3D users in any way.

I would argue that it is for the same reasons as tank mentioned, you wouldn't have a separation of RGB. Object oriented ways teach to make structures of things that are conceptually tied together, and the at-vector and up-vector surely is; the term is "orientation" and that is why you set it as a single property in openAL. There is only SetSourcefv(sourceId, AL_ORIENTATION, eightFloats) and not AL_ATVECTOR and AL_UPVECTOR. That would have cluttered the API.

But true it doesn't limit the 3D users and if SFML would take this approach it would still be usable indeed.

Anyway, I think we can summarize this discussion as follows:

• There is a problem whenever up and direction are linearly dependent, in both past and future. It was already possible to avoid the error in the past.

Correction: It is not only a problem when they are linearly dependent, but also when they are not orthogonal with each other, which is in all other calls to setDirection which does not look like this: setDirection(X, 0, Y).

The only question left is the name of the attribute. "UpVector" would be a possibility, but also "Upward(s)" or something completely different like "Overhead" (but a better word for it). Suggestions?

I still say go with upVector. Everyone knows what the direction of "up" is, you don't need to be into maths to get it. If you can understand what "a vector pointing forwards" is, then you can understand "a vector pointing upwards".

70

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 04, 2014, 02:44:19 pm »

therocode, what exactly is wrong? With the up vector, 3D spatialization will be possible. That was your main point of criticism, wasn't it? Or are you just denying that because you don't like the API design?

Maybe this whole thing is a misunderstanding

No I am not talking about you guys' recent talk about the API, I just replied to Laurent's posts where he said that most 3D cases use a static Y+ up vector and that the 3D sound API is affected by the 2D focus of SFML which are two things I simply disagree with.

As for the API I have stated my opinions already.

71

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 04, 2014, 02:35:43 pm »

No... I'm just saying that 2D represents most of the use cases of the audio module (this is easy to understand... most people use the audio API that goes with the graphics API that they chose, and SFML is often chosen for 2D because of its graphics module -- have a look at the Projects forum and tell me how many 3D projects you find), so this consideration must be taken in account when designing the modification. In other words, if I can design something simpler for 2D then most of SFML users will benefit from it and be happy. Whereas 3D users will still be able to achieve what they want. What's wrong with this reasoning?

The thing that is wrong with the reasoning imo is that the sound stuff claims to be a full 3D sound API with 3D sound spatialisations. It never says anything about being 2D specialised, which made at least me think that it was meant to work properly with 3D, but i guess I was wrong.

True you don't see many 3D projects being talked about on the forum. Maybe because newbies cannot do 3D and that more advanced users have realised the various limitations that SFML poses for more advanced use (context management, and until recently the GLEW issue, and similar topics) and moved on to libraries which does things in a way a decent programmer would expect.

I am just speculating here of course,  but more to the point I definitely think that a sound module which is advertised as capable of doing 3D sound spatialisation should do 3D sound spatialisation properly, regardless of if the library aims for 2D or not.

72

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 04, 2014, 01:32:43 pm »

If you have a static +Y up vector, you are only allowed to set the at-vector to any values where Y is 0.

This is called 2D, and is the main target of SFML

Okay so you're saying that the 3D audio spatialisation API of SFML is designed in a particular way because 2D is the main target of SFML? But you even said  "in most cases (all 2D and most 3D)" which is still plainly wrong because "most 3D cases" are not DOOM controls.

Also I must say that I am personally a bit disappointed since I didn't know that SFML focussed on 2D even in the 3D parts of the API and I would have assumed that it would be fine to use SFML for 3D audio since that is what is says in the documentation/tutorials etc, but I guess if I want to do 3D audio I am better off using something else indeed. Too bad it isn't that apparent though, since people might actually happen to use it for 3D before realising.

73

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 04, 2014, 01:23:22 pm »

Same for the listener orientation: in most cases (all 2D and most 3D) the up vector will be fixed to +Y and never change after that.

Sorry but this is just plainly wrong.

If you have a static +Y up vector, you are only allowed to set the at-vector to any values where Y is 0. In other words, this is DOOM movement where you can't tilt the camera up or down. In any basic 3D navigation application when you do any form of 3D calculations, you have to keep your at-vector and up-vector orthogonal. There is no way to hack around this and there is no way to hide this from the "noobs" who would use this feature. You have to when you navigate the camera set both the at-vector and the up-vector to keep the orthogonality, or the audio space will be skewed.

Hence it doesn't make sense to set them separately. I would find that way more awkward to have to call two functions whenever I set the orientation. It would also be as tank said a security flaw when someone doesn't understand that they have to set both orthogonally and they would only use one of the setters and ignore the other and things would not work properly.

74

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 04, 2014, 09:36:41 am »

Yes, I too would agree that Tank's API proposal is nice. I also agree on the fact that "up" is as semantically descriptive as "at". "at" is where the listener looks at, and "up" is what is up to the listener. Can't get more simple than that I think.

75

Audio / Re: Possible bug in the Audio Module with listeners?

« on: March 04, 2014, 08:23:24 am »

Yeah, well I could implement it for you but the problem is that we surely have different definitions of nice API. I would just go with setOrientation(atVector, upVector) (or even until 3.x to not break the api, i would do setDirection(atVector, upVector = (0,1,0)) and add a corresponding getUpVector() getter.

Your priorities are surely your business and I won't try to meddle with them, but I must say that I am surprised that fixing it or at least adding the info to the documentation is not a high prio since it doesn't involve much coding/writing and as long as it is not done, leaves the 3D spatialisation feature pretty broken imo. But you're the boss.

edit:
Btw, curious question: What was the idea with the setDirection() function in the first place if you know all the limitations with it? What is a proper use case that would not suffer from the skewed space problem?