Kleines "Labyrinth-Spiel", freu mich über jede Kritik!

[NES-Spieler]

Ihr immer mit Eurem scheiß system("cls") . Für Windows gibt es da entsprechende WinAPI-Funktionen:

const HANDLE OutputHandle = GetStdHandle(STD_OUTPUT_HANDLE);

void gotoxy(short x, short y)
{
    const COORD position = { x, y };

    SetConsoleCursorPosition(OutputHandle, position);
}

void clrscr()
{
    gotoxy(0, 0);

    const CONSOLE_SCREEN_BUFFER_INFO info = GetScreenBufferInfo();
    const COORD position = { info.dwCursorPosition.X, info.dwCursorPosition.Y };
    const DWORD lenght = info.dwSize.X * info.dwSize.Y;
    DWORD number;

    FillConsoleOutputAttribute(OutputHandle, info.wAttributes, length, position, &number);
    FillConsoleOutputCharacter(OutputHandle, TEXT(' '), length, position, &number);
}

Und bei Linux schreibt man schlicht und ergreifend

cout << "\033[2J";

Und nicht system("clear") .

Ansonsten:
Die Fehlermeldung, wenn man eine falsche Eingabe getätigt hat, erscheint immer nur ganz kurz und danach wird sofort der Bildschirm gelöscht.
Außerdem könntest Du vielleicht getch() für die Eingabe nehmen. Obwohl das nicht mehr plattformunabhängig ist, aber Du könntest ja auch hier ein #ifdef benutzen, so daß Windows-Benutzer mit getch() spielen können, während Linux-Benutzer weiterhin mit Eingabe + Enter spielen.
Und ich weiß nicht, ob es nötig ist, immer wieder den gesamten Bildschirm zu löschen und neuzuzeichnen. Geh doch einfach an die Position der Spielfigur, übermale sie mit einem Leerzeichen und zeichne sie dann an der neuen Position. Das gotoxy hab ich ja oben schon hingeschrieben. Für Linux geht es so:

cout << "\033[" << y + 1 << ";" << x + 1 << "m";

(Bitte beachten: Mit den Windows-Funktionen ist die Position oben links (0,0), während sie bei der Linuxfunktion (1,1) ist. Deshalb das x + 1 und das y + 1, damit Du mit denselben Positionsangaben beide Varianten benutzen kannst.)

[!!!!]

NES-Spieler schrieb:

Ihr immer mit Eurem scheiß system("cls") .

daran ist nix scheiße und für so ein spiel durchaus angemesen

[NES-Spieler]

Wow, was für eine geniale Begründung! Ja, damit hast Du mich jetzt echt überzeugt.

[!!!!]

deine einsicht freut mich, so brauche ich wenigstens keine überflüssigen erklärungen für so etwas offensichtliches abzugeben.

[NES-Spieler]

Vielleicht solltest Du es doch erklären, damit ich auch ganz sicher gehen kann, daß ich es wirklich verstanden habe: Warum ist es nicht scheiße, den Befehl, der eigentlich dazu gedacht ist, explizit externe Programme bzw. Kommandozeilenbefehle aufzurufen, zweckzuentfremden, um ein Verhalten zu simulieren, das eigentlich zum eigenen Programm gehört und gar nichts mit dem bewußten Aufrufen externer Kommandos zu tun hat?

[Systematiker]

NES-Spieler schrieb:

Warum ist es nicht scheiße, den Befehl, der eigentlich dazu gedacht ist, explizit externe Programme bzw. Kommandozeilenbefehle aufzurufen, zweckzuentfremden, um ein Verhalten zu simulieren, das eigentlich zum eigenen Programm gehört und gar nichts mit dem bewußten Aufrufen externer Kommandos zu tun hat?

Also geht es dir nur ums Prinzip? Oder gibt es auch ein echtes Problem?

Wobei, es bringt einem Anfänger sicher gewaltig viel mehr, wenn er statt system("cls") 20 Zeilen WinAPI-Code aus einem Internetforum kopiert, ohne eine einzige davon zu verstehen.

[NES-Spieler]

Stimmt. Soll er sich lieber schlechten Stil angewöhnen und lernen, daß es besser ist, mal schnell irgendwas hinzuhacken, statt zu gucken, ob es irgendwo Funktionen gibt, die genau dafür gedacht sind. Wieso sollte man sich auch mit WinAPI-Funktionen auseinandersetzen, wenn man einfach system("cls") schreiben kann? Ist zwar ein Systemaufruf, der normalerweise nur dazu gedacht ist, externe Anwendungen zu starten, aber er erfüllt doch seinen Zweck, nicht wahr? Und wenn man die Konsole offen lassen will, bis der Benutzer Enter bzw. eine Taste drückt, nimmt man system("pause") statt cin.get() bzw. fgets oder was es da in C auch immer gibt, stimmt's? Immerhin muß man sich bei solchen Funktionen um das mögliche Leeren des Puffers kümmern, falls da noch irgendeine Eingabe drin hängt, und das würde den Anfänger ja vollkommen überfordern. Und wenn er das Labyrinth in blau mit weißem Hintergrund darstellen will, dann empfehlen wir ihm system("color f9") statt ihn darauf hinzuweisen, daß es auch dafür richtige Funktionen gibt. Immerhin ist er ja ein Anfänger, also sollte man ihm keinen Code zeigen, durch den er sich erstmal durchfuchsen müßte, um ihn zu verstehen. Könnte ja sein, daß er dadurch noch was lernt oder vielleicht sogar angeregt wird, selbst in die Richtung nachzforschen, falls ihm in den Sinn kommt, daß er die clrscr -Funktion so umschreiben will, daß man angeben kann, von wo bis wo der Bildschirm gelöscht werden soll. Viel besser sind da billige Hacks, die allgemeine Shellbefehle einfach im lokalen Programm aufrufen. Wieso benutzen wir eigentlich noch cout und printf ? Nehmen wir doch gleich system("echo ...") . Und wenn wir mal rausfinden wollen, was es so für Ordner und Dateien im aktuellen Pfad gibt, dann machen wir system("dir /b > Dateien.txt") , lesen dann die Datei aus und löschen sie dann wieder mit system("del Dateien.txt") .

[Systemanalytiker]

NES-Spieler schrieb:

Wieso sollte man sich auch mit WinAPI-Funktionen auseinandersetzen, wenn man einfach system("cls") schreiben kann?

Genau das frage ich mich auch.

statt ihn darauf hinzuweisen, daß es auch dafür richtige Funktionen gibt.

Es gibt aber keine "richtigen" Funktionen dafür. Nicht, wenn man plattformunabhängiges C programmiert. Man muss Win-API benutzen, und überaus schöner Code ist das auch nicht.

Leider sagst du nach wie vor nicht, was wirklich das Problem ist. "Hack", "schnelle Shellbefehle", "schlechter Stil"... Werd lieber mal konkret. Einen Anfänger kümmern deine momentanen Argumente nämlich kein bisschen, solange er mit einer Zeile dasselbe erreicht wie du mit 20.

Wieso benutzen wir eigentlich noch cout und printf ?

Schlechter Vergleich. Die beiden sind einfach zu benutzen, portabel und erfordern kein wochenlanges Einstudieren in ein Framework.

[cirion]

Systemanalytiker schrieb:

Nicht, wenn man plattformunabhängiges C programmiert.

system("cls"); ist auch nicht gerade plattformunabhängig. funktioniert lediglich für ein paar plattformen mehr als nur eine.

letztlich läuft die ganze diskussion doch nur darauf hinaus, dass beide seiten recht haben. ja, das ist nicht sonderlich doller stil (erst recht, wenn man das als allgemeingültigen prototyp für situationen ansieht, in denen man anders nicht spontan weiter weiß), aber nein, das ist noch lange kein grund, als anfänger darauf unbedingt zu verzichten.

ru,
cirion

[dasdasa]

Und wenn ihr schon mal dabei seid... Warum nicht gleich SDL verwenden?

[NES-Spieler]

Systemanalytiker schrieb:

Leider sagst du nach wie vor nicht, was wirklich das Problem ist. "Hack", "schnelle Shellbefehle", "schlechter Stil"... Werd lieber mal konkret. Einen Anfänger kümmern deine momentanen Argumente nämlich kein bisschen, solange er mit einer Zeile dasselbe erreicht wie du mit 20.

Bitteschön: www.c-plusplus.net/forum/viewtopic-var-t-is-39453.html. Sogar ein FAQ-Eintrag, was zumindest zeigt, daß ich mit meiner Abneigung nicht allein dastehe.

dasdasa schrieb:

Und wenn ihr schon mal dabei seid... Warum nicht gleich SDL verwenden?

Weil die Frage nach SDL nicht nur eine codetechnische ist, sondern eine, die auch das Aussehen des Programms komplett ändern würde.

