Jump to content

  • Log In with Google      Sign In   
  • Create Account

Is it a good choice to practice the old skool programming methods ?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Zoltar26   Members   -  Reputation: 103

Like
0Likes
Like

Posted 22 January 2012 - 03:10 AM

Hi,

I would like to consult with you if it's a good choice to learn c / c++ game programming in the old DOS environment fashion ?
Is it a waste of time in our days or rather a good practice to sharpen my programming skills ?
Thanks in advance.

Sponsor:

#2 FoxC   Members   -  Reputation: 100

Like
0Likes
Like

Posted 22 January 2012 - 03:29 AM

It really depends on what you mean by "DOS environment fashion". I don't really recommend trying to get any of those old libraries running, or even coding a game as a console project (unless it's a text based game), as none of the libraries and such are really going to teach you anything that you couldn't learn from modern libraries. I DO however recommend training yourself to be very frugal with memory and cpu consumption, as I've seen too many programmers nowadays taking advantage of modern computing power, and they forget just how quickly those resources can dwindle. I've found it's much more beneficial to really learn good programming practices *before* you try to get into game development, because knowing how to create proper, efficient object oriented code is the best foundation, not necessarily the game coding practices themselves. Get a good library like SDL, or microsoft's XNA, so you can focus more on the coding practices and less on the mechanics of how a game works to get started, then you can move up to opengl or directx coding when you feel more confident in your abilities. I can't stress enough efficient coding practices though, I like to program on an old laptop with limited memory and processing power, because if I can get a game running without any hiccups on that, then I know it won't have any problems on more modern machines. + 2 cents

#3 Telastyn   Crossbones+   -  Reputation: 3730

Like
0Likes
Like

Posted 22 January 2012 - 08:03 AM

It is rarely a good choice to learn c++ if you're posting in for beginners.

It *is* a good idea to get a solid programming foundation before starting in with graphical libraries.

#4 mhagain   Crossbones+   -  Reputation: 8276

Like
2Likes
Like

Posted 22 January 2012 - 02:52 PM

Console mode programs are useful things even when you've got some experience under you're belt. I've an entire library of test programs for various scenarios, and I'd guess that maybe 75% of them are console mode.

The big advantage of console mode for beginners is that it lets you focus on the important stuff - algorithms and program structure - without being distracted or confused by having to also deal with UI code. An incredible amount of commercial console-mode programs still get released every year, and many of them are even fairly large (and expensive!) "enterprise-class" tools. So console mode is most definitely far from dead, and it's difficult to see it ever being so.

The advice about being frugal with memory and CPU is good, but don't make it a religion. In a real program you'll often find yourself in situations where you're doing what looks on the surface like it's "wasting memory", but in reality it's part of a tradeoff, the other side of which is increased performance elsewhere. A more balanced approach is best IMO, where you view memory as a resource that's there to be used, but you don't go unnecessarily nuts with it (same applies to CPU).

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#5 Bacterius   Crossbones+   -  Reputation: 9267

Like
0Likes
Like

Posted 27 January 2012 - 03:34 AM

The advice about being frugal with memory and CPU is good, but don't make it a religion. In a real program you'll often find yourself in situations where you're doing what looks on the surface like it's "wasting memory", but in reality it's part of a tradeoff, the other side of which is increased performance elsewhere. A more balanced approach is best IMO, where you view memory as a resource that's there to be used, but you don't go unnecessarily nuts with it (same applies to CPU).

This is very true, a classic example being large precomputed tables. A novice programmer will go "this is faster, it's just a memory lookup, memory is there to be used", whereas somebody with more experience will actually realize the table will be too large to fit in the CPU cache, causing cache misses to occur a lot more and introducing memory latency in the equation, which may negatively impact other areas of the program in a way which might not be immediately obvious. Same deal with spending hours optimizing away a part of the program which only represents 1% of its running time...

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS