Warum C Code in vielen Spieleprogrammier bücher bzw. Tutorial

BlackFalcon schrieb:

Ja gut im grunde genommen kann eh jeder machen was/wie er es will. Mich wundert nur das in den meisten Spieleprogrammierbücher die von C++ sprechen nur C Code enthalten. Naja vielleicht sollte ich aber auch mal ein Buch zu ende lesen. Ich lerne jetzt sowieso erst mal c++ mit diesem Buch: http://www.amazon.de/Einführung-die-Programmierung-mit-C/dp/3868940057/ref=sr_1_5?s=books&ie=UTF8&qid=1306216911&sr=1-5 ist zwar teuer aber eine gute Lektüre vor allem vergeht mir nicht der Spaß am lesen an diesem Buch was bei mir der Hauptgrund ist warum ich keine Bücher fertig bekomme

Mann, der Preis von diesem Buch ist in den vergangenen Jahren ja heftigst angestiegen.

Früher bekam man so ein Buch für 50 €.

dot schrieb:

Flori() schrieb:

Der Autor des von mir benannten Buches sagt auch folgendes:

Wann immer Sie vor der Aufgabe stehen etwas in C++ realisieren zu müssen, das in C einfacher machbar ist, dann rate ich Ihnen schweren Herzens, auf C-Code zurückzugreifen.

Ich glaub der Autor hat nicht so wirklich verstanden was C++ ist...

Objektorientierte Bloatware!

BlackFalcon schrieb:

60€ für ein Buch über C++ Programmierung halte ich ehrlichgesagt für rausgeschmissenes Geld

Wenn damit leichter lerne, ist mir der Preis völlig egal. Es darf nur nicht zuviel kosten.

Wann ist denn für dich zu viel?

Also > 70 € für ein Programmierbruch sind eigentlich nicht normal.
Wie schon gesagt, der Standardpreis für die wirklich guten Bücher, also nicht solche 30 € in 10 h Lernbücher ohne Inhalt, liegt bei 50 €.

dot

Ich weiß es! schrieb:

dot schrieb:

Flori() schrieb:

Der Autor des von mir benannten Buches sagt auch folgendes:

Wann immer Sie vor der Aufgabe stehen etwas in C++ realisieren zu müssen, das in C einfacher machbar ist, dann rate ich Ihnen schweren Herzens, auf C-Code zurückzugreifen.

Ich glaub der Autor hat nicht so wirklich verstanden was C++ ist...

Objektorientierte Bloatware!

...Aber wie du siehst ist der Autor damit bei weitem nicht allein...

Nexus schrieb:

Der Wrapper schrieb:

Die meisten APIs sind nunmal C basiert, dazu gehört auch die SDL, OpenAL und OpenGL, 3 wichtige Bibliotheken für die Spieleprogrammierung.

SDL ist nicht wichtig, da es eine austauschbare Highlevel-Bibliothek ist.

In der Open Source Szene oder für kleine Projekte ist die SDL wichtig und gerade Spieleprogrammieranfänger profitieren von ihr deutlich.

Klar kann man sie auch gegen eine eigenen Highlevel-Bibliothek austauschen und eigenes crossplattformfähiges Threading, Tastatur- und Joysticksteuerung usw. in seinen Code einbauen, aber warum sollte man sich diese Arbeit machen?

Insofern ist die SDL eine super Bibliothek.
Für 30 Mio € teure Großprojekte kann man natürlich auch alles selber in den Code einbauen, wenn es die gekaufte 3d Engine nicht schon von Haus aus mitbringt. Aber für Kleinstprojekte muß man sich so etwas ja nun wirklich nicht antun.

Mit SFML existiert inzwischen auch eine massiv bessere Alternative, besonders für C++.

Klar, die SFML ist ja auch in C++ geschrieben und nicht in C, wie die SDL.

Aber daraus folgt auch, daß sie eigentlich nur für C++ Code sinnvoll ist, für alle anderen Spiele in anderen Programmiersprachen, also Python, Pascal usw. nimmt man dann doch besser die SDL weil diese eben in C geschrieben ist und die meisten Programmiersprachen eben spielend mit C Code klarkommen.
Was im umgekehrten Fall, also C++ Code eben meist nicht der Fall ist.
Da müssen dann von Phyton zu C nach C++ Zwischenwrapper bzw. Bindings her und die machen das ganze dann wieder langsam oder einfach nur fetter.

Und mit Low-Level-Frameworks wie OpenGL muss man auch nicht unbedingt zu tun haben, wenn man Spiele programmiert. Das hängt sehr von den genauen Ansprüchen ab. Sobald man abstrahierende Frameworks verwendet, gibt es vieles direkt für C++, z.B. die Open-Source-Grafikbibliotheken Irrlicht und Ogre.

