Spiele in C#

EXDW

kommt darauf an welche art von spielen
c# ist nicht dafuer bekannt serh verformant zu sein - fuer ien kartenspiel oder solche "minispiele" reicht es locker - aber ein ego shooter oder generell aufwendigeres spiel mit 3d elementen - da ist c++ schon die beste wahl

zudem

die syntax von cpp und c# ist doch verdammt aehnlich...

_matze

Ich würde mal sagen, bei den Spielen, die der Threadersteller wahrscheinlich schreiben wird (ich gehe mal davon aus, dass er kein zweites Crysis programmieren wird), wird C# locker hinhauen. Er kann nicht soviele Fehler machen wie in C++, kommt schneller voran und kann genauso Schnittstellen wie DirectX nutzen...

Hallo

Ich glaube auch, dass ein Hobbyprogrammierer mit c# und xna sehr gut bedient ist.

chrische

Mr Evil schrieb:

kommt darauf an welche art von spielen
c# ist nicht dafuer bekannt serh verformant zu sein - fuer ien kartenspiel oder solche "minispiele" reicht es locker - aber ein ego shooter oder generell aufwendigeres spiel mit 3d elementen - da ist c++ schon die beste wahl

Ich hab mal gehört, C# kann da mithalten. Weiß aber nicht, was davon zu halten ist.

Mr Evil schrieb:

die syntax von cpp und c# ist doch verdammt aehnlich...

Aber viel unauberer und fehleranfälliger:

int i;         // Uninitialisiert, Verwendung später trotzdem möglich
if (i) { }     // Impliziter Cast von int in bool
if (i = 5) { } // Zuweisung statt Vergleich

switch (i)
{
    case 1:
        doSomething();
               // break vergessen
    case 2:
        doSomethingElse();
}

Seit ich umfassender mit C# zu tun habe, ist mir C++ ein Greuel geworden. (Aber off-topic, darum geht's jetzt nicht.)

Dass das Spiel für den C64 sein soll hatte ich erwähnt?

_matze

Gibt es bei C#-switches kein break?? Ich finde das eigentlich sehr praktisch, um mehrere cases zusammenzufassen, das spart redundanten Code oder umständliches Umdesignen. Und wenn man daran gewöhnt ist, vergisst man es normalerweise auch nicht.

_matze schrieb:

Gibt es bei C#-switches kein break?? Ich finde das eigentlich sehr praktisch, um mehrere cases zusammenzufassen, das spart redundanten Code oder umständliches Umdesignen. Und wenn man daran gewöhnt ist, vergisst man es normalerweise auch nicht.

Doch, es gibt eins. Das muss aber explizit angegeben werden oder man muss ein "goto case ..." schreiben, sonst gibt's einen Compilerfehler.

Nachtrag:

case 1:
case 2:
case 3:
Anweisung;
break;
geht natürlich sowieso.

EXDW

The schrieb:

Nachtrag:

case 1:
case 2:
case 3:
Anweisung;
break;
geht natürlich sowieso.

nur solang zwischen den cases kein code ist

[cs]

switch(bla)
{
case 1:
case 2:
DoSomeCode();
goto case 3;
case 3:
break;
}
[cs]

Im Grunde viel sauberer weil man den Sonderfall (fallthrough) explizit angeben muss. Bei einem nicht vorhandenen break kann man im nachhinein schwer sagen ob das absichtlich oder versehentlich vergessen wurde....

Wobei die C# variante mehr kann als nur fallthrough, da man zu einem beliebigen Label springen kann.

Badestrand

Braucht man das eigentlich manchmal oder sogar öfters, " goto case X "?

Destiniy

also das break brauch man auf jeden fall wenn man nicht will das der zur nächsten case Anweisung springt (http://msdn.microsoft.com/de-de/library/06tc147t(VS.80).aspx)

MfG

EXDW

- ich brauchte noch nie ein fallthrought, ein switch case selber hab ich wenn dann eh nur in ner factory - sonst hab ich kein bedarf nach switch/cases

@Destiniy
wenn man nach dem case kein break macht, aber das case code hat, wirft der compiler bereits ein error - nur wenn man kein code hat und die cases untereinander, nur dann wird weiter gesprungen bis code gefunden wird

dh ein unbeabsichtigtes aufrufen des nachfolgenden cases gibt es in c# nicht

Destiniy

das steht aber im wiederspruch zu dem MSDN beitrag in dem Link

_matze

Destiniy schrieb:

das steht aber im wiederspruch zu dem MSDN beitrag in dem Link

Wieso? Du sagst selbst, das break braucht man auf jeden Fall (einzige Ausnahme laut Doku: case enthält keinen Code). Und wenn man es vergisst, gibt's 'nen Compiler-Fehler. In der Doku steht ja auch, dass ein break nötig ist, abgesehen von der Ausnahme...

Destiniy

OK

hatte das mit dem leer überlesen

Im folgenden Beispiel wird veranschaulicht, dass bei leeren case-Bezeichnungen von einer case-Bezeichnung zur nächsten fortgefahren werden kann

Kommen wir zurück zu den Spielen. Was ist jetzt? Kann ich C#-Spiele auf dem C64 programmieren oder nicht?

jule37

Mr Evil schrieb:

kommt darauf an welche art von spielen
c# ist nicht dafuer bekannt serh verformant zu sein - fuer ien kartenspiel oder solche "minispiele" reicht es locker - aber ein ego shooter oder generell aufwendigeres spiel mit 3d elementen - da ist c++ schon die beste wahl

zudem

die syntax von cpp und c# ist doch verdammt aehnlich...

ist nicht ganz korrekt. c# ist performant genug für aufwändigere 3d spiele. ego shooter geht schon, gar kein thema. kommt halt drauf an, wie gut man codet. kann sein, dass es eine obere grenze gibt, aber prinzipiell geht alles in sachen 3d, was auch in anderen sprachen geht.

hab sogar mal gelesen, dass es angeblich möglich sein soll, gerade für 3d und multimedia, mit c# noch performanter als z.b. c++ zu coden. das kommt daher, dass der eigentliche maschinencode erst auf dem rechner erzeugt wird, auf dem er zur ausführung kommt und somit bessere nutzung von befehlssätzen wie mmx und 3dnow etc. machen kann. (wie gesagt - mal gelesen, also gebe ich das hier mal auf gerüchtebasis weiter. mit vorsicht genießen).

der hauptvorteil von c# ist wohl, dass die sprache produktiver ist. man schreibt in kürzerer zeit mehr code, der weniger fehler enthält.

asc

GameOne schrieb:

Kommen wir zurück zu den Spielen. Was ist jetzt? Kann ich C#-Spiele auf dem C64 programmieren oder nicht?

Bekommt man wenigstens ein gutes Gehalt als Troll, oder hast du sonst kein Hobby?

jule37 schrieb:

der hauptvorteil von c# ist wohl, dass die sprache produktiver ist. man schreibt in kürzerer zeit mehr code, der weniger fehler enthält.

Ha, das werde ich jetzt widerlegen. Pass auf:

#include <iostream>

int main()
{
    std::cout << "C# ist scheisse.\n";
}

Und nun C#:

class object()
{
    empty main
    {
        Writeline(cout << "C# ist immer noch scheisse.";
    }
}

Oberes Programm hab ich übrigens schneller niedergeschrieben.

Beweis erbracht: Mit C# muss man nicht zwangsläufig schneller und fehlerfreier coden.