Hello, Guest the thread was viewed26k times and contains 268 replies

last post from ogd at the

Möchte man direkt auf einem (modernen) Retro Computer programmieren? [aus: heute so gepixelt]

  • Wie lange schätzt du würde das dauern

    Habe ich bisher nicht kalkuliert bzw. abgeschätzt. Auch weil die Grundidee immer mal wieder die Richtung gewechselt hat. Anfangs war alles offen – es hätte auch ein diskret aufgebautes Mainboard mit einer existierenden (z.B. 68K) oder neuen CPU (Konzept von M. J., Realisierung als FPGA) sein können oder auch insgesamt ein FPGA-Rechner, wie der Mega65. Auch war Anfangs die IDE noch kein so großes Thema. Erst durch Betrachtung der verschiedenen Probleme bei bestehenden oder in Entwicklung befindlichen Retro-Rechnern habe ich für mich persönlich viele anfangs denkbaren Wege langsam ausschließen können – zu teuer, zu zeitintensiv, zu weit weg von einer möglichen Realisierung, zu wenig leistungsfähig für eine gute IDE ...


    Deshalb ging die Idee immer weiter in Richtung: Nehmen, was schon fertig ist und klug kombinieren. Ich habe meine Vorstellungen ja immer mit anderen hier diskutiert und ich habe sicherlich eine Menge Leute "zurückgelassen", die andere Ideen (z.B. richtig was bauen) favorisierten. Die können diese ja, genau wie ich, auch im Kopf weiter entwickeln und vielleicht finden sie ja Mitstreiter für eine Realisierung – was mich freuen würde, weil es auch gute Ideen sind.


    Mein drastisch vereinfachter Fantasie-Computer würde auf einem vorhandene RISC-Board aufbauen (mit großer Wahrscheinlichkeit ARM (RISC-V aber nicht ausgeschlossen) und dort mit großer Wahrscheinlichkeit irgendwas aus dem Regal von Raspberry). Was genau, hinge zum einem vom Zeitpunkt ab (RISC-V kommt ja in Fahrt) und zum anderen davon, welche Komplexität von Spielen man denn realisiert sehen möchte. Dafür müsste man sich dann mal genau angucken, ab wann welche PICO-8- bzw. TIC-80-Games nicht mehr ruckelfrei laufen würden – und dann durch die Hardware-Entscheidung irgendwo die Grenze ziehen.


    Meine nächste persönliche "Entscheidung" (alles natürlich vorläufig und im Fluss) war, die "virtuelle Konsole" nicht bare-metal auf den "Raspi" zu packen (was wohl möglich wäre), sondern auf ein vorhandenes Betriebssystem als "Zwischenschicht" zu setzen. Favorit wäre ein (abgespecktes) GNU/Linux oder Android. Nachteil: Längerer Bootvorgang (wobei ich hoffe, dass das durchs Abspecken nur "ein paar" Sekunden sind). Vorteil: Einfachere Implementierung der virtuellen Konsole und vor allem: Treiber für WiFi, USB, Bluetooth und HDMI. Diese Lösung spart also mächtig Zeit und Aufwand ein, weil man nicht alles "zu Fuß" und selber machen muss. Diese modernen Protokolle sind ja ein Krampf – also gut, wenn das jemand "für uns" schon erledigt hat.


    Und dann natürlich quasi das Wichtigste: Die virtuelle Konsole inkl. IDE. Auch die würde ich niemals from scratch entwickeln lassen (unrealistisch) und ich glaube auch nicht, dass man eine Erlaubnis bekäme, die proprietäre PICO-8-Umgebung auf die eigene Lösung anpassen zu dürfen. Aber da gibt es glücklicherweise ein OpenSource-Projekt mit ganz ähnlichem Ansatz: TIC-80. Das könnte man natürlich nehmen und an die eigenen Wünsche anpassen. Wieviel Aufwand das wäre, hinge natürlich u.a. von den Leuten ab, die es machen würden – und was man neben Modifikationen noch so integrieren möchte.


    Es würden also einige Programmierer für unterschiedliche Bereiche benötigt: Leute, die sich mit Linux (oder Android) auskennen, Leute die eine Serveranwendung für den App Shop (ohne Zahlungsmodalitäten) schreiben/anpassen können, Leute, die sich in den TIC-80 einarbeiten mögen, um ihn anzupassen usw. Es gäbe (immer noch) viel zu tun – aber deutlich weniger, als wenn man auf gar nichts aufbauen könnte/würde. Niemand muss hierfür eine CPU erfinden, niemand muss sich eine Programmiersprache ausdenken, niemand muss einen Compiler bauen, niemand muss ein Betriebssystem oder diverse Treiber schreiben, niemand muss etwas löten, niemand muss Platinen ätzen, niemand muss einen FPGA programmieren usw.


    Und ganz zum Schluss wäre dann ja auch noch die Diskussion zur Bauform bzw. zum Gehäuse. Da gibt es natürlich auch schon einiges an Ideen – aber Details machen natürlich zum aktuellen Zeitpunkt der Ideenfindung kaum Sinn. Der Aufwand wäre sehr unterschiedlich, je nachdem, ob man ein eigenes Keyboard, "nur" eigene Keycaps oder einfach ein Keyboard von der Stange favorisiert. Auch die unterschiedlichen Bauformen (Tastatur intern oder extern) ziehen natürlich unterschiedlich große/viele Spritzgussteile nach sich. Da muss man abwägen, wie teuer der Spaß in der Herstellung werden darf. Man kann auch jetzt schon anfragen, was die Formherstellung kostet und in 3 Jahren kostet es das Doppelte, daher macht eine Kostenabschätzung zum aktuellen Zeitpunkt keinen Sinn.


    Machen es die Leute in 2 Jahren, dann müssten auch erstmal die reinen Entwicklerkosten von bis zu einer halben Million Euro gedeckt sein.

    Ich denke, es ist unrealistisch, irgendwen full-time zu bezahlen (außer man findet einen Sponsor oder schaufelt überraschend viel Kohle über Kickstarter rein). Das wird der 8-Bit-Guy, denke ich, auch nicht tun. Würde ich an so einem Projekt teilnehmen, würde ich mir dafür auch kein Gehalt zahlen (lassen). Da gehört viel Enthusiasmus und Selbstausbeutung (= Hobbygedanke) dazu, sonst würde letztlich vielleicht auch das Endprodukt zu teuer werden.


    Man könnte mal gucken, wie lange die MEGA-Leute (die machen das ja als Verein auch nicht full-time) oder auch der 8-Bit-Guy gebraucht haben, von der vorgestellten Idee bis zur ersten Charge. Ich würde den zeitlichen Aufwand (je nach Größe, Skills und Enthusiasmus eines Teams) maximal in einem ähnlichen Bereich verorten – wahrscheinlich weniger, da ich schon versucht habe, Komplexität herauszunehmen.


    Wenn man sich Mut machen will, sagt man sich, man müsse nur einen Raspi nehmen, darauf ein Schmalspur-Linux packen und darauf einen leicht angepassten TIC-80 installieren. Das Ganze in ein hübsches Gehäuse packen und dieses in einen Karton und den ab zu Amazon – fertig. ;)

  • Man könnte mal gucken, wie lange die MEGA-Leute (die machen das ja als Verein auch nicht full-time) [...] gebraucht haben

    Der erste Blog-Eintrag von Paul ist aus dem Oktober 2014, damals war es noch der C65GS, und es war voellig unklar ob daraus je ein echter Rechner werden wuerde. Wie lang er davor schon dran gearbeitet hat im stillen Kaemmerlein weiss ich nicht. Die Kooperation mit MEGA geschah meines Wissens erst 2015 herum. Die ersten "fertigen" Rechner wurden im Mai 2022 ausgeliefert.

  • Das mit dem RaspberryPI + Linux und TIC-80 könnte man gut forken und das würde dann sicher auch in der Freizeit in 2 Jahren machbar sein. Aber auch sich in andere Projekte einarbeite kostet ganz schön Zeit. Ich brauch da gut immer so ein halbes Jahr bis ich irgendwo richtig drin bin in so einer neuen Sache. Wenn so eine Plattform auch einfach im Browser läuft ist das schon mal eine gute Sache, schon vor 20 Jahren hat man gesagt, dass der Browser eigentlich das neue OS sein wird und worauf der nun läuft ist herzlich egal.

  • Und wenn es noch einfachen sein soll, dann macht PyGame wirklich großen Spaß: https://www.pygame.org/news Auch hier braucht man nur Python und VSCode installieren.

    "noch einfacher" ist relativ und die Frage ist ja auch, zu was. Ich habe eben ein kurzes Pygame-Tutorial angeguckt und der Vortragende hatte schon VSCode (und Python) auf seinem Rechner und musste "nur" noch Pygame mittels Terminal installieren. Zum Thema Assets (Grafiken, Sounds) wurde darauf verwiesen, man solle sie sich aus dem Internet klauen (also nicht in einem eingebauten Editor selbst erstellen) und auf dem Desktop in einen Ordner neben sein Projekt packen.


    Das ist jetzt alles kein Beinbruch für jemanden, der ein Spiel programmieren will. Aber es ist eben etwas ganz anderes als z.B. die IDE von PICO-8, in der man nach Download und Start der App alles direkt dort selbst machen kann (und auf keine vorhandene IDE angewiesen ist), von der Grafik, über die Sound-FX bis hin zu kompletten Leveln. Man muss noch nicht einmal auf den Desktop wechseln, um irgendwas irgendwo hin zu packen – man hat ja alles IN der IDE.


    Und dann muss man sich natürlich für eine Canvas-Größe entscheiden und gibt Farben in RGB an, statt eine Palette zu haben (die müsste man sich also auch anfangs ausdenken/anlegen, usw.)


    Ich bekomme langsam einen Eindruck, was du unter "einfach" verstehst. ;)


    "Flexibler" wäre das Adjektiv, was ich hier vergeben würde – aber höhere Flexibilität erzeugt eigentlich immer auch höhere Komplexität. Nichts gegen Pygame, das scheint mir auch ein schönes Tool für die Entwicklung von (Retrostyle-) Games zu sein – aber "einfacher" ist da meines Erachtens nichts.

  • Auch die unterschiedlichen Bauformen (Tastatur intern oder extern) ziehen natürlich unterschiedlich große/viele Spritzgussteile nach sich

    Für mich: Retrocomputer=Heimcomputer=Tastaturcomputer.


    Leider würde vermutlich eine eigene Tastatur bei einer niedrigen Stückzahl das teuerste an einem solchen Computer sein, oder? Und wie wir ja gehört haben, gibt es da einige Fetischisten, da da schon was (außer)ordentliches erwarten würden. Und wenn man DARAUF programmieren solll, ist das Qualitätsinteresse durchaus berechtigt. Heutzutage würde ich dazu sogar eine beleuchtete Tastatur fast schon voraussetzen, weil programmiert wird vermutlich oft zur späten Stunde im dunklen Kämmerlein.:lol33:


    Vom Formfaktor stelle ich mir sowas wie einen Amiga 600 vor. Vom Design her natürlich NICHT. :)


  • Nach deutlich weniger Code (geht hier schon über 2 Screenshots) konnte man in ZeHas Demo schon mit dem virtuellen Joystick ein selbstgezeichnetes Männchen über den Bildschirm steuern. Hier hat man gerade mal ein weißes Fenster erzeugt und kann es schließen. ;)


    Wen das Video trotzdem interessiert: Link. Ich finde, der Typ erklärt alles sehr gut – aber man muss doch viel mehr am Anfang tun, als bei PICO-8. Und letztlich macht das alles die Sache nicht leichter lesbar/verständlich.

  • Nach deutlich weniger Code (geht hier schon über 2 Screenshots) konnte man in ZeHas Demo schon mit dem virtuellen Joystick ein selbstgezeichnetes Männchen über den Bildschirm steuern. Hier hat man gerade mal ein weißes Fenster erzeugt und kann es schließen. ;)

    ...und in meinem Video kommt danach ja auch noch ein PyGame-Example, mit ca. 4x so vielen Zeilen :)


  • Nach deutlich weniger Code (geht hier schon über 2 Screenshots) konnte man in ZeHas Demo schon mit dem virtuellen Joystick ein selbstgezeichnetes Männchen über den Bildschirm steuern. Hier hat man gerade mal ein weißes Fenster erzeugt und kann es schließen. ;)


    Wen das Video trotzdem interessiert: Link. Ich finde, der Typ erklärt alles sehr gut – aber man muss doch viel mehr am Anfang tun, als bei PICO-8. Und letztlich macht das alles die Sache nicht leichter lesbar/verständlich.

    Wie Zeha es im Video gezeigt hat, da kamen gleich Erinnerungen auf, wie ich auf dem Zx Spectrum angefangen hatte, Print at x,y "🙂" If at x,y "Ghost" then... Oder so ähnlich :D das würde mir als fast nur Enduser zusagen...

  • Für mich: Retro=Heimcomputer=Tastaturcomputer.

    Ich kann den Einwand verstehen. Aber der 8-Bit-Guy versucht es ja auch anders. Und natürlich ist das ein wirklich großer Kostenfaktor.


    Es gab auch früher schon Rechner neben den typischen IBM-Bürocomputern, die eine abgesetzte Tastatur hatten, wie der C128D, Amiga 1000, Mega ST, IBM PCjr, Apple IIGS etc. Die wollten darüber natürlich professioneller wirken – aber letztlich landeten viele von denen trotzdem im Jugendzimmer – und man erfreute sich an der besseren Ergonomie.


    Aber ich denke dabei sogar noch etwas weiter: Nämlich an Spiele-Konsolen. Die hatten ganz selten (Philips G7000) ein integriertes Keyboard, sondern versuchten, auch ohne dieses markant und sympathisch auszusehen (mir fällt dabei sofort Nintendos GameCube ein). Und warum? Klar, weil man mit dem Joystick oder Gamepad zockt(e) und kein Keyboard benötigt(e). Das ist beim Homecomputer anders – aber nur, wenn man gerade nicht zockt – und ich habe früher recht viel gezockt. Ich würde sagen, dass einige meiner Kumpels es gar nicht gemerkt hätten, wenn der C64 kein Keyboard gehabt hätte (außer natürlich bei den DOS-Kommandos, um ein Spiel zu laden). ;)


    Warum also nicht das Keyboard behandeln, wie jeden anderen Controller (Gamepad, Maus, Lichtgriffel, Paddles, Lenkrad ...) auch? Wenn man es benötigt, "schließt man es an" (lustig bei Bluetooth) ;) und wenn nicht, dann eben nicht. Wenn man im Wohnzimmer ohnehin nur mit dem Gerät zocken will, warum dann nicht das Keyboard im Arbeitszimmer (oder neben dem Sofa) lassen?


    Natürlich ist die Herausforderung viel größer, einen ikonischen Homecomputer ohne integrierte Tastatur zu entwerfen – aber ich fände es (vor allem aufgrund der Kosten) einen Versuch wert.

  • Cool waere natuerlich auch ein Tastaturrechner mit wireless HDMI ;)


    Aber das tolle an diesem "Projekt" ist ja, dass man das zum jetzigen Zeitpunkt noch gar nicht festlegen muesste - man koennte rein mit der Software beginnen (allerdings durchaus mit Hardware im Hinterkopf), haette damit auch gleichzeitig den "Emulator" schon parat, und wenn daraus wirklich was werden sollte, koennte man immer noch die passende Hardware drumherum (fertig)designen, je nachdem was sich dann so anbietet.


    Inzwischen faende ich es ja auch reizvoll, solch ein Projekt direkt fuer den Pi400 als Plattform zu designen. Ich habe vor Jahren auch mal mit so einer Idee begonnen, habe ich aber eingestellt (und im Nachhinein gesehen war das auch die richtige Entscheidung), da wollte ich irgendwann in Richtung Raspi-in-Tastaturcase gehen. Wuerde ich das ganze jetzt nochmal neu angehen, wuerde ich aus Einfachheitsgruenden erstmal den Pi400 anvisieren.

  • die eine abgesetzte Tastatur hatten, wie der C128D, Amiga 1000, Mega ST, IBM PCjr, Apple IIGS etc

    Ich hatte/habe: C64C, Amiga500+, AMIGA1200HD(68030-50). Nur zum Verständnis meiner Sichtweise.8)


    Aber ich denke dabei sogar noch etwas weiter: Nämlich an Spiele-Konsolen.

    Das ist durchaus ein interessanter Ansatz.:thumbsup:


    Hauptgerät+Keyboard= Retro-(Heim-)Computer, Hauptgerät-Keyboard=Retro-Spielekonsole.

    In etwa wie CDTV und CD32, nur andersrum. :)


    Da müsste man halt vorher festlegen, welche "Buttons" für Spiele benötigt werden bzw. dass eben keine Tastatur vorausgesetzt werden darf (für Highscores u.ä. wäre das aber schon praktischer). Das Problem bestand ja grundsätzlich beim C64GS.

    Bei normalen C64-Spielen würde eine fehlende Tastatur schon das Überspringen des Crack-Intros verhindern.:D

    Man könnte auch ne Hand voll zusätzlicher Buttons am Gerät anbringen. Das gab's vor dem C64GS mal an einen Prototypen AFAIR.
    Da wären wir dann auch schon gleich (wieder) beim Joystick/-pad....:rolleyes:


    Eine externe, bereits verfügbare BT-Tastatur also. Die sollte man aber schon irgendwie CI-konform an den Rest des Systems/Designs anpassen, oder?

  • Da müsste man halt vorher festlegen, welche "Buttons" für Spiele benötigt werden bzw. dass eben keine Tastatur vorausgesetzt werden darf.

    Ja klar, das wäre so. Normale 1-Player PICO-Games steuere (und starte) ich auf dem Keyboard über die Cursortasten und Y/Z und X. Über die SDL-Library können bis zu 8 Controller angesprochen werden. Über PICO hinaus (ich würde ja ohnehin auf TIC-80 aufbauen wollen) würde ich je Controller vielleicht auf mehr als 2 Buttons und auch auf optionale Analog-Steuerung setzen. Die meisten BT-Controller dürften ja ganz gut ausgestattet sein.


    Eine externe BT-Tastatur also. Die sollte man aber schon irgendwie CI-konform an den Rest des Systems/Designs anpassen, oder?

    Optimal wäre eine optionale Tastatur im passenden Design. Wer das Geld dafür ausgeben mag (und/oder noch keine hat), könnte sie mitkaufen, wer sparsam ist und lieber seine vorhandene Tastatur nutzen möchte, kann das tun. So wäre allen geholfen. Ähnliches könnte man auch beim Gamepad machen: Entweder nimmt man einen PS- oder XBox-kompatiblen Controller oder den, der optisch zum Hauptgerät passt. Bei der Maus auch, usw.

  • Ich bekomme langsam einen Eindruck, was du unter "einfach" verstehst.

    Wenn alles schon komplett dabei ist inkl. Editoren für Musik und Grafik, dann hat das schon mehr was von so einem Game Maker, aber gut, wenn das viele so lieber haben, warum nicht.

    Bei PyGame muss man mehr machen als beim Pico, das ist richtig, aber dafür kann man hinterher Python programmieren, was auch nicht schlecht ist. Aber ist alles Geschmackssache, wenn man fest in einem System bleiben möchte incl. Grafik, Musik und Sound, dann ist das ok. Es gibt auch visuelle Programmiersprachen, da kann man sich das Kodieren auch noch sparen und klickt "nur" noch was zusammen. Die Unreal Engine kann man übrigens auch programmieren ohne eine Zeile Code zu schreiben, nennt sich da Blueprint.
    Unreal Engine 5 2D Game Tutorial [2023] - YouTube

  • Ich bekomme langsam einen Eindruck, was du unter "einfach" verstehst.

    Wenn alles schon komplett dabei ist inkl. Editoren für Musik und Grafik, dann hat das schon mehr was von so einem Game Maker, aber gut, wenn das viele so lieber haben, warum nicht.

    Bei PyGame muss man mehr machen als beim Pico, das ist richtig, aber dafür kann man hinterher Python programmieren, was auch nicht schlecht ist. Aber ist alles Geschmackssache, wenn man fest in einem System bleiben möchte incl. Grafik, Musik und Sound, dann ist das ok. Es gibt auch visuelle Programmiersprachen, da kann man sich das Kodieren auch noch sparen und klickt "nur" noch was zusammen. Die Unreal Engine kann man übrigens auch programmieren ohne eine Zeile Code zu schreiben, nennt sich da Blueprint.
    Unreal Engine 5 2D Game Tutorial [2023] - YouTube

    An Gary Kitchen's Game Maker für den C64 hat mich die Pico-8 auch erinnert. Nur, dass es halt integriert ist und nicht erst als Software geladen werden muss.

  • Wenn alles schon komplett dabei ist inkl. Editoren für Musik und Grafik, dann hat das schon mehr was von so einem Game Maker

    Nein, hat es nicht. Nur weil man sich seine Grafiken und Sounds nicht aus dem Netz zusammenklaut, sondern selber macht, ist das noch lange kein Game Maker. Programmieren muss man nach wie vor.


    Bei PyGame muss man mehr machen als beim Pico, das ist richtig, aber dafür kann man hinterher Python programmieren, was auch nicht schlecht ist.

    Und bei PICO lernt man Lua, was auch nicht schlecht ist. Du meinst doch selbst, dass es eigentlich egal ist, Hauptsache man lernt die Konzepte kennen. Und wie gesagt, die Idee ist nicht: Wie bringe ich jemandem Python bei, damit der Fit für den Arbeitsmarkt ist. Die Idee ist eher: Wie kann ich jemanden mit viel Spaß an der Sache dazu bringen, selbst ein Spiel zu coden, statt es nur zu spielen. Und wenn man dabei programmieren lernt: Um so besser!


    Es gibt auch visuelle Programmiersprachen, da kann man sich das Kodieren auch noch sparen

    Richtig. Aber das ist ja genau das, was hier niemand will. Wir wollen das Drumherum erleichtern, damit man sich auf das Programmieren konzentrieren kann – nicht das Programmieren abschaffen.


    Aber ich glaube, so langsam kommst du hinter das Konzept, was hier seit 11 Seiten Thema ist. ;)

  • Nein, hat es nicht. Nur weil man sich seine Grafiken und Sounds nicht aus dem Netz zusammenklaut, sondern selber macht, ist das noch lange kein Game Maker. Programmieren muss man nach wie vor.

    Musste man nicht bei einem GameMaker auch programmieren, weiß aber nicht mehr ob das auf dem Amiga oder C64 war?


    Und bei PICO lernt man Lua, was auch nicht schlecht ist. Du sagst doch selbst, dass es eigentlich egal ist, Hauptsache man lernt die Konzepte kennen.

    Das ist richtig, aber der Vorteil bei Python ist, dass man damit auch in der Berufswelt oder bei anderen Sachen weiter kommt, wie KI etc.

  • Musste man nicht bei einem GameMaker auch programmieren

    Keine Ahnung, habe ich mich nie für interessiert. Für mich hat schon der Name suggeriert, dass man da nur Fertigbauteile mit Maus oder Joystick zusammenstöpselt. Ich kenne eigentlich nur das, was bei SEUCK meistens herauskam: horizontal oder vertikal scrollende Ballerspiele (der Name sagt es eigentlich), die alle gleich funktionierten und bei denen sich nur die Sprites unterschieden. Zumindest war das seinerzeit mein Eindruck.


    Bei PICO hast du ein leeres Blatt. Ob du damit nun ein Text-Adventure, einen First-Person-Shooter, einen Zelda-Clone, einen scrollenden Bullet-Hell-Shooter, ein Labyrinth-Spiel, Super-Mario oder einen Strategie-Puzzler programmierst, hängt ganz von dir alleine ab. Alles geht, nichts ist vorgegeben. Dich scheint aber zu stören, dass man in der IDE Grafiken und Sounds direkt erzeugen kann und sich keine externen Editoren dafür suchen muss. Keine Ahnung, was daran frevelhaft sein soll. Ich würde es einfach "praktisch" nennen.

  • Dich scheint aber zu stören, dass man in der IDE alle Grafiken und Sounds direkt erzeugen kann und sich keine externen Editoren dafür suchen muss. Keine Ahnung, was daran frevelhaft sein soll. Ich würde es einfach "praktisch" nennen.

    Das würde mich nur stören, wenn die Leute dann vorhaben auch noch weiter die Reise der Spieleprogrammierung zu gehen, also dann auf dem PC z.B. Mit so einem Pico hat man zwar Grundkonzepte dann gelernt, aber muss sich dann erst mit IDE auf dem PC, andere Editoren usw. wieder auseinandersetzen. Ich finde, wenn man direkt auf dem PC anfängt, dann spart man schon Zeit am Ende. Wenn man allerdings bei Pico bleiben möchte, ist wieder alles fein, also wer den Käfig eh nicht verlassen möchte, für den ist der Käfig was Tolles, so in etwa, weiß ich ob ich das gut erklärt habe wie ich das meine.


    Hängt halt stark davon ab was die Zielgruppe möchte. Man könnte z.B. auch die Zeit für die Entwicklung des FantasyHeimcomputers nutzen um supertolle 2D Pixelgrafik Tuts für PyGames zu entwickeln + Community und zeigen wie das Ökosystem so auf dem PC funktioniert. Davon gibt es sicher schon eine Menge, aber das geht sicher noch viel besser, mit Discord Kanal, Forum, YouTube Videos, Templates, Erklärung von Algorithmen wie Wegfindung, Generierung von Zufallswelten ala Elite usw. Also so den Fokus auf das Wesentliche setzen, die Spieleentwicklung von PixelArt 2D Games der verschiedensten Gattungen, die dann auf jedem PC laufen.


    Wenn allerdings wirklich so ein geschlossenes System von der Zielgruppe erwünscht ist, dann wird da der Schwerpunkt drin liegen und Leute die dann mehr machen wollen, müssen erstmal umlernen, was nicht schlimm ist, nur eben wieder Zeit und Nerven kostet. Dann wurde hier noch die Ablenkung am PC genannt, die anscheinend für einige ein Problem ist, gut dann macht euch eine VM, in der nur die eine HobbySpieleprogrammierung drin ist, bei 2D Pixelart sollte Performance nich so das Problem sein, ansonsten müsste man sich einen VM-Host suchen der auch GPU-Passthrough kann, damit man die volle GPU-Power in der VM hat.

  • Das ist richtig, aber der Vorteil bei Python ist, dass man damit auch in der Berufswelt oder bei anderen Sachen weiter kommt, wie KI etc.

    Warum bringst du eigentlich immer wieder die Berufswelt ins Spiel? In diesem Forum sind die meisten User Ü40, Ü50, Ü60 und die Berufswahl ist abgeschlossen. Wenn ich eine neue Sprache lerne (egal, ob einen neuen Basic Dialekt, LUA, Python oder, oder, oder), denke ich als letztes darüber nach, was ich damit beruflich erreichen könnte. Aus mir wird kein professioneller Python-Programmierer mehr werden. Ich möchte einfach Spaß am Hobby haben, gelegentliche Programmiersessions inbegriffen. Dabei habe ich auch keinerlei Interesse am Programmieren für moderne Betriebssysteme, obwohl es ja z.B. durchaus interessante Sprachen gibt (z.B. BlitzMax, Pure Basic oder BBC Basic for SDL). Das finde ich einfach langweilig.


    Und wenn ein Projekt wie Pico-8 eine so niedrige Einstiegshürde und superschnelle Erfolgserlebnisse bietet, dabei aber durchaus mehr Möglichkeiten hat, als ich je ausnutzen können werde (siehe die vielen grandiosen Spiele), ist es mir furzegal, ob ich mit Python und co. NOCH MEHR Möglichkeiten hätte. Da schiele ich bestimmt nicht auf meine berufliche Zukunft...


    *****


    Was das Programmieren AUF (moderner) Retro-Hardware angeht: Es braucht (für mich!) eine halbwegs brauchbare IDE, somit sind schon mal fast alle klassischen Homecomputer ausgeschlossen. Nur am Amiga macht es halbwegs Spaß. Aber ich muss zugeben, dass ich oft mit dem Laptop auf dem Bauch auf dem Sofa liege und ein bisschen mit AmiBlitz unter WinUAE rumfrickle, anstatt mich an den (gut ausgestatteten) Amiga 3000 zu setzen. So würde es wohl auch mit einem "richtigen" modernen Retro-Computer laufen.


    Meine Antwort auf die Frage "Möchte man direkt auf einem modernen Retro-Computer programmieren?": Da halte ich es wie Fettes Brot: Ja, äh...nein...ich meine: JEIN! (Soll ich's wirklich machen, oder lass ich's lieber sein?) :D