cirion schrieb:

aber nein, das ist noch lange kein grund, als anfänger darauf unbedingt zu verzichten.

Außer natürlich, wenn man die richtige Variante bereits fertig vorgelegt bekommen hat. Und da ich mir vorstellen kann, daß als nächstes die Frage kommt, wie man das Spiel auch farbig gestaltet, wäre in dem Fall die WinAPI sowieso unausweichlich, denn dann hat's sich mit den Systembefehlen geschissen, wenn man nicht nur eine Farbe für alles haben will.

[volkard]

NES-Spieler schrieb:

Bitteschön: www.c-plusplus.net/forum/viewtopic-var-t-is-39453.html. Sogar ein FAQ-Eintrag, was zumindest zeigt, daß ich mit meiner Abneigung nicht allein dastehe.

Keines der Argumente greift hier.
Plattformabhängigkeit? Recht egal, die angestrebte Alternative wäre WinAPI, wenn ich mich recht erinnere.
Geschwindigkeit? Für eine Wartefunktion.
Hänger bei Fehlern? Naja, da schreibt man pause halt mal richtig.
Sicherheit? Soll ich meinen Rechner knacken?

[NES-Spieler]

Es ist einfach Zweckentfremdung. system ist dazu da, explizit externe Programme zu starten. Das Löschen eines Bildschirms ist aber nichts, was rein logisch dem Aufruf eines externen Programms gleichkommen sollte, sondern das ist nur eine Funktionalität des eigenen Programms. Ja, ja, rein praktisch mag es jetzt vielleicht noch egal sein, aber ich sage: "Wehret den Anfängen!" Heute nimmt man system("cls") als Notlösung, morgen hält man es nicht für nötig, einen oft vorkommenen Wert als Konstante zu deklarieren, "da er sich ja sowieso nicht ändert" und man die Zahl auch direkt hinschreiben kann. Und übermorgen? Da friemelt man sich ein so beschissenes Konstrukt zusammen, das eine tickende Zeitbombe ist, weil man nie gelernt hat, was sauberes Programmieren bedeutet.

[volkard]

Rufst Du ping mit system auf oder machste rawsockets per hand? Und touch? Und ftp?

[Ad aCTa]

Sieh das nicht so engstirnig, NES-Spieler! Um Spiele-Logik zu verstehen und um zu setzen, muss man nicht gleich wie ein 1337-h4xX0r alles aus der Win32-API rauskratzen. Techn. Details sind hier erst mal auf Rang 2.

[NES-Spieler]

volkard schrieb:

Rufst Du ping mit system auf oder machste rawsockets per hand? Und touch? Und ftp?

Das kommt drauf an, was das Programm aussagen will. Wenn es explizit aussagen soll: "Achtung, ich starte jetzt ein externes Programm. Das gibt es auch losgelöst, das ist also nicht Teil meines eigenen Binärcodes", dann würde ich system benutzen. Wenn das Programm dem Benutzer sagen soll: "So, das, was jetzt kommt, ist ein Feature von mir", dann benutze ich dazu richtige Funktionen, die für diese Aufgabe gedacht sind.

Ad aCTa schrieb:

Sieh das nicht so engstirnig, NES-Spieler! Um Spiele-Logik zu verstehen und um zu setzen, muss man nicht gleich wie ein 1337-h4xX0r alles aus der Win32-API rauskratzen.

Wie bitte? Was hat denn eher etwas von einem 1337-h4xX0r? Die Funktionen zu nehmen, die explizit für diese Aufgabe gedacht sind (und dabei noch was über richtige Programmierung zu lernen)? Oder zu sagen: "Hab ich Tricky-Tricky gemacht und den Shell-Befehl genommen."

[Big Brother]

NES-Spieler schrieb:

Wenn es explizit aussagen soll: "Achtung, ich starte jetzt ein externes Programm. Das gibt es auch losgelöst, das ist also nicht Teil meines eigenen Binärcodes", dann würde ich system benutzen.

Ich schätze, ein system("cls") unter Windows ruft die entsprechenden WinApi Funktionen auf. Das Parsen von "cls" und der system Aufruf dürfte wohl die eine oder andere Mikrosekunde mehr benötigen, als wenn man die WinApi Funktionen direkt aufruft. Hier, in diesem Fall ( und schätzungsweise in 99% der übrigen Fälle ), kann man m.M.n. mit ruhigem Gewissen, um deine Wortwahl zu erweitern, drauf schei ...