Quite new to C++

Hello there,

I'm quite new to C++ but not to programming in general. I have a lot of experience to javascript but only in a game development point of view. I have noticed so many limitations with the game creating software I have used that I thought id try out learning how to properly code.

Im not sure where to start, so I thought id go with a tile based map editor, purely for making maps and wont worry about any kind of engine for now. But find myself immediatly confused.

For now I just want a container, that will display a tileset inside it. I need the container to have scrollbars as the images will be quite large.

I would also like a grid to be displayed over the image, seperating tiles to 32 x 32 sizes. Also when the cursor is over the container, have a box appear over the tile that is beneath the cursor at the time.

Can anyone help just to get me started? I promise I pick this up quite quickly with help on forums (Well at least I have with Ruby and Javascript so far).

Thanks guys (this is my first post btw so I hope I got it in the right section, sorry if i didnt)

You seem to be missing some basic concepts. I would suggest picking up one of the C++ beginners manuals that are prevalent at your local bookstore. (Or at least sit down and read the first couple of chapters.)

If you feel that you need to order it online, "Programming Windows" from Petzold is always a good place to start.

-Erik

Quote:

---

Originally Posted by egawtry

You seem to be missing some basic concepts. I would suggest picking up one of the C++ beginners manuals that are prevalent at your local bookstore. (Or at least sit down and read the first couple of chapters.)

If you feel that you need to order it online, "Programming Windows" from Petzold is always a good place to start.

-Erik

---

That was a good place to start 20 years ago. I wouldn't recommend it any more.

I agree that the OP needs to walk before he runs. I'd even suggest that perhaps C# and .Net would be more appropriate given his goal.

Quote:

---

Originally Posted by Harry Bo21

For now I just want a container, that will display a tileset inside it. I need the container to have scrollbars as the images will be quite large.

I would also like a grid to be displayed over the image, seperating tiles to 32 x 32 sizes. Also when the cursor is over the container, have a box appear over the tile that is beneath the cursor at the time.

---

You are immediately talking about graphics. Graphics are not a beginner's subject in C++; first you should master the basics of the language. Then, you can find an appropriate GUI library to create the widgets you want.

Quote:

---

Originally Posted by GCDEF

That was a good place to start 20 years ago. I wouldn't recommend it any more.

---

I will argue with you on that until the cows come home. That is the BIG problem with CS students these days. They learn from the top down instead of the bottom up and learn some very bad programming practices.

Quote:

---

Originally Posted by GCDEF

I agree that the OP needs to walk before he runs. I'd even suggest that perhaps C# and .Net would be more appropriate given his goal.

---

I suppose C# is similar enough to Java, but he said...

Quote:

---

Originally Posted by Harry Bo21

...I thought id try out learning how to properly code.

---

:p

-Erik

Quote:

---

Originally Posted by egawtry

I will argue with you on that until the cows come home. That is the BIG problem with CS students these days. They learn from the top down instead of the bottom up and learn some very bad programming practices.

---

I would argue it's just as bad to learn entirely from the bottom up. There are college grads out there who claim to know C++ on their resumes but have never used the STL. There's no point in wasting their time or the employer's reinventing the wheel when they don't have to. Occasionally you'll get one who is such a guru that they can write hyper-efficient C code, and they are a gem; but more often you get someone throwing dynamic memory management around willy-nilly and adding weeks of debugging time to development in the process.

The key, in my view, is a balance approach. Teach C for low-level skills, and also teach C++ with an eye to abstraction. Do not teach them as if they are the same language with a few new features.

Quote:

---

Originally Posted by egawtry

I will argue with you on that until the cows come home. That is the BIG problem with CS students these days. They learn from the top down instead of the bottom up and learn some very bad programming practices.





I suppose C# is similar enough to Java, but he said...



:p

-Erik

---

With MFC and now .Net, there's no need to learn low level Windows programming. It doesn't hurt to understand it, but that's not a place to start. As to saying C# isn't proper coding, that's just silly.

Quote:

---

Originally Posted by GCDEF

With MFC and now .Net, there's no need to learn low level Windows programming.

---

On the contrary, I use MFC because I can do low level programming with it at the same time have all the nice prepackaged GUI items.

I agree it is nearly impossible to do low level programming with .NET. Of course, it is also almost impossible to debug .NET as well.

Quote:

---

Originally Posted by GCDEF

As to saying C# isn't proper coding, that's just silly.

---

And I suppose you think Visual Basic is a real language for commercial apps. :sick:

-Erik

Quote:

---

Originally Posted by egawtry

On the contrary, I use MFC because I can do low level programming with it at the same time have all the nice prepackaged GUI items.

I agree it is nearly impossible to do low level programming with .NET. Of course, it is also almost impossible to debug .NET as well.



And I suppose you think Visual Basic is a real language for commercial apps. :sick:

-Erik

---

Nice red herring, but we're not talking about Visual Basic.

I've been using Visual C++ for almost 20 years and making a pretty decent living at it. I couldn't write a Windows program using nothing but the Windows API to save my life. There's no reason to since there are several wrappers that make it much easier to use.

