>>6
SDL is nice, but quite outdated. It's also implemented in C, so your codebase might end up being a little more complicated assuming you use C++. And you can forget about hardware acceleration.
I recommend SFML. It's simple and fast, as implied by the name. It is also better maintained.
>>11
Shoehorning a C library into a C++ program produces unnecessary complexity. Why would OP do this if there are no performance gains for it and there are simpler and more robust alternatives available?
Name:
Anonymous2012-07-10 20:44
>>13
Have you ever used SDL with c++? There's no difference from using it in c whatsoever.
Name:
Anonymous2012-07-10 20:51
>>14
If you're writing C++ like you would write C, you're doing it wrong.
Name:
Anonymous2012-07-10 20:54
>>15
not 14, but dude seriously stfo you don't fucking know what you're saying
Name:
Anonymous2012-07-10 21:06
>>16
That's true, my apologies. I haven't done any C or C++ or used SDL or SFML in ages. I just like being proved wrong because it helps get rid of fauly concieved notions and shows I have more to learn.
no, you are sort of right. C++ style does clash with C style, but it is ok to break into C style for the sake of compatibility with a library or an existing code base. It's manageable as long as the transition has a border to it. Like once you are inside the library, it is all C, and once you are outside the library, it's all C++. Doing stuff like mixing malloc free new and delete all over is bad news.
Name:
Anonymous2012-07-11 2:24
The only logical choice is C++11 with GLFW.
Name:
Anonymous2012-07-11 5:35
The current, longstanding version of SDL (1.2) is entirely implemented with software surfaces, unless you're just using for an opengl context and timing/io. Software surfaces are slower than old people fucking. Per-pixel operations or any other sort of low-level image transformation take multiple seconds, even on small images. OpenGL or DirectX (if you don't care about your software running on anything other than windows) is your only hope.
Name:
Anonymous2012-07-11 12:46
In my first experience using SDL, I failed to use it for a simple project. I believe I got problems with mouse handling (out of window + mouse key up or something, can't remember for sure), problems you'd expect when using non-professional solutions, it appeared just another random FOSS project, so I switched to OpenGL which fixed any limitations I experienced with SDL. It just left me wondering why people through decades recommends SDL? For 'what' I ask, because programming using OpenGL/AL is just as simple. Really, it is very simple.
Later on I got to write a wave propagation simulator, using that produced perfect (analytic) wave functions in the time domain, supporting arbitrary amounts of waves and interferences, using OpenGL but it wasn't like OpenGL had anything to do with it really, it's just a stupid API to put doodles on the screen, same as SDL. What you really need is either:
A. A shit load of time to implement the mathematics to handle what ever you want to do, collision detection etc, what ever it might be.
B. A proprietary engine that solves 99% of your problems.
Name:
Anonymous2012-07-11 13:50
Just use python, it's easy and you have pygame, which is basically optimized SDL for python.
Name:
Anonymous2012-07-11 13:54
>>21
Why not skip the FOSS bullshit and use what the pros use?
I'd use DirectX or what ever would be needed today, but at that time, I was mesmerized by FOSS (even had linux t-shirt) and thought it was the shit. I'm embarrased to say I'd been using Linux for well over 10 years at that time. I ate shit for ten years, i.e. reading shitty code, shitty documentation, shitty mailing lists, working with shitty APIs that would change to diarrhea at anytime repeatedly, yet I never realized it for such a long time.
Name:
Anonymous2012-07-11 15:12
Nobody use SDL for drawing pixels you niggers. Also OpenGL is not OOP: deal with it and encapsulate everything!