Messages

1

Graphics / Re: setView() performance penalty

« on: May 01, 2018, 11:52:17 am »

Generally for optimal performance you should sort your drawcalls by state changes. Of course, the most expensive ones should be changed the least often. I.e. Context switches (=rendertexture/window), framebuffer (=rendertexture), shader (but this is as far as I know useless with SFML, as shaders are always set again), textures, vertex buffers (if you use any) and then all the small stuff just as matrices, uniforms and so on. In SFML you further have to sort by "depth", i.e. the order you want things to be drawn. However, the order has only to be considered if the two entities somehow overlap.

Especially when you have a lot of overlapping entities, this can become very complex so you should first profile your application to see if there is a need for improvement here. But for optimal performance this is one of the ways to go there.

2

Graphics / Re: Shaders slowing down app significantly

« on: April 16, 2018, 12:04:09 pm »

If you want high performance, you should generally avoid calling create functions or allocating a lot of memory often unless its absolutely necessary. Both the create functions of renderwindow and rendertexture are very heavy as they allocate memory, create a new OGL context and so on. Just do it like suggested above and reuse the once created rendertexture, that's the way the rendertexture class is intended to be used.

3

Graphics / Re: Vertex Drawing Issue

« on: April 10, 2018, 09:28:00 am »

You could also try to increase your tiles (in the texture file) by 1 Pixel around each edge of the tile (like a frame) and fill this 1 Pixel with the same information as the original "edge pixel" had. In your game you set your tex-coords still only on the original tile-coordinates (meaning w/o the "frame"). When OpenGL now samples outside your original tex-coords you do not get a color of the background or the neighboring tile but you basically "mimic" GL_REPEAT behaviour. Another solution would be to use ArrayTextures but thats not possible with SFML or you could use a single texture for each tiletype but this would be not very efficient.

Edit: just saw thats what eXpl0it3r was suggesting in the end. sorry for the double information

4

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: April 06, 2018, 11:14:18 pm »

Would you mind to explain a little bit how you compute the shadow maps for directional lights without any "knowlege" about the geometry (as you basically seem to only render sprites eg. for the tree)?

Btw. the waves and foam of your current version look very nice!

5

General / Re: SFML has HUGE GPU usage

« on: March 11, 2018, 06:50:09 pm »

I would not say this is a bad thing. You essentially do nothing but drawing a shape over an over again, so high GPU usage is in this case even the best case. Although, it is still interesting that you observe this. Usually I would expect that your CPU will bottleneck way earlier in this case, as you only draw very few triangles per draw call. Maybe your driver detects that you never change the shape and kind of caches the draw call but thats just a guess. How many FPS do you get? It could also be that your GPU stays in idle but I think thats unlikely.

6

Graphics / Re: Blur shader confusion

« on: March 09, 2018, 11:54:58 pm »

Is this really what you expect on the CPU?
Maybe I understood you wrong but when you just draw a square or any other shape and then apply the blur shader, the original shape (with maximum "intensity") should always be in the center and fading out around. To me it looks like your CPU version has the same problem as the GPU version but less strongly, maybe because it runs much slower.

Looking at the image you definitly forgot to clear something somewhere. Can you provide a complete minimal example? Probably you will find the error yourself when preparing this minimal example. Is the tail fading out after some time or does it stay forever?

Alternatively start from the SFML example again. Reading your initial post I think you just simply want to apply the blur shader multiple times to get it to fade out more than with only one pass?

7

SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine

« on: March 07, 2018, 03:19:58 pm »

Your project looks really nice!
However, at least for your final game you want to create with your engine you should work on the performance I think. I tried it on my laptop and the graphics are awesome but I get about 5 FPS only with the GPU being utilized at 30% and one of the CPU cores runs at max utilization.
i7 4700MQ + gt755m.

Technically I find your approach to handle sprites as "3D objects" inspiring

8

Graphics / Re: sf::RenderTexture issue

« on: February 23, 2018, 06:11:47 pm »

First of all, your main loop is very strange. Usually one would check all events for one frame and not go through a whole frame for each event - you will certainly get problems here when you later on begin to use more events and react in your game on those events. Look at the tutorials how it is done in a better way.

Regarding your actual problem to be honest I do not have a solution. There are no plausible reasons why it should work perfectly fine without your if statement compared to the case you've shown. I'd suggest to just slowly go through it with the debugger.

9

SFML development / Re: How should SFML handle non-legacy shaders?

« on: February 21, 2018, 03:21:16 pm »

My personal opinion is: skip the legacy stuff. To be honest, whose computer does not support OGL 3(.3) in 2018? The first graphics cards supporting OGL 3.3 were the HD2000 and GTX8000 series (as well as iGPUs from Ivy Bridge on). According to the steam hardware survey, 98,11% (not current values, I looked them up like half a year ago) use a graphics card capable of DX10 and thus also modern OGL. Why not making a survey here in the forums to see if there is really still a need for the legacy part?

I'm using SFML since many years and I actually love its simplicity, especially for beginners. But over the years, I noticed many limitations of the graphics module. For some of those I found posts in the feature requests forum but most of them were rejected because "too modern" or "would not be available to all users because it is not possible in legacy". I understand that you do not want to exclude users without modern graphics card/iGPU but as explained above - are there still such users today? With skipping the legacy part, the API would not get more difficult - simiplicity is one of the main advantages of SFML - but in my opinion would make many things faster, easier and more flexible for advanced users.

I think the current SFML is great for quick prototyping or very small games but as soon as you want to do something more advanced (e.g. (2D) game with more advanced graphics or a (2D) game where generally rendering performance matters) you basically have to recode half of the graphics module just because of the legacy focus. Furthermore you have to be careful when combining SFML's legacy rendering with more modern features (e.g. vertex buffer objects combined with vertex array objects).

