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.
Spieleprogrammierung
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
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
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.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.
Solche Strategiespiele zeichnen beim scrollen einen Haufen "Kacheln"/Quadrate neu, das ist was ganz anderes. Da ist PyGame brauchbar.
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 muss ich mir im Zeitalter von GeForceZehnMillionen noch gedanken machen, welchen Teil des Bildschirms ich neu zeichne?
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 ist drehen und Zoomen so ein Aufwand?
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.Warum muss ich mich zwischen Alpha pro Pixel und Alpha pro Surface unterscheiden?
Der Punkt ist aber bei beidem, dass der ganze Bildschirm neugezeichnet werden muss, weil nichts am alten Platz ist.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.
Wie gesagt: Freiheiten an anderer Stelle.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.
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.
Ist OpenGL so unportabel? Ich nahm bis jetzt eigentlich immer das Gegenteil an.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 ist drehen und Zoomen so ein Aufwand?
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.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.
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)
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.keppla hat geschrieben:Der Punkt ist aber bei beidem, dass der ganze Bildschirm neugezeichnet werden muss, weil nichts am alten Platz istIch 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.
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.Wie gesagt: Freiheiten an anderer Stelle.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.
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.
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.Ist OpenGL so unportabel? Ich nahm bis jetzt eigentlich immer das Gegenteil an.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 ist drehen und Zoomen so ein Aufwand?
Da ist dann die Entwicklungsumgebung nicht portabel. Und Flash+64Bit-Linux ist auch so ein Kapitel für sich.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.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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:Ist OpenGL so unportabel? Ich nahm bis jetzt eigentlich immer das Gegenteil an.
LGT (oder eines der Unterprojekte) kapselt Pygame in PyOpenGL, vielleicht suchst du ja sowas.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)
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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
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
Leichtdio.de - Das Kreativ-Blog
http://www.leichtdio.de
http://www.leichtdio.de
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...
(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...
Die Schrebfehler sind absicht und dienen der Belustigung.
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
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
Leichtdio.de - Das Kreativ-Blog
http://www.leichtdio.de
http://www.leichtdio.de
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...
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...
Die Schrebfehler sind absicht und dienen der Belustigung.
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
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
Die Schrebfehler sind absicht und dienen der Belustigung.
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.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++
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