Messages

31

Graphics / Re: Texture coordinates on GLSL (shaders)

« on: April 14, 2013, 05:38:43 am »

Are you sure you called ".display()" on the renderTexture after drawing to it?

32

Graphics / Re: Rotating Texture

« on: March 03, 2013, 06:05:47 pm »

Just rotate the sprite you're drawing the texture with??

33

General / Re: What IDE should I use?

« on: February 20, 2013, 04:40:03 am »

Geany hardly qualifies as an IDE, because it lacks a lot of basic features such as generating your makefile, code completion, managing lib dependencies, link edition and creating build targets.
It's "just" a text editor with the ability to compile your current .c/.cpp unit into a .o object.
More advanced features are just buttons for which you need to specify the command line callback.

Which is why it's called a "light IDE". It has syntax highlighting, rudimentary code completion, and can "make all" on click as well as custom defined targets.
And since when do IDE's generate Makefiles? That's the build system's job

34

General / Re: What IDE should I use?

« on: February 18, 2013, 05:09:36 am »

Hi!
My primary platform is Linux, and I use both Geany and QtCreator for coding (sometimes a plain text editor too, haha).
While Geany is really light in that it can be described as an text editor with IDE capabilities and syntax highlighting, and is sufficient for C, it isn't as helpful with C++ if you're heavily relying upon context aware input completion (Geany has no context awareness AFAIK).

That's where QtCreator really shines IMO, it has perfect context aware completion and a lot of other nice utilities (like the integration with gdb) and is definitely worth the few Qt dependencies. Although the native build system is qmake, it also supports cmake.

35

Graphics / Re: drawing quad efficiently for Spine

« on: February 17, 2013, 03:56:19 pm »

Great info, thanks for the jump start. Will see how far I can get today. I'm already calculating the vertices, so that is no problem. All I need to do is draw the little bastards!

sf::VertexArray is already a Drawable, so it goes straight into the window.draw() call ^^ Just remember to bind the texture, or pass it as part of a RenderStates instance.

36

Graphics / Re: drawing quad efficiently for Spine

« on: February 17, 2013, 04:35:20 am »

Hm, the way I would do it personally is to create an sf::VertexArray with the number of quads*4 you'll be using (which won't have to be resized since you'll be using the same amount of quads throughout the animation, right?), attach them to the correct texture positions and then update their screen positions as the animation proceeds. This way you can always draw them in one call.

37

Audio / Re: sf::SoundBuffer doesn't discard data on second loadFrom* call

« on: February 16, 2013, 12:48:40 pm »

Ok, it really looks like a bug. Can you please open a new issue on the tracker so that I don't forget it?

kk

38

Audio / Re: sf::SoundBuffer doesn't discard data on second loadFrom* call

« on: February 16, 2013, 12:35:53 pm »

Unfortunately I can confirm this issue.
When the second audio file should get loaded, the console spits the following out:

An internal OpenAL call failed in SoundBuffer.cpp (253) : AL_INVALID_VALUE, a numeric argument is out of range

And then it plays the same sound again.

Adding a .stop() after the pause doesn't help either.

Ah damn, I should have used my debug build, then I would have gotten this message too I think and could have saved myself some fruitless debugging..

39

Audio / Re: sf::SoundBuffer doesn't discard data on second loadFrom* call

« on: February 16, 2013, 10:07:32 am »

You say that the sound buffer is not updated, but you probably mean that the sound that uses the buffer is not updated, right? Does it work if you call sound.setBuffer again after reloading the buffer?

I've tried doing the setBuffer (although that shouldn't do anything I think, because an sf::Sound instance should only ever point to an sf::SoundBuffer object, not the raw sound samples themselves, no?). I also tried calling resetBuffer() before.

This is what I mean:

#include <SFML/Audio.hpp>
#include <SFML/System.hpp>

int main(int, char**)
{
        sf::SoundBuffer buffer;
        buffer.loadFromFile("sound1.ogg");

        sf::Sound sound(buffer);
        sound.play();

        sf::sleep(sf::seconds(5));

        buffer.loadFromFile("sound2.ogg");
        sound.setBuffer(buffer);
        sound.play();

        sf::sleep(sf::seconds(5));

        return 0;
}
 

"sound1.ogg" is played two times on my machine.
Currently I'm working around it by using an allocated sf::SoundBuffer object, which I delete and create again when another sound is to be loaded. I was writing a small and simple Qt app that plays back a user chosen sound on a certain action, so I tried to keep it as simple as possible and was hoping I could just load new samples into the buffer every time the user chose a new sound file.

40

Audio / sf::SoundBuffer doesn't discard data on second loadFrom* call

« on: February 16, 2013, 07:05:41 am »

Hi!

It seems to me that when calling a load function on an sf::SoundBuffer that already has contents from a previous load, it will just keep the old data and not actually load any new samples. Is this intended behavior?

41

Graphics / Re: Tips and hints on how to correctly use glScissor with SFML?

« on: February 15, 2013, 11:20:21 am »

No... I said that each context has its states, not that these states were reseted every time you switched the contexts. Once a state is set in a context, it stays there until it is set again with another value.

Oh ok. I was just confused because I said

Ok, just so I understand you correctly, each render target has its own context
which does not keep the scissor state between context switches. Correct?

And you said yes.. turns out it's actually a no because the contexts
do in fact retain their individual scissor states between switches. (They don't lose it on switch)
So once I specified a clipping box for a context, I don't have to worry about
having to set it again, unless I want to change it.
Conclusively, this means I don't have to call glEnable over and over again,
just once for each context.

Thanks for the clarifications^^

42

Graphics / Re: Tips and hints on how to correctly use glScissor with SFML?

« on: February 15, 2013, 10:01:15 am »

Ok, just so I understand you correctly, each render target has its own context
which does not keep the scissor state between context switches. Correct?

Yes. As I said, each OpenGL context has its own states. If you define and activate the scissor on a particular context, it will be activated and defined only on this context.

Wowow, your wording is still confusing me a little 
So, to illustrate what I understood from your sentence:
 -> Create two contexts (render targets)
 -> Activate context one
 -> Set scissor box A
 -> Do some drawing
 -> Activate context two
 -> Do some drawing
 -> Activate context one
 -> Context one's scissor box from before is now gone due to context switch,
     therefore needs to be set to box A again.

So I would basically have to keep track of each clipping area for each render target
(because openGL doesn't do it for me), and apply it after each setActive() call to restore it.
Correct?

43

Graphics / Re: Tips and hints on how to correctly use glScissor with SFML?

« on: February 15, 2013, 09:35:06 am »

And yes, when you switch the active render-target, you need to set it again because each target has its own OpenGL context with its own states.

Ok, just so I understand you correctly, each render target has its own context
which does not keep the scissor state between context switches. Correct?

But it sounds strange to apply the same clipping rectangle to multiple render-targets.

That wasn't my intention, sorry for being unclear ^^"

44

Graphics / Re: Tips and hints on how to correctly use glScissor with SFML?

« on: February 15, 2013, 05:59:57 am »

sfml 2.0 has it, its worth switching, I don't know if 1.6 has sub rectangling, however

Sfml 2.0, C++:

sf::Rect SubRectangle(x1,y1,x2,y2);
sf::Sprite.SetSubRect(SubRectangle);

Sorry, should have stated it, but I have always been working with 2.0 (never even looked at 1.6)
Your solution is not what I'm looking for =/ I need per render target clipping

45

Graphics / Tips and hints on how to correctly use glScissor with SFML?

« on: February 15, 2013, 03:42:48 am »

Hi!

Since SFML doesn't (yet) have functionality for clipped drawing,
and thankfully my requirements are very low (ie. only rectangle clipping areas),
I intend to use glScissor for that. However, I'm a complete newb in terms of openGL,
so besides calling

Code: [Select]

glEnable(GL_SCISSOR_TEST);
glScissor(x, y, w, h);before every call to window.draw(...) there isn't much I'd know about.
I feel like calling the glEnable every time I draw seems unnecessary (as I will always use it),
but I don't know where the right place would be to call it once.
Also, do I need to call window.setActive() so openGL knows which context to apply
the scissor test to?
And how should I do all this when I'm using render textures in between normal draws
to the screen? Do I need to "refresh" the scissor box for every render target when I switch them?
Ie. -> set scissor box -> draw to window -> draw to other render target
-> scissor box gone, need to set again ?
(Sorry if this sounds confusing, I'm just not very knowledgeable as to how context and state
like this are managed under the hood in openGL)

A minimal example of using glScissor, maybe with an alternating clip box based on some conditional
would be greatly appreciated