API, MFC und so weiter

[Ein ehemaliger Benutzer]

rüdiger schrieb:

Was Vertices und Texturen sind, muss er ja auch bei einer fertigen 3D Engine wissen.

Ja, aber das Verständnis einer GameEngine fällt tausend mal leichter, wenn man das schon weiss. Einem Anfänger in der Spieleprogrammierung würde ich eher alle Nehe-Tutorials empfehlen, als eine fertige Engine. Da bekommt man Schritt für Schritt die Grundlagen und vor allem die Begriffe beigebracht.
rya.

[rüdiger]

Scorcher24 schrieb:

rüdiger schrieb:

Was Vertices und Texturen sind, muss er ja auch bei einer fertigen 3D Engine wissen.

Ja, aber das Verständnis einer GameEngine fällt tausend mal leichter, wenn man das schon weiss. Einem Anfänger in der Spieleprogrammierung würde ich eher alle Nehe-Tutorials empfehlen, als eine fertige Engine. Da bekommt man Schritt für Schritt die Grundlagen und vor allem die Begriffe beigebracht.
rya.

Ich sehe jetzt den Unterschied nicht. Um wirklich zu begreifen was Vertices und Texturen sind, sollte er wohl eher einen Renderer selbst schreiben.

[wowuwu]

rüdiger schrieb:

Was Vertices und Texturen sind, muss er ja auch bei einer fertigen 3D Engine wissen.

Ja, und?

[rüdiger]

wowuwu schrieb:

rüdiger schrieb:

Was Vertices und Texturen sind, muss er ja auch bei einer fertigen 3D Engine wissen.

Ja, und?

Du meintest, er soll wissen was das ist.

[Apollon]

Ruediger hat Recht, oder anders gefragt: wo beginnt denn die "Spieleprogrammierung"?

Fertige Engines wie Ogre3D oder Irrlicht schaffen eine hoehere Abstraktionsebene, was einem erlaubt auf Detailwissen zu verzichten und sich auf die "Spieleprogrammierung" zu konzentrieren, statt auf die Grafikprogrammierung. Bei Spieleprogrammierung denkt man nicht an Grafikobjekte, sondern an Spielobjekte.

[wowuwu]

rüdiger schrieb:

wowuwu schrieb:

rüdiger schrieb:

Was Vertices und Texturen sind, muss er ja auch bei einer fertigen 3D Engine wissen.

Ja, und?

Du meintest, er soll wissen was das ist.

Ich hab mehr gesagt als das. Musst schon den Zusammenhang betrachten und nicht nur ein paar Wörter raussuchen.

Apollon schrieb:

Ruediger hat Recht, oder anders gefragt: wo beginnt denn die "Spieleprogrammierung"?

Fertige Engines wie Ogre3D oder Irrlicht schaffen eine hoehere Abstraktionsebene, was einem erlaubt auf Detailwissen zu verzichten und sich auf die "Spieleprogrammierung" zu konzentrieren, statt auf die Grafikprogrammierung. Bei Spieleprogrammierung denkt man nicht an Grafikobjekte, sondern an Spielobjekte.

Grundlagen != Detailwissen. Ich weiß nicht wieso ihr das immer vermischt.

[seux]

danke erstmal für die vielen Antworten
ich hab jetzt erstmal das API Buch beiseite geschoben und eins für die MFC rausgesucht.

Was Vertics, Texturen und so sind, weiß ich und ne Umgebung würde ich hinkriegen.

@Scorcher24: danke, ich werd dir gleich ne e-mail schicken, oder per icq...

Wenn MFC veraltet ist, wie rüdiger meint, was ist denn dann aktuell?

[Ein ehemaliger Benutzer]

wxWidgets als Bsp oder GTK. Ich empfehle aber wxWidgets, ist imho attraktiver und komplett in C++.
http://wxwidgets.org
rya.

[seux]

kann ich in den wxWidgets auch auf API funktionen zugreifen, wie bei den MFC?

[rüdiger]

API? API ist ein allgemeiner Ausdruck. Welche API meinst du?

