As a dissenting view, I'd just like to say that how computer architecture works, or what high level languages compile down to is largely orthogonal to being able to use them effectively.
Knowing all of that stuff won't help the OP understand bad tutorials better, it just provides more terms they don't understand and relationships that aren't clear.
Thank you to everyone, over the past 24 hours (when it hasn't been someone telling me I'm asking the 'wrong' questions) I have gained so much understanding. I spent a good hour reading everything Norman Barrows had to say and then did a lot of research on it, all this time I've had no idea that a method and a function were the same thing, except methods are more used in Java and C++ is based on functions, they work the same way with differences based around whether they are related to an object or not. I am appreciative of all the examples given and I'm referring to this thread a lot, which has helped me learn more.
The bolded part is somewhat accurate, but misleading.
In Java, methods are "more used" namely because there are no free functions (that is, functions which are not either methods or associated with a class) in Java in the first place, whereas in C++ there are. I wouldn't use this to distinguish between the two things since saying that they are used in one language but less so in another does not tell you what they are. It's true that the terms "method" and "function" do tend to be used interchangeably, and programmers will understand what you mean if you use them that way, but they aren't quite the same thing, just as "procedures" and "functions" are not the same thing if you're sufficiently pedantic.
As a dissenting view, I'd just like to say that how computer architecture works, or what high level languages compile down to is largely orthogonal to being able to use them effectively.
Knowing all of that stuff won't help the OP understand bad tutorials better, it just provides more terms they don't understand and relationships that aren't clear.
Yeah, totally agree. I think the OP has two main problems right now:
1. The OP may be focusing on C++.
2. The OP may have tutorial-itis.
On 1., don't start with C++. Try C#, Java, or Python or just about anything else besides Perl or C or C++.
On 2., don't read tutorials. There are some good ones but most of them suck and at this point you won't be able to tell the difference.
As a dissenting view, I'd just like to say that how computer architecture works, or what high level languages compile down to is largely orthogonal to being able to use them effectively.
Knowing all of that stuff won't help the OP understand bad tutorials better, it just provides more terms they don't understand and relationships that aren't clear.
Yeah, totally agree. I think the OP has two main problems right now:
1. The OP may be focusing on C++.
2. The OP may have tutorial-itis.
On 1., don't start with C++. Try C#, Java, or Python or just about anything else besides Perl or C or C++.
On 2., don't read tutorials. There are some good ones but most of them suck and at this point you won't be able to tell the difference.
Damnit, I just spent 3 days watching a 72-video series on C++. I feel like I have a handle on it but I'm not sure where to go next. I was recommended to use SFML to start making some really basic games but I'm already lost. It's like I learned the C++ syntax and now I'm in an entirely different world.
I read everyone's posts and I can't reply to them all, but I think I get the whole concept of stacks and binary a lot better now such that each variable takes up a certain amount of space and is allocated a memory address (hence why you can use pointers to cout << the address directly and see them) and it's helped a lot.
I guess my real problem now is picking either SFML or OpenGL and running with it whilst reading C++ books on the side.
I don't really want to learn about graphics though, I want to learn how to manipulate graphics but with the least amount of "learning to make Disney movies" side of it as possible. I am almost exclusively learning C++ for games.
I've tried C# and Java but I find them much harder and less enjoyable than C++. I know that everyone wants to become teh n3xt besterest AAA c++ pr0gramma in teh w0rld!11! and usually give up after a week but I'm generally interested in sticking with C++ and maybe using Lua to handle some of the load. Permanently. I've been coping so far, it's just come to a bit of a point where I'm unable to figure out what to do next.
I've learnt the syntax, I can do basic code and understand it relatively easy, and the rules are etched into my head. I just need the next step to making my really terrible 2D rip off of Pong in terms of manipulating screen graphics with an API through C++.
If you go to the following website and grab the very first example, you will have a Visual Studio project that creates a window using OpenGL. I ran it using Visual Studio 10 Express. It builds and runs without any extra dependencies, I went to some trouble to find something that would run right away without any hassle or setup nonsense, this is it.
http://www.codesampler.com/oglsrc/oglsrc_1.htm#ogl_primitive_types
If you then go all the way to the bottom to the Render Function you will see the following
//========================================================================================================
//========================================================================================================
If you change it to look like the following, you will have the beginning of that Pong game that you mentioned making.
It will be nice and plain old boring looking like you want. A white square on a black background.
The following code that I added in comes from the first chapter of the OpenGL Redbook. Found here.
http://fly.cc.fer.hr/~unreal/theredbook/
//========================================================================================================
//========================================================================================================
Damnit, I just spent 3 days watching a 72-video series on C++.
I guess my real problem now is picking either SFML or OpenGL and running with it whilst reading C++ books on the side.
I've learnt the syntax, I can do basic code and understand it relatively easy, and the rules are etched into my head.
[overstatement]No, no, and no.[/overstatement] That's too harsh, but I've always wanted to use a multiquote to respond that way. These three quotes together scream for you to slow down. Spending three days watching 72 video lessons is nowhere near enough to understand C++. It's not enough to jump into OpenGL. It's probably not enough to make a game with graphics.
Even if you know all of the syntax rules by heart as well as how and when to use each, you are still lacking in programming experience. It's like learning the grammar rules of a second language (over three days) but not knowing any vocabulary. And now you want to write a novella in that language. Your other thread ("Touching base...") has some great suggestions, particularly from kseh and frob. Pick a small, easy task or tiny game and fiddle with your compiler to make it.
You don't need more books at the moment, nor do you need to be researching libraries to use, nor looking up online video tutorials. You need programming experience. So using what you already know, make a calculator or hangman game or guess the number. Make a text adventure consisting of five rooms and one monster. At most, play with SFML to make a window that changes colors when you press a key.
If you want to stick with C++, go for it. If you want to start using SFML, great. That's as far as I'd go for now. No programming exercise is too basic to bother with until you've already demonstrated that you can do it, and most programming tasks will be too big to reasonably tackle for a while.
Agreed. Programming can really only be learnt by doing.
It's just like how you don't learn maths by looking at the questions and then looking at the answers. You might start to get a feel for it, but you really only solidify that knowledge and actually learn it, by solving the problems yourself.
The process of learning is also all about making mistakes, and learning from those mistakes. Being all into the theory side of things might seem great, but the moment something doesn't work as expected, you wont have a clue what is wrong.
