Messages

46

Graphics / Re: Changing the Hue of a Sprite

« on: February 03, 2013, 10:30:42 pm »

It depends on what you want to do with the image and the image itself. For example there are cases where shifting the hue does nothing or nearly nothing (gray and near gray colors) as they have little to no saturation. In a colorful image it actually has a purpose to shift the hue for color purposes. In the case you want to colorize an image a set in stone saturation helps get more consistent results.

Most of my tests when I first programmed it were with color codes and plain colored images,and since they turned fine after extensive debugging I just uploaded the class and forgot about it. I'm gonna make a more extensive testing of the algorithm with more complex images and see if I get odd results.

My use case is almost exclusively hue shifting of normal, multi-colored images,
to get new variations and "looks" out of them.
An example would be to take an image of a flower bouquet and use hue shifting to
get interesting new flower colors, while keeping each flower's differences.

47

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

« on: February 03, 2013, 10:06:16 pm »

What's wrong with pooling and why do you need so much render textures?

Nothing is wrong with pooling^^ That's why I just started implementing it know.
I didn't know I needed it until recently (hence this thread).

My engine exposes certain on-screen types, one of them being drawables ("Bitmaps"),
some of them constructs rendered by the engine which need render textures to look
correctly. And the scripts that my engine will run (not written by me) basically encourage
diligent freeing of unused resources, which is of course harder to deal with at the engine level.

Imagine that you would free all resources making up your current level whenever the player
opens the menu, then freeing all resources related to the menu once the player leaves it again.
That's of course not how you would code your game in SFML, but that's the way the scripts
I will run are coded.

48

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

« on: February 03, 2013, 07:55:17 pm »

Thanks Laurent, it kind of dawned on me that SFML can't really see past openGL and into
the driver implementation. I just thought maybe SFML did some optimizations of its own.

It's also good to know texture size is equal to image size (4bytes per pixel),
and, against my expectations, that there is not much additional overhead for render textures.

creating a texture or a render-texture is a slow operation but it's fine because it's not supposed to happen very often.

Yeah, I know.. unfortunately the way my engine will be used requires frequent
"destruction and creation of on-screen drawables", which right now I map almost
directly to (render) textures, so apart from pooling and reusing resources there is not much I can do.

49

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! ^^

50

Graphics / Re: Changing the Hue of a Sprite

« on: February 02, 2013, 09:35:37 pm »

I don't remember that well, maybe I even used it wrong? All I did was something along

for each pixel x, y do
    sf::Color c = image.getColor(x, y)
    HSL hsl = TurnToHsl(c);
    hsl.Hue += some_shift;
    c = hsl.TurnToRGB();
    image.setColor(x, y, c);
end

Ah, now I remember that some macro epsilon wasn't set. It looked like some sort of float comparison tolerance, so I set it to a very low number (0.0001 or something). Maybe that was the reason? Anyway, it's good to know you wrote that code, maybe I'll come back at you for some support =P (I will need to do image manipulation in software soon).

51

Graphics / Re: Changing the Hue of a Sprite

« on: February 01, 2013, 10:21:44 pm »

Try using something like this HSL colour class(from the sfml github wiki)

getColour() from the sprite, convert it into a HSL colour object, modify the hue, and then convert it back.

The github code comes with functions to convert back and forth between HSL colour objects and sfml colour objects.

I tried the algorithm in the link above, and the results were horrendous. I would show you screenshots if I still had them,
but somehow for me it didn't work out at all.

I ended up using this (first answer) shader to draw the whole texture into a second render texture, and use that instead.
I think using a hue shift shader on each draw call is way too expensive though..

52

Graphics / Re: Shaders: General questions

« on: January 12, 2013, 02:52:30 pm »

Can I assign vec4 with non normalized components to gl_FragColor? (it's for computation, not graphics)

Why not? It's just a bunch of floats. Although they must be normalized to be interpreted correctly I guess.
What would be the purpose of passing non-normalized floats to gl_FragColor? It's not like you can later
sample them 1 to 1 again from the resulting color..

53

General discussions / Re: How do you like to handle Multiplatform SFML projects?

« on: January 12, 2013, 02:42:08 pm »

I've lately discovered I much prefer qmake to cmake...in that I can get qmake to work... plus Qt Creator works very well as an ide it turns out. Lucky for me, since eclipse decided it no longer wants to play nice with the latest version of GCC on windows.

Cool^^ I use qmake+QtCreator for my SFML work too, but that's mostly because almost all of my limited C++ experience so far has been in relation to Qt (work related, didn't use C++ before). I really love Creator and feel very comfy in it, so just using qmake and simply "coding away" was a no brainer. I might switch to something else later though if it limits me in any way (e.g. cross platform deployment).
I tried to get into cmake once, but it seemed very complicated.. I could never wrap my head around either cmake or autoconf for that matter..

54

Graphics / Re: sf::BlendAdd explained...

« on: January 03, 2013, 09:34:23 pm »

I fixed it, should be ok now.

Wow, on GitHub already? YOU'RE THE BEST! Thank you so much!

55

Graphics / Re: sf::BlendAdd explained...

« on: January 03, 2013, 11:03:47 am »

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.

You start with alpha = 0, then you add alpha = 127; how could you get 255 as a result?

Yeah, sorry, that doesn't make sense. I meant to say "when I paint it with half-opacity twice" ^^"

56

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.

57

Graphics / Re: SFML2 nightly how to flip a Sprites Texture?

« on: January 03, 2013, 07:40:00 am »

I don't know if it's really efficient or not, but the way I recently solved flipped textures was in my shader,
something like:

Code: [Select]

vec2 coor = gl_TexCoord[0].xy;
if (flip)
coor.x = (1.0 - coor.x);
gl_FragColor = texture2D(texture, coor);
for horizontal flipping.

The nice thing about this was that I didn't have to fiddle with any Sprite related stuff
(changing the state before drawing, and restoring it afterwards),
and just set a little parameter in my sprite shader.

58

Graphics / Re: sf::RenderTarget and display()

« on: January 01, 2013, 08:54:51 pm »

Ah, I see, thanks.
Yeah, you're right, as far as I can tell RenderWindow::display() flips buffers,
whereas the single-buffered RenderTexture just corrects the Y-axis.

The reason I asked was because I needed a "finalize draw" method that works from RenderTarget,
but it's trivial to do that myself ^^

59

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

60

General discussions / Re: SFML 2 and Qt5 on Windows

« on: December 31, 2012, 03:41:22 pm »

The only important thing is that ANGLE only supports OpenGL (ES) 2, and that SFML still uses old OpenGL 1.x functions.

Just out of curiosity (and because I'm a openGL noob), where are those 1.x functions used? In many places? And how hard would it be to replace them with 2.x equivalents?