So I gather we have some of these in here somewhere?

Of course "games programming" sounds fun and exciting, and from what I 
can gather *everybody* wants to be doing it. But what is it *really* 
like, and what kind of thing do developers really look for when hiring?

Mainly I'm just being nosey. ;-)

(As some of you may remember, the careers advice guy said I should 
consider games programming. Personally I think it's a pretty absurd 
idea. If there's this many people wanting to get in, it must be pretty 
competetive. And presumably being hyper-fluent in C and/or C++ is an 
absolute mandatory requirement. Both of these things pretty much 
instantly rule me out completely...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message
news:48c63073$1@news.povray.org...
> So I gather we have some of these in here somewhere?
>
> Of course "games programming" sounds fun and exciting, and from what I can
> gather *everybody* wants to be doing it. But what is it *really* like, and
> what kind of thing do developers really look for when hiring?
>

They are really pushing games programming here. They've even started a
course in the high school's here. The part that bugs me is that it's called
Information Technology around here. I keep trying to coin a new term
(Entertainment Technology) but it hasn't taken hold. I guess that's the "old
school" in me that see's Information Technology in a more traditional sense.
>
> And presumably being hyper-fluent in C and/or C++ is an absolute mandatory
> requirement. Both of these things pretty much instantly rule me out
> completely...)

You should see the looks I get when I say that I'm fluent in fortran, ada,
and pascal, so I guess you're right about that!

Cheers Jim

Post a reply to this message

Jim Holsenback wrote:

> They are really pushing games programming here. They've even started a
> course in the high school's here. The part that bugs me is that it's called
> Information Technology around here. I keep trying to coin a new term
> (Entertainment Technology) but it hasn't taken hold. I guess that's the "old
> school" in me that see's Information Technology in a more traditional sense.

Hmm. Becuase there's a *really big market* for games programmers, right?

<cynic>Or rather, there's a really big market for students who want to 
study games programming.</cynic>

> You should see the looks I get when I say that I'm fluent in fortran, ada,
> and pascal, so I guess you're right about that!

Next time - just for giggles - tell then you're fluent in "Haskell" and 
see what kind of a reaction that gets. ;-)

(Alternatively, try "Lisp". People have at least *heard* of that...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

And lo on Tue, 09 Sep 2008 09:45:07 +0100, Jim Holsenback  
<jho### [at] hotmailcom> did spake, saying:

> They are really pushing games programming here. They've even started a
> course in the high school's here. The part that bugs me is that it's  
> called
> Information Technology around here. I keep trying to coin a new term
> (Entertainment Technology) but it hasn't taken hold. I guess that's the  
> "old school" in me that see's Information Technology in a more  
> traditional sense.

I think it was in Edge magazine one of the developers lashed into these  
'cool' games programming lessons saying they were a waste of time and  
you'd be better of with a Mathematics course and plain old Computer  
Science. They want people who can produce path-finding algorithms and  
other AI routines not have a degree in level design, you can get the  
equivalent of that just from playing games a lot.

-- 
Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message

Phil Cook wrote:

> I think it was in Edge magazine one of the developers lashed into these 
> 'cool' games programming lessons saying they were a waste of time and 
> you'd be better of with a Mathematics course and plain old Computer 
> Science. They want people who can produce path-finding algorithms and 
> other AI routines not have a degree in level design, you can get the 
> equivalent of that just from playing games a lot.

Wait - there's a course you can take that just involves playing games a 
lot? SIGN ME UP! :-D

(But yeah, I'm sure *real* game design isn't nearly as interesting as it 
sounds. Listening to the commentary on HL2:EP2, most of it sounds pretty 
mundane.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

And lo on Tue, 09 Sep 2008 12:44:10 +0100, Invisible <voi### [at] devnull> did  
spake, saying:

> Phil Cook wrote:
>
>> I think it was in Edge magazine one of the developers lashed into these  
>> 'cool' games programming lessons saying they were a waste of time and  
>> you'd be better of with a Mathematics course and plain old Computer  
>> Science. They want people who can produce path-finding algorithms and  
>> other AI routines not have a degree in level design, you can get the  
>> equivalent of that just from playing games a lot.
>
> Wait - there's a course you can take that just involves playing games a  
> lot? SIGN ME UP! :-D
>
> (But yeah, I'm sure *real* game design isn't nearly as interesting as it  
> sounds. Listening to the commentary on HL2:EP2, most of it sounds pretty  
> mundane.)

Apparently it's the same with being a game tester, repeating the same  
section over and over again in various minor different ways until it  
breaks.

-- 
Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message

>> (But yeah, I'm sure *real* game design isn't nearly as interesting as 
>> it sounds. Listening to the commentary on HL2:EP2, most of it sounds 
>> pretty mundane.)
> 
> Apparently it's the same with being a game tester, repeating the same 
> section over and over again in various minor different ways until it 
> breaks.

Yeah - generally they don't just go "hey, play this game, tell us if 
it's fun or not". They want to know something more specific than that.

Again, listening to the commentary from HL2:EP2, they tell you stuff 
like "this map used to be like X, but we found that playtesters would 
get here and not be able to figure out what they're supposed to do, so 
after a few iterations trying various things we made it like Y, and 
playtesters responded much better to that".

So yeah. They want to know if the game is fun. But if it isn't, they 
want to know specifically *why* so that they can actually *fix* it...

(And I'm sure they also have other people who just play and play and 
play the game and see if it crashes or glitches in some way. And still 
other people who try it on various hardware. And yet others who try to 
climb out of the levels or throw switches in the wrong order to see what 
happens. Damn, making games has gotta be real expensive...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Of course "games programming" sounds fun and exciting, and from what I 
> can gather *everybody* wants to be doing it. But what is it *really* 
> like, and what kind of thing do developers really look for when hiring?

  I think we should distinguish between different types of game programming.
The game programming industry can be divided, very roughly, into two
categories:

1) Big game houses, ie. those which develop games like Doom3 and HL2.

2) Small game houses, ie. those which develop small casual games
   (http://en.wikipedia.org/wiki/Casual_game)

  In the first case budgets are often rather humongous, teams relatively
large (at least a dozen programmers and artists, some kind of management
hierarchy between the different departments, etc.), and development times
which are often counted in years. The development language of the core game
engine is most often C++, in a few cases perhaps with some C, and perhaps
in rare cases some other language. Games often have an internal scripting
language for non-core features, and this can be either an existing language
(such as lua) or the company's own language.

  In the second case budgets, teams and timelines are much smaller, and
the development language of the core game code much more varied. It can
range all the way from C/C++ to Flash ActionScript. Development teams
typically consist of one programmer (or at most a very few) and 2-3
graphics artists, plus perhaps some project leader (who may be a separate
person or one of the main developers).

  I have never worked in a big game company, but from what I have heard
(I have a friend who has worked in several such companies, including
Ubisoft), the development procedures are ofteh much less strict than one
could imagine for such a big software company. I have got the impression
that so-called cowboy coding is much more usual even in very big game
companies than one would think (even to the point of becoming detrimental
and causing problems in some cases).

  Naturally cowboy coding is more or less self-evident in the small game
houses, where there's typically one single lead programmer and nothing
else, and projects are relatively small. I suppose that in many cases
it doesn't really matter how you do it, as long as it works. (But
personally I try to avoid this, and try to develop things so that they
are stable, safe, easy to use and reusable.)

  Most game companies, when they are hiring, always accentuate the
importance of communication. They always state that the applicant should
be fluent in English (or whichever the local language might be) and have
good communication and teamwork skills. Big game companies probably
accentuate this more than smaller ones. I suppose it depends on the
company (and on the applicants) how strongly they really impose this
requirement. I have heard of cases where it's not imposed at all, and
that people who are very poor at the company's native language are hired
anyways. Other companies may have a stricter policy (which may also
heavily depend on who is the project leader).

  If you are applying to a big game company, knowing C++ fluently (as well
as its internal workings) will probably help. It also helps if you have
experience in computer graphics and algorithm programming. Knowing other
popular languages won't hurt either. Extensive programming experience in
general, and game programming experience in particular, is also good.

  For the smaller companies I suppose it depends a lot on which programming
language they are using. It's quite clear that if they are developing Flash
games and you don't even know what ActionScript is, that won't look good.

  In both cases knowledge and experience of the gaming field in general
is important, as well as an interest in developing games. (Everyone likes
to *play* games, but how many *really* enjoy programming them? Programming
games can be much more tedious than it might sound.)

-- 
                                                          - Warp

Post a reply to this message

And lo on Tue, 09 Sep 2008 15:05:25 +0100, Invisible <voi### [at] devnull> did  
spake, saying:

>>> (But yeah, I'm sure *real* game design isn't nearly as interesting as  
>>> it sounds. Listening to the commentary on HL2:EP2, most of it sounds  
>>> pretty mundane.)
>>  Apparently it's the same with being a game tester, repeating the same  
>> section over and over again in various minor different ways until it  
>> breaks.
>
> Yeah - generally they don't just go "hey, play this game, tell us if  
> it's fun or not". They want to know something more specific than that.

Damn their oily hides.

> Again, listening to the commentary from HL2:EP2, they tell you stuff  
> like "this map used to be like X, but we found that playtesters would  
> get here and not be able to figure out what they're supposed to do, so  
> after a few iterations trying various things we made it like Y, and  
> playtesters responded much better to that".
>
> So yeah. They want to know if the game is fun. But if it isn't, they  
> want to know specifically *why* so that they can actually *fix* it...

Heh I like the Simpsons game that pops up the Comic Book Guy with a cliche  
"Steep Slope Barrier - You would know this was impossible if you’d ever  
actually been outside."

> (And I'm sure they also have other people who just play and play and  
> play the game and see if it crashes or glitches in some way. And still  
> other people who try it on various hardware. And yet others who try to  
> climb out of the levels or throw switches in the wrong order to see what  
> happens. Damn, making games has gotta be real expensive...)

Well let me think. I've got trapped in Oblivion unable to climb back over  
some (really small) rocks, again in Oblivion I can't deal with a character  
because I refused a request of his despite the fact I'm disguised so he  
shouldn't know it's me. I've slipped through a seam in the world in  
Resistance FOM. Skipped the entire penultimate level in Jak and Daxter by  
accident.

I've laughed out loud at the pathetic AI in Killzone that allowed me to  
snipe a group of enemies without any of them noticing. In reverse got  
annoyed with the AI in Mercenaries that had every enemy pinpoint my  
location as soon as I shot someone from a distance of half a mile away,  
and I've defeated the big bad in Lego Star Wars in about 10 seconds due to  
an AI bug.

Sometimes you can say 'yeah okay I'm not surprised that got missed' but at  
other times you've got to wonder who was testing the game. I'm still  
wondering how either TimeShift or Haze managed to get released with the  
state they're in.

-- 
Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message

Warp wrote:

>   I think we should distinguish between different types of game programming.
> The game programming industry can be divided, very roughly, into two
> categories:
> 
> 1) Big game houses, ie. those which develop games like Doom3 and HL2.
> 
> 2) Small game houses, ie. those which develop small casual games
>    (http://en.wikipedia.org/wiki/Casual_game)
> 
>   In the first case budgets are often rather humongous, teams relatively
> large (at least a dozen programmers and artists, some kind of management
> hierarchy between the different departments, etc.), and development times
> which are often counted in years. The development language of the core game
> engine is most often C++, in a few cases perhaps with some C, and perhaps
> in rare cases some other language. Games often have an internal scripting
> language for non-core features, and this can be either an existing language
> (such as lua) or the company's own language.
> 
>   In the second case budgets, teams and timelines are much smaller, and
> the development language of the core game code much more varied. It can
> range all the way from C/C++ to Flash ActionScript. Development teams
> typically consist of one programmer (or at most a very few) and 2-3
> graphics artists, plus perhaps some project leader (who may be a separate
> person or one of the main developers).

Right. Gotcha.

>   I have never worked in a big game company, but from what I have heard
> (I have a friend who has worked in several such companies, including
> Ubisoft), the development procedures are often much less strict than one
> could imagine for such a big software company.

That would certainly explain a few things...

> I suppose that in many cases
> it doesn't really matter how you do it, as long as it works. (But
> personally I try to avoid this, and try to develop things so that they
> are stable, safe, easy to use and reusable.)

Always the best way, IMHO. You never know when you'll need to change 
something, and if it's a mess you'll have a hard time altering without 
breaking...

>   If you are applying to a big game company, knowing C++ fluently (as well
> as its internal workings) will probably help. It also helps if you have
> experience in computer graphics and algorithm programming. Knowing other
> popular languages won't hurt either. Extensive programming experience in
> general, and game programming experience in particular, is also good.
> 
>   For the smaller companies I suppose it depends a lot on which programming
> language they are using. It's quite clear that if they are developing Flash
> games and you don't even know what ActionScript is, that won't look good.
> 
>   In both cases knowledge and experience of the gaming field in general
> is important, as well as an interest in developing games. (Everyone likes
> to *play* games, but how many *really* enjoy programming them? Programming
> games can be much more tedious than it might sound.)

Thanks for your input.

I'm still fairly sure I don't have what it takes, but casual gaming 
isn't something I'd considered. Maybe it's not as impossible as I'd 
imagined. Hmm... something to think about anyway.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I'm still fairly sure I don't have what it takes, but casual gaming 
> isn't something I'd considered. Maybe it's not as impossible as I'd 
> imagined. Hmm... something to think about anyway.

  Be careful, though: If you go into casual gaming, there's a high
probability that you will have to develop games for the iPhone, which
is probably against your deepest principles. ;)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Be careful, though: If you go into casual gaming, there's a high
> probability that you will have to develop games for the iPhone, which
> is probably against your deepest principles. ;)

Oh noes! ._.

Seriously though... if they're going to *give* me an iPhone to test it 
with, I think I can probably live with that. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Seriously though... if they're going to *give* me an iPhone to test it 
> with, I think I can probably live with that. ;-)

  The thing is, you don't only need an iPhone, you also need a Mac...

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> Seriously though... if they're going to *give* me an iPhone to test it 
>> with, I think I can probably live with that. ;-)
> 
>   The thing is, you don't only need an iPhone, you also need a Mac...

Really? There isn't some iPhone SDK that just gives you an emulator?

Oh well, I guess getting a Mac too would be a bonus. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> (But yeah, I'm sure *real* game design isn't nearly as interesting as it 
> sounds. Listening to the commentary on HL2:EP2, most of it sounds pretty 
> mundane.)

Do you fancy trying to write a fast, realistic looking, and robust collision 
engine for meshes in 3D?  I could certainly do with some improvements in the 
game I've been writing in my spare time - and I'm fed up with the actual 
coding (I have lots of ideas, just can't be bothered to actually sit down 
and code them).  Oh and the AI needs improving quite a bit.

Maybe I should employ a game programmer? ;-)

Post a reply to this message

scott wrote:

> Do you fancy trying to write a fast, realistic looking, and robust 
> collision engine for meshes in 3D?  I could certainly do with some 
> improvements in the game I've been writing in my spare time - and I'm 
> fed up with the actual coding (I have lots of ideas, just can't be 
> bothered to actually sit down and code them).  Oh and the AI needs 
> improving quite a bit.
> 
> Maybe I should employ a game programmer? ;-)

Yeah. :-P

Correct me if I'm wrong, but don't game engines "usually" use an 
invisible skeleton rather than the actual visible polygon mesh for 
collision detection purposes? (Precisely to simplify the problem and 
make it tractable in realtime.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Warp wrote:
> > Orchid XP v8 <voi### [at] devnull> wrote:
> >> Seriously though... if they're going to *give* me an iPhone to test it 
> >> with, I think I can probably live with that. ;-)
> > 
> >   The thing is, you don't only need an iPhone, you also need a Mac...

> Really? There isn't some iPhone SDK that just gives you an emulator?

  There is. For the Mac.

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] laptopcom> wrote:
> Do you fancy trying to write a fast, realistic looking, and robust collision 
> engine for meshes in 3D?

  Why reinvent the wheel, when there are lots of such libraries already
available and widely used in games?

-- 
                                                          - Warp

Post a reply to this message

>> Really? There isn't some iPhone SDK that just gives you an emulator?
> 
>   There is. For the Mac.

...HAHAHAHAHA!

Ah, it's good to be alive... :-D

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> Do you fancy trying to write a fast, realistic looking, and robust 
>> collision
>> engine for meshes in 3D?
>
>  Why reinvent the wheel, when there are lots of such libraries already
> available and widely used in games?

Because I enjoy coding and learning from it.  I'm writing this for fun, not 
in order to make the maximum profit with the least work from my side!

Post a reply to this message

> Correct me if I'm wrong, but don't game engines "usually" use an invisible 
> skeleton rather than the actual visible polygon mesh for collision 
> detection purposes? (Precisely to simplify the problem and make it 
> tractable in realtime.)

No, you're completely correct, in fact I'm already doing that in my game. 
The problem I have now is that because my physics loop runs at 100 Hz and 
some objects are moving quite quickly (like a metre per physics step) it's 
hard to determine exactly where the collision took place, and hence 
calculate the correct impulse to stop them intersecting at the next step.  I 
don't have enough CPU cycles spare to roll back the simulation with a finer 
time step, so I'm just using some hackery to estimate it for now.  It works 
ok most of the time, and things bounce and spin off nicely in 3D, but 
occasionally one object visibly goes inside another for a bit.  I'm sure 
with a bit more hackery I can make it more robust without having to do more 
physics steps.  Then I need to optimise the collision *detection*, as it 
gets a bit slow when 10 or so objects are colliding simultaneously.

