I hate when a bug is mine..

MM sprays brad with bug spray, steps back, smiles and says outloud "that outta take care of yer bug"

It makes me sad that you still have to write games in C++ when C# is so pretty

Looks more like plain C to me.

umm how can you tell by that short code section, the difference between C,C++ and C# ??

Well due to the pointer notation I'm pretty sure its not C#

( pCiv->lMoney<500)

I have never written in C#, but I know its not C because there is a == operator for string comparison. In pure C, that would be a strcmp() call.

END COMMUNICATION

I don't think C# is ready for games yet, just my opinion though.  People thought Java woudl be a good language for game development too.

Christ, Java is slower'n molasses.

Not the language, but the virtual machine.

Screw compatability, give me C!

Draginol do you guys still have the 'live' version for dowload? The one that you devs are using.. i believe that there was a place to download this. Be nice to get the fix without having to wait for another week

I hate when the bug is mine as well... I develop in house software and we have some very bitchy users, so I usually scramble for a quick fix for them and after pushing a new version out (I am a one man dev/QA team ), I realize that, oops, I forgot to clear that variable or that there is another crash-inducing bug. So, then, I am rushing even faster to correct the bug that was caused by the fix to the original issue that wasn't a bug but a cleverly-designed feature...

Well due to the pointer notation I'm pretty sure its not C# ( pCiv->lMoney<500)

Blasted pointers kicking you out of Managed mode ...

Technically ... C# allows the use of pointers, it just dumps the application (in toto) out of managed mode and into unmanaged mode. At that point, it becomes C++ w/ some funky syntax.

I'm sorry any language that doesn't allow for pointer manipulation will never replace C/C++. There are too many really nifty things that you can do in a few lines of code with pointers that take two or three times that without.

Hehe... bugs... happens to the best of us .

I generally find C to be too ineffecient for my needs. But I usually only code micro controllers.

Of course C++ is far less efficient than C, and C# is even less efficient. Assembly is obviously the most efficient, but I like FORTH as well - being a high level language.

Assembly? Someone else who likes to code in Assembler!?

Any time I've told people I like Assembler I get looked at like I had just told them I eat glue!

I find that C++ is over engineered, too many things added that - as stated - reduce efficiency.

C is a nice compromise between utility and efficiency.

I LOVE Assembly!

And yeah I get the same reaction Kato when I say that hehe.

Of course I haven't gotten to use it in years *sniff*

I'm forced to use Visual Basic around here... damn DoD job. *sigh*

Felk the Forlorn

I prefer C and ASM, myself.

Computer languages are just tools. You pick the tool based on the job you want to do. Since GUIs are naturally object-oriented they lend themselves to object-oriented development. All O-O languages have rich libraries to support GUI development. With GUIs, performance is not usually the primary concern (developer time and maintainability are) since waiting for user input is usually the bottleneck.

However, if I need to write a device driver, encode a crypto algorithm, or write a high performance server, I'll use C.

If performance was the only concern then we would all still be encoding in assembler.

I used to teach assembly in college some years ago.  But it's not really something you'd want to use to make a PC game.

No, Assembler would take too long to make the monstrous modern programs (also known as bloatware).

Regretable, but simply the way it is.

Visual Basic Felkethar? Och, poor lad.

These days I mostly only get to use scripting languages myself, but at least they are stringly influenced by C so I'm not offended by them. But VB? Ick.

Well I'm not a software engineer by training or experiance but rather a hardware guy, so I feel kinda dirty using ANY higher level language . I have to use VB to make applications to make the hardware do what I need it to do without involving all the software guys upstairs.

Fortunatly I use the programs to do a heck of a lot of hex and boolean calculations and mux bus communication so I don't feel like I've... totaly gone over to the dark side

I did try and make a game with VB once. I learned two things...

1) VB isn't very good for making games.
2) I suck at making games.

Felk the 01000010 01101001 01101110 01100001 01110010 01111001

Allow me a monent to categorize certain programming zealotry (note: the following is 100% joke):

I'm sorry any language that doesn't allow for pointer manipulation will never replace C/C++. There are too many really nifty things that you can do in a few lines of code with pointers that take two or three times that without.

Behold: the C/C++ Zealot.

You can distinguish the C/C++ Zealot by how he values the number of lines it takes to do something rather than the clarity of said code. The C/C++ Zealot tends to keep to his own kind, avoiding contact with more "evolved" Zealots, such as the Whooping Generic Programming Zealot. Of course, few other Zealots deign to approach the Whooing GP Zealot, for it is most aggressive and insidious, spewing forth types with truly bizzare names at an incredible rate when anyone approaches.

I find that C++ is over engineered, too many things added that - as stated - reduce efficiency.

Behold: the Pure-C Zealot

You can distinguish between the Pure-C Zealot and the C/C++ Zealot by the way that the Pure-C Zealot misunderstands the way in which C++ is considered "inefficient". They also attempt to visciously savage other Zealots of opposing alignment, such as the Parented Object-Oriented Programming (or POOP) Zealot. The POOP Zealot tends to win in conflicts with the Pure-C Zealot, as it brings a truly gigantic lineage of parents and children that really don't do anything more or less than it itself does. Even so, the Pure-C Zealot is usually able to escape with minor injuries by confusing its enemies with a trail of references to global variables defined in files far from here.

Joke over.

Personally, I think C# is ready for limitted game use. Not for the low-level "here's how you render stuff" part, but I could imagine that GC2's AI wouldn't be slowed down much by being written in C#. Indeed, the basic game rules of GC2 could probably be written in C# without any noticable slowdown. The primary problem with using Java is that the Java-to-C/C++ interface is painful at best and hard to deal with. Interfacing between C++ and C#, by contrast, is much simpler and easier.

Christ, Java is slower'n molasses. Not the language, but the virtual machine. Screw compatability, give me C!

The old stereotype. If you're willing to open your mind, take a look at this - these are benchmarks of a Quake port to Java. So much for "Java is too slow for gaming" ^^

A true thing is that the runtime needs some seconds to start, ie the program takes a moment longer to load. But that's becoming negligible on todays hardware, and the runtimes themselves get better too. And if I can use the time I saved developing (say, compared to C++) for more features, it's a win

Good Grief Martimus
"Assembly is obviously the most efficient, but I like FORTH as well - being a high level language. "
For time critical stuff assembly is the way to fly although you can shoot yourself in the foot. But FORTH, man that one will let you take your whole leg off. But it is nifty

There are too many really nifty things that you can do in a few lines of code with pointers that take two or three times that without

Sure. And you can also create nasty bugs that may be hard to track

And here I went around thinking they programmed the game by going into DOS mode and typing...

c:\>Copy con galciv2.exe

..and then just typed in the needed stuff