Bullet Hell performance and optimization problems

[Ashenwraith]

I see.

Unfortunately, I don't plan to add compressed texture formats to SFML.

I'm curious why that is.

DDS has made so many strides at the forefront of graphics tech with new improvements in quality.

Now with YCoCg you can have near lossless, but even good old DXT 1 and 3 have are optimized to where you no longer have to fear artifacts.

SFML doesn't support 8bit, but it's also not going to support DDS?

32bit pngs are not very useful for making any kind of an optimized 2D game.

[Laurent]

I'm curious why that is.

Because nobody needs that except you
This is not a feature, this is an optimization. And my point is view is that an optimization should not be written unless it is really needed, so I'll wait for a little more feedback like yours before deciding to support compressed textures.

[Ashenwraith]

You might not be able to use a single sprite

Why not? You should definitely be using a single Image instance since its all the same image, but you can also use the same Sprite instance. Just set the values on the sprite before drawing it.

Because most people use their sprites to store their position/transformation and other data. If you are constantly changing it then it needs to be stored somewhere else.

[Ashenwraith]

I'm curious why that is.

Because nobody needs that except you
This is not a feature, this is an optimization. And my point is view is that an optimization should not be written unless it is really needed, so I'll wait for a little more feedback like yours before deciding to support compressed textures.

Well honestly I don't think most people know about it because they haven't made a game with a lot of 2D assets/art. It's sort of necessary because you will hit a wall with 32-b png when you grow out of pac-man/mario clones.

The Holy Spirit project is one for example that could benefit a lot from dds compression (whether they know or not I'm not sure), but they don't even have an artist last I checked.

[SuperV1234]

By commenting the Draw instruction, the game handles 20000 bullets without slowdowns.

Is it a SFML limitation, or is there any chance I'm doing something wrong drawing the sprite?

I'm not really sure about what I'll say, because I can't open your code file (Ubuntu, so C# is hard to read).

But, what I understand is that you are not drawing all your sprites in one block. I think that SFML2 was optimized for such things. If you are drawing some sprites and doing others things, you are not using SFML optimization.
Can you show us your main loop and the place where you are doing the drawings ?
I usually do updates of all my objects, then drawing of all them.

I'm using SFML 1.6 because I had trouble rendering text with the SVN version.

My rendering code is a for loop, which does this:

Code: [Select]

public void Tick()
        {
            for (int i = Entities.Count - 1; i >= 0; i--)
                Entities[i].Tick();  
        }

Entities.Tick(); basically means Entities.Update(); Entities.Draw();

So it's taking a single entity, updating it, drawing it, then passing to the next entity.

[Laurent]

Well honestly I don't think most people know about it because they haven't made a game with a lot of 2D assets/art. It's sort of necessary because you will hit a wall with 32-b png when you grow out of pac-man/mario clones.

The Holy Spirit project is one for example that could benefit a lot from dds compression (whether they know or not I'm not sure), but they don't even have an artist last I checked.

I agree, but I'm just waiting until people actually need it. There are so many things that I can do before it happens...

[Mindiell]

Entities.Tick(); basically means Entities.Update(); Entities.Draw();

So it's taking a single entity, updating it, drawing it, then passing to the next entity.

Right, what about Updating every entities, then drawing each entities ?
Something more like :

Code: [Select]

for (int i = Entities.Count - 1; i >= 0; i--)
                Entities[i].Update();
for (int i = Entities.Count - 1; i >= 0; i--)
                Entities[i].Draw();I'm not sure (Laurent ?), but I think it would be better to draw everything in only one pass, while doing nothing else...

[Laurent]

I'm not sure (Laurent ?), but I think it would be better to draw everything in only one pass, while doing nothing else...

I don't think that would make a difference, actually.

[Ashenwraith]

I'm not sure (Laurent ?), but I think it would be better to draw everything in only one pass, while doing nothing else...

I don't think that would make a difference, actually.

What about drawing the bullets as sf::shapes or even points?

Are there hardware optimizations for that?

[Laurent]

What about drawing the bullets as sf::shapes or even points?

Are there hardware optimizations for that?

It wouldn't help, unless its computer is limited by texture operations, which is probably not the case.

[SuperV1234]

I updated to SFML 2 and now it handles around 13000 bullets at 60FPS. Do you think I should spend more time optimizing or should I start working on the game itself?

[Laurent]

You should definitely work on the game. Optimizing something that is far from being complete is a waste of time.

[Ashenwraith]

I updated to SFML 2 and now it handles around 13000 bullets at 60FPS. Do you think I should spend more time optimizing or should I start working on the game itself?

You have to ask yourself if it it's worth it and motivates you to get it done.

If it's bugging you a lot because your bullet hell feels like bullet boring than work on it, but...

A lot of people like to at least have a skeleton of a game to play with and improve.