Irrlicht und Ogre sind fertige 3d Grafikengines und nicht nur Grafikbibliotheken.
Hättest du OSG gesagt, ja, dann würde es anders aussehen.

Burkhi schrieb:

Engine siehe hier: https://secure.wikimedia.org/wikipedia/de/wiki/Gameengine

Man beachte den Unterschied:
Grafikengine != Gameengine

Eine Grafikengine ist nur eine Teilmenge aus einer Gameengine.

OGRE oder Irrlich sind z.B. keine Gameengines, sondern nur eine Grafikengines.
Dafür ist Crystal Space eine Gameengine.

Directx stellt die Funktionen zur Verfügung, um die Darstellungen, die die Engine generiert, auf dem Bildschirm anzuzeigen, mal so ganz grob gesagt.

Das ist falsch.

Diesen Teil macht nur Direct3d, eine Teilmenge von DirectX
DirectX kümmert sich auch um die Soundausgabe und Eingabegeräte etc.

Nexus

Der Wrapper schrieb:

Klar kann man sie auch gegen eine eigenen Highlevel-Bibliothek austauschen und eigenes crossplattformfähiges Threading, Tastatur- und Joysticksteuerung usw. in seinen Code einbauen, aber warum sollte man sich diese Arbeit machen?

Ich habe nicht von Selbstmachen gesprochen. Aber davon, dass SDL nicht essentiell für das Funktionieren einer Grafikanwendung ist, weil man in vielen Fällen gerade so gut eine Alternative nutzen kann.

Der Wrapper schrieb:

Aber daraus folgt auch, daß [SFML] eigentlich nur für C++ Code sinnvoll ist, für alle anderen Spiele in anderen Programmiersprachen, also Python, Pascal usw. nimmt man dann doch besser die SDL weil diese eben in C geschrieben ist und die meisten Programmiersprachen eben spielend mit C Code klarkommen.

SFML hat ein C-Binding, also geht auch dieser Vorteil von SDL verloren. Damit bleibt nicht mehr viel übrig, das für SDL spricht.

Übrigens hat SFML auch Bindings für .NET, Ruby, Python und D. Soweit ich weiss, gibt es auch Leute, die ein Java- und Haskell-Binding implementieren.

Der Wrapper schrieb:

Irrlicht und Ogre sind fertige 3d Grafikengines und nicht nur Grafikbibliotheken.

Danke für den Hinweis. Den Begriff "Engine" habe ich noch nie gemocht...

Nexus schrieb:

Der Wrapper schrieb:

Klar kann man sie auch gegen eine eigenen Highlevel-Bibliothek austauschen und eigenes crossplattformfähiges Threading, Tastatur- und Joysticksteuerung usw. in seinen Code einbauen, aber warum sollte man sich diese Arbeit machen?

Ich habe nicht von Selbstmachen gesprochen. Aber davon, dass SDL nicht essentiell für das Funktionieren einer Grafikanwendung ist, weil man in vielen Fällen gerade so gut eine Alternative nutzen kann.

Das die SDL essentiell für das Funktionieren einer Grafikanwendung wäre, steht auch nirgends in meinem Posting.

Der Wrapper schrieb:

SFML hat ein C-Binding, also geht auch dieser Vorteil von SDL verloren. Damit bleibt nicht mehr viel übrig, das für SDL spricht.

Übrigens hat SFML auch Bindings für .NET, Ruby, Python und D. Soweit ich weiss, gibt es auch Leute, die ein Java- und Haskell-Binding implementieren.

Dann schau dir mal an, wie bei C++ Bibliotheken Bindings zu anderen Sprachen gemacht werden, also schau es dir low Level an, dann stößt du genau auf das, was ich geschrieben habe.

Deswegen ist die SFML eben kein guter Ersatz für SDL, wenn man z.b. in C oder einer anderen nicht C++ Sprache programmiert.

Der Wrapper schrieb:

Irrlicht und Ogre sind fertige 3d Grafikengines und nicht nur Grafikbibliotheken.

Danke für den Hinweis. Den Begriff "Engine" habe ich noch nie gemocht... :)[/quote]

Das ändert aber nichts daran, daß Engine nunmal der Begriff ist für Engines.

Grafikbibliotheken sind viel abstrakter, das kann alles sein, schon eine Lib, die dir hilft eine JPEG oder PNG Datei zu laden, ist eine Grafikbibliothek.
Sie ist aber dann noch keine Grafikengine.

Nexus

Der Wrapper schrieb:

Das die SDL essentiell für das Funktionieren einer Grafikanwendung wäre, steht auch nirgends in meinem Posting.

Okay, es steht etwas anders. Aber SDL ist aus dem gleichen Grund auch keine wichtige Bibliothek für die Spieleprogrammierung.

"Wichtig" bedeutet für mich "sollte man kennen" bzw. "man hat einen grossen Vorteil davon, wenn man es kennt". Und das ist meiner Meinung nach bei SDL nicht gegeben, zumindest nicht mehr als bei anderen ähnlichen Bibliotheken.

Der Wrapper schrieb:

Dann schau dir mal an, wie bei C++ Bibliotheken Bindings zu anderen Sprachen gemacht werden, also schau es dir low Level an, dann stößt du genau auf das, was ich geschrieben habe.

Du meinst, dass das Ganze durch ein Binding langsamer wird? Und ausgerechnet bei SDL bringst du das Geschwindigkeits-Argument?

Ethon

Also ich hab in meinem ganzen Leben noch nie ein Problem gesehen das in reinem C besser lösbar ist als in C++...

Ach, ich finde fscanf teilweise echt deutlich besser als mit std::ifstream zu arbeiten.

dot

Auch wenn ich das nicht nachvollziehen kann, fscanf() gibts auch in C++...

It0101

Wie macht man eigentlich das hier in C++ ?

printf( Text, "%-10.4s %-10.2f %-10.i" )

Also quasi "formatierte linksbündige Ausgabe".

otze

boost::format.

It0101

Das reine C++ bietet da also quasi nichts vergleichbares an?
Würde dann ja eigentlich ( von Boost mal abgesehen ) die Verwendung von Ansi-C-Code rechtfertigen.

RHBaum

Ich seh es so:

Beim Spieleprogrammieren wirst sehr oft ueber Bibliotheken(DirectX,OpenGL,SDL ... ) getrieben. Bibliotheken haben sehr oft ein C-Interface (Binaerkompatiblitaet fuer andere compiler, bindings fuer andere sprachen werden einfacher).
Also hasst Du sowieso scho eine C-like Aufrufsyntax am Hals.

Um das in gutes c++ zu überfuehren, muesstest halt viel wrappen. Wrappen bedeutet oft "kopie" -> performance ade.

Hinzu kommt, das grad c++ einen viel alltaegliches abnimmt, das aber oft performancetechnisch sehr naiv umsetzt. Man kann auch in C++ sehr porformant programmieren, klar, aber man muss sich an den einfachsten C++ Dingen da gedanken drueber machen.
In C sind die Dinge offensichtlicher. Man sieht kopien ! man denkt in kopien, weil jede kopie expliziet getaetigt wird. Man macht sich expliziet ueber Ressourcen im Vorfeld Gedanken. In C++ geht vieles im Hintergrund ...

Fazit:
Um performant in C++ Spiele Programmieren zu koennen, muss man sich bissi von dem C++ Hallo World Schema trennen, mehrere Dinge hinterfragen, in c++ untypische Richtungen denken. Und die Technik, die geschwindigkeitsnachteile wieder rausholen kann, ohne den Geschriebenen Code wie einen C-Dialekt aussehen zu lassen -> generische Programmierung -> aka Templates ist halt auch eines der Komplexesten und kompliziertesten Themen in C++.

Ciao ...

dot

RHBaum schrieb:

Also hasst Du sowieso scho eine C-like Aufrufsyntax am Hals.

Deswegen musst du dein Programm aber noch lange nicht in C schreiben.

RHBaum schrieb:

Um das in gutes c++ zu überfuehren, muesstest halt viel wrappen. Wrappen bedeutet oft "kopie" -> performance ade.

Gerade in C++ stimmt das so eben nicht unbedingt. Und die API zu Wrappen ist für ein gutes Design nicht wirklich eine notwendige Vorrausetzung. Manche C-style APIs (z.B. OpenGL) lassen sich rein prinzipiell nur sehr schlecht objektorientiert Wrappen, was aber auch gar kein Problem ist.

RHBaum schrieb:

Hinzu kommt, das grad c++ einen viel alltaegliches abnimmt, das aber oft performancetechnisch sehr naiv umsetzt.

An was denkst du da so z.B.? Mir fällt grad kein Sprachmittel ein das ein vernünftiger C++ Compiler "performancetechnisch naiv" umsetzt...

RHBaum schrieb:

Fazit: [...]

Du sagst also um mit C++ gut programmieren zu können muss man C++ beherrschen. Ja, dem kann ich nur zustimmen, aber das trifft auf jede beliebige andere Sprache auch zu...

dot