You see all the time people on this board recommending stl to beginners who are trying to write their own lists and manage dynamic arrays and such. Sure it's nice to know how to do that stuff but it's not essential, and more than likely information overload to a beginner. I don't think you'd find any regulars hear coding their own linked list for the same reason I doubt very many of us use nothing but the raw API. There are simply better, faster, easier ways to do it.

Quote:

---

Originally Posted by GCDEF

Nice red herring, but we're not talking about Visual Basic.

---

C# is like Visual Basic - for non-serious programmers.

Quote:

---

Originally Posted by GCDEF

I've been using Visual C++ for almost 20 years and making a pretty decent living at it. I couldn't write a Windows program using nothing but the Windows API to save my life. There's no reason to since there are several wrappers that make it much easier to use.

---

I have also been using it for 20 years, actually 22 years (MFC for 20 years). Almost every program I write I tweak at the Windows API level for speed and to fix bugs in MFC.

Harry, the orginal poster on this thread, wants to write games. You absolutely cannot write a real game without tweaking low level code. ALL professional developers should be able to modify things at the assembly level. None of the "well this works, so use it" crap. If a programmer doesn't know how something works, then do not use it without really, really protecting his/her backside.

-Erik

Quote:

---

Originally Posted by egawtry

Harry, the orginal poster on this thread, wants to write games. You absolutely cannot write a real game without tweaking low level code. ALL professional developers should be able to modify things at the assembly level. None of the "well this works, so use it" crap. If a programmer doesn't know how something works, then do not use it without really, really protecting his/her backside.

-Erik

---

I don't entirely agree. Yes, inner-loop optimization is a good skill to have; but that really only eeks out the last few milliseconds of performance. Most of your optimization improvements will come from simply choosing the right algorithm, and if a library has already implemented the algorithm or data structure you need, you may as well use it.

Save the low-level work (assembly if necessary, though I doubt that's often as much of a help these days as it used to be, compilers are pretty good now) for the 10% of the code that does 90% of the work. The other 90% of the code won't affect speed significantly, so just throw it together in the most robust way possible....which usually does not mean low-level coding.

Some code is speed-sensitive, but all code is bug-sensitive. Appropriate use of libraries and frameworks can reduce bug opportunities significantly.

Quote:

---

Originally Posted by Lindley

Some code is speed-sensitive, but all code is bug-sensitive. Appropriate use of libraries and frameworks can reduce bug opportunities significantly.

---

And while you're out there optimizing your assembly code and tweaking using the native APIs, your competitor will bet using .net or MFC and get to market way before you do. It's nice to know that stuff but for most work, it's just not essential or even practical.

Quote:

---

Originally Posted by egawtry

C# is like Visual Basic - for non-serious programmers.


-Erik

---

That's just silly.

Oh, I just pictured that serious programmer: an untidy beard with pizza crumbs in it, a beer spotted "I'm a total geek. You'll love me" T-shirt with the famous penguin, canvas pants, dusty leather sandals, an absent look. Yeah, such guys cannot even stand a smell of C#/VB... :D

Except for the beer, you got it. A good programmer uses Mountain Dew, Dr. Pepper, or Jolt. Since you are from Russia, I bet that is why you substitute beer. Kvass is just too disgusting, even for one of those guys, and Coke or Pepsi give a headache after only ten or so cans. Chai is just too weak. :D

Seriously, C# is a hack from Microsoft because they lost the Java lawsuit (and I liked J++). Like VB, sure it works, but ONLY on Windows machines. Most real RPG games these days are cross-platform which means C, C++, or Java. Java is a bit slow for RPG, so we are talking C or C++. If MS released C# under gnu license, then I might take it more seriously...

-Erik

I picture Harry shaking his head wondering *** happened to his thread.
As far as the rest goes.....I have to give the edge to Egawtry.

Quote:

---

Originally Posted by GCDEF

And while you're out there optimizing your assembly code and tweaking using the native APIs, your competitor will bet using .net or MFC and get to market way before you do. It's nice to know that stuff but for most work, it's just not essential or even practical.

---

Depends on what you are doing. If you are writing a office app to transfer specific data using SOAP or something like that, C# or unoptimized MFC is great. If you are writing a game like Harry (the orginal poster) then you need to do low level tweaking. Last RPG I worked on, I had to really tweak code to get the laser gun sound to match the screen graphic, there was too much latency in the standard code.

-Erik

Quote:

---

Originally Posted by egawtry

Depends on what you are doing. If you are writing a office app to transfer specific data using SOAP or something like that, C# or unoptimized MFC is great. If you are writing a game like Harry (the orginal poster) then you need to do low level tweaking. Last RPG I worked on, I had to really tweak code to get the laser gun sound to match the screen graphic, there was too much latency in the standard code.

-Erik

---

in this, I agree

one should always specify the programming area he's speaking of, because we're not ultimately interested on the absolute performance ( = the time needed to complete an operation ), we're interested in the "value" of performance, and in turn the latter can be a non linear function of the former.

an example is the latency Egawtry alluded to: double/half the sound latency doesn't mean half/double the gamer satisfaction, because there's a sharp cutoff separating a synchronized from an unsynchronized sound; so, near the cutoff a small absolute performance increase translates into a big performance value increase, away from the cutoff the opposite occurs ...