Topics

1

General / [Solved] [Linux] How do I make cmake configure/install the pkg-config files?

« on: October 13, 2013, 02:14:58 pm »

I apologize if this has been posted before. Being a cmake noob, I tried everything I could think of:

Code: [Select]

cmake INSTALL_PKGCONFIG_FILES ..
cmake SFML_INSTALL_PKGCONFIG_FILES ..
cmake BUILD_SHARED_LIBS:bool=true INSTALL_PKGCONFIG_FILES:bool=true ..
cmake BUILD_SHARED_LIBS:bool=true SFML_INSTALL_PKGCONFIG_FILES:bool=true ..

Frustrated, I just gave up and moved the pkg-config generating code out of the conditional clauses in CMakeLists.txt (and voila, I got my .pc files), but since I'm helping someone else install these I'd still like to know, how do you properly tell cmake to generate the pkg-config files?

Also, why aren't they generated/installed by default on Linux?? In two years I have never come across a library that doesn't automatically install those.

2

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?

3

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

4

Graphics / Couple questions regarding sf::(Render)Texture performance

« on: February 03, 2013, 05:53:48 pm »

So, I have come to the point with my engine where most of the infrastructure is in place
and I can slowly start looking at actual performance. Only now did I notice how big the gap
in time needed is between allocating normal and render textures (I am using render textures
all over the place, so this really shows).

As a first step, I let this code run to get some first numbers. Here are my results on
my laptop's "Mobility Radeon HD 3650" (all times in microseconds):

Creating 4 512x512 RENDER textures
0 : 348745
1 : 74412
2 : 77889
3 : 73580
Freeing took: 45563
 
Creating 4 512x512 textures
0 : 174984
1 : 17
2 : 17
3 : 16
Freeing took: 12156
 
Creating 4 512x512 textures AND render textures, interleaved
tex  0 : 171275
rtex 0 : 75883
tex  1 : 52
rtex 1 : 79667
tex  2 : 51
rtex 2 : 73639
tex  3 : 49
rtex 3 : 76513
Freeing took: 40397
 
Creating 4 512x512 textures with immediate free
0 : 173745
1 : 170852
2 : 170081
3 : 167905

 
Uploading 512x512 image data 4 times
0 : 3977
1 : 741
2 : 681
3 : 464

 
Downloading 512x512 image data 4 times
0 : 6717
1 : 2428
2 : 2327
3 : 2374
 

This showed me a couple things, namely:

• When allocating normal textures in series, all allocations after the first one are very fast
• Allocating render textures in series bears no speedup
• Allocating render textures in between normal texture allocation doesn't reset the speedup
• However, freeing normal textures seems to reset the speedup
• Using an image/texture pair over a render texture
  (ie. render locally and upload on each update) is actually viable

The reason I say image+texture might be viable is because the upload times aren't big enough
to cause frame drops if only a handful are being updated each frame (at 40-60 FPS), while the render texture
would induce a massive frame drop on creation, something that image+texture wouldn't suffer from (I think).
Still there are parts where I absolutely need render textures.

Due to the high cost of render textures, and the convenient fact that although they will be
allocated and freed pretty often, the allocations mostly happen with the same repeated sizes
(ie. same sized render texture will be requested repeatedly) in my engine, I decided to implement
a sort of render texture cache/pool mechanism where an x amount of last "released" render textures
are retained for reuse by the next call that requests an rtexture with the same size.

So now a couple questions both in relation to normal and render textures arise,
as I have had no previous experience with graphics
programming prior to SFML (except software vector graphics with cairo/Qt),
and am therefore pretty oblivious to the intrinsic parts of openGL:

• What are other "speedup blockers" that I should be aware of, which slow down texture allocation?
• Are the numbers I am getting actually valid (ie. when the texture 'create()' call returns,
  has it really been created), or is there some "command buffer" that only gets flushed on certain events (eg. first access)?
• Regarding VRAM, how big is the memory usage of normal and render textures?
  How many would approximately fit into, let's say, 256MB?
• Is memory usage of textures directly proportional to their pixel count?
  Ie., is the space a 200x200 texture occupies in VRAM exactly 4 times the amount a 100x100 texture uses?
  And how about render textures?

Those last questions are important to me so I can make an estimate on how many render textures
to pool.

Thanks! ^^

5

Graphics / sf::BlendAdd explained...

« on: January 03, 2013, 08:03:37 am »

Hi all!
I was under the impression that I understood how BlendAdd works... but I don't apparently.
Take this testcase:

sf::RenderTexture source;
source.create(400, 400);
source.clear(sf::Color(255, 0, 0));

