spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

ein Vorteil von wxWidget ist auch noch die Plattformunabhängigkeit. Man muss halt wissen was man haben will!

Ciao DarthB :huhu:

WinAPI rulez.

Wenn du wirklich etwas elemetares und vernünftiges lernen willst dann lerne WinAPI, so schwer isses auch nicht. Du wirst NIE wieder riesige Bibliotheken benötigen und hast ein sehr mächtiges Werkzeug. Ausserdem ist sie unerlässlich um wirklich mal windows zu verstehen. Wenn du MFC und den anderen Kram dir anschaust, sieht du Abstraktionen der WinAPI. Nur MFC hat ne ganze Menge Nachteile, u.a. die Größe.

Das einzige Buch was du dir kaufen solltest ist Petzolds "Windows-Programmierung". Wenn du das hast brauchst du kein weiteres. Da werden mir sicher alle zustimmen.

Der einzige, gute Grund um auf WinAPI zu verzeichten ist Plattformunabhängigkeit. Aber die ist dir sicher im Moment wurscht.

Zitat

De facto ist die WinApi das Grundgerüst für alle Win Anwendungen.

Zitat

Und normal braucht man die Winapi gar nicht zum Spieleprogrammieren da man ja ne Engine hat die einem das alles abnimmt, dafür sind die doch da.

Eben doch, den ohne die WinAPI wäre deine schöne "Engine" vollkommen nutzlos.

Zitat

Also von daher ist es nicht nötig dich mit der winapi tiefer auseinanderzusetzen.

Falsch. Wenn du etwas über Windows Programme lernen willst und vorallem verstehen, ist WinAPI der einzig vernünftige Weg.

Zitat

Wenn du Tools für dein Spiel programmierst wirst du sowieso auf ne GUI Library zurückgreifen.

... welche wiederrum die WinAPI benutzt. Ok, nicht alle aber die meisten. Problem an der Geschichte ist wiederrum die Große. Warum willst du Programme die >10MB sind, nur wegen dieser "tollen" Bibliotheken?

Ein guter Programmierer schafft ein Programm in < 1MB mit den gelichen Funktionen, glaub mir. Du solltest auch mal an den User denken, nicht alle haben DSL. (z.b. ich )

Es gehört einfach zu einem guten Programmierstil, genauso wie NO BUGS.

Zitat

Das heißt, auch mit der Vollversion von VC 2005 habe ich Zugriff auf die API-Funktionen und das wurde in der Express Beta abgestellt?

Hmmmnn... keine Ahnung, kann aber sein. Microsoft probiert eh von je her alles vernünftige zu abstrahieren. Mich würde es nicht wundern wenn .NET MFC benutzt *G* welches wiederrum WinAPUI braucht LOL. Aber ich glaube so intelligent sind die schon.

Zitat

Wenn du allerdings ganz spezielle Dinge brauchst ist die winapi manchmal der einzige Weg...

Aha. Richtig, weiso dann nicht gleich alles mit der guten, alten WinAPI? Oder soll ich jetzt da die GUI Lib nehmen, dort das .NET Framework und wenn ich mal nicht weiterkomm die WinAPI? DAS ist SEHR sCHLECHTER PROGRAMMIERSTIL.
Und sollte von keinem anzustreben sein.

.Net nutzt winforms, die wiederum eine versteckte winapi nutzt

@SP

Beides LOL. Ich hab ne eigene Engine die DirectX abstrahiert, mir aber trotzdem vollen Zugriff erlaubt. Aber die "Engine" wurde von mir entwickelt und enthällt die ein oder andere Abstraktion (z.B. Netzwerk).
Hat vom Netzwerk übber 3D bis zu Sound soweit alles drinne. Ist aber wesentlich schlechter als die Tribase.

Reine Windows Anwendungen schreib ich mit WinAPI reinform.

Sry, wenn mein beitrag vorhin etwas "aggressiv" war.
Aber ich hab früher selber mit VCL gearbeitet, später hab ich erkannt das das keinem was bringt, da ich das nicht verstehe. Insofern möchte ich jedem von diesen "Bibliotheken" abraten, verbieten kann man es nicht .


@Crash.
Petzolds Buch ist die optimale Referenz zu dem Thema. Hat wirklich alles drinn (bis auf Kleinigkeiten). Von Bitmaps in Menüs, bis hin zu Erläuterung von UniCode. Es kostet zwar etwas, aber das ist es Wert. (hab es selber)

Rechenintensiv sollte meiner Meinung vor Zeitintensiv stehen, wer dies nicht beachtete der ist kein wirklich guter Programmierer.

Zitat von »"Nox"«

.Net nutzt winforms, die wiederum eine versteckte winapi nutzt

hehe, nicht unbedingt. ist ja theoretisch alles plattformunabhängig und auch die winforms werden mittlerweile von der aktuellen mono-version untersützt und laufen ohne winapi auf linux/unix/mac...