Messages

31

Graphics / Why is VertexArray.myVertices private?

« on: February 17, 2012, 10:11:08 pm »

I am wondering why is the myVertices vector private in VertexArray?
It would be helpful if I could loop through it and perform operations on individual vertices, remove them one by one instead of clearing all, etc.

32

Graphics / Example of utilizing VertexArray?

« on: February 12, 2012, 09:54:02 am »

Thank you, I'll try to do that.
The ones I need to rotate are sparks, that get rotated to the direction they are flying to and smoke/flame that are just very slowly rotating to some random direction.

For others I just use a random initial rotation, so all the particles don't look the same.

33

Graphics / Example of utilizing VertexArray?

« on: February 12, 2012, 09:44:09 am »

You can also use sf::Transform and its member function TransformPoint().

Thanks for your reply.

You mean using that instead of having my Particle inherit from Transformable?

Or have it inherit from Transformable, then when myTransformNeedUpdate == true I would manually change each vertices position?

Could you be a bit more specific? I'm quite a newbie in this.

34

Graphics / Example of utilizing VertexArray?

« on: February 12, 2012, 04:15:58 am »

If I may have one more question:

So a particle will be a class having some basic position, velocity, color information, and a sf::Vertex verices[4] array.

If I want to scale, rotate a particle, am I supposed to write my own rotateQuad(sf::Vertex v[4]) function, where I deal with the individual vertices, or are there some SFML functions that can handle transformations that I could use, like sf::Sprite.SetRotation()?

EDIT: Should I make my Particle class inherit from sf::Transformable?
If yes, what do I need to do in order for the transformations to be "linked" with the 4 vertices, so that if I rotate/scale my particle, each particle's vertices' positions will be changed accordingly?

I see in the documentation, a custom Transformable class can be created like this:

Code: [Select]

class MyEntity : public sf::Transformable, public sf::Drawable
 {
     virtual void Draw(sf::RenderTarget& target, sf::RenderStates states) const
     {
         states.Transform *= GetTransform();
         target.Draw(..., states);
     }
 };

But my Particle is not Drawable, the VertexArray is, and for all the particles, there is only one draw call with one RenderStates in it, so if RenderStates contains the transformation information, then I am not sure how to pass a separate RenderStates for each Particle in the VertexArray.

35

Graphics / Example of utilizing VertexArray?

« on: February 11, 2012, 09:52:00 pm »

Thank you, I get it now.

36

Graphics / Example of utilizing VertexArray?

« on: February 11, 2012, 12:02:18 pm »

There are several possible solutions.

Here is one of them:...

Thank you very much.
The only thing I don't seem to understand, is where/how the actual texture is passed or assigned to the vertices/vertex array.

I see that each vertex has its position, color and texture coordinates. Specifying texture coordinates serves as a subrectangle selection from a texture? If yes, where is it told what texture are they dealing with?
If no, I seem to be misunderstanding it.

Some clarification would be much appreciated.
Thanks in advance!

37

Graphics / Re: infinitely repeating background

« on: January 27, 2012, 06:46:34 am »

Hello,

How do I implement an infinitely repeating background that will work well with parallax and camera movement/zooming?

I was thinking about using a small texture with repeating on, and a scaled sprite with an overly large texture rectangle, but it wouldn't be infinite, wouldn't it? And I'm not sure about the math involved in drawing the backgrounds side by side while accounting for camera location and zoom.

FYI, for the parallax, I used a custom Transform passed to window.Render() in which the position of an object is multiplied by a parallax factor and the scale by the zoom factor; and for the camera I used sf::View. The system works quite perfectly, but I am baffled about how to implement the infinite background.

Thanks in advance!  

This is my implementation for pretty much what you said:
Repeating background (starfield, far in the background) with a star_overlay that appears closer, using parallax.

Code: [Select]