Post a reply to this message

>> Correct me if I'm wrong, but don't game engines "usually" use an 
>> invisible skeleton rather than the actual visible polygon mesh for 
>> collision detection purposes? (Precisely to simplify the problem and 
>> make it tractable in realtime.)
> 
> No, you're completely correct, in fact I'm already doing that in my 
> game.

Yay for me!

> The problem I have now is that because my physics loop runs at 100 
> Hz and some objects are moving quite quickly (like a metre per physics 
> step) it's hard to determine exactly where the collision took place, and 
> hence calculate the correct impulse to stop them intersecting at the 
> next step.  I don't have enough CPU cycles spare to roll back the 
> simulation with a finer time step, so I'm just using some hackery to 
> estimate it for now.

I was under the impression that this is pretty much standard procedure; 
compute the path of an object for the next few split seconds and see if 
it intersects the path of anything else. Otherwise objects would have to 
collide exactly on the bounderies of your time steps - which is, uh, 
"improbable". ;-)

> It works ok most of the time, and things bounce 
> and spin off nicely in 3D, but occasionally one object visibly goes 
> inside another for a bit.

That's nothing! With the Havok physics engine, sometimes objects hit the 
ground and flail around indefinitely. (Presumably the engine trying to 
prevent the object intersecting the ground.) Sometimes objects just keep 
jiggling and won't stop - and sometimes the movement is quite significant.

> I'm sure with a bit more hackery I can make 
> it more robust without having to do more physics steps.  Then I need to 
> optimise the collision *detection*, as it gets a bit slow when 10 or so 
> objects are colliding simultaneously.

Uh, yeah, I have no idea how to fix that...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> So I gather we have some of these in here somewhere?

I dabble. I've worked out the timing issues, which is a big step, but I 
still haven't released a full-featured game because DirectX looks 
different depending on the hardware used to view it.

> If there's this many people wanting to get in, it must be pretty 
> competetive. 

It's bad enough wanting to do graphics for a living. There are plenty of 
people clamoring for what few jobs there are... Fortunately, many of 
those loud people aren't very good at their jobs ;)

About games programming. If you really want to do something, do it alone 
and in your spare time. Come up with something special, and you might 
become another success story like the developers of Cave Story, Crayon 
Physics, Fez... some of these guys have won large cash prizes for simply 
being good at what they do in their spare time. Companies are contacting 
*them*, not the other way around.

BTW, Fez looks like a game I might actually buy. Cool-looking stuff...

Sam

Post a reply to this message

> I was under the impression that this is pretty much standard procedure; 
> compute the path of an object for the next few split seconds and see if it 
> intersects the path of anything else.

Well yes, but I can't do the full simulation any more often because it's 
already too slow (simulating car tyres accurately and suspension for several 
cars is not fast!).  What I think I could do is to wait until a normal 
physics step indicates two objects are colliding (it is unlikely they would 
completely miss each other, unless travelling very fast or only just 
"scraping" a corner at speed, both of which I think I can ignore for now). 
Then, assume constant velocity and work backwards until the two objects are 
*just* touching.  Do the same for any other collisions, then find the 
earliest collision in time, apply the repelling impulses and do a full 
physics step from that time onwards.  Then repeat the above until no more 
collisions are found in that time period.  Hopefully that will not require 
too many more physics steps and should avoid things going wrong with fast 
objects.

> Otherwise objects would have to collide exactly on the bounderies of your 
> time steps - which is, uh, "improbable". ;-)

Well currently I just detect if they are intersecting and moving towards 
each other, and if they are apply an impulse to each object to separate 
them.

> That's nothing! With the Havok physics engine, sometimes objects hit the 
> ground and flail around indefinitely. (Presumably the engine trying to 
> prevent the object intersecting the ground.) Sometimes objects just keep 
> jiggling and won't stop - and sometimes the movement is quite significant.

Yep!

>> I'm sure with a bit more hackery I can make it more robust without having 
>> to do more physics steps.  Then I need to optimise the collision 
>> *detection*, as it gets a bit slow when 10 or so objects are colliding 
>> simultaneously.
>
> Uh, yeah, I have no idea how to fix that...

Need to implement some sort of LOD / binary tree of the collision mesh, at 
the moment I just test every face of the mesh against every other face once 
the objects' bounding spheres are intersecting.

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> I'm still fairly sure I don't have what it takes, but casual gaming 
>> isn't something I'd considered. Maybe it's not as impossible as I'd 
>> imagined. Hmm... something to think about anyway.
> 
>   Be careful, though: If you go into casual gaming, there's a high
> probability that you will have to develop games for the iPhone, which
> is probably against your deepest principles. ;)
> 

Or Flash. And a bit of Flash development goes on on Macs.


I keep hoping to get used to the difference. One would think that Adobe 
would make a smooth transition between the two platforms, but no. Alt+F9 
is now apple+F9, but CTRL+F8 maps to Alt+T or something like that. I 
forget the actual keys that are mixed up, Adobe has trained me to slow 
down and go back to the mouse.

Post a reply to this message

"Orchid XP v8" <voi### [at] devnull> wrote in message 
news:48c6cc58$1@news.povray.org...


>> It works ok most of the time, and things bounce and spin off nicely in 
>> 3D, but occasionally one object visibly goes inside another for a bit.
>
> That's nothing! With the Havok physics engine, sometimes objects hit the 
> ground and flail around indefinitely. (Presumably the engine trying to 
> prevent the object intersecting the ground.) Sometimes objects just keep 
> jiggling and won't stop - and sometimes the movement is quite significant.

    Yeah, that's quite standard in games at the moment from what I've 
experienced. In Crysis, I've thrown a grenade at an NK, killed him, and he's 
been catapulted through a building wall - only to be stuck in that portion 
of the wall. Very funny to watch. :)

 See this vid: http://www.youtube.com/watch?v=6vK3CfiYCao

  Is this down to programming?


    ~Steve~