Don't get me wrong - I don't want to be SFML a game engine or graphics engine but just suggesting to make the SFML framework more "modern OGL friendly". And the easiest way to do this without crippling the API is to get rid of all the legacy stuff.

If you only want to do legacy stuff, then the current SFML is perfectly fine, there is not much need for improvement, you can do everything you could think of for a small game or a quick prototype. But if you want to do more modern stuff it gets nasty. You have to ask yourself: Assuming SFML 3 would still support all the legacy stuff, would a user of SFML 3 who targets legacy platforms profit from all the planned new features and the greater flexibility regarding modern OGL? Probably not. Would a user of SFML3 who uses modern OGL be somehow limited or confused or have more work to do just because there is this big rat tail of legacy stuff which he does not need? Probably yes. So why not keeping the current SFML for legacy users and for SFML3 focusing on modern OGL only?

10

Graphics / Re: RenderTarget and OpenGL?

« on: February 27, 2017, 12:13:13 am »

You bind the Target by calling sf::RenderTarget::SetActive(), then you set your states, buffers etc. and call the draw function (e.g. glDrawArrays(...)). If you want to mix OpenGl and SFML Rendering you need to reset/push/pop the respective states (see tutorials). Generally you can bind sfml textures and shaders by their bind() function.

11

Graphics / Re: Draw very big tilemaps

« on: January 29, 2017, 02:09:06 am »

Do you rebuild your whole Tilemap every 0.5 seconds? (not sure if I correctly understood your code from above in the correct context)

If so, why? I recommend to only build it once at the start of the game and then, as you already tried, divide your tilemap in chunks, maybe 20x20 Tiles is worth a try to start with. Each chunk would then be represented by a vertex array. Then you iterate over all your chunks every frame and only draw those which are seen (= intersect with your current view). Even though your graphics card is not that powerful, this should be not a problem at all.

Your code from above is (almost) the worst case. You are rebuilding your tilemap every 0.5 seconds and you are drawing the whole map even though most of it is not even seen on screen. Worst case would be if you built your map every frame and drew the whole thing every frame.

12

Graphics / Re: Crash visualization of Diffusion-limited aggregation

« on: January 23, 2017, 12:57:46 pm »

I think your problem is located in this loop:

for (std::size_t i = 0; i < circle_free.size(); i++) {
            for (std::size_t j = 0; j < circle_stucked.size(); j++) {
                //printf("OK");
                float dist = pow(circle_free[i].getPosition().x - circle_stucked[j].getPosition().x, 2) +
                    pow(circle_free[i].getPosition().y - circle_stucked[j].getPosition().y, 2);
                dist = sqrt(dist);

                if (dist <= (r * 2) ) {//here we stuck moving particles
                    sf::Color color = sf::Color(0, 255, 0, 200);
                    circle_free[i].setFillColor(color);

                    //add moving particle to stucked vector
                    circle_stucked.push_back(circle_free[i]);
                    //delete moving particles from vector

                    circle_free.erase(circle_free.begin() + i);
                }
            }
        }

Try adding a

break;

after

circle_free.erase(circle_free.begin() + i);
 

. The problem is, if you erase the element i, and then further iterate through the circle_stucked, your're trying to access circle_free[ i ], which you already deleted an iteration ago.

Therefore, since your moving_particle[ i ] got deleted, you do not need and you should not further check interation with circle_stucked.

Another possibility to solve your problem would be you do not erase/push_back the circles in this multidimensional loop at all, but instead you only process and calculate and then you save all your erase/push_back jobs somehow in a list/vector etc.
After completing this step, you apply your erase/push_back job list.

13

Graphics / Re: Creating Sprite array from a single Sprite

« on: January 18, 2017, 10:32:36 pm »

By having a Sprite Array do you mean for the "chess field" (the black/white squares)?
If yes, why are you not using one Sprite for the whole field?

Regarding the issue with loading the sprites: You just need to have 1 sf::Texture (which will contain your whole Texture/Image/Picture...). Then you create a Sprite for every game entity you have (e.g. for each chess figure) and store them in an array/vector or somehow in another way (e.g. in your game-entity-classes/structs) and call setTexture(....). After that you finally just need to specify the section of your texture which shall be mapped on your Sprite by calling sf::Sprite::setTextureRect(...).

Regarding the isse with the positions: You probably have an Array representing your chess field (and holding information like: On field XY stands figure Z) and you know the size of one of your small sub-fields (black/white square). Then, the position for each sub-field is simply calculated by multiplying the array-index of that sub-field with the size of one of your sub-fields.
For the sprites you can then call sf::Sprite::setPosition(...).

Hope that helps. If not, try to specify where or what exactly your problems are (e.g. what exact issue do you have with loading all your sprites from one file?).

14

Graphics / Re: SFML with OpenGL

« on: December 29, 2016, 12:46:16 am »

Maximum texture size on more or less modern gpus is much larger than 1024x1024.
Since you plan to use modern OpenGl, I assume you won't support too old gpus. Therefore 8k textures or even 16k textures are most likely supported on your target hardware.

For example the IntelR HD Graphics 4000 supports up to 16k.

15

Graphics / Re: Drawing large triangles/sprites is slow | Possible bug?

« on: December 29, 2016, 12:33:59 am »

Maybe you are just Fillrate-limited.

Number of pixels your graphics card has to draw:
With 10 large triangles: 10x800x800/2 = 3.2 Megapixel
With 500 small triangles: 500x100x100/2 = 2.5 Megapixel

So actually in terms of fillrate, 500 of your small triangles are even faster than 10 of your large ones. But with 500 triangles you get more overhead (draw calls) and more load on the rasterizer etc. In the end you get about the same performance.

I don't know if this is the reason for your observed behaviour but for me it seems plausible.