void Display_Backgrounds()
{

sf::Sprite current1;
sf::Sprite current2;
if (background_x < -2048)
{
background_x = 0;
part_count++;
}


background_x -= 0.2f * timescale;


if (starfield3_sprite_count <= 5 && bg_anim_forw == true)
{
if (frame % (6 * ts_inv) == 0)
starfield3_sprite_count++;
if (starfield3_sprite_count == 5)
{
bg_anim_forw = false;
starfield3_sprite_count = 4;
}
}
else if (starfield3_sprite_count >= 0 && bg_anim_forw == false)
{
if (frame % (6 * ts_inv) == 0)
starfield3_sprite_count--;
if (starfield3_sprite_count == 0)
bg_anim_forw = true;
}


current1 = starfield1[part_count % 3][starfield3_sprite_count];
current2 = starfield1[(part_count + 1) % 3][starfield3_sprite_count];
current1.SetPosition(background_x, 0 - (camera.Top * 0.1));
current2.SetPosition(background_x + 2048, 0 - (camera.Top * 0.1));
App.Draw(current1);
App.Draw(current2);
star_overlay.SetPosition(background_x*2, 0 - (camera.Top * 0.2));
App.Draw(star_overlay);
}

Since the starfield image is too large for some video cards' max texture, I split them into 2048x1250 segments (that is what part_count is for), and the whole thing is animated (that is what starfield3_sprite_count for).

The parallax effect comes from both the x and y componet's rate of change being directly proportional (the star overlay changes twice as much on both axis (axes?) as the background stars).

The animation implementation might not be the nicest, and the whole thing could be a bit less hardcoded, which I will work on later, but it should be clear enough.

Also I have Star objects generated into a vector in 3 separate foreground layers each with their own parallax constant.

The "infiniteness" comes from using 2 sprites all the time, each the size of the full Window. They both scroll to the left at the same rate, side by side (continuously, without any sign to the user that they are 2 separate images, not one), and when the leftmost goes out of the screen, and the right one fills the screen, you put the left one to the right (or put a continuation of the 2nd image to the right)

Here is a vid from a quite old build, when I was still doing it in SDL.
This only has the animated bg and the layers of star objects (no star overlay):

38

Graphics / Example of utilizing VertexArray?

« on: January 26, 2012, 06:25:34 pm »

Hi,

I have read the documentation for VertexArray, but I am not sure how to convert my current "loop through every sprite in a container and Draw" implementation to it.

I have a vector<Particle>, each Particle has its own Sprite, and every frame I loop through, calling Particle->show(); that does some logic and the Draw calls
(I didn't separate logic and render for these so I don't have to loop through them twice, which would have a performance hit)

From this, how would I go to using a VertexArray?

Thanks in advance!

39

General / Performance: scaling size VS switching textures around

« on: January 24, 2012, 08:51:29 am »

Scaling a sprite doesn't cost anything. Every entity is transformed by a matrix on the GPU, whether it is the identity or a scaling matrix doesn't make any difference.

But, changing the current transform matrix takes time too.

So the best solution would be to move / resize all your particles with the CPU, put them into a vertex array (latest SFML 2) and draw that with one OpenGL call.

Thanks for the fast reply,I'll use one base size texture then. I'll look into the vertex arrays now, I haven't used that before.

EDIT:
A similar question. If there are same sprites that I want to draw, but different color, is it expensive to do Sprite.SetColor compared to dealing with a Sprite set to a pre-colored texture?

40

General / Performance: scaling size VS switching textures around

« on: January 24, 2012, 08:08:21 am »

I understand that between Draw calls if sprites are drawn from different textures, it takes a performance hit, since opengl has to bind to another texture every time.

I am wondering what is more expensive when I want to use the same sprites, but different sizes. Should I pre-make my textures separately, such that SFML/opengl doesn't need to scale them, or should I just scale the same texture, as the texture switching between each Draw call might cost more than the scaling?

(In a context where 300-500 3x3 to 30x30 particles are drawn each frame)

41

SFML projects / SFML Light System - Let There Be Light

« on: January 24, 2012, 01:35:52 am »

Wow, this is awesome, exactly what I need!
Keep up the good work!

Are you planning on making documentation for it?

42

General / SFML 2.0 - CPU/GPU utilization behavior

« on: January 23, 2012, 11:58:47 pm »

You do know that SDL can also use DirectX as a backend? Though that doesn't explain the problem.

The only thing I can say is that you probably have something in the background fighting for the graphic card at the same time or something. Can you do automatic tests? That you hard code in a specific behavior in the application and measure the time there. I.E no matter what that the application will always behave the same. If it acts exactly the same and you get a repeatable performance. Then I am afraid it's in your code sir

If the above case is true then you are facing alternating CPU and GPU bound bottlenecks.

If it's not that, then I rest it on that you have something else running that is using the graphics card.

Thanks for the reply,

The GPU load while I'm not running my program is 0-1%, so I don't think it would need to fight for GPU time. Even if it would, every time I run the SDL build (I am not sure if it uses DirectX or what) it puts ~30% load on the GPU and ~35% on CPU. Regardless of what backend it uses, it would also have to fight for GPU time if something running in the background would hijack the GPU.

To make sure it's not something in my code I will compile one of the SFML1.6 demos in 2.0 (I really doubt it though, I made a very small, simple program when I was first learning SFML2.0 and it happens to that too)

43

General / SFML 2.0 - CPU/GPU utilization behavior

« on: January 23, 2012, 10:59:24 pm »

Thanks for the responses,

I have just updated my nVidia driver, but it doesn't make any difference.
I am not too familiar with how exactly the GPU cache operates, but it doesn't seem to be like something "normal", since in most cases when this GPU overtake performance boost kicks in, it happens within 3-5 seconds from execution, and other times I am running it for minutes, and it doesn't happen (while a cpu core is running on full load, and the frame rate drops below 60).

This project I am working on was converted from SDL to SFML2.0, and it seems like that currently I get better performance on the SDL build. I have tested the CPU and GPU load on the SDL build, and with that the CPU load is around ~35% (in contrast to SFML's 60%+ without the GPU kicking in) and the GPU load is ~25-30% (in contrast to SFML's below 10% without the GPU kicking in). When this thing is triggered in SFML, the performance is much better on the SFML build than the SDL one.

So I am assuming that this thing that sometimes kicks in, sometimes it doesn't is something that should always happen by default.

I will try running it on another computer when I get the chance, see if this is specific to mine.

EDIT:
The reason this bothers me so much, is that I am trying to make my program get 60FPS, and for that I always have to adjust/optimize the particles, that take most of the resources, yet I know that with this thing getting triggered, the frame rate doesn't fall below even 200.

44

General / SFML 2.0 - CPU/GPU utilization behavior

« on: January 23, 2012, 12:07:13 pm »

Hi,

Since I started using SFML 2.0 I sometimes, randomly occurring experienced this strange behavior:
When I am testing performance and removing FPS limits I usually have a constant frame rate (lets say 100FPS), and most of the time it keeps going constantly for several minutes (as long as the program was running).
Some other times however, after some time has passed from executing the program (pretty random, sometimes after 5 seconds, other times after a minute) the frame rate suddenly multiplies by 3-4, and after this random event is triggered, the frame rate stays that high. It remains like that even if I restart the game (not by closing the application, but inside the game reloading every file, reinitializing and restarting everything).

This random occurence seems to be independent of the code (running the same executable, this performance boost might or might not get triggered)

I have tried to investigate what might be going on by running a process manager and GPU-Z for GPU load, and this is what I have found out:

During normal performance, I have a ~60% CPU Load, so full load on one core (I have dual core) ,a bit on the other, and 6-8% on the GPU.

After this performance boost is triggered and framerate jumped to 3-4x the CPU Load goes to around 30-35% (huge drop considering the great frame rate increase) and the GPU load goes up to ~35%.

Feels like initially the CPU is doing everything, and after a while, triggered by something, the GPU goes "alright, let me help you out with that", and takes the load off (and gives a huge performance boost)

I have no idea what causes this, but I would very much like to be in control of it, as if I could always rely on this increased performance it would make things easier.

I am running Win7 x64, nVidia 8800GTS, intel core2 duo CPU, not sure if relevant.

Please let me know if you have an idea of what could be causing this.

Thanks in advance!

45

Graphics / SetBlendMode in SFML2.0?

« on: January 22, 2012, 07:54:20 pm »

Take a look at the RenderStates.
This can be passed as the second parameter to your Draw function.

Thanks a lot, I got it to work now!