Fascinating.

I sugest you to read this book The black art of multiplatform game programming. The book is well written and at the end, you will have a little game engine that you will be able to easily modify. You will made a little pong game, a breakout game and a little side scroller shooter. It take me around 1 month to read it.

I sugest you to read this book The black art of multiplatform game programming. The book is well written and at the end, you will have a little game engine that you will be able to easily modify. You will made a little pong game, a breakout game and a little side scroller shooter. It take me around 1 month to read it.

Unfortunately it uses the old SDL1.x rendering API (based on what's available in "Look Inside"), so while it might be a great book on using the old API, it's actually quite out of date and not terribly useful for learning how to use the new API. I'm pretty sure SDL2.0.0 was released about year before that this book was published, it's curious that they did not use SDL2.

Unfortunately it uses the old SDL1.x rendering API (based on what's available in "Look Inside"), so while it might be a great book on using the old API, it's actually quite out of date and not terribly useful for learning how to use the new API. I'm pretty sure SDL2.0.0 was released about year before that this book was published, it's curious that they did not use SDL2.

I guess that the same principles apply to both API versions. I am thinking to buy this one in order to grasp the fundamentals and the basic concepts of SDL.However, I would be interested to know if there are any books (or any other tutorial/video) using SDL + C instead of C++. I would love to create a game in C first, since I am not that fan of oop.

Unfortunately it uses the old SDL1.x rendering API (based on what's available in "Look Inside"), so while it might be a great book on using the old API, it's actually quite out of date and not terribly useful for learning how to use the new API. I'm pretty sure SDL2.0.0 was released about year before that this book was published, it's curious that they did not use SDL2.

I guess that the same principles apply to both API versions. I am thinking to buy this one in order to grasp the fundamentals and the basic concepts of SDL.However, I would be interested to know if there are any books (or any other tutorial/video) using SDL + C instead of C++. I would love to create a game in C first, since I am not that fan of oop.

Some portions of the API are pretty much the same (event handling, threads, timers, audio). The most important portions of the API (window, rendering) are totally different.

I even got the book SDL Game Development after reaching till page 65 and so... I thought that the author is going about things pretty much his way. So I might feel boring at some times and get interested in some further things (I suppose it isn't my way of learning).

Sorry to say, but I really do not recommend that book. I found it slightly sloppy and a bit inconsistent in several ways... One example that stuck with me is that the author claims the book is not for the absolute beginner, and indeed he does some advanced witchery with little or no explanation sometimes, yet later on he went to surprising lengths to explain how the Y axis is inverted in computers...

Go figure.

I had trouble learning SDL. Mostly because at the time I couldn't find any proper tutorials. Maybe there weren't any... Lazy Foo's seemed alright, but they didn't teach you much more than just SDL. It didn't teach me how to properly organize the code in separate files either (which that book actually kinda did). That, in my opinion is a great red flag. I would think there's a good chance a beginner who's tackling SDL has already been through the frustrating experience of having 3000+ lines of code in one file...

I really don't know if it was SDL, Lazy Foo, or just me. I just couldn't go forward with it. I tried Allegro later on and I found it comprehensible enough that I did quite some progress. And more recently I started tackling SFML and I'm happier with it every day. So I dunno...

I'd say, by all means, try SDL and try Lazy Foo. If you find yourself struggling much, then try to find tutorials that focus mainly on making a game... with SDL (personally, I would try this right away, but LF's tutorials might have improved - I wouldn't know, it's been a while for me). If that still doesn't work, then perhaps try another library. Don't get too attached to anything, and don't condition yourself to follow a strict path. At this point the smartest thing you could do is really to just go with whatever works.

I had trouble learning SDL. Mostly because at the time I couldn't find any proper tutorials. Maybe there weren't any... Lazy Foo's seemed alright, but they didn't teach you much more than just SDL. It didn't teach me how to properly organize the code in separate files either (which that book actually kinda did). That, in my opinion is a great red flag. I would think there's a good chance a beginner who's tackling SDL has already been through the frustrating experience of having 3000+ lines of code in one file...

lazyfoo.net has a tutorial on http://lazyfoo.net/articles/article07/index.php about multiple source files!
Well, but that was not the way I learned how to separate into multiple source files. I just browsed through some of the source code of the book SDL Game Development and then understood what type of separation is there.

I really don't know if it was SDL, Lazy Foo, or just me. I just couldn't go forward with it. I tried Allegro later on and I found it comprehensible enough that I did quite some progress. And more recently I started tackling SFML and I'm happier with it every day. So I dunno...

I'd say, by all means, try SDL and try Lazy Foo. If you find yourself struggling much, then try to find tutorials that focus mainly on making a game... with SDL (personally, I would try this right away, but LF's tutorials might have improved - I wouldn't know, it's been a while for me). If that still doesn't work, then perhaps try another library. Don't get too attached to anything, and don't condition yourself to follow a strict path. At this point the smartest thing you could do is really to just go with whatever works.

So, I'm going to stick with SDL for some time. Also, I'm already working on a Pong Game with the basic mechanism and player controls worked out. I just have to do the AI and the menu!

As for the other libraries I'm going to head everywhere, SFML, Java2d, PyGame, OpenTK, HTML5 and work out all them (For some reason not Allegro). Afterwards I'll chose the best of them (the one which I found most comfortable with) and make some real game project. Hope it comes soon!

Lazy Foo's seemed alright, but they didn't teach you much more than just SDL.

Yes, Lazy Foo assumes you'll learn other elements of game development and project management from other sources (and a handful of the tutorials contain what I consider to be bad practices). It's really only focused on covering SDL.

As for the other libraries I'm going to head everywhere, SFML, Java2d, PyGame, OpenTK, HTML5 and work out all them (For some reason not Allegro). Afterwards I'll chose the best of them (the one which I found most comfortable with) and make some real game project. Hope it comes soon!

you've got a lot of learning to do!

It's a very good idea to learn low-level game development at some point. But I usually recommend beginners start by getting a grasp on the high-level (more abstract) concepts of game development. If you don't know what it's like to work in a fully realized game engine, you're going to have a very difficult time building your own.

Making a ton of small games in an easy to use environment like Clickteam Fusion is, in my opinion, a much more natural and pleasant way to learn game dev than slogging through making your own engine right from the get go.

It's a very good idea to learn low-level game development at some point. But I usually recommend beginners start by getting a grasp on the high-level (more abstract) concepts of game development. If you don't know what it's like to work in a fully realized game engine, you're going to have a very difficult time building your own.

Making a ton of small games in an easy to use environment like Clickteam Fusion is, in my opinion, a much more natural and pleasant way to learn game dev than slogging through making your own engine right from the get go.

Well, my experience was different. I have written it here: http://www.gamedev.net/topic/677275-where-to-start-programming-games-c/#entry5282811