Das deutsche Python-Forum

Hi, ich frage mich ob man in der Lage ist mit Pygame schnelle 2d Scroll Games zu schreiben. Ich denke da an alte C64 und Amiga Games wie Uridium oder R-Type.

Ist Pygame dafür geeignet? Speziell die Bewegung und Kollisionsabfrage von vielen Objekten dürfte eine Herausforderung sein

Dürfte durchaus möglich sein. Aber ich würde dir eher Pyglet/OpenGL dafür ans Herz legen. Das bietet dir mehr möglichkeiten, mehr Performance und nimmt dir viele Aufgaben bereits ab.

- Jonas

veers hat geschrieben:Dürfte durchaus möglich sein. Aber ich würde dir eher Pyglet/OpenGL dafür ans Herz legen. Das bietet dir mehr möglichkeiten, mehr Performance und nimmt dir viele Aufgaben bereits ab.

Wo ist der Vorteil/Unterschied zu Pygame?

Andere API und OpenGL. Letzteres kann man sowohl als Vor- als auch als Nachteil sehen. Unter Linux kann SDL bei so ziemlich jeder Grafikkarte auf einen Treiber mit ein wenig 2D-Beschleunigung bauen, wogegen Pyglet halt auch bei 2D-Grafik langsam bis unbrauchbar wird, wenn es keinen OpenGL-Treiber für die Karte gibt, bzw. gibt's halt auch Leute die zusätzlich darauf bestehen, dass der Treiber "frei" sein soll.

Ich überlege gerade ob sich in dem Zusammenhang QGraphicsView von Qt eignen würde. Hat ja auch die Möglichkeit OpenGL zu verwenden. Gibt sogar Kollisionsabfragen (QGraphicsItem.collidesWithItem)

Hi burli,

ich frage mich ob man in der Lage ist mit Pygame schnelle 2d Scroll Games zu schreiben. Ich denke da an alte C64 und Amiga Games wie Uridium oder R-Type.

Daran denke ich auch immer mal wieder. Bisher habe ich mit Pygame das gemacht:

http://www.python-forum.de/topic-9104.html

Die Performance fand ich da gar nicht so schlecht, sind ja aber nur simple Rechtecke (und auch kein Scrolling).

Man muß aber auch berücksichtigen, daß die alten 8-Bit und 16-Bit-Spiele von Profis auf einheitlichen und daher bis ins Detail bekannten Systemen in ASSEMBLER geschrieben wurden . Schon C wäre da damals wahrscheinlich zu langsam gewesen.

Mit Pygame ist aber z.B. immerhin sowas

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

möglich. Schon das war aber nicht gerade wenig Arbeit.
Werde jetzt mal dieses Tutorial

http://www.python-forum.de/topic-13367.html

lesen.

Viele Grüße

abgdf hat geschrieben: Mit Pygame ist aber z.B. immerhin sowas

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

möglich. Schon das war aber nicht gerade wenig Arbeit.

Das spiel ist niedlich, läuft sogar auf meinem uralten Pentium3 mit 1GHz, allerdings etwas lahm

"Hallo Welt !", sozusagen:

http://paste.pocoo.org/show/92044/

Gruß

Kurz drübergeschaut (nicht ausgeführt): viel, viel zu lange Codezeilen die man sicherlich umbrechen kann außerdem Modulglobaler Code: das müsste jetzt auch nicht sein. Die Pygame-Globals via Stern-Import herienziehen halte ich auch für eine eher schlechte Idee, auch wenn das in allen Tutorials so ist.

Die Code-Kritik ist sicher berechtigt (und würde bei einer größeren Anwendung auch berücksichtigt), aber in diesem kurzen Beispiel ging es mehr um's Ergebnis ...

Er kennt bei mir das Modul "locals" nicht. Pygame hab ich installiert

Prinzipiell würde ich ja sagen, dass ein typischer mit 2048 Mhz getakteter durchschnittlicher PC, der damit 256x schneller ist als ein mit 8 Mhz getakteter Amiga, der Aufgabe wohl auch in Python gewachsen sein sollte.

Zugegeben ist die Bildschirmauflösung höher und man will jetzt statt 320x200 Bildpunkten in 32 Farben (0,05MB) wahrscheinlich 1280x1024 in 16 Mio Farben (5MB) haben, aber darum sollte sich die Grafikkarte kümmern.

Unter der Annahme, dass Python 100x langsamer als Maschinen- oder C-Code ist, wäre das immer noch 2x schneller als der Amiga.

Daher: Go for it. RType fand ich damals jedenfalls Klasse. 3D hat die Spiele auch nicht immer nur besser gemacht.

Falls PyGames oder Pyglets nicht schon Unterstützung für eine Kollisionsabfrage haben, was ist so schwer daran, einfach für jeden Sprite seine "bounding box" in einer Liste zu speichern und dann darin zu suchen? Ist es die Befürchtung, das eine lineare Suche zu langsam dauert? Da gibt es passende Partitionierungsalgorithmen, allerdings sind dann die dafür notwendigen Bäume aufwendiger zu bauen, das die bessere "Nachguckzeit" wieder aufheben könnte, da sich ja die Sprites auch bewegen sollen.

Stefan

Ich denke alleine die Ausführungsgeschwindigkeit von Programmiersprachen zu vergleichen bringt da nicht so viel, weil in den alten Kisten fast immer spezielle Hardware für flotte Grafik gesorgt hat.

PyGame hat schon Unterstützung für "rechteck-basierte" Kollisionsabfragen. In der neuesten Version anscheinend auch eine, die Masken unterstützt um pixelgenaue Kollisionen zu erfassen.

sma hat geschrieben:Unter der Annahme, dass Python 100x langsamer als Maschinen- oder C-Code ist, wäre das immer noch 2x schneller als der Amiga.

Python ja (wobei 100x, das hängt eben ab wie man schreibt und was man macht), aber die Libs auf die Pyglet und Pygame zugreifen sind in C geschrieben, damit würde ich schätzen dass Python etwas besser als 2x schneller abschneidet.

sma hat geschrieben:Falls PyGames oder Pyglets nicht schon Unterstützung für eine Kollisionsabfrage haben

Pygame bietet das, von daher kein Problem. Bei Pyglet habe ich in der Dokumentation nichts gefunden, aber zur Not kann für 2D-Sachen auch bei Pygame kopieren, die implementieren das in Python, wenn ich mich richtig erinnere und es sich nicht zwischendrin geändert hat.

Eigentlich ist pyglet wirklich schön gemacht, es ist wundervoll einfach damit etwas zu schreiben, aber die 2d Performance ist derartig gruselig, das ich eher davon abraten würde.
Bei 2 vergleichbaren Programmen, hatte ich bei pyglet 60-80% Cpulast und bei pygame 1-2% Cpulast, bei halb so viel Speicherverbrauch. Was natürlich auch an meinem Stil oder fehlender Opengl beschleunigung für pyglet liegen könnte.

Ich werde mich mal mit Pygame befassen. Mal schauen wie ich anfange.

Er kennt bei mir das Modul "locals" nicht. Pygame hab ich installiert

Lösch' einfach die Zeile und ersetze zweimal im Code "KEYDOWN" durch "pygame.KEYDOWN".

Dann sollte es gehen.

Gruß

Das seltsame ist das es bei anderen Programmen funktioniert

Du hast die Datei nicht zufällig ``pygame.py`` genannt, oder?

Leonidas hat geschrieben:Du hast die Datei nicht zufällig ``pygame.py`` genannt, oder?

Wenn man doof ist sollte man es lassen