SDL
I was getting back to c++ programming when i saw SFML 2.2 was about to be released. Instead of going through the hassle of updating it again when it came out ( i'm on windows ) i decided to learn some SDL2 while i'm waiting for SFML 2.2 . My question is: Working with SDL, do I create an abstraction layer or should I work pure SDL2?
Last edited on
closed account (jyU4izwU)
Hail friend,
I too am searchin' for information about SDL, I'm trying to start OpenGL and make a 3D game, maybe we can work together?
I too am searchin' for information about SDL, I'm trying to start OpenGL and make a 3D game, maybe we can work together?
SDL is already abstracted. You can use it directly or some choose to make a small layer over it to implement RAII.
I know SDL is abstracted, but what i want to do is abstract it even more, turning it into a C++ OO library
If you want to do that, why not just use SFML? It's already nicely abstracted into classes. If you have any SFML2.x, then just use that. No need to be up-to-date on minor releases really.
A thin abstraction layer is probably a good idea because if you decide to switch to SFML or something else later on, it will be easier to rewrite your abstraction layer than remove everything that depends on SDL when it's spread throughout your program.
| chrisname wrote: |
|---|
| A thin abstraction layer is probably a good idea because if you decide to switch to SFML or something else later on, it will be easier to rewrite your abstraction layer than remove everything that depends on SDL when it's spread throughout your program. |
| lockandstrike wrote: |
|---|
| I know SDL is abstracted, but what i want to do is abstract it even more, turning it into a C++ OO library |
| This is overkill, and also a waste of time. |
Not really, see it done with a lot of C libraries.
http://sdlmm.sourceforge.net/
Is one such he could use. It can be hard to find a decent library, i know some that use namespaces and create some absurdly long namespace name with a MiX oF CaSeS that makes it harder to write all the time, SFML is probably one of the best out there though and native to C++.
It's great that SDL2 is backward compatible with the previous version. But it would also be good to make an abstraction layer(even just a thin one) maybe if you want to port it to other libs/api say for example opengl.
My 2 cents.
Use SDL2 as is. This may sound stupid but, write the instructions you want the computer to run, not instructions for how to write instructions.
If you notice redundant patterns in your code you should then start abstracting (if you think it will be better).
relevant recommended reading http://mollyrocket.com/casey/stream_0019.html
Use SDL2 as is. This may sound stupid but, write the instructions you want the computer to run, not instructions for how to write instructions.
If you notice redundant patterns in your code you should then start abstracting (if you think it will be better).
relevant recommended reading http://mollyrocket.com/casey/stream_0019.html
| ezchgg wrote: |
|---|
| Not really, see it done with a lot of C libraries. |
Based on the original post, he doesn't even know SDL2. He's putting the cart before the horse.
| rjvc wrote: |
|---|
| It's great that SDL2 is backward compatible with the previous version. But it would also be good to make an abstraction layer(even just a thin one) maybe if you want to port it to other libs/api say for example opengl. |
| Abstracting an abstraction layer is just redundant. |
SDL has a similar stack for audio output. In fact, any system of moderate complexity will have at least one stack of abstraction layers, often several.
Some of you failed to read my original post. I know SFML has all these features, I'm just waiting for the next release (2.2).
But as I see, it's the primary opinion to use SDL as it is and being so, I'll just wait for SFML 2.2 or just go for 2.1 already since I programm in C++, not C
But as I see, it's the primary opinion to use SDL as it is and being so, I'll just wait for SFML 2.2 or just go for 2.1 already since I programm in C++, not C
Last edited on
| Avilius wrote: |
|---|
| If you have a program working in SDL2, there is no reason for you to port it over to SFML. |
There are plenty of reasons why you might want to port your program from one library to another. Your requirements could change, you could decide to use both libraries on different platforms because one supports more platforms but the other is faster on the platforms it supports, or you could finish your program only to learn that a new library which is better than the one you're using in every way exists and you'd like to port your codebase to it. Abstracting the libraries you use lets you do all of that far more easily because your core logic needn't be changed so long as the interface to the abstraction layer doesn't change.
If your abstraction layer is implemented as dynamically loadable modules, you can hotplug whatever library you want just by writing a new module, so long as the interface is the same, without even recompiling the rest of your program. You could even switch SDL for curses for systems that only support text. When in text mode, Qemu can be run with a curses UI, but defaults to SDL. Abstracting your libraries makes that much easier.
| chrisname wrote: |
|---|
| There are plenty of reasons why you might want to port your program from one library to another. Your requirements could change, you could decide to use both libraries on different platforms because one supports more platforms but the other is faster on the platforms it supports, or you could finish your program only to learn that a new library which is better than the one you're using in every way exists and you'd like to port your codebase to it. Abstracting the libraries you use lets you do all of that far more easily because your core logic needn't be changed so long as the interface to the abstraction layer doesn't change. |
| lockandstrike wrote: |
|---|
| i decided to learn some SDL2 while i'm waiting for SFML 2.2 . |
If you're writing an abstraction layer, then you should know all of the libraries you're planning to support. In the OP's case, (s)he doesn't.
I'm not saying to litter your code with SDL2. Your code should be modular already. SDL2 things should only belong in input and rendering modules. Since it's only in those portions of the program, the person interfacing with the module shouldn't know what you're using. If you're explicitly making an abstraction layer just for SDL2 to go into your input and rendering modules, you're wasting your time. You're essentially making modules inside your modules, and if you're not getting anything done because you're making 27 modules inside one, then that's a serious problem.
Last edited on
I actually don't like it when programs support multiple libraries that do the exact same thing. If one library does one thing better than another, then use it... if none of them do what you want, make the changes necessary to the library. That's how free libraries evolve.
If you don't like the design of one library compared to another, add the functionality to the one you like.
Etcetera.
If you don't like the design of one library compared to another, add the functionality to the one you like.
Etcetera.
Last edited on
Status update: I said **** it to waiting for SFML 2.2 and went and grabed a copy of SFML 2.1 which I'm very familiar with, thus throwing away anything related with SFML. After reading what you guys said, I'm probably going to build an abstraction layer on SFML, allowing me in the future to change libraries without having to rewrite the game.
Anyways, thank you all. Problem deal with
Anyways, thank you all. Problem deal with
As a novice game programmer and one that made a lot of stupid mistakes, i would give you this advice.
First of all, all the advices that are given are right in a sense. But the question is which one is more appropriate to your situation.
If you are learning how to game programming, SDL is a crucial library to learn as some companies(etc. Valve) uses it. Since you already know sfml you wont have to learn all the basics. Also learning Qt(used by EA at some places) and OpenGL might be needed. As for SDL a small abstraction could be needed, just classes. Also c++11 features removes that need too. A few lines of codes will be enough if you are familiar with them.
If you are trying to make a game with SDL from scratch. Just kill yourself and whoever gave you that advice. It is just waste of time and unnecessery pain. Just use an engine according to your needs as there are many good ones(etc. Unreal, CryEngine, Unity). Also some game frameworks can be used if necessery.
And lastly, learning all these libraries shouldnt fear you, since most of them are similar learning becomes easy after a few.
First of all, all the advices that are given are right in a sense. But the question is which one is more appropriate to your situation.
If you are learning how to game programming, SDL is a crucial library to learn as some companies(etc. Valve) uses it. Since you already know sfml you wont have to learn all the basics. Also learning Qt(used by EA at some places) and OpenGL might be needed. As for SDL a small abstraction could be needed, just classes. Also c++11 features removes that need too. A few lines of codes will be enough if you are familiar with them.
If you are trying to make a game with SDL from scratch. Just kill yourself and whoever gave you that advice. It is just waste of time and unnecessery pain. Just use an engine according to your needs as there are many good ones(etc. Unreal, CryEngine, Unity). Also some game frameworks can be used if necessery.
And lastly, learning all these libraries shouldnt fear you, since most of them are similar learning becomes easy after a few.
Last edited on
| Ceset wrote: |
|---|
| If you are trying to make a game with SDL from scratch. Just kill yourself and whoever gave you that advice. |