C++ Library for 2D Games?

[B1N4RY!]

[QUOTE=Random112358;26709389]If you want complete freedom I suggest OpenGL. I have used it for a bit and it really is very good and you can pretty much do anything.

Also there are a load of sites dedicated to OpenGL as well.[/QUOTE]

I don't think OpenGL is a good idea for a beginner.

[backwardspy]

I also recommend SFML. Even when you decide to move on to OpenGL, you still can (and probably should) use SFML for your window handling, image loading and so on!

[Niteshifter]

It's not that bad to start out with openGL (it's how I did it). It can be a steep learning curve though.

[Jookia]

[QUOTE=Shotgunz;26719957]The only reason I use SDL is because I'm OCD about standards.[/QUOTE]

First of all, SDL isn't a standard. Second of all, OCD isn't a verb.

If you're using C++ to do OOP, use SFML. Otherwise, use SDL.

[Z_guy]

[QUOTE=q3k;26727790]SDL if you want raw speed[/QUOTE]
SFML is faster than SDL, mostly because SFML uses OpenGL and SDL uses software blitting.

[Catdaemon]

[QUOTE=Z_guy;26730496]SFML is faster than SDL, mostly because SFML uses OpenGL and SDL uses software blitting.[/QUOTE]

I'm pretty sure the blitting is accelerated. But it's still not as fast as fast as SFML.

[q3k]

[QUOTE=Z_guy;26730496]SFML is faster than SDL, mostly because SFML uses OpenGL and SDL uses software blitting.[/QUOTE]

Nope. I wrote a program which displayed multiple (10^4) short lines at each frame, and SDL was way faster (20FPS) than SFML (3FPS or so).

[hexpunK]

I'd go with SFML if you are a beginner. I still know barely any C++, but SFML made a lot of sense to me. Might be because I was coming from Java (OOP all up in my education).

[Z_guy]

[QUOTE=q3k;26731242]Nope. I wrote a program which displayed multiple (10^4) short lines at each frame, and SDL was way faster (20FPS) than SFML (3FPS or so).[/QUOTE]
Do you still have the code for that? I'd like to see it.
Also, [url]http://www.sfml-dev.org/forum/viewtopic.php?t=43[/url]

[Catdaemon]

[QUOTE=q3k;26731242]Nope. I wrote a program which displayed multiple (10^4) short lines at each frame, and SDL was way faster (20FPS) than SFML (3FPS or so).[/QUOTE]

I can pretty much guarantee that's your fault.

[Random112358]

[QUOTE=B1N4RY!;26728105]I don't think OpenGL is a good idea for a beginner.[/QUOTE]

I started out on OpenGL, granted it is not the easiest way but it really makes you understand what you are doing.

[q3k]

[QUOTE=Z_guy;26731592]Do you still have the code for that? I'd like to see it.
Also, [url]http://www.sfml-dev.org/forum/viewtopic.php?t=43[/url][/QUOTE]

