Pixelor

Zitat von »henrikf«

Ja, ganz genau. Im harten Programmieralltag drückt sich das dann darin aus, das Unmassen an Software-Schnittstellen zwischen dem Spiel und der Computer-Hardware liegen. Es geht los bei der eigenen Programmierung, dann kommt eine wie auch immer geartete »Engine«, dann kommt das Betriebssystem und der Treiber für CPU/Motherboard/RAM/Grafik/Sound/sonstwas und dann landen die Daten irgendwann einmal dort, wo sie hoffentlich ankommen sollen. Zusammen gehalten wird das von einer oder mehreren Programmiersprachen (C, C++, Java, Lua, etcpp.). Und alle diese Ebenen müssen zum einen mit deren jeweiligen Schnittstellen korrekt angesprochen werden, was für sich schon ein unglaublicher Aufwand ist. Und dann haben die allesamt auch noch irgendwelche Bugs (Software hat IMMER Bugs). Und das kumuliert sich und dann kommen noch Terminschwierigkeiten dazu ... und ... BUMM!

Jepp. Selbst die Hardware wird heutzutage ja über eine Abstraktionsschicht befeuert. Immer mehr Funktionen und die Schnittstellen brauchen eben Speicher. Dazu kommt noch der Overhead durch Compiler. Assembler schreibt heute kaum jemand mehr - nicht nur aus Gründen der Portabilität auf andere Plattformen. C wird nur noch für Hardware-Nahes verwendet. Für Anwendersoftware kommt es immer seltener zum Einsatz - aus Gründen der Effizienz bzgl. Produktivität und Wartbarkeit.

C++ ist da schon besser, hat aber deutlich mehr Overhead, insbesondere wenn Templates zum Einsatz kommen. Aber ohne vielseitige Bibliotheken geht auch hier nicht viel. Kompiliert man die STL, dann vergrößert sich die Exe um ein Vielfaches. Das Einbinden der Boost-Lib und der UI-Lib Qt macht es so fett, dass es mit Java konkurriert. Frameworks als nächstgrößere Einheit vergrößern den Speicherbedarf um Größenordnungen. Und wenn man weiter abstrahieren möchte, z.B. mittels einer Engine oder einer Laufzeitumgebung, dann wird's richtig fett.

Selbst auf dem C64 konnte man das gut erkennen. Maschinensprache-Programme zu coden, dauert lange. Der Speicherbedarf war minimalst. Aus Spaß hatte ich dann mal Pascal auf dem C64 verwendet, mit dem ich deutlich produktiver war, weil ich mich auf das Problem, also auf das "Was" konzentrieren konnte und nicht unbedingt auf das "Wie". Wenn ich mich recht erinnere, nahm aber ein Kompilat schon mindestens 50 Blöcke (á 256 Bytes) in Anspruch. Spaßbremse war dann "Archer McLeans's Game Maker" mit 190 Blöcken für ein Game, dass aus ein bisschen Gedudel und zwei vierfarbigen Screens mit maximal acht Sprites bestand. Da kam ich bei Freunden schon in Erklärungsnot Da brachte es auch nichts, denen zu vertellen, dass ich das an einem Nachmittag zusammengeklickt hatte.

Aus betriebswirtschaftlicher Sicht ist es unsinnig, komplexere Sachverhalte per Assembler zu coden, die mehr als 128 KB einnehmen. Das kann dir keiner bezahlen, sofern es nicht Hobby bzw. Liebhaberei ist.

Die Einfachheit und die absolute Nähe zum System, das direkte Ansprechen von Registern... das vermisse ich heute in der Tat. Aber so etwas wird heute gar nicht mehr gewürdigt und als "Handwerk" abgetan. Nicht umsonst verdienen echte Coder recht wenig und sind austauschbare Ware (Offshoring). Die "Elite" philosophiert über Continous Integration / Lifecycle, Hot Deployment, Microservice und den restlichen Gedankenfürzen...

Um wieder on-topic zu kommen: Acrid hat mich wieder auf's Wesentliche zurückgeholt. Den noch verbleibenden C64 werde ich nun definitv nicht mehr verkaufen. Mehr noch: ich habe mir noch ein paar Sachen hierfür bestellt. Um Platz zu schaffen, verticke ich lieber die XBox, zu der ich im Gegensatz zum C64 so gar kein Bezug habe.

Mission erfüllt, lieber Acrid

Nachtrag: ... und weil ich mir die Princess Ultra bestellt habe, hätte ich die V2 noch für einen Rechner aus der 264er-Reihe übrig

Sehr schönes Video, habe mich sehr darüber gefreut

In Sachen Retro-Computer bin ich weiterhin sehr gespannt auf den Mega65 bzw. wie das System - sofern es irgendwann einmal kommen sollte - aufgenommen wird.