4. Spieleprogrammierung

Spieleprogrammierung

  • G

    otze schrieb:

    -> WinAPI wurde und wird immer weiter Entwickelt!

    *hust* *hust* sorry, hab mich spontan verschluckt 😉

    die winapi wird nicht mehr weiterentwickelt, das nächste windows unterstützt sie zwar noch,aber führt sogleich was völlig neues ein.

    Naja, bisher hatte ich den Eindruck die bauen alles in C (erweitern quasi die WinAPI) und kapseln dass dann in was objekt-orientiertes weg 😉

    0
  • B

    *humpf* jetzt beantwortet doch nicht alle Fragen, die nur mir gestellt wurden 😃 😉

    MiC++ha schrieb:

    Blue-Tiger schrieb:

    WinAPI zu lernen ist IMO Zeitverschwendung: WinAPI ist uralt, wird nicht weiterentwickelt, ist monstroeus und ist haesslich....

    Frage: hast du #includes "windows.h" in deinen Source, wenn ja warum?
    Frage2: Sollen Gamedev´s nicht in der lage sein App´s mit einfachen Funktionen zu schreiben, für z.B. leveleditor etc. -> braucht WinAPI;

    -> WinAPI wurde und wird immer weiter Entwickelt!
    -> WinAPI brauchst du bei jedem Windows Programm, ob Game oder App
    Die einzige Zeitverschwendung war dein Posting!

    1. nein, hab ich in noch gar keinem... Es gibt bessere GUI-Libraries, z. B. gtkmm ( www.gtkmm.org ), wxWidgets (www.wxwidgets.org) usw. Es gibt auch eigens auf Gamedesigner zugeschnittene, z. B. das FLTK...
    Und wenn ich auf GUI-Funktionalitaet verzichten kann, hab ich z. B. mit SDL ( www.libsdl.org ) auch was besseres zur Hand

    2. ja, sie sollen einfache Apps schreiben, Nein, sie sollen dafuer NICHT die WinAPI verwenden, da die WinAPI wie gesagt uralt ist, nicht weiterentwickelt wird, monstroeus und haesslich ist 😉 Wie unter 1. genannt (und von anderen Leuten im Thread ja auch) gibts wesentlich bessere Tools fuer den Job

    -> WinAPI brauchst du bei jedem Windows Programm, ob Game oder App
    Die einzige Zeitverschwendung war dein Posting!

    Absolut falsch, brauchst du NICHT in jedem Windows Programm (mal so BTW: Konsolen-Programme sind auch Windowsprogramme).... wie gesagt siehe oben 😉

    (also wessen Post jetzt Zeitverschwendung (aber noch viel schlimmer: Fehlinformationen-Weitergebend) war.... 😉 )

    0
  • F

    @ otze

    Was ist den das Neue, das Bessere was es sich zu lernen lohnt?

    0
  • M

    Ich bin vermutlich doch ein zu hartnäckiger "Hardcore-Coder" 😉
    Klar mit entsprechenden anderen Libs die dann wiederum auf die Windows Functionen zugreifen, braucht man das nicht und wer Borland-Builder hat auch nicht, ausser es wird etwas speziäler.

    "Wird nicht weiter Entwickelt!" dem kann ich nicht ganz zustimmen, denn die wird gut überarbeitet so das einige Funktionen auch auf bestimte Versionen laufen, e.g. "now supported in XP, 2000 and NT"
    Und es wird auch was neues kommen wo die Funktionen der WinAPI drinn stecken, es wird nur anders heissen, aber nicht direkt was anderes sein.
    Das Ziel von M$ ist es nicht die WinAPI Progger zu verärgern, sondern ihnen noch mehr zu bieten.

    0
  • C

    Nochmal: Die WinAPI und MFC werden NICHT mehr weiterentwickelt. Es wird zukünftig nur mehr die bereits bestehende API aus kompatibilitätsgründen unterstützt bzw. vom .NET Framework emuliert. Aber die Methode um neue Programme zu schreiben, wird definitiv .NET lauten.

    0
  • H

    ChockoCookie schrieb:

    Nochmal: Die WinAPI und MFC werden NICHT mehr weiterentwickelt. Es wird zukünftig nur mehr die bereits bestehende API aus kompatibilitätsgründen unterstützt bzw. vom .NET Framework emuliert. Aber die Methode um neue Programme zu schreiben, wird definitiv .NET lauten.

    schon, vordegründig. Die Base Feautures der WinAPI sind natürlich nicht weiterentwickelt worden, jedoch neue Funktionen wurden durchaus eingeführt.
    z.B. wurden mit Windows 2003 neue Fiber Funktionen eingeführt(FlsAlloc etc.).

    Sogar beim SP1 vom Windows XP wurden afaik ca. 10 neue Funktionen in die WinAPI getan.

    Klar, allzu sehr setzten sollte man nicht mehr auf die WinAPI. Jedoch als .net Verfechter kann ich nur sagen, dass man die WinAPI nur nutzen sollte, wenn es umungänglich ist 😉

    MFC ist natürlich ein Auslaufmodell. Wer die verwendet ist selbst schuld 😃
    (Außerdem wurde auch die MFC weiterentwickelt. z.B. ist die jetztige Versionsnummer 7 oder so. Aber weiter gehen die von MS afaik nicht mehr)

    0
  • B

    Hauptmann schrieb:

    z.B. ist die jetztige Versionsnummer 7 oder so. Aber weiter gehen die von MS afaik nicht mehr)

    sicher dass du nicht die ATL meinst? Die hat naemlich wirklich Versionsnr. 7 im Moment... MFC ist AFAIK absolut total tod 😉

    0
  • H

    Blue-Tiger schrieb:

    Hauptmann schrieb:

    z.B. ist die jetztige Versionsnummer 7 oder so. Aber weiter gehen die von MS afaik nicht mehr)

    sicher dass du nicht die ATL meinst? Die hat naemlich wirklich Versionsnr. 7 im Moment... MFC ist AFAIK absolut total tod 😉

    hmm denke schon. In der MSDN(von mir offline) steht:

    The MFC Reference covers the classes, global functions, global variables, and macros that make up the Microsoft Foundation Class Library version 7.0.

    😉

    0
  • I

    Facer schrieb:

    @ otze

    Was ist den das Neue, das Bessere was es sich zu lernen lohnt?

    .NET.

    Mir Wurst ob es unsachlich klingt, aber: Managed DX rules 😃

    0
  • B

    Hauptmann schrieb:

    Blue-Tiger schrieb:

    Hauptmann schrieb:

    z.B. ist die jetztige Versionsnummer 7 oder so. Aber weiter gehen die von MS afaik nicht mehr)

    sicher dass du nicht die ATL meinst? Die hat naemlich wirklich Versionsnr. 7 im Moment... MFC ist AFAIK absolut total tod 😉

    hmm denke schon. In der MSDN(von mir offline) steht:

    The MFC Reference covers the classes, global functions, global variables, and macros that make up the Microsoft Foundation Class Library version 7.0.

    😉

    sorry, wusst ich nicht 🙂

    0
Anmelden zum Antworten