Messages

16

Graphics / Re: probably problem with linux nvidia driver

« on: September 01, 2013, 09:33:58 am »

You could try recording an area of your screen using ffmpeg, with eg.:

Code: [Select]

ffmpeg -f x11grab -r 40 -s 800x600 -i :0.0+0,0 output.mkv
Although if your GPU is already weak, the video will lag no matter what, so I'm not sure screen recording is the way to go here..

By the way, have you tried running your application with everything else on your desktop closed? I have found that the jerking goes down a bit when there's not as much load on the GPU.

17

Graphics / Re: probably problem with linux nvidia driver

« on: August 31, 2013, 08:31:40 pm »

I know exactly what you mean. Even though I'm on a Mobility Radeon HD 3650, I always get these "jerks" as I call them. I never managed to get rid of them besides rendering at ridiculously high frame rates.
The vsync implementation in my driver is also broken, it uses a spinlock instead of properly sleeping until vblank (you can see the system load going towards 50% (one full core) with vsync as compared to ~4% without).

18

Graphics / Re: Is there any way to use custom blend mode without recompilling library?

« on: August 31, 2013, 08:23:11 pm »

Why not just clone the repo and keep your personal branch with additional blend modes? Unless Laurent completely breaks the blending code you should be able to keep up with master just fine.

19

Graphics / Re: Clearing only Selected parts of a render texture.

« on: August 31, 2013, 10:40:40 am »

If you want to skip the sf::Drawable/Transformable overhead, you could alternatively simply draw a transparent quad.

20

General / Re: resources

« on: July 29, 2013, 12:27:27 pm »

Well, sf::Texture is a pretty heavy class, but I doubt it would consume that much RAM unless you were attempting to create and draw thousands of them.

Actually, sf::Texture is not heavy not the RAM at all, since textures are stored in VRAM.

21

Graphics / Re: Vertex arrays and diagonal lines

« on: July 29, 2013, 12:18:01 pm »

You have to understand how OpenGL samples from textures. When you specify the tex coords (16, 16), this is pointing to the top-left corner of the texel. Ideally, you'd want it to sample from the center of the texel however, for which you need to specify (16.5, 16.5). This might be the reason why the drawn image you're seeing looks a bit "shifted" to the top left. You could try and add "0.5" to all your tex coordinates.

22

Graphics / Re: Triangle Fan Hex Map

« on: July 27, 2013, 08:00:20 pm »

At what number of hexes would drawing each hex separately become a significant demand on modern video cards?

Honestly, don't worry about it. Unless you're literally drawing millions at once it will not matter. Remember, triangle strips are not there to alleviate the GPU from drawing "less" stuff; a GPU always renders triangles, so your fans are going to be broken up into triangles anyway. The only thing it saves is a little bit of memory bandwidth and transform cost, but as I said, for your demands it is most likely negligible.

23

Graphics / Re: Vertex arrays and diagonal lines

« on: July 27, 2013, 07:42:01 pm »

So what you want is this jagged red outline around your hexagon? Why don't you just add a transparent background to your tileset and draw the quad enclosing the hexagon instead?

24

Graphics / Re: sf::RenderTexture, why is the update method called "display" ?

« on: July 26, 2013, 11:21:05 am »

You should change both to update, to better represent their use clearer source wise.  Pretty sure neither class uses an update method so there wouldn't/shouldn't be any issues.

Just a suggestion for future updates IMHO.

Uh, pls no.

There's nothing worse than a generic "update()" that could be updating any state or none. For a RenderWindow, "display()" is pretty intuitive, and as Laurent said RenderTexture inherits that name for consistency.

25

Graphics / Re: Vertex array - HUGE memory usage and bad performance

« on: July 26, 2013, 11:08:21 am »

The idea is that you use indexing, yes... but you don't advance all attributes at the same pace, i.e. glVertexAttribDivisor. As you probably noticed, there is no way of going around newer OpenGL if you want all the performance you can get . If you use your own VBO for tile rendering you can already drop the redundant color data (-20%). If you are really crazy, you could write your own shader to render the tiles with minimal data. Think about it, you are just iterating through a grid and changing the texture that is applied to each quad along the way. You don't have to provide much besides basic information about the grid structure and the type data at each tile. Haven't done this myself, however it seems theoretically possible (maybe something I might try when I get really bored ).

Ah... Yes, yes, I see. You would provide the raw tile index data, set the attrib divisor to 4 so packs of 4 vertices describing one tile/quad get the same tile index (or is it based on indices, ie. 6 because 6 indices per tile?), and the rest of all the vertex pos and texpos data could be generated on the fly based on the provided vertex id in the shader. For a map with eg. 100x100 tiles, you would only specify a 100x100 big ushort buffer and that's all.

That would be an interesting space/computation trade off (you'd be calculating the same exact data 60 times per second), but for huge maps it might indeed help with memory concerns. Interesting.

26

Window / Re: How thread safe is a sfml window?

« on: July 25, 2013, 08:02:45 pm »

I think I recall having read somewhere that input event handling doesn't work anywhere besides the main thread on at least OSX (confirm Laurent?), so you'd probably be best off doing the rendering in a dedicated thread.

27

Graphics / Re: Vertex array - HUGE memory usage and bad performance

« on: July 25, 2013, 07:51:31 pm »

Hmm yeah forgot that sf::VertexArray needlessly duplicates vertices position data... oh well don't use them myself anyways . Using indexed VBOs you could slash so much off that requirement...

Can you explain to me where these redundant vertices could be slashed off? Having recently implemented a tmx loader in openGL using indexed VBOs, I came to the conclusion that it's not really very viable, because the only cullable vertices would be those where two adjacent tiles on the screen were also adjacent in the tileset, in which case you'd safe 2 vertices per occurance, which IMO doesn't happen that often (as compared to eg. the same ground tile repeated over huge parts of the map).

Also, on the topic of the wasted std::vector memory: If the amount of vertices per tile and the amount of tiles is known before hand, why not just call vector.reserve(count) at the beginning (avoiding all reallocations) and avoid the waster memory?

28

Graphics / Re: Pixel perfect texture blitting?

« on: July 22, 2013, 09:12:51 pm »

Was one of them this one? In any case, if you need full IME/composition support, I guess yeah, you're on your own with either SDL or SFML =/

29

Graphics / Re: Pixel perfect texture blitting?

« on: July 22, 2013, 07:56:06 pm »

I previously used SDL for drawing and event management but it has some flaws like missing keyboard input and other things.

Off topic, but I'm curious: In what way does SDL not have keyboard input support?

30

Graphics / Re: sf::Lines type and anti-aliasing

« on: July 22, 2013, 07:44:52 pm »

I might be totally wrong about this, but isn't this just the issue with lines defined in between pixel boundaries?

Ie. does writing

Code: [Select]

line[0].position = sf::Vector2f(50.5, 50.5);
line[1].position = sf::Vector2f(199.5, 50.5);

instead fix the problem?

Edit: Forgot to add that when doing this, lines need to be defined one pixel shorter (updated my example).