sf::RenderTexture target;
target.create(400, 400);
target.clear(sf::Color(0, 0, 0, 0));

sf::Sprite sprite(source.getTexture());
sprite.setColor(sf::Color(255, 255, 255, 127));
target.draw(sprite, sf::BlendAlpha);

sf::Color c = target.getTexture().copyToImage().getPixel(200, 200);
qDebug() << c.r << c.g << c.b << c.a;
 

(replace qDebug() with your favorite out stream..)

We create a source texture, fill it with 100% opaque red.
Then we paint the source texture over the (0, 0, 0, 0) cleared
target texture, with opacity set to half (127) in Sprite::setColor().

Now, in using BlendAlpha, everything works as expected:
"127 0 0 127"
The opacity halves the red color value, and it is painted over the (0, 0, 0, 0) pixel.
The alpha value itself(!) remains unchanged, it is still 127.

Now, change the BlendAlpha above to BlendAdd. What happens is:
"127 0 0 63"
This is very unexpected. I was thinking the red value would get halved again,
the alpha would remain unchanged(!), and everything would just be added
to the (0, 0, 0, 0) resulting in (127, 0, 0, 127), but apparently, for some reason,
the alpha is multiplied by itself (ie. halved too)? How does that work, is it openGL specific?
And how could I possibly work around it?
What I would like to achieve is to have the target texture at full red (255, 0, 0, 255)
when I paint it using BlendAdd and half-opacity red.

Thanks.

6

Graphics / sf::RenderTarget and display()

« on: January 01, 2013, 04:34:15 pm »

Just a small confusing thing that I noticed, but why is 'display()' not a pure virtual function
of sf::RenderTarget? It has the same signature in both RenderTexture and RenderWindow o.o

7

General discussions / sfml + librubberband: a small experiment

« on: December 29, 2012, 10:28:56 am »

Hi everyone.

I recently did a little experiment of trying to inject librubberband into sfml. For those of you that don't know, this library is for time stretching/pitch shifting, and what I wanted to achieve was true pitch shifting, ie. not just 2x faster playback at 2.0 pitch. What I was able to do so far (not much lol) is on this github fork ("rubberband" branch). Basically, you can load up a sf::Music, set the pitch, and play it back.
What doesn't work:
 - Changing pitch safely during playback
 - (Probably) seeking

Also, there's a weird sound fragment coming up when a looping track rewinds to start.. don't really know yet where that's coming from. The quality is.. well, not too good, but we get this much without doing any previous preprocessing-pass (pitch is shifted on the fly). I could try and add a pre-pass, but that would delay playback by a couple seconds, which is not nice. Also, I will need to try out some other fine-tuning parameters for rubberband.

So, is there anybody else out there who ever trying getting correct pitch-shifting working on sfml? Or is there possibly a far easier way I just overlooked all the time?
I think I really do want this feature (for myself), so I might work a bit more on it later (also for sf::Sound). I'm not really sure what to do next because I have absolutely no experience in digital audio. =P

Edit:
Oh yeah, actually I was hoping that sfmidi would work with my changes out of the box, but somehow it doesn't seem to work at all. The way I understand it, sfmidi preloads the entire audio data into RAM, and then just feeds that into the stream.. is this wrong? I can't seem to figure out what's wrong..

By the way, because I absolutely suck at build systems (qmake is the only one I barely manage to use), I didn't integrate librubberband via cmake or anything, so when you link against the SFML libraries built from my tree, make sure to add "-lrubberband" to the linker flags.

8

Feature requests / Non-const access to RenderTexture's texture?

« on: December 26, 2012, 06:21:23 pm »

Hi!
I'm not really sure if there is a deeper meaning behind RenderTexture's getTexture() call only returning const
references, but it is something that I keep having to work around.
Because almost all textures I use must support being rendered to,
they're RenderTextures by default. This however makes things like
initializing from image files, where I have to create a throw-away texture,
unnecessarily wasteful, and some things, like setting repeat mode,
apparently impossible (?).

Is there a technical reason why the internal texture cannot be manipulated
like a usual texture?

9

Window / Is Xlib fix for threading still relevant?

« on: December 24, 2012, 09:20:25 am »

Hi! I recently started working with SFML, and I must say I enjoy it very much^^

When I split off event handling in my project into a separate thread,
all sorts of weird would happen, from bad X request errors to hanging in a window.clear() call.

This patch fixes those issues, but I was wondering if I should even create a pull request for this,
as it seems the relevant parts will soon be replaced by xcb anyway?