Das deutsche Python-Forum

Seid ihr wirklich sicher, dass PyGame für ein "Z"-Clone geeignet ist? Ich hab es auf Anieb nicht wiedergefunden, aber als ich mich mal mit PyGame beschäftigt habe, bin ich da mal über eine FAQ gestolpert in der vage sowas stand:

Frage: Wie mache ich ein Spiel, bei dem viel gescrolled wird?
Antwort: Nicht mit Pygame, dafür ist das Zeichnen zu langsam.

Ich will die Bibliothek nicht schlechtmachen, nur einige Eigenschaften, die sie hat (oder hatte), haben Spieleprogrammierung wie ich sie mir vorgestellt habe, unnötig verkompliziert.
Warum muss ich mir im Zeitalter von GeForceZehnMillionen noch gedanken machen, welchen Teil des Bildschirms ich neu zeichne? Warum ist drehen und Zoomen so ein Aufwand? Warum muss ich mich zwischen Alpha pro Pixel und Alpha pro Surface unterscheiden?

Es ist mir klar, dass die Punkte keine Fehler oder Dummheiten sind, sondern an anderer Stelle Freiheiten bieten (z.B. dass man für graphische Menus keine GeForceXX brauch).
Aber auf die reine Spieleprogrammierung bezogen war es Teilweise einfacher, den Spass direkt in einer 3D-Engine zu realisieren.

Ich würde vorschlagen du fängst einfach an - und löschst nach 3 monaten die erste version und machst es nochmal.

Learning by doing, und das erste python programm wird sowieso nichts besonders gutes vom code her. Deswegen nochmal neuschreiben - und du wirst erstaunt sein was du ändern wirst

keppla hat geschrieben:Seid ihr wirklich sicher, dass PyGame für ein "Z"-Clone geeignet ist? Ich hab es auf Anieb nicht wiedergefunden, aber als ich mich mal mit PyGame beschäftigt habe, bin ich da mal über eine FAQ gestolpert in der vage sowas stand:

Frage: Wie mache ich ein Spiel, bei dem viel gescrolled wird?
Antwort: Nicht mit Pygame, dafür ist das Zeichnen zu langsam.

Ich glaube nicht, das das ein Problem ist. Bei dem Scrollen ist pixelweises, "weiches" scrollen wie bei den üblichen 2D Ballerspielen oder Jump'n'Runs gemeint wo der Hintergrund kontinuierlich sanft in alle 8 Richtungen scrollen kann.

Solche Strategiespiele zeichnen beim scrollen einen Haufen "Kacheln"/Quadrate neu, das ist was ganz anderes. Da ist PyGame brauchbar.

Warum muss ich mir im Zeitalter von GeForceZehnMillionen noch gedanken machen, welchen Teil des Bildschirms ich neu zeichne?

Warum solltest Du das bei einer GeForce nicht mehr machen müssen? Das ist keine Frage der Grafikkarte, sondern eine Optimierungsfrage, die man nun mal nicht ganz so einfach automatisch Lösen kann.

Warum ist drehen und Zoomen so ein Aufwand?

Weil das viel Rechenaufwand für den Prozessor bedeutet. Wenn Du das beschleunigt haben möchtest, dann musst Du OpenGL benutzen und keine Bibliothek, die im Grunde auf einem Framebuffer-Prinzip aufbaut. Und damit wesentlich portabler ist als OpenGL.

Warum muss ich mich zwischen Alpha pro Pixel und Alpha pro Surface unterscheiden?

Musst Du ja nicht. Alpha pro Surface verbraucht weniger Speicher und kann eventuell schneller ausgeführt werden, aber Du kannst natürlich auch ein Bild mit dem gleichen Alphawert pro Pixel benutzen um den gleichen Effekt zu erzielen.

Ich glaube nicht, das das ein Problem ist. Bei dem Scrollen ist pixelweises, "weiches" scrollen wie bei den üblichen 2D Ballerspielen oder Jump'n'Runs gemeint wo der Hintergrund kontinuierlich sanft in alle 8 Richtungen scrollen kann.

Solche Strategiespiele zeichnen beim scrollen einen Haufen "Kacheln"/Quadrate neu, das ist was ganz anderes. Da ist PyGame brauchbar.

Der Punkt ist aber bei beidem, dass der ganze Bildschirm neugezeichnet werden muss, weil nichts am alten Platz ist.

Zitat:
Warum muss ich mir im Zeitalter von GeForceZehnMillionen noch gedanken machen, welchen Teil des Bildschirms ich neu zeichne?

Warum solltest Du das bei einer GeForce nicht mehr machen müssen? Das ist keine Frage der Grafikkarte, sondern eine Optimierungsfrage, die man nun mal nicht ganz so einfach automatisch Lösen kann.

Wie gesagt: Freiheiten an anderer Stelle.
Ich frage mich halt nur, warum ich im Falle eines Spieles da meine Zeit mit optimieren verschwenden sollte. Aktuelle Spiele zeichnen jedes Frame ein Huntertfaches an Flächen auf den Bildschirm, ohne, dass das die vorhandenen Ressourcen nennenswert auslastet.
Also, selbst wenn mein Spiel 100 mal Langsamer ist, als es in Optimiert wäre, würde es trotzdem immer noch nur einen Bruchteil der auf einem durchschnittlichen Rechner zur Verfügung stehenden Ressourcen Fressen.
Und da man kaum zwei Spiele parallel Spielt, ist es imho eine unglaubliche Verschwendung.
Ich kümmere mich auch nicht um so Dinge wie Garbage Collection oder Pointerarithmetik, obwohl ichs könnte.

Warum ist drehen und Zoomen so ein Aufwand?

Weil das viel Rechenaufwand für den Prozessor bedeutet. Wenn Du das beschleunigt haben möchtest, dann musst Du OpenGL benutzen und keine Bibliothek, die im Grunde auf einem Framebuffer-Prinzip aufbaut. Und damit wesentlich portabler ist als OpenGL.

Ist OpenGL so unportabel? Ich nahm bis jetzt eigentlich immer das Gegenteil an.

Musst Du ja nicht. Alpha pro Surface verbraucht weniger Speicher und kann eventuell schneller ausgeführt werden, aber Du kannst natürlich auch ein Bild mit dem gleichen Alphawert pro Pixel benutzen um den gleichen Effekt zu erzielen.

Doch, musste ich damals. Ich wollte einen runden Tooltip einfaden lassen. Weil er rund ist, brauchte ich AT/P, damit die Kanten nicht blöd aussehen, damit er insgesamt transparenter wird, brauchte ich AT/S.
Und ich hatte nur die Wahl entweder/oder.

Wie gesagt: Ich mache Pygame nicht schlecht. Ich halte es für ein gutes Framework. Nur finde ich es ärgerlich, wenn selbst Flashspiele bei gleicher Grafik einfacher zu Programmieren und Portabler sind als meine "Professionelle" Lösung.
Wie du schon sagtest: Ich will vermutlich OpenGL. Aber nur eine kleine Untermenge. Vielleicht mach ich mich mal dran, diese Untermenge hübsch zu Kapseln. Sofern es nicht schon sowas gibt (die Hoffnung stirbt zuletzt)

keppla hat geschrieben:

Ich glaube nicht, das das ein Problem ist. Bei dem Scrollen ist pixelweises, "weiches" scrollen wie bei den üblichen 2D Ballerspielen oder Jump'n'Runs gemeint wo der Hintergrund kontinuierlich sanft in alle 8 Richtungen scrollen kann.

Solche Strategiespiele zeichnen beim scrollen einen Haufen "Kacheln"/Quadrate neu, das ist was ganz anderes. Da ist PyGame brauchbar.

Der Punkt ist aber bei beidem, dass der ganze Bildschirm neugezeichnet werden muss, weil nichts am alten Platz ist

Aber bei Startegiespielen nicht kontinuierlich und flüssig mit mindestens 30 FPS. Denk einfach mal an die Rechner als Z neu war und dann an die heutigen GHz Monster. Da sollte der "Reibungsverlust" durch Python wieder aufgefangen werden.

Zitat:
Warum muss ich mir im Zeitalter von GeForceZehnMillionen noch gedanken machen, welchen Teil des Bildschirms ich neu zeichne?

Warum solltest Du das bei einer GeForce nicht mehr machen müssen? Das ist keine Frage der Grafikkarte, sondern eine Optimierungsfrage, die man nun mal nicht ganz so einfach automatisch Lösen kann.

Wie gesagt: Freiheiten an anderer Stelle.
Ich frage mich halt nur, warum ich im Falle eines Spieles da meine Zeit mit optimieren verschwenden sollte. Aktuelle Spiele zeichnen jedes Frame ein Huntertfaches an Flächen auf den Bildschirm, ohne, dass das die vorhandenen Ressourcen nennenswert auslastet.

Das ist meistens von der Grafikkarte beschleunigt und Du musst Dir ja keine Gedanken bei SDL machen, Du kannst auch dort einfach grundsätzlich den Bildschirm komplett neu zeichnen.

Warum ist drehen und Zoomen so ein Aufwand?

Weil das viel Rechenaufwand für den Prozessor bedeutet. Wenn Du das beschleunigt haben möchtest, dann musst Du OpenGL benutzen und keine Bibliothek, die im Grunde auf einem Framebuffer-Prinzip aufbaut. Und damit wesentlich portabler ist als OpenGL.

Ist OpenGL so unportabel? Ich nahm bis jetzt eigentlich immer das Gegenteil an.

Ein Framebuffer ist supersimpel, den stellt alles was einen Bildschirm hat, vom Mobiltelefon bis zur Handheld-Spielekonsole, zur Verfügung. Für OpenGL brauchst Du entweder entsprechende Grafikhardware oder viel Platz für Code für die Emulation und ordentlich Rechenpower. Ich weiss, mittlerweile gibt's auch schon 3D-Chips für Mobiltelefone, aber SDL ist auch auf ältere Amigas portiert.

Wie gesagt: Ich mache Pygame nicht schlecht. Ich halte es für ein gutes Framework. Nur finde ich es ärgerlich, wenn selbst Flashspiele bei gleicher Grafik einfacher zu Programmieren und Portabler sind als meine "Professionelle" Lösung.

Da ist dann die Entwicklungsumgebung nicht portabel. Und Flash+64Bit-Linux ist auch so ein Kapitel für sich.

keppla hat geschrieben:Ist OpenGL so unportabel? Ich nahm bis jetzt eigentlich immer das Gegenteil an.

Da es trotz der vielen Open Source Programmierer unter Linux keinen brauchbaren freien 3D-Trieber für Linux gibt, sehr wohl aber gute 2D-Treiber (unter denen SDL wunderbar läuft), würde ich sagen dass OpenGL nicht so prtabel ist wie man denkt. Dennoch portabler als DirectX, ganz recht.

keppla hat geschrieben:Wie du schon sagtest: Ich will vermutlich OpenGL. Aber nur eine kleine Untermenge. Vielleicht mach ich mich mal dran, diese Untermenge hübsch zu Kapseln. Sofern es nicht schon sowas gibt (die Hoffnung stirbt zuletzt)

LGT (oder eines der Unterprojekte) kapselt Pygame in PyOpenGL, vielleicht suchst du ja sowas.

pygame kann pyopengl in sich benutzten warum sollte man es andersherum machen?!

Desweiteren wenn du ein Spiel haben willst was super mega hammer geil schnell läuft (ja ich liebe Übertreibungen), damit du bei deinen Kumpels angeben kannst, dann solltest du kein Python verwenden sondern C/C++

Jedoch ist dies für den Anfang einfach zu schwierig! pygame ist einfach das einfachst und trotzdem im Verhältnis effektivste was du für das was du vor hast benutzten kannst

SigMA

Naja und wenn du ein remake von Z machen willst müsste der ja uff meinen Shclechtesten PC uch loofen
(90 MHZ aber sao gut wie 133;
8MB Ram hochgetcktet auf 16!!! (Ne Menge ich weiss)
und ne 8MB-Grafik Karte!)

Aber was ich schön finden würde idt, wenn die community vielleicht mal ein gemeinsames Project machen würde. So das die unerfahrenen von den erfahrenen lernen! und für ein Grösseren Zusammenhalt.
Muss ja kein Spiel sein...

http://berlios.de

Es gibt on Mass Projekte wo sowas ist! Ich bin ja sowieso immer noch der festen Ansicht, das man am besten durch lesen eines Buches lernen kann.

@Remake:
Remake heißt nicht es muss die gleichen Systemanforderungen haben ;D

aber genau das hat mich fasziniert an Z:

Die Pixelige, aber doch Geilöe Grafik
und die super krasse und Lustige "Story" es ist eigentlich eine verarsche von c&c. problem: c&c kam erts danach raus...

aber genau das hat mich fasziniert an Z:

Die Pixelige, aber doch Geile Grafik
und die super krasse und Lustige "Story" es ist eigentlich eine verarsche von c&c. problem: c&c kam erts danach raus...

und zu dne projeckten: hab ja nru gemient *pöh * ne das währe ja auch dann ein wenig werbung für python-forum.de

SigMA hat geschrieben:Desweiteren wenn du ein Spiel haben willst was super mega hammer geil schnell läuft (ja ich liebe Übertreibungen), damit du bei deinen Kumpels angeben kannst, dann solltest du kein Python verwenden sondern C/C++

Nicht ganz. Wenn man ein "Ambitioniertes Projekt ohne vorzeigbare alpha, aber supergeiler Engine (noch in entwicklung)" haben möchte, mit dem man vor seinen Kollegen angeben möchte*, dann kann man C++ benutzen.
All die, die lieber fertig werden, nehmen eine etwas abstraktere Sprache.

Gerade deshalb hätte ich ja gerne eine 2d-Engine, bei der die Technischen Details absolut aussen vor bleiben: Ein nichtfertiges Spiel läuft auf weniger Systemen, als ein Fertiges, das diejenigen, die keine nicht-freien Treiber nutzen wollen, oder einen Rechner vor 2000 haben, ausschliesst.

*) geht leider nur bei nerds <16 Jahre