• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Pygame vs. Amiga

abgdf

Guru
Hi,

die meisten Pygame-Spiele gefallen mir nicht. Gut, so viele hab' ich auch nicht probiert, nur ein paar. Aber die sahen schlecht aus. Woran lag das? Vielleicht, weil die Umgebung nicht so war, wie ich das gewohnt war. Für den Anfang wollte ich eine einfache, vertraute Umgebung und hatte Pygame so eingestellt, daß das Ergebnis genau so aussah, wie auf einem Sinclair ZX Spectrum, meinem ersten Computer. Man konnte die Auflösung und die acht Farben genau einstellen, schließlich auch die Spectrum-typische Schrift (nach Konvertierung der Font-Daten aus dem alten ROM). Ok, das war alles interessant, aber soll jetzt nicht das Thema sein.
Den C64 kenne ich nicht gut, lerne den vielleicht gerade erst kennen.
Aber wäre es nicht cool, mit Pygame ein Amiga-Spiel programmieren zu können? Dachte ich gerade. Ist das dafür schnell genug? Python und Pygame sind relativ langsam, aber moderne Rechner sind einige tausendmal schneller als ein Amiga 500, der mit nur 7 Mhz getaktet ist. Das müßte doch eigentlich gehen.
Und hier ist jemand, der sowas gemacht hat. Er hat 1992 einen 3D-Teil einer Demo auf dem Amiga programmiert und diesen Teil nach Pygame "portiert". Und in einem Blog detailliert beschrieben, was er gemacht hat. Sehr cool, finde ich. Bin beeindruckt.

Die Amiga-Demo von 1992:
https://youtu.be/OKF2cj8rIKg?t=164

Blog und Download der Python-Skripte:
https://oldskoolpython.blogspot.com/2020/02/real-time-3d-vector-graphics-with-python.html
https://github.com/zeque92/RealTime3DwithPython

Zum Vergleich: "Frontier / Elite II" (1993) mit Mussorgskis "Bilder einer Ausstellung" (1874):
https://youtu.be/Yc9o_ldmlVs?t=74

--------------------

Ah ja, einen Atari 800 XL hatte ich früher auch mal, hab' aber ebenfalls nie begriffen, wie man den programmiert. Ein Programmierer, der vor allem für seine Musik auf dem Atari bekannt war, war Kemal Ezcan. Der nennt sich heute, ein halbes Leben später, Yoda Zhang, und hat eine Webseite mit Spielen im Atari-Stil, die im Browser laufen. Z.B. "Bomber Jack" ist recht gut:

http://www.yodasvideoarcade.com

Das kann man also auch machen. Cool.
 

manzek

Hacker
Wenn ich mich recht entsinne, war der C64 sogar nur mit 1.0 MHz getaktet; der C128 mit 2.0 MHz. Eine Emulation hätte heutzutage also fast 32.000 mal mehr Zeit als damals, wenn man den heutigen Takt mit 4.0 GHz sowie die Anzahl der Rechenkerne mit durchschnittlich 4 und jeweils 2 Threads rechnet.
Ich hatte mich damals eher um praktische Themen, wie die Darstellung eines Telefonsymboles eines Textverarbeitungsprogrammes auf einem 24-Nadel-Drucker gekümmert, das in einer BASIC 2.0-Version dem Verlag Markt & Technik damals immerhin 100 DM wert war. :D
 
abgdf schrieb:
... aber moderne Rechner sind einige tausendmal schneller als ein Amiga 500, der mit nur 7 Mhz getaktet ist.
Das stimmt so nicht. Der Amiga 500 lief mit dem 68000 (dieser Prozessor war jedoch vor meiner Zeit).
Angefangen habe ich während meiner Studienzeit mit dem 68030 (CPU Frequenz 50 Mhz). Der stammt aus derselben Motorola Familie.
Dieses Design war in der graphischen Darstellung schon damals ca. doppelt so schnell als ein heutiger, moderner Rechner.
Mit der damaligen Auflösung brauchte man für ein Sprite ca. 140 pixels (Grafikobjekt mit 12x12), heute brauchst du über 10.000 pixels, sonst siehst
du das Objekt nicht mehr. Dazu kommt Python, die gesamte Pipeline zwischen CPU und Graphikkarte, wesentlich mehr bits je pixel wegen der
hohen Farbtiefe und viel mehr pixels, um dieselbe Objektgröße zu erreichen. Obendrein bewegst du ein Sprite in der Horizontalen im alten desigen von einem Ende zum anderen in ca.160 Instruktionen, am neuen Rechner brauchst du 2000. Im Gegensatz zum alten Design von Motorola erhält
die CPU in modernen Rechnern keine Unterstützung von einem Graphikprozessor für Grafikobjekte, außer du schreibst direkt in die GPU, wie das
Spieledesigner heutzutage so machen. Wird das von Python unterstützt? Keine Ahnung.
Wenn ich das alles multipliziere, bin ich mir ziemlich sicher, dass du mit einem modernen Rechner an die Geschwindigkeit eines alten Amiga 500
für deinen Zweck nicht herankommst.

PS. Tipp von einem Kollegen, der in der Spielebranche tätig war.
Um dem Problem zu entgehen, verwenden die virtuelle Pixel.
Diese virtuellen Pixel bestehen aus einem Array aus Pixeln, z.B. 12x12 und mit denen werden die Objekte gezeichnet.
Dadurch wirkt die Auflösung zwar niedriger aber die Bewegung wird flüssig.
 
marce schrieb:

Für 1 pixel galt damals 8 bits.
Der 68000 hatte ein Busbreite von 16 bits, d.h. er setzt 2 pixels pro Prozessorzyklus je 0.6µS.
Sind in der damaligen gesamten Vertikalen von 256 pixels ca. 80µS

Ein modernes System verwendet 32 bits je pixel, davon 1 byte für alpha. (Darfst du abziehen)
Rechne aus die Prozesszeit für eine Vertikale bei heutzutage verwendeter Auflösung und einer Linkbreite von typisch x16 auf PCI 4.0
Danach vergleichen wir wie lange es braucht, diese Linie horizontal über die gesamte Breite zu verschieben.
Tipp: der Amiga brauchte dafür 320*128 Prozessorzyklen für 640 auf der Horizontalen.

*rofl*
 
OP
A

abgdf

Guru
@Gräfin Klara: Danke für die Infos. Ich hab' mich immer gewundert, wieso das anscheinend so schwer ist, wenigstens an die Geschwindigkeit des Amiga heranzukommen. Deine Angaben würden das wohl erklären. Allerdings: Für Spiele und solche Sachen benutzt man unter Linux ja meist die SDL-Bibliothek. Die heißt ja schon SDL - "Simple Direct Layer", sollte also ebenfalls relativ direkten Hardwarezugriff ermöglichen. pygame sind dann nur Python-Bindings für SDL.
In dem Artikel schreibt er, der Unterschied komme auch daher, daß der Amiga damals ganz "leer" gewesen sei und sich nur auf diese direkten Hardwarezugriffe konzentriert habe, während bei Linux ja noch das ganze Betriebssystem im Hintergrund mitlaufe. Das wäre auch eine Erklärung.

Wie schnell pygame dann wirklich ist, kannst Du ja mit dem Python-Code in dem Link sehen. Deshalb hatte ich den ja gepostet. Es sieht tatsächlich aus wie in der Amiga-Demo (was mich überrascht hatte) - schöne (alte) 3D-Vektorgraphik. Bei vielen Schattenberechnungen usw. wird es allerdings etwas langsam. Fragt sich, ob man das noch optimieren könnte.
Aber es muß ja auch nicht 3D sein. So ein Top-Scroller wie "Xenon" oder so wäre doch auch nett. Ich finde auch, das alte "Giana Sisters" sieht immer noch besser aus als "SuperTux" (Linux). Kann aber auch am Artwork liegen.
Hier hatte auch jemand "Rick Dangerous" für SDL (denke ich) nachgebaut. Geht also im Prinzip. Würde mich interessieren, wie schnell das mit pygame wäre:

http://www.bigorno.net/xrick/

Hier wäre so ein 2D-Spiel in pygame, das ich kenne. Seitliches "smooth scrolling" geht von der Geschwindigkeit her also schon:

http://www.imitationpickles.org/barbie/

"Barbie Seahorse Adventures" sieht in meinen Augen nur leider nicht so wirklich schön aus, es geht so. Na ja, früher war auf solchen Spielen der Fokus der kommerziellen Entwicklung, die hatten bessere Grafiker und bezahlten sie. Ich kann das auch nicht, schöne Grafiken zeichnen. Bei Pixelgrafik hilft wohl so ein "graph paper" oder "grid paper".
Außerdem gibt es heute überall so viel digitales Zeugs, das man wohl nicht mehr die Geduld hat, an so einem Spiel so präzise zu arbeiten. Na ja, natürlich gibt es die Spielebranche noch, sogar viel größer als früher, und manchmal gibt es auch noch originelle 2D, bzw. isometrische Spiele wie z.B. "Grave Yard Keeper" oder "Curious Expedition Rivals" (auf Steam; meist für neueres Window jedoch).
manzek schrieb:
Wenn ich mich recht entsinne, war der C64 sogar nur mit 1.0 MHz getaktet; der C128 mit 2.0 MHz.
Das stimmt; aber klar, es kommt dabei auch darauf, was es für ein Prozessor ist - was ich oben mal übergangen hatte.
Der C128 war eine recht seltsame Maschine mit zwei Grafikchips und zwei Prozessoren (einer davon war ein Z80A). 2 Mhz machte nur mit dem Grafikchip VDC Sinn, der mehr für Büroanwendungen gedacht war, und für den man einen Monitor brauchte. Betrieb man den C128 in den Modi, in denen der VIC-IIe aktiv war (wofür man auch einen Fernseher benutzen konnte), verlor man bei 2 Mhz die Bildschirmausgabe, weil der VIC-II nur 1 MHz verarbeiten konnte. Meist lief der C128 daher nur mit 1 MHz, auch im C128-Modus mit 40 Zeichen pro Zeile. Hatte mich kürzlich mal damit beschäftigt, und z.B. dieses Video angeschaut.
 
abgdf schrieb:
@Gräfin Klara: Danke für die Infos. Ich hab' mich immer gewundert, wieso das anscheinend so schwer ist, wenigstens an die Geschwindigkeit des Amiga heranzukommen. Deine Angaben würden das wohl erklären.
Der Vergleich ist ja in Wahrheit unfair. Die hatten damals Pixelgrößen wie Bauklötze und nur 32 Farben. Die Hardware war genau auf diese
Lösung zugeschnitten. Bei solch geringen Anforderungen kann man den speed natürlich bringen.
Ich glaube nicht, dass du nur mit Python diese Geschwindigkeit auf neuen Systemen erreichen kannst.

abgdf schrieb:
Allerdings: Für Spiele und solche Sachen benutzt man unter Linux ja meist die SDL-Bibliothek. Die heißt ja schon SDL - "Simple Direct Layer", sollte also ebenfalls relativ direkten Hardwarezugriff ermöglichen. pygame sind dann nur Python-Bindings für SDL.
Das ist ja genau das was du brauchst! Leider kenne ich mich mit OpenGL und diesen Sachen überhaupt nicht aus. Doch scheint es so zu sein, dass
dieses SDL als Layer zwischen System und Python die notwendige Geschwindigkeit bringen kann. SDL ist in C geschrieben, so ist dort zu lesen und
ein Interface zu C++ bringt es auch mit. Nun wird es aber Zeit, dass du Python auf die Seite legst und mit C++ weitermachst!
Du würdest es nicht bereuen und die Geschwindigkeit wäre dann auch kein Thema mehr.

Gruß
Gräfin Klara
 
OP
A

abgdf

Guru
Gräfin Klara schrieb:
Nun wird es aber Zeit, dass du Python auf die Seite legst und mit C++ weitermachst!
Du würdest es nicht bereuen und die Geschwindigkeit wäre dann auch kein Thema mehr.
:-D Ja, vielleicht hast du recht.
 
OP
A

abgdf

Guru
Ok, hier dann also meine ersten Schritte mit C++ und der SFML-Bibliothek (ähnlich wie SDL, vielleicht besser):

Code:
#include <SFML/Graphics.hpp>

// scrolling.cpp

/* Compilation:
 g++ scrolling.cpp -o scrolling -std=c++11 -I/usr/local/include/SFML -L/usr/local/lib -lsfml-audio -lsfml-graphics -lsfml-window -lsfml-system
*/

using namespace sf;

int main() {

    int WIDTH  = 800;
    int HEIGHT = 600;

    Color BLACK  = Color(0, 0, 0);
    Color GREY   = Color(127, 127, 127);
    Color RED    = Color(255, 0, 0);
    Color WHITE  = Color(252, 252, 252);

    RenderWindow screen(VideoMode(WIDTH, HEIGHT), "Scrolling View");
    screen.setFramerateLimit(100);

    View view = View();
    view.setSize({200, 150});
    view.zoom(2.5);
    RectangleShape ws1 = RectangleShape({200, 600});
    ws1.setFillColor(WHITE);
    ws1.setPosition(200, 0);
    RectangleShape ws2 = RectangleShape({200, 600});
    ws2.setFillColor(WHITE);
    ws2.setPosition(600, 0);

    RectangleShape r = RectangleShape({20, 20});
    r.setFillColor(RED);
    r.setPosition(0, 300);

    RectangleShape r2 = RectangleShape({20, 20});
    r2.setFillColor(GREY);
    r2.setPosition(720, 300);

    Event event;
    int delay = 0;

    while (screen.isOpen()) {
        screen.clear(BLACK);
        screen.draw(ws1);
        screen.draw(ws2);

        while (screen.pollEvent(event)) {
            if (event.type == Event::Closed) {
                screen.close();
            }
            if (Keyboard::isKeyPressed(Keyboard::Escape)) {
                screen.close();
            }
        }

        if (r.getPosition().x < 700 and delay >= 120) {
            r.move(1, 0);
        }
        screen.draw(r);
        screen.draw(r2);
        screen.display();
        if (r.getPosition().x < 200) {
            view.setCenter(200, r.getPosition().y);
        } else {
            view.setCenter(r.getPosition());
        } 
        screen.setView(view);
        ++delay;
    }
}
Das Schöne ist, man kann relativ leicht einen Prototyp in Python (PySFML) schreiben, und das dann übersetzen. Definitiv ausbaufähig. :)
 
Oben