I haven't made any of those "here" and "here" and i've said that before.
The 6 months part is for first learning and when i'm done with that i'll start physics and maths before i do the "here" and "here". How won't i know that physics and maths increases your problem solving skills?
Are you sure this compartmentalized way of learning is effective? What benefit is it to focus on one area for six months then switch to a completely different area for the next six months? You should be learning a bit of everything in that time frame. Many of the simple games mentioned here do not require complex math or physics - you can start making them right now. Furthermore, what good is it to learn physics and math in isolation? You'll want to apply what you've learned to an actual project - that's how learned concepts will really stick.
It seems like you think it's necessary to know absolutely everything there is about C++, graphics programming, physics, and math in order to make even the simplest of games. Making games is part of the learning experience, it's not simply the product of having learned everything else first.
I will still stick to directx.
You obviously like 2d more than i do because before this thread i didn't doing 2d (i don't have a problem with it, i just prefer 3d games)
For the sake of learning, you should really make several simple 2d games before jumping into 3d. 3d complicates things, not just graphically but with physics and game logic as well. And I would advise against using DirectX for the time being. Yes, it's a powerful API in its own right, but it's less user friendly to the novice user who's just getting into game development. APIs such as SFML and SDL abstract away a lot of the complex code you'll have to deal with in DirectX, making the learning experience a lot less frustrating. You can switch back to DirectX when you gain more experience.
"Cin" is the standard input stream which simply retrieves characters (from the keyboard, by default). In graphical games, you will not be using the console window so you won't be able to retrieve input this way. In any case, "cin" just retrieves characters and requires a termination (by the user hitting "enter"), making this method of input unsuitable for real-time games where you want actions to be performed by holding down keys.
No, you'll need to start working with graphics. Select an API and learn some of its basic functions (creating a window, getting user input, drawing graphics, etc.) then start making simple graphical games with that API.
If you're getting bored of C++ then it's probably because you're not creating anything that really motivates you. You've probably learned enough C++ to start making simple games, so I suggest picking up an API such as SDL. After becoming somewhat familiar with the basic operations of that API, start making simple games such as Tic-Tac-Toe, Pong, or Snake. Sure, there will be gaps in your knowledge as you create these games, but you can learn as you create. There is no need to learn absolutely every aspect of a programming language or API before you start making games.
It's perfectly acceptable to mix themes together. Final Fantasy VI mixed together steampunk and high fantasy (which included magic). It's really up to you if you want to mix themes and to what extent. It can open more possibilities, but at the same time it could turn the world into a mish-mash of ideas that don't feel like they fit together. The key to creating a convincing world is consistency.
Steampunk is fun for the same reason that any fantasy theme is fun - it opens the possibility of strange technology, awe-inspiring locations/architecture, interesting personalities, and more. Also, like with any fantasy genre, it creates a suspension of disbelief for the audience, allowing for narrative and storytelling that would seem improbable in a more realistic setting. A steampunk setting is just another way to create a consistent theme to make your fantasy world more believable.
As exOfde has already said, you should be using textures instead of surfaces. This will allow you to take advantage of your GPU's processing power to transform images quickly and efficiently, and scaling is automatic given the destination rect. The reason you're experiencing slowdown is because you're using the CPU for image processing, which is very slow for that kind of thing.
When a game is saving it has to write the data to the hard drive or other data storage medium. This is a relatively slow process, so in a single threaded game it must wait until this process is finished before the game resumes.
It would add a great amount of depth if there were some kind of underlying principles that determine the outcome of a particular mixture of ingredients. Perhaps these principles would involve mathematical formulas where each ingredient would have certain values which are used in a formula to determine how it reacts to other ingredients. The amount of each ingredient would also play a role, as well as preparation methods (e.g. grinding an ingredient into powder before mixing).
Speaking of which... You should perhaps try something on the scale of what's now known as RuneScape Classic (which originally was created by just a few people), or even simpler. In other words, very simple graphics, simple interface, simple mechanics, etc. Actually, scratch that - you'd be best starting with creating a MUD before trying something on a larger scale.