LinkBack URL
About LinkBacksI have, it works just fine.Originally Posted by happytechie
OO is a useful tool, but it's not "The One True Programming Style" or anything.
I have, it works just fine.
OO is a useful tool, but it's not "The One True Programming Style" or anything.
If you want to get into game programming, get yourself a flash card and a ds and learn on that. There are a number of homebrew libraries for it, including the popular PaLib. You can also code using C++ and the nds library if you want to mess with more low level stuff. (PaLib is also a C++ library)
Last edited by Whiternoise; 12-05-2008 at 12:10 AM.
I disagree, having been games programming for 6 years now, I still really enjoy it.Have to chime in again with my negative views..
Games programming is some of the most boring programming I have come across in my 3 years of Uni. I actually was on Game Programming for a semester and had to swap to computer science as it was so dull and in my particular university, badly taught imo.
But it's definitely something you have to enjoy to get on with - if you don't like it, don't even try to get into games, there's better money to be made elsewhere. Games is quite competitive too, especially at graduate level.
Games dev courses are largely useless IME - you're just as likely to get a job with a normal CS degree as with a games specific degree.
FWIW, C++ is definitely still the gamedev language of choice, by far.
He used to write software used for keeping aeroplanes up in the air using it IIRC
Indeed, the only people i've come accross who sing the merrits of haskel, are almost always from Imperial!
Modular developement, even assiging ownership and responisibility to a function (method or procedure) level is common. The language, or design paradign should have no problem fitting in.
As for jobs determining your language, theres no garentee that the job market will be the same in 2 years time. There was a major C++ shortage in finance 3 months ago, but now thanks largerly to layoff of middle office staff, there seams to be a practical glut, in no small way due to one firm. My point is that you should really try to master the concepts behind as many different languages as possible, you should be able to switch between C# and Java with absolute ease. But without a through understanding you can't go between CameL and C#.
I'd have to strongly agree, with a lot of these specialist courses it seams that no one actually gets a job with them.
The thing is enjoying it is largely dependant on the company you work for. Guessing yours isn't an EA slave driven one.
throw new ArgumentException (String, String, Exception)
the core of game programming is hard - lots of nasty physics stuff, time-dependent, etc. there's a reason game programming wasn't a module until 4th year at southampton. and that most game engines are horrible messes that would make you run in terror
I've been spending far too long immersed in Java at the moment, and have been proving exactly why it is good to learn both a weakly typed language like C/C++ and a more strongly typed one like Java (although Java's typing system isn't quite as complete).
Unless you learn both, the differences between the two forms will drive you completely and utterly up the wall and result in all kinds of annoyances in adapting across.
Either you'll end up desiring the proper code layout of of the full type conversions or checks when having to code in a weakly typed language, or find yourself having to use a strongly typed one and being driven crazy by having to do that
Argh!
In what way is C++ weakly typed?
For a given Object o:
C++ allows:
if (o) {...}
Whereas Java forces
if (o != null) {...}
Also, checking for a valid return in C++ can be done via
if (result = functioncall() ) {...}
whereas Java similarly requires that you convert to a boolean
if (0 != (result = functioncall()) {..}
The difference is that C++ lets you treat almost anything as a boolean operation. Partially this is down to the pointer based implementation, however that happens at a later stage - the compiler has access to all the information it needs to be more strongly typed.
Compared to some weakly and strongly are comparisons, so C++ is definately stronger typed than some other languages, yes, but compared to newer ones it is weak.
And I should note that the C++ examples above are probably best considered poor practice, as explicit coding is better than implicit. Having learnt to program via Object Pascal (Delphi), I used to prefer the explicit form. However I have become overly used to the implicit form, and there is a certain beauty and simplicity to it once you understand how it works.
Ah to be fair this isn't week typing, this is one of my pet hates.
Implicit Casts.
ie, its perfectly fine to convert a byte upto an int without the need for an explicit cast, because no loss of data will occur.
And this has some great useages, for instance in C# say one has a dictionary, they have a class which has a unique ID (for databasing) and you have about 100,000 of them. You can get a hudge increase by creating a struct (which isn't a reference type, litterally stored) which consists of the unique id, and a pointer to the class. You then declair the dictionary to be indexed by the struct. Define an implict cast for going from the class to the struct. You can then have amazing performance in your hashing, without anyone who uses that dictionary realise whats going on. This is a really nice change that can be made to existing code bases, that leverages implicit casting well.
sticking with .Net (as it is my true love) we can find an AWFUL AWFUL AWFUL use of an implicit cast in a strongly typed language.
Lots of SQL systems can't store datetimes that go beyound a certain point. The Native DateTime can. So you might think you want something like
DateTime dateTimeInput = DateTime.MinValue;
if (dateTimeInput < SqlDateTime.MinValue)
dateTimeInput = SqlDateTime.MinValue;
would ensure that dateTimeInput was never below the bounds of the database server.
its not. Because some utter rubbishrubbishrubbishrubbish, put an implicit cast conversion going from DateTime to SqlDateTime. Meaning you get an arithmetic overflow as the compiler sees
if (SqlDateTime)dateTimeInput < SqlDateTime.MinValue)
This is why implicit casting is bad.
Also you can get a performance hit as you stop certain optomisations in a C++ compiler when you go from a bool to a short say.
throw new ArgumentException (String, String, Exception)
Yes, implicit casting indeed = meh. Although I do rather like the way 0 is false and everything else is true in C++.
C++ is a strongly typed language. Look at Python, for instance, if you want a weakly typed one. I've had plenty of headaches wrapping a C++ library in Python due to Python's weak typing. Grrr.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote
