Hi, I'm fairly new to GameDev.net, but have been lurking the forums for quite a while now and decided to join to ask my question. I've made a few games in ActionScript 3 (Flash) and have a decent idea about game desgin and the like. However, now I've moved onto C++ and learned the basics such as the syntax, pointers, etcetera that are new concepts for me.
Coming from a Flash background where tutorials just get to the point and start making games to help you learn the language itself, I'd like to know if there's any tutorials like that for the SFML API that uses the C++ language. As stated, I already read up and wrote some C++ code to get used to the syntax and new concepts, I just now want to know if there's any tutorials that makes a simple, basic game while explaining the code with good C++ practices. I might be asking a bit too much in a tutorial but as close as it can be, I'll be able to adapt.
Also, I'm using the GNU C++ Compiler in Linux (openSuSE in case you're wondering).
TL;DR: Good C++ and SFML tutorials that shows you how to make a simple and basic game.
Thanks.
EDIT: Yes, I have googled this question and got no results on this. And the tutorials I've seen have comments saying that the classes made are bad practice and very easy to get into.
C++ and SFML Good Game Tutorials?
You can read the official web site's tutorials:
http://www.sfml-dev.org/tutorials/1.6/
Youtube useful channels:
SFML coder
CodingMade Easy
Or a good tutorial:
http://www.gamefromscratch.com/page/Game-From-Scratch-CPP-Edition.aspx
SFML is a good library, but if you want to use SDL:
lazyfoo's tutorials
http://lazyfoo.net/SDL_tutorials/index.php
You can use SDL with OpenGL to make 3d rendering too.
Good luck ;)
http://www.sfml-dev.org/tutorials/1.6/
Youtube useful channels:
SFML coder
CodingMade Easy
Or a good tutorial:
http://www.gamefromscratch.com/page/Game-From-Scratch-CPP-Edition.aspx
SFML is a good library, but if you want to use SDL:
lazyfoo's tutorials
http://lazyfoo.net/SDL_tutorials/index.php
You can use SDL with OpenGL to make 3d rendering too.
Good luck ;)
Author
Hi, thanks for the useful links! I just have a two questions. First of all, I saw gamefromscratch.com but in part 2, he uses static for his Game header file. I read that in C++ it's not generally good to make everything static, etc. Is there a way to make everything not static? Secondly, what version of SFML should I use? I have 1.6 installed, but 2.0 RC is out, should I move to 2.0?
Thanks.
Thanks.
You could always download my source code I made an asteroids style game using SFML, Box2D and an archive loader for my assets file. Here is the link, just if you wanted to reference anything. My website is http://www.johnschmuff.com
Author
You could always download my source code I made an asteroids style game using SFML, Box2D and an archive loader for my assets file. Here is the link, just if you wanted to reference anything. My website is http://www.johnschmuff.com
Cool, thanks! I'll definitely check out your source code for your asteroids styled game.
My 2 questions still stand:
1. The tutorial from gamefromscratch.com makes everything static in his Game.h file and heard that in C++ it's not generally good to make everything static like that (and in AS3 too). Is there a way to make it better and not make it so that it's not making everything static?
2. What version of SFML should I use? 1.6 or the 2.0 Release Candidate? I have 1.6 installed currently.
I'll continue with the gamefromscratch tutorial, but will switching to 2.0 RC mess any of the source code up?
If you guys have anymore good tutorials I could check out, please post it as it will help me and hopefully many others out there. Thanks.
I am still learning myself here so I may be off the mark but...
When you use all static members of a class you create a singleton, or a class that can only have a single instance... theres a bit of a discussion over wether one should use singletons or namespaces in cases of where only one instance is required.
As far as I know the only real difference is in how you acces the member functions... singleton is make a static object of your class as a means to access, then access via your object normally and namespace is to create a namespace class (using the keyword namespace rather than class) and use namespace::function system.
I would say use your tutorials system until you understand what the tutorial is doing, then try changing the singleton to a namespace as an experiment and decide which code looks and feels more elegant to you .
... as to using SFML 1.6 or 2RC ? I cant answer that as I am using SDL, but I would imagine its best to use the tutorials set until you are happy with what the tutorial is trying to show you... then make a new project and see if you can convert the tutorial code to the new ver.
Bare in mind that as a RC it will still have some bugs and wont have that much documentation out yet, so its an additional issue to consider... are you ready to tackle possible library issues as well as learning to code ?
When you use all static members of a class you create a singleton, or a class that can only have a single instance... theres a bit of a discussion over wether one should use singletons or namespaces in cases of where only one instance is required.
As far as I know the only real difference is in how you acces the member functions... singleton is make a static object of your class as a means to access, then access via your object normally and namespace is to create a namespace class (using the keyword namespace rather than class) and use namespace::function system.
I would say use your tutorials system until you understand what the tutorial is doing, then try changing the singleton to a namespace as an experiment and decide which code looks and feels more elegant to you .
... as to using SFML 1.6 or 2RC ? I cant answer that as I am using SDL, but I would imagine its best to use the tutorials set until you are happy with what the tutorial is trying to show you... then make a new project and see if you can convert the tutorial code to the new ver.
Bare in mind that as a RC it will still have some bugs and wont have that much documentation out yet, so its an additional issue to consider... are you ready to tackle possible library issues as well as learning to code ?
Author
Thanks for answering my questions!
While I was reading your answer to my first question, I decided to tackle the singleton and changed it to using namespaces instead; successfully. Also, I think I'll stick with SFML 1.6 and until I finished this project, I'll try converting it to 2.0.
Thanks again.
While I was reading your answer to my first question, I decided to tackle the singleton and changed it to using namespaces instead; successfully. Also, I think I'll stick with SFML 1.6 and until I finished this project, I'll try converting it to 2.0.
Thanks again.
http://www.gamefromscratch.com/page/Game-From-Scratch-CPP-Edition.aspx < Where I learned SFML and C++ together. 
As the author of the tutorial in question, I suppose I should chime in here.
First off, in retrospect, the use of static was probably a mistake. Not in the fact it's usage was wrong, but perhaps it was the wrong time to broach such a subject. A lot of that tutorial is actually geared towards illustrating various language concepts, over actually showing you how to use SFML. This means on occassion things are implemented a certain way because it became a convenient way to introduce a concept.
As to static itself, in the case it was used it was perfectly fine, but there is some need to understand exactly what static does. One of the big confusions is that static==singleton, which isn't specifically true, although the inverse is. Singletons are generally static.
When a variable is static, you are essentially taking it's allocation out of the traditional life cycle. When something is declared as static, it is created at the point the program is initialized. ( If you are wondering what happens when you have two statics... which is allocated first... this is a very good question! ). The major advantage of this is it means there can be only one. In cases where "there can be only one", well... this is obviously a very good attribute to have! The static in question was the game class itself, something that you cannot have more than one allocated. Of course, there are other ways to prevent this ( none quite as easily though ), as well, it is also a perfectly acceptable thing to not deal with and allow the code to explode if the user does try to allocate another.
Be careful with following rote advice, it can lead you into trouble. Far too often people like to pass off opinion as fact, especially in this field, and that is extremely dangerous. One classic example, there are a class of developers that subscribe to the single responsibility principle to a zealous degree. Many of these people will pass this off as a fact, but it isn't. It's one way of doing things, and in many ways a good way, but it is not the only way. Singletons are another great example with even more people willing to use absolutes like "never use a singleton", and I really don't want to rehash that old chestnut in this thread; but.... take a look out in nature and you will see it's pretty damned common in some really successful projects. Ogre, cocos2D, PlayStation Mobile SDK, Source Engine....
Oh, and starting with 1.6 and porting to 2.0 later is perfectly acceptable. Truth is, it's pretty easy too, and by part 7 or so I started providing 1.6 and 2.0 versions of the projects, thanks to a readers contributions. Both have their merits... 1.6 is the best documented version out there, but there is a nasty ATI related bug that the developer never bothered fixing. 2.0 is a bit cleaner, but is currently lacking in documentation and is technically a release candidate.
In the end the biggest code difference is the move to camelCase naming conventions and removal of GetInput from the window object, which from a design perspective, makes a ton of sense. With the way the tutorial was written though, this transition is pretty easy as I put a very small abstraction layer of the IO anyways. Perfectly demonstrating why it is you do such things.
First off, in retrospect, the use of static was probably a mistake. Not in the fact it's usage was wrong, but perhaps it was the wrong time to broach such a subject. A lot of that tutorial is actually geared towards illustrating various language concepts, over actually showing you how to use SFML. This means on occassion things are implemented a certain way because it became a convenient way to introduce a concept.
As to static itself, in the case it was used it was perfectly fine, but there is some need to understand exactly what static does. One of the big confusions is that static==singleton, which isn't specifically true, although the inverse is. Singletons are generally static.
When a variable is static, you are essentially taking it's allocation out of the traditional life cycle. When something is declared as static, it is created at the point the program is initialized. ( If you are wondering what happens when you have two statics... which is allocated first... this is a very good question! ). The major advantage of this is it means there can be only one. In cases where "there can be only one", well... this is obviously a very good attribute to have! The static in question was the game class itself, something that you cannot have more than one allocated. Of course, there are other ways to prevent this ( none quite as easily though ), as well, it is also a perfectly acceptable thing to not deal with and allow the code to explode if the user does try to allocate another.
Be careful with following rote advice, it can lead you into trouble. Far too often people like to pass off opinion as fact, especially in this field, and that is extremely dangerous. One classic example, there are a class of developers that subscribe to the single responsibility principle to a zealous degree. Many of these people will pass this off as a fact, but it isn't. It's one way of doing things, and in many ways a good way, but it is not the only way. Singletons are another great example with even more people willing to use absolutes like "never use a singleton", and I really don't want to rehash that old chestnut in this thread; but.... take a look out in nature and you will see it's pretty damned common in some really successful projects. Ogre, cocos2D, PlayStation Mobile SDK, Source Engine....
Oh, and starting with 1.6 and porting to 2.0 later is perfectly acceptable. Truth is, it's pretty easy too, and by part 7 or so I started providing 1.6 and 2.0 versions of the projects, thanks to a readers contributions. Both have their merits... 1.6 is the best documented version out there, but there is a nasty ATI related bug that the developer never bothered fixing. 2.0 is a bit cleaner, but is currently lacking in documentation and is technically a release candidate.
In the end the biggest code difference is the move to camelCase naming conventions and removal of GetInput from the window object, which from a design perspective, makes a ton of sense. With the way the tutorial was written though, this transition is pretty easy as I put a very small abstraction layer of the IO anyways. Perfectly demonstrating why it is you do such things.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