>
> -- 
> http://blog.orphi.me.uk/
> http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> (As some of you may remember, the careers advice guy said I should 
> consider games programming. Personally I think it's a pretty absurd idea. 
> If there's this many people wanting to get in, it must be pretty 
> competetive. And presumably being hyper-fluent in C and/or C++ is an 
> absolute mandatory requirement. Both of these things pretty much instantly 
> rule me out completely...)

If you can learn an obscure language like Haskell, you can learn C++. If you 
learned C++, or maybe Java if you preferred, you could use that skill to get 
a job you would like (games or not). Why don't you put the time into it? I 
had a lot of fun with C++ and OpenGL in college. It's really not that hard 
to learn for someone like you.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

And lo on Tue, 09 Sep 2008 19:48:55 +0100, Warp <war### [at] tagpovrayorg> did  
spake, saying:

> scott <sco### [at] laptopcom> wrote:
>> Do you fancy trying to write a fast, realistic looking, and robust  
>> collision
>> engine for meshes in 3D?
>
>   Why reinvent the wheel, when there are lots of such libraries already
> available and widely used in games?

Because you might end up with a better wheel or even a hover-bike :-)

-- 
Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:
> If you can learn an obscure language like Haskell, you can learn C++. If you 
> learned C++, or maybe Java if you preferred, you could use that skill to get 
> a job you would like (games or not). Why don't you put the time into it? I 
> had a lot of fun with C++ and OpenGL in college. It's really not that hard 
> to learn for someone like you.

  The big problem with someone who has programmed almost exclusively with
a language like Haskell for the past years is that he will be very biased
towards the features and strong points of that language, and will then be
constantly pulling his hair when trying to code something in C++. "Why do
I have to do it like this? It's stupid. Why can't I do it like in Haskell?"

-- 
                                                          - Warp

Post a reply to this message

stbenge wrote:
> BTW, Fez looks like a game I might actually buy. Cool-looking stuff...

I had not heard of Fez before, but I agree that it does look like it has 
some pretty good potential.  It looks sort of like like a super-fancy 
Cave Story, so hopefully the actual gameplay will be of as high a 
quality as well.  Thanks for alerting me its existence!

Post a reply to this message

Warp wrote:


>   Why reinvent the wheel, when there are lots of such libraries already
> available and widely used in games?
> 

Have you used those libraries? Most are undocumented, unfinished, 
undesiable or COSTs. What's worst is you don't know what you got until 
you try and to use them.

Post a reply to this message

Slime wrote:

> If you can learn an obscure language like Haskell, you can learn C++.

I see. And what do you base this observation on?

Haskell is a small, simple, logical language. C++ is a huge, messy, 
complex language. I don't see how learning an easy language should 
enable me to learn a hard language.

> If you 
> learned C++, or maybe Java if you preferred, you could use that skill to get 
> a job you would like (games or not).

I already *know* Java. ;-)

(Although it sounds like they've added a few new language features since 
I used it. And I am 100% certain that most of the APIs I know have been 
deprecated, undeprecated, and redeprecated at least twice by now. For 
some reason, the Java guys like to completely change all the APIs with 
each minor release...)

> Why don't you put the time into it?

What makes you think I haven't?

Actually, at college we spent a whole semester programming in C. I'm 
sure I've recounted the tale before. Basically C is a language designed 
for experts. If you do something dumb, it will make absolutely no 
attempt to save you. It will just merrily produce garbage, and leave you 
with no hope of finding out why. Apparently there are people who know 
the Secret Techniques for debugging C programs, and even writing C 
programs that are correct in the first place - but this wasn't part of 
the syllabus.

 From what I've read, C++ is exactly like C, but 80% more complicated. 
Given that I could bearly produce working code in C with the tutor's 
help, my chances of getting anywhere with C++ are basically nil.

> I 
> had a lot of fun with C++ and OpenGL in college. It's really not that hard 
> to learn for someone like you.

As I say, the trouble is that if your program doesn't work, there is no 
way you can ever find out why. (Especially if you're using something 
like OpenGL. It's an extremely complicated API, and unless you pay money 
it's not possible to get hold of useful documentation.)

I've actually thought about trying to use OpenGL from Haskell, but I 
keep being put off by just how huge and complex the API is...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:

>   The big problem with someone who has programmed almost exclusively with
> a language like Haskell for the past years is that he will be very biased
> towards the features and strong points of that language, and will then be
> constantly pulling his hair when trying to code something in C++. "Why do
> I have to do it like this? It's stupid. Why can't I do it like in Haskell?"

Like this:

http://lukeplant.me.uk/blog.php?id=1107301645

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible a écrit :
> Apparently there are people who know 
> the Secret Techniques for debugging C programs

You mean putting some strategically placed printf's :-) ?

Seriously. Is that difficult?

-- 
Vincent

Post a reply to this message

Vincent Le Chevalier wrote:
> Invisible a écrit :
>> Apparently there are people who know the Secret Techniques for 
>> debugging C programs
> 
> You mean putting some strategically placed printf's :-) ?
> 
> Seriously. Is that difficult?

printf() is usually the part I'm trying to debug. (As in, it prints 
gibberish instead of printing what I was expecting.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible a écrit :
> Vincent Le Chevalier wrote:
>> Invisible a écrit :
>>> Apparently there are people who know the Secret Techniques for 
>>> debugging C programs
>>
>> You mean putting some strategically placed printf's :-) ?
>>
>> Seriously. Is that difficult?
> 
> printf() is usually the part I'm trying to debug. (As in, it prints 
> gibberish instead of printing what I was expecting.)
> 
Once you've figured how to put in the right format for the type you want 
to print, you know enough to debug. If you consider that this is harder 
than learning Haskell...

Hell, in C++ it's even easier as there is not even this problem of 
formats anymore...

-- 
Vincent

Post a reply to this message

>> printf() is usually the part I'm trying to debug. (As in, it prints 
>> gibberish instead of printing what I was expecting.)
>>
> Once you've figured how to put in the right format for the type you want 
> to print, you know enough to debug.

Well you'd think so, and yet even with the correct format strings, it 
doesn't always print what it's supposed to.

> If you consider that this is harder than learning Haskell...

I still don't get it: Learning Haskell is *easy*, not hard.

> Hell, in C++ it's even easier as there is not even this problem of 
> formats anymore...

So I hear. This presumably doesn't stop a program from segfaulting when 
you try to append a string from stdin to a string constant or some such.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible a écrit :
>> If you consider that this is harder than learning Haskell...
> 
> I still don't get it: Learning Haskell is *easy*, not hard.
> 

For some definition of easy and hard. Which may not be the same for 
everyone in this case :-) Ordinarily people choose the easiest way; yet 
Haskell does not get that many users.

> This presumably doesn't stop a program from segfaulting when 
> you try to append a string from stdin to a string constant or some such.

I figure that if you use the std::string class you're safe from that. I 
haven't tried, though.

-- 
Vincent

Post a reply to this message

>>> If you consider that this is harder than learning Haskell...
>>
>> I still don't get it: Learning Haskell is *easy*, not hard.
> 
> For some definition of easy and hard. Which may not be the same for 
> everyone in this case :-) Ordinarily people choose the easiest way; yet 
> Haskell does not get that many users.

Learning Haskell is like learning algebra; once you grasp a few basic 
principles, the rest follows from there. It isn't instantly obvious that 
(for example) the solution to ax^2 + bx + c = 0 is x = 1/2a (-b +/ 
Sqrt(b^2 - 4ac)), but if you know the basic principles you can at least 
verify that it works.

Learning C is like learning the works of Shakespear; you just have to 
memorise a huge wedge of stuff. If you come across something you haven't 
memorised... sorry.

As for ordinary people... I think you'll find they choose the *most 
popular* way, which may or may not actually be any good. ;-) (See 
Betamax vs VHS, IE vs Netscape, etc.)

I will say this: Haskell is a great *language*, but the *tools* for it 
are sadly lacking, as are the *libraries*. C may be one of the most 
horrid languages ever invented, but at least it has an insane collection 
of tools and libraries, the like of which few others can match.

>> This presumably doesn't stop a program from segfaulting when you try 
>> to append a string from stdin to a string constant or some such.
> 
> I figure that if you use the std::string class you're safe from that. I 
> haven't tried, though.

Wait... you mean they made it a class?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
>  From what I've read, C++ is exactly like C, but 80% more complicated. 
> Given that I could bearly produce working code in C with the tutor's 
> help, my chances of getting anywhere with C++ are basically nil.

	In terms of actual coding, in some ways C++ is simpler and more 
intuitive than C. Also more readable.

	I would say learning C++ is easier than C.

	Seriously,

-- 
Who is General Failure and why is he reading my hard-disk.


                     /\  /\               /\  /
                    /  \/  \ u e e n     /  \/  a w a z
                        >>>>>>mue### [at] nawazorg<<<<<<
                                    anl

Post a reply to this message

Invisible wrote:
>> I figure that if you use the std::string class you're safe from that. 
>> I haven't tried, though.
> 
> Wait... you mean they made it a class?

	Well, you *do* know that was the whole point of C++, right?

	Trust me - I felt like you for a long time. Until I finally found a 
good, recent book. Then I realized I'd been learning it the wrong way 
all along.

	Most of the books I had read assumed you didn't know too much about 
programming, and would emphasize basic skills: Loops, arrays, even 
C-style strings (character arrays). They'd make sure you could do the 
basics. Stuff like vectors would be introduced way at the end, and stuff 
like sets and maps often not at all.

	I didn't need a book that taught me the basics of programming. I assume 
you don't either. So finally I got a book that taught me how things 
should be done in C++. Then I realized C++ code doesn't have to be 
*that* ugly.


-- 
Who is General Failure and why is he reading my hard-disk.


                     /\  /\               /\  /
                    /  \/  \ u e e n     /  \/  a w a z
                        >>>>>>mue### [at] nawazorg<<<<<<
                                    anl

Post a reply to this message

>>  From what I've read, C++ is exactly like C, but 80% more complicated. 
>> Given that I could bearly produce working code in C with the tutor's 
>> help, my chances of getting anywhere with C++ are basically nil.
> 
>     In terms of actual coding, in some ways C++ is simpler and more 
> intuitive than C. Also more readable.
> 
>     I would say learning C++ is easier than C.
> 
>     Seriously,

Manual memory management? Pointers vs references? Copy constructors and 
assignment constructors? The macro preprocessor? Method overrides that 
don't actually override unless you insert special code? Templates? 
Untrapped numeric overflows? Unchecked array indicies?

Sure. Sounds really simple to me...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> Manual memory management? Pointers vs references? Copy constructors and 
> assignment constructors? The macro preprocessor? Method overrides that 
> don't actually override unless you insert special code? Templates? 
> Untrapped numeric overflows? Unchecked array indicies?
> 
> Sure. Sounds really simple to me...

I don't think it's much more worse than the POV SDL, actually. Of 
course, I haven't gotten into class programming (yet), so maybe I'm in 
the dark about how hard C++ really is. There are really only a few ways 
you can mess things up badly.

You could always try Euphoria. There are some OpenGL wrappers for that 
language. Easy dynamic arrays make Euphoria more fun than C++, and you 
don't even have to compile the code if you don't want to. EU is a very 
fast interpretive language, and even supports C++ style operations (ei. 
var+=2). I left EU because the SVGA library I was using depended on DOS, 
and when I switched to XP... well you get the picture :(

Sam

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Manual memory management?

  You can mostly forget about that if you avoid the keyword 'new'.

> Pointers vs references?

  You can usually avoid using pointers if you avoid the keyword 'new'.

> Copy constructors and assignment constructors?

  You usually don't need to care about them if you avoid the keyword 'new'.

> The macro preprocessor?

  You usually don't need it in C++.

> Method overrides that don't actually override unless you insert
> special code?

  What do you mean?

> Templates?

  One of the coolest, most powerful and most useful things around.

> Untrapped numeric overflows?

  You want the compiler to automatically insert a conditional after each
single arithmetic operation you perform? Maybe you should use some other
language.

> Unchecked array indicies?

  You can use checked array indices if you avoid raw arrays and the 'new'
keyword, by using the at() method of random access containers.

> Sure. Sounds really simple to me...

  It's complicated only if you make it so.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
>  From what I've read, C++ is exactly like C, but 80% more complicated. 

  Incorrect. C++ support most of the things as C, but is approximately 80%
less complicated to use.

  For example, handling dynamic data in C++ is usually laughably easy and
safe, while in C it's a nightmare.

> Given that I could bearly produce working code in C with the tutor's 
> help, my chances of getting anywhere with C++ are basically nil.

  On the contrary: C++ makes it much easier to write working safe code.
You just need a few rules of thumb:

1) If you ever get the temptation of using the keyword 'new', don't.
   (And no, "malloc()" is not good either. See rule 3.)

2) If possible, avoid using pointers.

3) If possible, avoid functions in the C standard library.

4) If you want, use the at() method to access data in random access data
   containers.

  That's it. With these simple rules you will be writing clean safe code
in no time. These rules should be broken only when you get very fluent
with the language and know what you are doing.

> > I 
> > had a lot of fun with C++ and OpenGL in college. It's really not that hard 
> > to learn for someone like you.

> As I say, the trouble is that if your program doesn't work, there is no 
> way you can ever find out why.

  Modern compilers and profilers do a quite good job at catching typical
beginner mistakes in C++ programs.

-- 
                                                          - Warp

Post a reply to this message

>> The macro preprocessor?
> 
>   You usually don't need it in C++.

Well, from what little I've seen, you "usually" don't need it in C 
either. Unless you want symbolic constants...

>> Method overrides that don't actually override unless you insert
>> special code?
> 
>   What do you mean?

Recall that I've never actually programmed in C++. I just read a book 
about it to see if it was any good.

Anyway, according to this book, by default all class methods have static 
binding. If you want real OO-style dynamic binding, that's an extra 
feature that you have to remember to turn on. (Presumably because it 
incurs a small performance hit, and C++ is targetted at speed, not 
flexibility.)

This also suggests that if somebody else wrote some code and you only 
have a binary copy, and they decided to not make some method 
overridable... too bad. (But then, frankly, trying to extend classes 
that somebody else wrote is usually pretty hard in any OO language.)

>> Templates?
> 
>   One of the coolest, most powerful and most useful things around.

And also one of the hardest parts to learn, no doubt.

>> Untrapped numeric overflows?
> 
>   You want the compiler to automatically insert a conditional after each
> single arithmetic operation you perform? Maybe you should use some other
> language.

The "maybe you should use some other language" part pretty much hits the 
mark, IMHO.

The long and short of it is that C++ is designed to be used by experts, 
and if you're not one, the langauge will make no attempt to prevent you 
hurting yourself. Now I don't know about you, but when *I* code things, 
I make mistakes. And I appreciate having systems in place to help me 
find and fix those mistakes. Clearly this is not C's design goal, and it 
appears not to be the goal of C++ either. These languages are designed 
to be efficient, not safe.

>   It's complicated only if you make it so.

Well, there sure seems to be a lot to learn there, that's all I'm saying...

(It's not even a complete list. Isn't there a special syntax for bit 
fields or something? And then there's the fun of destructors. And all 
kinds of interesting edge cases where that's "meant" to happen becomes 
slightly grey. And...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> Given that I could bearly produce working code in C with the tutor's 
>> help, my chances of getting anywhere with C++ are basically nil.
> 
>   On the contrary: C++ makes it much easier to write working safe code.
> You just need a few rules of thumb:
> 
> 1) If you ever get the temptation of using the keyword 'new', don't.
>    (And no, "malloc()" is not good either. See rule 3.)
> 
> 2) If possible, avoid using pointers.
> 
> 3) If possible, avoid functions in the C standard library.
> 
> 4) If you want, use the at() method to access data in random access data
>    containers.
> 
>   That's it. With these simple rules you will be writing clean safe code
> in no time.

Rule 3 should be easy - assuming C++ provides good replacements. (Seems 
like a safe assumption to me.) Rule 1 looks fairly easy.

Rule 2 is the one that puzzles me. At least in C, *anything* larger than 
a machine register is a pointer. So "avoid pointers" is pretty much 
impossible as soon as you want to touch anything larger than 32 bits. No 
strings, no arrays, no structs, nothing. Unless C++ radically changes 
the rules in this respect, I'm not sure I see a way round that.

Regarding rule 4... does this mean C++ at least manages to provide some 
standard containers *other* than arrays? (And that you can *query the 
size* of an array?)

> These rules should be broken only when you get very fluent
> with the language and know what you are doing.

But you can 100% guarantee that any code you read that was written by 
somebody else will be full of such exceptions. ;-)

>>> I 
>>> had a lot of fun with C++ and OpenGL in college. It's really not that hard 
>>> to learn for someone like you.
> 
>> As I say, the trouble is that if your program doesn't work, there is no 
>> way you can ever find out why.
> 
>   Modern compilers and profilers do a quite good job at catching typical
> beginner mistakes in C++ programs.

Well, perhaps. I doubt they'll help you fix OpenGL issues though...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Anyway, according to this book, by default all class methods have static 
> binding. If you want real OO-style dynamic binding, that's an extra 
> feature that you have to remember to turn on. (Presumably because it 
> incurs a small performance hit, and C++ is targetted at speed, not 
> flexibility.)

  The basic design principle in C++ is that you don't have to pay for
what you don't use.

  If C++ classes were always dynamically bound (like eg. Java classes are),
then each instance of each class would have a size overhead of one pointer,
and every function call would have a double indirection (making it very hard
for the compiler to perform inlining and other optimizations).

  This means that if you had, for example, a pixel class which has nothing
else than 4 bytes inside it (for rgba), its size would actually be 8 bytes
(or 12 in 64-bit systems, which would be even worse), even if you didn't
use dynamic binding for anything, and everything you cared about with your
pixel class is optimal memory usage and speed. Also all the functions of
that pixel class would be double indirections.

  C++ supports dynamic binding if you need it, but it's not shoved down
your throat by force.

> This also suggests that if somebody else wrote some code and you only 
> have a binary copy, and they decided to not make some method 
> overridable... too bad. (But then, frankly, trying to extend classes 
> that somebody else wrote is usually pretty hard in any OO language.)

  Nowadays object-oriented features such as dynamic binding are falling
out of fashion, and they are less and less popular. In this way C++ actually
got to the winning side by turning it off by default.

> >> Templates?
> > 
> >   One of the coolest, most powerful and most useful things around.

> And also one of the hardest parts to learn, no doubt.

  What's so hard to learn about them? Usually the only difference is
that theres one or more type which are abstracted away, and that's it.
For example, rather than writing:

int foo(int parameter) { ... }

where the type of the parameter and the return value is fixed to int,
you abstract them away like this:

template<typename Data_t>
Data_t foo(Data_t parameter) { ... }

  Now you can call that function with ints, longs, doubles, chars...

  Sure, when you start developing really complicated template code, you
can get quite obfuscated templates, but that's usually more the exception
than the rule.
  The most complicated template sentence I have written in actual code
has been this:

typename Allocator::template rebind<size_t>::other(*this).deallocate(refCount, 1);

  It would probably take half a book to explain everything that is involved
there. :P
  However, you don't usually have to write code like that when you are
making regular programs.

> >> Untrapped numeric overflows?
> > 
> >   You want the compiler to automatically insert a conditional after each
> > single arithmetic operation you perform? Maybe you should use some other
> > language.

> The "maybe you should use some other language" part pretty much hits the 
> mark, IMHO.

  Sometimes you have to use what the industry demands, not what you would
like to use. Besides, it's not that bad.

> The long and short of it is that C++ is designed to be used by experts, 
> and if you're not one, the langauge will make no attempt to prevent you 
> hurting yourself. Now I don't know about you, but when *I* code things, 
> I make mistakes. And I appreciate having systems in place to help me 
> find and fix those mistakes.

  I don't like that when it's shoved down your throat whether you want
it or not, at the expense of, among other things, memory usage efficiency
and speed.

  Yes, debug checks are nice. They are nicer if you can turn them off
for a final release.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Rule 2 is the one that puzzles me. At least in C, *anything* larger than 
> a machine register is a pointer. So "avoid pointers" is pretty much 
> impossible as soon as you want to touch anything larger than 32 bits. No 
> strings, no arrays, no structs, nothing. Unless C++ radically changes 
> the rules in this respect, I'm not sure I see a way round that.

std::string someText(1000, ' ');
someText += "Hello";
someText.at(10) = 'A';

std::vector<int> anArray(1000);
anArray.at(10) = 5;

std::vector<std::string> anArrayOfStrings(1000);
anArrayOfStrings.at(10) = "Hello";

std::cout << someText << "\n" << anArrayOfString.at(10) << "\n";

  Lots of dynamically allocated data, no pointers anywhere.

> Regarding rule 4... does this mean C++ at least manages to provide some 
> standard containers *other* than arrays?

  Dynamically allocated vectors, strings, doubly-linked lists, binary trees
(as sets, multisets, maps and multimaps) and double-ended queues. None of
them requiring any pointers or 'new' to use. (The upcoming C++ standard
will also include hashmaps as a new data container.)

> (And that you can *query the size* of an array?)

  Getting the size of a vector, string, deque and binary tree is O(1).
(For doubly-linked lists it's not guaranteed.)

> > These rules should be broken only when you get very fluent
> > with the language and know what you are doing.

> But you can 100% guarantee that any code you read that was written by 
> somebody else will be full of such exceptions. ;-)

  Don't make the same mistakes as others.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   The basic design principle in C++ is that you don't have to pay for
> what you don't use.
> 
>   C++ supports dynamic binding if you need it, but it's not shoved down
> your throat by force.

I prefer the Eiffel way, where the compiler looks at your program and 
automatically decides which things can be bound statically (with all the 
optimisations that follow), and which things actually require dynamic 
binding.

(Actually, Haskell does something similar - but Haskell is so un-OO that 
that's a fairly bad comparison.)

But I guess having to do it manually isn't so hard.

>>>> Templates?
>>>   One of the coolest, most powerful and most useful things around.
> 
>> And also one of the hardest parts to learn, no doubt.
> 
>   What's so hard to learn about them?

I don't know - I haven't tried yet. ;-)

> Usually the only difference is
> that theres one or more type which are abstracted away, and that's it.
> For example, rather than writing:
> 
> int foo(int parameter) { ... }
> 
> where the type of the parameter and the return value is fixed to int,
> you abstract them away like this:
> 
> template<typename Data_t>
> Data_t foo(Data_t parameter) { ... }
> 
>   Now you can call that function with ints, longs, doubles, chars...

So that basically means the same thing as Haskell's

   foo :: x -> x
   foo = ...

then?

Does it actually build a seperate copy of the function for each data 
type, or just build one generic version that works with all of them?

>   Sure, when you start developing really complicated template code, you
> can get quite obfuscated templates, but that's usually more the exception
> than the rule.

Well, yeah, that goes for any language feature... ;-)

>> The "maybe you should use some other language" part pretty much hits the 
>> mark, IMHO.
> 
>   Sometimes you have to use what the industry demands, not what you would
> like to use.

Ain't that the truth! ;-)

> Besides, it's not that bad.

Well, I guess not. I could have people forcing me to write Bash 
scripts... >_<

>   Yes, debug checks are nice. They are nicer if you can turn them off
> for a final release.

There is certainly something to be said for that.

The problem is that, certainly with C anyway, there's no switch to turn 
it ON in the first place. :-(

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message