It0101 schrieb:

Das reine C++ bietet da also quasi nichts vergleichbares an?

Ähm, klar doch, printf() ist natürlich auch Teil von C++...
Allerdings würde man in C++ besser Streams verwenden und dafür gibts z.B. das. Die Streams bieten so sogar die Möglichkeit zwischen dem Vorzeichen und der Zahl aufzufüllen, was mit printf() afaik nicht geht. Und sie sind dabei natürlich typsicher...

It0101

dot schrieb:

dafür gibts z.B. das.

Aber das ist relativ umständlich zu verwenden. Für jede auszugebende Variable eine Zeile und deutlich mehr geschreibsel...

Also da bevorzuge ich immernoch printf...

RHBaum

Deswegen musst du dein Programm aber noch lange nicht in C schreiben.

Aber die Grenzen bzw. Codeanteile verschwimmen eh mehr in Richtung C ...

Gerade in C++ stimmt das so eben nicht unbedingt. Und die API zu Wrappen ist für ein gutes Design nicht wirklich eine notwendige Vorrausetzung. Manche C-style APIs (z.B. OpenGL) lassen sich rein prinzipiell nur sehr schlecht objektorientiert Wrappen, was aber auch gar kein Problem ist.

Das faengt schon viel tiefer an.
die klassische Version von C einen String zu liefern ist:

int getString(char * Buffer,size_t BufferSize);

Das ist Typisch C ...
Nun Wrappe das mal auf C++ ... Das einzige was mir zu einfallen wuerde ist ...

std::vector<char> myBuffer(128,0); 
int ir = getString(&myBuffer[0],myBuffer.size());

Super C++ dein String steht in nem Vector, ne wandlung in nen std::string ist die unnötige Kopie.

eine Alternaive:

char myBuffer[128];
int ir = getString(myBuffer,128);

Das das C++ ist, wirst wohl nich behaupten oder ?

andere Alternative:
Ne Klasse in C++ schreiben, die den String ersetzt und dann auch gleich mit Arrays aufm Stack umgehen kann.
Resultiert in üblen (Programmier)Overhaed ... oder verwendung von Bibliotheken, deren Anwendung alles andere als Trivial ist Und den Rahmen jedes Buches sprengen wuerde, wenn die da reinnimmst (boost z.b.)

An was denkst du da so z.B.?

Ganz konkret denk ich an das Beispiel. ct vor paar jahren. Vergleich von den Programmierumgebungen hinsichtlich performance. Das Abstruse Ergebniss: C++ ist langsammer als Java und C# mit .Net ...
Jeder der sich bissi tiefer in c++ auskennt, hat sofort gesehen, warum das Ergebnis kam. Das am C++ Beispielcode Performancetechnisch Verbrechen begangen wurden! Aber am Ende war es Code im dem Stil, wie es einige naive Tuts und andere Literatur vorschlagen und welcher auch von C++ Befuerwortern propagiert wird. Einfacher super wartbarer C++ code.
Ubrigens, Kommentar des ct Autors im Forum wo die Vorwürfe Ihm entgegengebracht wurden: Er habe c++ so verwendet wie man es "üblicher weisse" verwenden würde. Spezielle Kniffe und Tricks wie templates würden das ergebnis verzerren.
Das sagt doch scho mehr wie 1000 Worte oder ?

Das ne std::mapstd::string,std::string nie mit einem speziellen Dictonary in Java mithalten kann ... begreift man doch wirklich erst mit spaeterer Ausbaustufe. Oder warum QMap<QString,QString> um so vieles schneller ist ? Zu welchen Preis ?
<ironie>
Ja die Qt iss halt performanter als C++
</ironie>
Der compiler kann nix fuer, in sofern hab ich mich vielleicht falsch ausgedrueckt, nur c++ suggeriert eine einfache unkomplizierte naive Programmierweisse, welche Performance kostet. Und sogar ct Autoren fallen darauf rein ....

Ciao ...

Das das C++ ist, wirst wohl nich behaupten oder ?

Doch natürlich. Gewrappt könnte das dann so aussehen, wenn du unbedingt std::string verwenden willst:

std::string Wrapper::someFunctionName()
{
    char myBuffer[128];
    getString(myBuffer,128); // Den Rückgabewert müsste man natürlich irgendwie prüfen
    return myBuffer;
}

Natürlich wird hier auch kopiert, aber die Kopie ist nur unnötig, wenn du die zusätzliche Abstraktionsschicht durch std::string nicht brauchst. Wenn dem tatsächlich so ist, dann kannst du natürlich auch gleich einen char* zurückgeben und hast durch den Wrapper nichts gewonnen.