Ergebnis 1 bis 20 von 33

Thema: Programmiersprache für games

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Java hat dafür das Problem einer in die Jahre gekommenen API. In C++ gibt es dafür keine wirkliche einheitliche API. Es gibt Boost und diverse Sachen, aber trotzdem habe ich das Gefühl das jedes C++ Programm seine eigenen Standard-Datenstrukturen und Algorithmen schreibt, das Rad also jedes Mal neu erfunden wird oO Was mich in C++ aber eher stört ist, dass es dem Programmierer zu viele Möglichkeiten gibt. Dadurch das selbst so grundlegende Operatoren wie der Zuweisungsoperator überladen werden können, kann man sich letztlich überhaupt nicht mehr darauf verlassen das ein Stück Code das tut was man von ihm erwartet. Hier ist Java halt sehr übersichtlich, da die Sprache in sich recht einfach aufgebaut ist. Dafür muss man halt sehr viel Code schreiben ^^°
    So Scriptsprachen wie Python, Ruby oder Lua sind natürlich auch ganz was feines. Ich denke aber das es für Anfänger sehr sinnvoll ist sich erst mal mit einer statisch typisierten Sprache vertraut zu machen um überhaupt die Ideen und Konzepte der Typisierung zu verstehen. Denn auch wenn in Python oder Ruby die Variablen keine Typen haben, sind deren Objekte dennoch strikt typisiert.

  2. #2
    Das Rad muss nicht immer neu erfunden werden, wenn man frei-nutzbare Code-Schnipsel (sogenannte Snipets, z.B. aus Tutorials) nutzt um seinen Code zusammen zu schreiben (Code-Recycling). C und C++ sind die meist-genutzten Programmiersprachen, da findet man vieles, was man haben will, und viel Unterstützung.

    Ich nutzte an der Runtime, die ich unter Ubuntu schreibe, C++ als Programmiersprache, für die Grafik ist SDL verantwortlich und für die Skriptbarkeit wird LUA rein gelinkt. Es funktioniert wunderbar damit.

    Bei Java und .Net braucht man immer noch eine VM die den Bytecode just-in-time interpretiert. Mono ist zwar schon weit, aber ist nicht 100%-.Net kompatibel.

    PS: Einziges Manko bei SDL: Es fehlt die Darstellung von Schrift. Es gibt zwar das Paket SDL_TTF, das aber irgendwie rumzickt. In 9 von 10 Fällen stürzte mein Programm mit einer "Segmentation Fault" ab. Deswegen nutze ich jetzt einen Bitmap-Font.

  3. #3
    Zitat Zitat von niR-kun Beitrag anzeigen
    Bei Java und .Net braucht man immer noch eine VM die den Bytecode just-in-time interpretiert. Mono ist zwar schon weit, aber ist nicht 100%-.Net kompatibel.
    Für alle die jetzt denken eine VM ist eine Seltenheit: Nein, jeder hat so was auf seinem Rechner, der einen modernen Browser nutzt.

    @Topic

    Was Maki und Kyuu gesagt haben sagt eigentlich alles. Ich hab mit dem Maker angefangen und bin da zu Java gegangen.

  4. #4
    Zitat Zitat von R.D. Beitrag anzeigen
    Für alle die jetzt denken eine VM ist eine Seltenheit: Nein, jeder hat so was auf seinem Rechner, der einen modernen Browser nutzt.
    Die Java VM, ob nun IceTea6 oder die OpenJDK/JVM nutzt ist ja egal - funktioniert größtenteils überall. Bloß bei .Net ist das Problem, dass es auf älteren Windows-Versionen nicht geht und nur eingeschränkt mit Mono läuft.

    Ob man nun Programmier-Sprachen nutzt, die auf einer VM laufen oder die nativ, ist eine Glaubensfrage. Beides hat Vor- und Nachteile:

    VM:
    Vorteil: - läuft auf so gut wie allen Systemen (.Net nur teilweise)
    - kein neu-kompilieren nötig bei anderem OS
    Nachteil: - die VM muss installiert sein und unterstützt werden
    - der Bytecode muss jedes mal beim aufrufen neu interpretiert werden

    nativ:
    Vorteil: - man brauch nur einmal zu kompilieren
    - keine VM nötig
    Nachteil: - für anderes OS (und z.B. bei Update der Shared-Libarys) neu-kompilieren notwendig

    PS: Ich hab mit dem RM2K angefangen, bin zwischendurch mal bei Pascal geblieben, dann auf RM2K3 umgestiegen und habe dann angefangen zu C++ um zu steigen.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •