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
Ist Pygame für schnelle 2d Scroller geeignet?
- veers
- User
- Beiträge: 1219
- Registriert: Mittwoch 28. Februar 2007, 20:01
- Wohnort: Zürich (CH)
- Kontaktdaten:
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
- Jonas
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
Wo ist der Vorteil/Unterschied zu Pygame?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.
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.
Hi burli,
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
Daran denke ich auch immer mal wieder. Bisher habe ich mit Pygame das gemacht: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.
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
Das spiel ist niedlich, läuft sogar auf meinem uralten Pentium3 mit 1GHz, allerdings etwas lahmabgdf 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.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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 ...
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
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.
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.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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:Unter der Annahme, dass Python 100x langsamer als Maschinen- oder C-Code ist, wäre das immer noch 2x schneller als der Amiga.
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.sma hat geschrieben:Falls PyGames oder Pyglets nicht schon Unterstützung für eine Kollisionsabfrage haben
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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.
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.
Lösch' einfach die ZeileEr kennt bei mir das Modul "locals" nicht. Pygame hab ich installiert
Code: Alles auswählen
from pygame.locals import *
Dann sollte es gehen.
Gruß