Messages

16

Audio / What unit does OnProcessSamples give me?

« on: February 10, 2011, 10:09:33 am »

It is soundcard dependent. So If you really need to know, you would have to calibrate it (I.e. measure what voltage amplitude creates which digital amplitude, or if you care about sound pressure, you'll have to calibrate the whole system of microphone, preamp and soundcard with a sound source of known volume like a pistonphone)

17

Window / sf::ContextSettings, opengl version hint

« on: February 10, 2011, 10:05:01 am »

I am not sure, but I thought that the purpose of the forward compatibility bit is a stop gap measure by the opengl team, to allow code to still work with the old API.

Forward compatible would mean without the removed functions, "compatibility profile" would mean with the removed functions still available (backward compatible).

However in future, all vendors would eventually drop support for the old functions. In such cases when calling with the compatibility bit set, it would allow a user to use the old functions, but it probably wouldn't work, as the card and drivers would no longer support them.

I am not 100% sure about this though.

That may be the plan, but large vendors like nVidia already stated that they would continue supporting all OpenGL features for all new cards.

Maybe in future, when Laurent upgrade the internal opengl code, we can ignore the compatibility bit in the 3.0++ versions?? and if user require the old functions, they can still request for a 2.0 version. Anyway if a user request a 3.0 version, it would mean they would be making changes to support a 3.0 version, and since they are making changes, it would be highly likely that they would change all code to support it rather than mixing 3.0 with 2.0 context.

What SFML would need is different versions of the rendering code, one for 1.x to 3.0 (as 3.0 still includes all 1.x features!) And one for 3.1+ as the 3.1+ code would not work with GL versions 1.x through 2.x. But I believe a more flexible rendering backend is in planning anyways since it is needed for GLES as well.

18

Window / sf::ContextSettings, opengl version hint

« on: February 09, 2011, 10:24:10 am »

In fact the compatibility bit is set internally by SFML, because I need the deprecated functions. So I must disable 3.1 contexts, that's it.

Oh, ok, that is certainly simpler. Are you still using the begin/end drawing?

19

Window / sf::ContextSettings, opengl version hint

« on: February 08, 2011, 11:23:49 pm »

Ok, that's what I thought. Thanks for clarifying it. But what happens in 3.1 contexts? Deprecated functions are removed, but there's no compatibility profile yet, so what?

If I'm not mistaken, you are quite plainly out of luck (SOL) if you have a system which only supports 3.1 and want to use GL 1.x functions. I presume this is why they introduced the concept of profiles in 3.2 (should have thought of it earlier...). For SFML this means that to be technically correct you would have to do the following:

• If the user requests 3.2+ with compatibility profile, and 3.2 is not available, ask for 3.0 (without setting the compatibility profile bit and mask), since 3.0 supports all 1.x functionality, but 3.1 does not.
• If the user requests 3.2+ without compatibility profile, you have to go to 3.1, again without setting the bit and mask. In this case, the lack of 1.x support should not matter (otherwise a compatibility profile would have been requested)
• When directly requesting 3.1 or 3.0 ignore the compatibility setting, as it wouldn't be valid (or maybe jump to 3.0 when 3.1 is selected with compatiblity)

It's ugly, but I don't think there is any clean way around this. The cleanest solution would probably be to combine mercurios array solution with a hardcoded exception when 3.2 fails and for 3.0 and 3.1 (as they don't support the mask and bit)

Or you could simply decide that you ignore this, as pretty much every graphics card that supports 3.0 also supports 3.1 through 3.3 (except, according to wikipedia the Intel sandy bridge 2000 and 3000 which only support 3.0). Personally though, I think this would be a bad, as you do know that there is a potential problem, and it is not that hard to solve.

20

Window / sf::ContextSettings, opengl version hint

« on: February 08, 2011, 08:27:24 pm »

However if I am to remove the attribute pair:

WGL_CONTEXT_PROFILE_MASK_ARB
WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB

it would work.

Indeed, this stuff seems to be new to OpenGL 3.2. But it seems that the 1.x were deprecated in 3.0. So what happens in 3.0 and 3.1?

P.S: I am not sure if this is intended, but if the creation of a 3.0 context fail, the return value from ContextSettings shows that the context was created with a 2.9 version. Maybe it would be better to report a 2.1 version or 2.0 version

Ah, this is true

3.0 deprecated features, but did not remove any. 3.1/3.2 actually removes them (and deprecates other features). In 3.2 the concept of different profiles was introduced, to allow using removed features when specifying a compatiblity profile.

So, if you specify 3.0, there is no need to use a compatibility profile because all parts of the 1.x standard are still part of the standard (just deprecated, not removed!)

21

Audio / Music Slicing

« on: February 08, 2011, 03:14:25 pm »

really removing the lyrics is almost impossible. The best option is probably to simply subtract the left channel from the right channel (as vocals are usually centered)

22

Feature requests / Double Precision

« on: February 06, 2011, 06:04:53 pm »

I should add that regardless of Sleep(), the functions using clock() I’ve posted earlier did solve my timing issues when playing video.

However, when I turn the audio on, I’m getting latency and I was wondering if sf::SoundStream has any timing issue I should be aware of? Is it using ::Clock ::Sleep or any other timing methods?

Audio latency depends on the buffer size used. But you cannot reduce the buffer size arbitrarily, as a smaller buffer costs more performance (and increases the risk of dropouts). If your audio is lagging behind video, you could get back in sync by delaying video (or vice versa if video is lagging)

23

Window / OpenGL cubes some faces see-through?

« on: February 03, 2011, 10:54:40 am »

Hmm... Even calling PreserveOpenGLStates didn't work. Can anyone help?

You are either using some state, which SFML uses but does not preserve (unlikely), or you are not setting your states correctly in the first place / doing something wrong.

24

Feature requests / Push/Pop GL state

« on: February 03, 2011, 10:51:20 am »

of course you need to call both push and pop every frame. example:

drawOpenGL()
pushAttrib/_preSFML()
drawSFML()
popAttrib/_postSFML()
(drawOpenGL() could also happen here, just never between push+pop)

if you don't do this, your OpenGL state stack will overflow. also if you don't pop the attributes from the stack, what is the point in pushing them?

25

Feature requests / Push/Pop GL state

« on: February 03, 2011, 10:32:50 am »

My program crashes when I call pushattrib(GL_LIGHTING_BIT). What's wrong?

it shouldn't crash... driver error? but you don't really need it, as SFML doesn't use lighting. and the enable state of lighting is already covered by GL_ENABLE_BIT

26

Graphics / RenderImage doesn't work

« on: January 31, 2011, 09:12:40 pm »

pretty sure it's a driver problem. intel graphics chips have incredibly crappy opengl support. on my previous laptop, whenever blending was enabled, all colors were inverted (and it didn't blend  :roll: )

27

Window / OpenGL cubes some faces see-through?

« on: January 29, 2011, 12:08:57 pm »

What about glEnable(GL_DEPTH_TEST); ?

Is that directed at my post? If yes, this is covered by

glPushAttrib(/* ... */  | GL_ENABLE_BIT  | /* ... */ );

respectively

glPopAttrib();

28

Window / OpenGL cubes some faces see-through?

« on: January 29, 2011, 11:06:09 am »

Yes: When preserveopenglstates is enabled, every draw that SFML2 does is wrapped with popping/pushing all opengl state. You can instead wrap your own opengl code (which is probably all in one place instead of many draw calls) with pushing/popping all opengl state. Much more efficient. see: http://www.sfml-dev.org/forum/viewtopic.php?t=1480&highlight=state

29

General discussions / SFML 2.0

« on: January 14, 2011, 07:43:41 pm »

I think implicit batching (i.e. having a renderer which sorts the renderables before rendering) would be a better choice for sfml.

30

Audio / SoundStream Latency

« on: January 14, 2011, 03:43:05 pm »

There's still something that I don't understand though. The idea behind all these examples is that you have a large amount of samples queued, and suddenly want to play new samples immediately, so basically you want to discard the data which is buffered and replace it with the new samples. Am I right?

Not quite. Discarding data/changing buffers after the fact is a bad idea, if it works at all. But reducing the buffer length, will automatically result in lower latency, without any discarding. But there's really nothing you can do SFML-wise as OpenAL simply doesn't support the kind of streaming required (the fact that streaming itself is only possible with polling is a sign of a really really bad API design if you ask me... wonder what the designers of OpenAL were thinking)

First, you have valid data queued and ready to be played, so if you want to get rid of it you must tell the audio system to do so (music.Stop() for example). Secondly, this is not what a sound stream is supposed to do. Streams are continuous flows of data. All the data that you enqueue is supposed to be played, it's like a network connection, what you send is received, you cannot suddenly remove data which is in the pipe and restart with something new.

What does a synthesizer or a continuous stream of dynamically changing music produce? Not individual sounds which can be played one after the other (or just stopped in the middle), but a continuous stream of samples. Individual 20µs samples. Streaming is the only option. Not via OpenAL though, since it isn't designed for low-latency streaming.

So my conclusion is that to do what you describe, I wouldn't use a SFML sound stream at all, this looks totally different to me.

Sorry if there's still something that I misunderstood

I wouldn't use SFML sound stream either, but a portaudio device, which also streams but with a single, small buffer. Still a stream though