[url=http://pastie.org/private/tsibqjygvnrkxs2fs5mvw]Here's my SDL code[/url]. The SFML one was pretty obvious, but I don't have it on me and I CBA to rewrite it, but it was very simple: create window, start loop, draw lines.

[Jookia]

You're using inlines wrong.
You're using custom types (uint32) wrong.
You're trying to outsmart the compiler's optimizations. Don't.

[noctune9]

[QUOTE=q3k;26731242]Nope. I wrote a program which displayed multiple (10^4) short lines at each frame, and SDL was way faster (20FPS) than SFML (3FPS or so).[/QUOTE]

In what real situations would you need to draw 10^4 lines? That's a meaningless benchmark. Doing benchmarks with sprites would be much more relevant.

[q3k]

[QUOTE=Jookia;26733165]You're using inlines wrong.
You're using custom types (uint32) wrong.
You're trying to outsmart the compiler's optimizations. Don't.[/QUOTE]

How am I using inlines wrong?
This is for portability. sizeof(int) != sizeof(int) on every platform. And it matters when it comes to accessing a screen buffer. Also, yes, the colour arguments in the draw functions are from previous tests, don't mind them.

[QUOTE=noctune9;26733195]In what real situations would you need to draw 10^4 lines? That's a meaningless benchmark.[/QUOTE]

Doesn't change the fact that, [url=http://imgur.com/gyD4c.png]in some cases[/url], SDL is faster, which was my main point.

[Z_guy]

[QUOTE=q3k;26733066][url=http://pastie.org/private/tsibqjygvnrkxs2fs5mvw]Here's my SDL code[/url]. The SFML one was pretty obvious, but I don't have it on me and I CBA to rewrite it, but it was very simple: create window, start loop, draw lines.[/QUOTE]
I was unfortunately mostly interested in the SFML version, since that was the slower one, where you probably did something wrong.

[q3k]

[QUOTE=Z_guy;26733542]I was unfortunately mostly interested in the SFML version, since that was the slower one, where you probably did something wrong.[/QUOTE]

I did this:

    sf::RenderWindow App(sf::VideoMode(960, 600, 32), "FluidSim");
    while (App.IsOpened())
    {
        sf::Event Event;
        while (App.GetEvent(Event))
        {
            // Close window : exit
            if (Event.Type == sf::Event::Closed)
                App.Close();
        }

        App.Clear();
        for (itParticles = m_Particles.begin(); itParticles < m_Particles.end(); itParticles++)
	{
               // ...
               App.Draw(sf::Shape::Line(X0, Y0, X1, Y1, 1, st::Color(255, 255, 255));
        }        
        App.Display();
    }

[sim642]

[QUOTE=q3k;26733626]I did this:

    sf::RenderWindow App(sf::VideoMode(960, 600, 32), "FluidSim");
    while (App.IsOpened())
    {
        sf::Event Event;
        while (App.GetEvent(Event))
        {
            // Close window : exit
            if (Event.Type == sf::Event::Closed)
                App.Close();
        }

        App.Clear();
        for (itParticles = m_Particles.begin(); itParticles < m_Particles.end(); itParticles++)
	{
               // ...
               App.Draw(sf::Shape::Line(X0, Y0, X1, Y1, 1, st::Color(255, 255, 255));
        }        
        App.Display();
    }

[/QUOTE]

You're allocating sf::Shape every time you draw a line. That takes soooo much time.

[q3k]

[QUOTE=sim642;26733802]You're allocating sf::Shape every time you draw a line. That takes soooo much time.[/QUOTE]

Okay, what should I do then, if the line changes at each render frame?

(also, it's not technically allocating, since it's creating it on the stack - but yes, this is running the constructor every frame)

[pollyzoid]

[QUOTE=q3k;26733856]Okay, what should I do then, if the line changes at each render frame?[/QUOTE]

Have a static list of 10^4 sf::Shapes and then shape->SetPointPosition in the for-loop?

[NorthernGate]

[QUOTE=q3k;26733243]How am I using inlines wrong?
This is for portability. sizeof(int) != sizeof(int) on every platform. And it matters when it comes to accessing a screen buffer. Also, yes, the colour arguments in the draw functions are from previous tests, don't mind them.

Doesn't change the fact that, [url=http://imgur.com/gyD4c.png]in some cases[/url], SDL is faster, which was my main point.[/QUOTE]

Uhm, how is that relevant though. If SDL is only faster in cases that most people will never find themselves in, where SFML is faster in cases almost everyone finds themselves in.

[q3k]

[QUOTE=raBBish;26733960]Have a static list of 10^4 sf::Shapes and then shape->SetPointPosition in the for-loop?[/QUOTE]

[url]http://pastie.org/private/i9ee6r8k6qr5ue0gp7oja[/url]

Still slow. Any ideas?
(also, is there a less hacky way to manipulate lines than what I'm doing?)

[QUOTE=NorthernGate;26734203]Uhm, how is that relevant though. If SDL is only faster in cases that most people will never find themselves in, where SFML is faster in cases almost everyone finds themselves in.[/QUOTE]

...this is what I meant.

[Jookia]

[QUOTE=q3k;26733243]How am I using inlines wrong?[/QUOTE]

Inlines are meant to put the actual function in to where its 'called' from and remove the need of overhead. However, what you have is a massive function that you want to be inlined. This can have the opposite effect and decrease performance as it can make your code larger, provoke paging and defeat compiler optimizations.

[QUOTE=q3k;26733243]This is for portability. sizeof(int) != sizeof(int) on every platform. And it matters when it comes to accessing a screen buffer. Also, yes, the colour arguments in the draw functions are from previous tests, don't mind them.[/QUOTE]

The effect of padding in memory could cause your code to slow down especially since this is a performance-critical test. Such as the one you're doing now.
But what worries me is that you're actually handling colours this way, which is probably a source of performance loss.

[q3k]

[QUOTE=Jookia;26736918]Inlines are meant to put the actual function in to where its 'called' from and remove the need of overhead. However, what you have is a massive function that you want to be inlined. This can have the opposite effect and decrease performance as it can make your code larger, provoke paging and defeat compiler optimizations.[/QUOTE]

This function isn't going to get that bigger, since the loops aren't getting unrolled. Does this look like a "massive" function to you?
[media]http://imgur.com/k31WD.png[/media]

Also, paging, seriously? Right now most Windows OS's have their page size set to 4mb, and my executable is 19k in size.

[QUOTE=Jookia;26736918]The effect of padding in memory could cause your code to slow down especially since this is a performance-critical test. Such as the one you're doing now.[/QUOTE]

...x86 is 32-bit. Every performance-critical program out there pads its shit to either 1, 2 or 4 bytes to move stuff around. How is using 32-bit data fields going to slow my code down? Should I use a 24-bit screen buffer instead, and use sluggish 24-bit blitting routines instead of lightning fast 32-bit ones (which are just a mov dword ptr)?

[QUOTE=Jookia;26736918]But what worries me is that you're actually handling colours this way, which is probably a source of performance loss.[/QUOTE]

What way? The code isn't final, I was moving stuff around, forgot to remove an unused parameter.

[Jookia]

I thought you were talking about portability. You know, across hardware that isn't x86.

If your code wasn't final, then don't use it as a benchmark to claim X is slow.

[inzuki]

[QUOTE={ABK}AbbySciuto;26714317]Allegro, if you're up for a challenge.[/QUOTE]

Allegro's a challenge?

I think it's fairly easy, and with AllegroGL it's actually pretty nice.

I dislike SDL because with the font library, it causes memory leaks. At least it did for me.

[ProWaffle]

Alright, if OpenGL's good, can someone link me to a tutorial for OpenGL for absolute beginners?

Preferrably starting with 2D stuff.

[q3k]

[QUOTE=Jookia;26740428]I thought you were talking about portability. You know, across hardware that isn't x86.[/QUOTE]

Is there any 24-bit processor out there?

[QUOTE=Jookia;26740428]If your code wasn't final, then don't use it as a benchmark to claim X is slow.[/QUOTE]

The function was inline, so the three additional parameters didn't do jack shit in terms of speed. Not to mention that I was showing that SDL is faster, which was true, so even if it did made it slower it wouldn't change the result.

[noctune9]

Inline is only a hint to the compiler, anyways. The compiler might as well just ignore it unless you use __forceinline.

[Jookia]

If you can make a completely unbiased test that's identical for both SFML and SDL to show that X is faster, do it. All I see is half-assed code portions that don't compile as you've removed half of it.