Ich würde dir eher FLTK empfehlen, da es klein und kompakt ist. Die API ist ein bisschen OpenGL ähnlich und verfügt über gute OpenGL Integration.

[C++ Forumbot]

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Andere GUIs - Qt, GTK+, wxWidgets verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[seux]

ich mein die WinAPI

[Ein ehemaliger Benutzer]

seux schrieb:

ich mein die WinAPI

Natürlich würde das gehen, ist aber nicht notwendig. wxWidgets ist XPlatform, das bedeutet, deine Progs kompilieren sowohl unter Windows als auch unter Linux oder Mac etc. wenn du jetzt direkt die WinAPI verwendest, geht das nicht mehr.
Vor allem isses aber wie gesagt nicht nötig. Alles was mit der WinAPI an Fenstern/Controls etc geht, geht auch mit wxWidgets und vieles mehr.
rya.

[Artchi]

seux! Denke doch mal nach: nur weil du eine zweit oder dritte Library benutzt, fliegt doch die erste Library nicht raus. Warum sollte also die Win32-Library nicht mehr funktionieren, wenn du wxWidgets benutzt?

Scorcher24! Er kann trotzdem Win32-APIs aufrufen, ist ja seine Entscheidung, wofür er wxWidgets missbraucht. Da er auch MFC benutzt hätte, ist ihm platformunabhängigkeit ziemlich wurscht. Und das ist legitim.

[seux]

ich danke euch erstmal für die Antworten

@Scorcher ich hab dich über icq ne Nachricht geschickt, wegen dem nativen Win32 Fenster

[Ein ehemaliger Benutzer]

Artchi schrieb:

Scorcher24! Er kann trotzdem Win32-APIs aufrufen, ist ja seine Entscheidung, wofür er wxWidgets missbraucht. Da er auch MFC benutzt hätte, ist ihm platformunabhängigkeit ziemlich wurscht. Und das ist legitim.

Hab ja geschrieben, dass er das kann und ihm zugleich aufgezeigt, dass es nicht gerade sehr weise wäre, das zu tun. Wenn Ihm Plattformunabhängigkeit egal is, is mir das auch egal^^. Aber darauf hinweisen ist doch erlaubt oder? Oder wo liegt das Problem?
rya.

[Shogun]

Scorcher24 schrieb:

seux schrieb:

ich mein die WinAPI

Natürlich würde das gehen, ist aber nicht notwendig. wxWidgets ist XPlatform, das bedeutet, deine Progs kompilieren sowohl unter Windows als auch unter Linux oder Mac etc. wenn du jetzt direkt die WinAPI verwendest, geht das nicht mehr.
Vor allem isses aber wie gesagt nicht nötig. Alles was mit der WinAPI an Fenstern/Controls etc geht, geht auch mit wxWidgets und vieles mehr.
rya.

Events, WaitForMultipleObjects
Zwei Gründe dafür, dass man bei wxWidgets doch an die Api muss. Ich hab noch keinen wirklichen Ersatz gefunden.

[phlox81]

Shogun schrieb:

Scorcher24 schrieb:

seux schrieb:

ich mein die WinAPI

Natürlich würde das gehen, ist aber nicht notwendig. wxWidgets ist XPlatform, das bedeutet, deine Progs kompilieren sowohl unter Windows als auch unter Linux oder Mac etc. wenn du jetzt direkt die WinAPI verwendest, geht das nicht mehr.
Vor allem isses aber wie gesagt nicht nötig. Alles was mit der WinAPI an Fenstern/Controls etc geht, geht auch mit wxWidgets und vieles mehr.
rya.

Events, WaitForMultipleObjects
Zwei Gründe dafür, dass man bei wxWidgets doch an die Api muss. Ich hab noch keinen wirklichen Ersatz gefunden.

Events kannst du auch mit wxWidgets selber implementieren.
Und sonst lässt sich das ja ohne probleme in ein #if hüllen, so das man trotzdem XPlattform bleibt,
aber evtl. einige Funktionalitäten halt erstmal in mit der WinAPI abbilden muss.