Hallo,
da ich mich von den Datenbanken erstmal abgewendet habe, habe ich mich der 2D-Spiele Programmierung gewidmet.
Momentan habe ich eine Art Weltraumshooter ^^ der Hintergrund bewegt sich und die Sterne saußen auch schon an dem Schiff vorbei.. so damit es wirkt es würde fliegen ohne sich wirklich zu bewegen.
Mein Schiff fliegt ebenfalls schon und kann sogar schon mit Laser feuern.
Bisher brauchte ich 6 Sprite wobei der Laser mehrfach je nach Schuss gesetzt wird.
Zu meinen Spiel kommen ja noch andere Sachen vor wie kp. Kometen und feindl. Schiffe u. feindl. Beschuss.
Also brauche ich wieder mehr Sprites die ich lade ... und so setzt sich das fort....
Da kommt mir nun die Frage auf ob das ganze auch noch Leistungsfähig auf einen älteren PC ist wie einem (800 Mhz Rechner) ...
Momentan teste ich das eigentlich auf 3Ghz und 2GB Ram und einer relativ guten Grafikkarte... daher habe ich keine Möglichkeit rauzufinden ob das Programm auf älteren Rechner auch stabil läuft.
Wo liegen die grenzen für verschiedene Anzahl von Sprites und Auflösungen für jeweilige Hardware Anforderungen ?
Und, wenn kann man das evtl. mit gut programmierten Code umgehen ?
Das Hauptproblem ist ich hab mir die meisten Programmiersprachen selbst erlernt, daher bin ich mir selten sicher ob die Lösungswege wirklich so "Norm-Gerecht" sind.
Wenn jemand den Code sehen will und ihn vorallem Kritisieren will dann ist das auch okay... Allerdings ist er momentan noch bei 110 Zeilen.
Flüssigkeit des Spiels und Effizenz des Codes
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
Hi Schlingel
die grenze für die anzahl der Sprites liegt in der größe des graka-speichers.
alles was nicht mehr direkt in die Graka passt, muss in den Hauptspeicher geladen werden,
und ist daher wesentlich langsamer beim darstellen.
der bedarf kannst du grob überschlagen, indem für für 2x Screenbuffer plus alle sprites die anzahl pixel berechnest, und das mit der farbtiefe in byte multipliziest.
beispiel:
screen 800x600 = 480.000 pixel, *32bit farbtiefe = 480.000 * 4 = 1.920.000 byte pro screenbuffer = 3.840.000 byte für beide buffer.
sagen wir mal, 25 verschiedene sprites, alle 100x100 groß,
= 10.000 pixel pro sprite = 40.000 byte pro sprite, *25 = 1.000.000 byte für alle sprites
=> knapp 5MB für screen und sprites
das ist jetzt ein eher kleines beispiel, soll halt die berechnung verdeutlichen.
(irgendwie gabs auch ne möglichkeit, der speicherverbrauch in der graka direkt von system abzufragen, weiß aber nimmer, wie das ging)
an performance...
die darstellung der sprites ist eigentlich verdammt schnell.
oft sind komplexe berechnungen in spielablauf wesentlich zeitaufwendiger.
also ein relativ einfaches spiel
(ballerspiel mit sternenhintergrund, zwei dutzend gegnern und drei dutzend schüssen)
sollte eigentlich relativ problemlos auch unter 1GHz laufen.
letztendlich hängt das aber von so vielen faktoren ab, dass du ums testen nicht drumrumkommst.....
die grenze für die anzahl der Sprites liegt in der größe des graka-speichers.
alles was nicht mehr direkt in die Graka passt, muss in den Hauptspeicher geladen werden,
und ist daher wesentlich langsamer beim darstellen.
der bedarf kannst du grob überschlagen, indem für für 2x Screenbuffer plus alle sprites die anzahl pixel berechnest, und das mit der farbtiefe in byte multipliziest.
beispiel:
screen 800x600 = 480.000 pixel, *32bit farbtiefe = 480.000 * 4 = 1.920.000 byte pro screenbuffer = 3.840.000 byte für beide buffer.
sagen wir mal, 25 verschiedene sprites, alle 100x100 groß,
= 10.000 pixel pro sprite = 40.000 byte pro sprite, *25 = 1.000.000 byte für alle sprites
=> knapp 5MB für screen und sprites
das ist jetzt ein eher kleines beispiel, soll halt die berechnung verdeutlichen.
(irgendwie gabs auch ne möglichkeit, der speicherverbrauch in der graka direkt von system abzufragen, weiß aber nimmer, wie das ging)
an performance...
die darstellung der sprites ist eigentlich verdammt schnell.
oft sind komplexe berechnungen in spielablauf wesentlich zeitaufwendiger.
also ein relativ einfaches spiel
(ballerspiel mit sternenhintergrund, zwei dutzend gegnern und drei dutzend schüssen)
sollte eigentlich relativ problemlos auch unter 1GHz laufen.
letztendlich hängt das aber von so vielen faktoren ab, dass du ums testen nicht drumrumkommst.....
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
-
PureLust
- Beiträge: 1145
- Registriert: 21.07.2005 00:02
- Computerausstattung: Hab aktuell im Grunde nur noch 'nen Lenovo Yoga 2 Pro im Einsatz.
- Wohnort: am schönen Niederrhein
Hallo Schlingel, ...
nur mal so als Anhaltspunkt:
Ältere Rechner haben meist eine eher 2D-taugliche Grafikkarte - neuere hingegen eine mehr 3D-lastige.
Wenn Du also mit Sprites arbeitest und Spiele für ältere Rechner schreiben möchtest, so solltest Du die 2D-Spritebefehle benutzen - ansonsten eher die Sprite3D-Befehle.
Ich hatte mir für solche Zwecke mal ein kleines Sprite-Testprogramm geschrieben welches Du ja mal auf Deinem und ggfl. auf einem Ziel-PC testen kannst:
Sprite_SpeedTest_DX7.pb
Sprite_SpeedTest_DX9.pb
Sprite_SpeedTest_OpenGL.pb
(Rechte Maustaste -> Speichern unter ...)
Interessant hierbei ist auch, dass 2D-Sprites mit dem DX9-Subsystem rund 8mal und mit OpenGL sogar über 10mal so schnell dargestellt werden wie bei DX7, welches ja standardmäßig von PureBasic angewand wird.
(Diese Vergleichswerte sind von einer ATI Radeon 800XL).
Für einen kleinen Weltraumshooter mit - sagen wir mal - 200 2D-Sprites, sollte aber selbst ein 400MHz PC schnell genug sein.
nur mal so als Anhaltspunkt:
Ältere Rechner haben meist eine eher 2D-taugliche Grafikkarte - neuere hingegen eine mehr 3D-lastige.
Wenn Du also mit Sprites arbeitest und Spiele für ältere Rechner schreiben möchtest, so solltest Du die 2D-Spritebefehle benutzen - ansonsten eher die Sprite3D-Befehle.
Ich hatte mir für solche Zwecke mal ein kleines Sprite-Testprogramm geschrieben welches Du ja mal auf Deinem und ggfl. auf einem Ziel-PC testen kannst:
Sprite_SpeedTest_DX7.pb
Sprite_SpeedTest_DX9.pb
Sprite_SpeedTest_OpenGL.pb
(Rechte Maustaste -> Speichern unter ...)
Interessant hierbei ist auch, dass 2D-Sprites mit dem DX9-Subsystem rund 8mal und mit OpenGL sogar über 10mal so schnell dargestellt werden wie bei DX7, welches ja standardmäßig von PureBasic angewand wird.
(Diese Vergleichswerte sind von einer ATI Radeon 800XL).
Für einen kleinen Weltraumshooter mit - sagen wir mal - 200 2D-Sprites, sollte aber selbst ein 400MHz PC schnell genug sein.
Zuletzt geändert von PureLust am 09.07.2007 15:05, insgesamt 2-mal geändert.
[Dynamic-Dialogs] - komplexe dynamische GUIs einfach erstellen
[DeFlicker] - Fenster flimmerfrei resizen
[WinFX] - Window Effekte (inkl. 'durchklickbares' Window)
[DeFlicker] - Fenster flimmerfrei resizen
[WinFX] - Window Effekte (inkl. 'durchklickbares' Window)
Meine Experimente mit einem 800MHz Prozessor und einer antiken Geforce 2MX liefen noch sehr flüssig mit 250 Sprites die jeweils fast ein drittel des Screens einnahmen, wobei also der gesamte Bildinhalt duzende male überschrieben wurde. Bei kleineren Sprites sollten deutlich mehr als 250 drin sein.
Das ganze lief unter DirectX mit aktiven Hardwareblitter, aber selbst im reinen Prozessormodus sollten sich extrem viele Sprites realisieren lassen.
So generell kann man aber nicht sagen, wieviele Sprites welche Systemkomponenten ermöglichen, weil die ergebnisse in verschiedenen kombinationen sehr unterschiedlich ausfallen können.
Auch ist es ja sinnlos Sprites nur dumm anzuzeigen, normalerweise passiert darauf ja auch noch Logik. Dabei kommt es dann sehr darauf an, was du pro Sprite an anderen Rechenaufwand hast.
"Normwege" gibt es für die wenigsten Probleme. Wenn man über seine Lösungen wirklich nachdenkt wird man selbst erkennen, ob die Lösung akzeptabel ist oder nicht.
Leider wird häufig nicht genug nachgedacht und irgendwelcher Tutorialcode halbverstanden hin un her kopiert, dass führt dann fast immer zu schlechten Lösungen.
Wenn du dir bei einem deiner Programme nicht sicher bist, dann kannst du deine Problemlösung ja hier schildern. Da es hier schon ein paar leute gibt die etwas mehr Erfahrung im Programmieren haben wirst du dann sicher entsprechend auf Probleme hingewiesen.
Das ganze lief unter DirectX mit aktiven Hardwareblitter, aber selbst im reinen Prozessormodus sollten sich extrem viele Sprites realisieren lassen.
So generell kann man aber nicht sagen, wieviele Sprites welche Systemkomponenten ermöglichen, weil die ergebnisse in verschiedenen kombinationen sehr unterschiedlich ausfallen können.
Auch ist es ja sinnlos Sprites nur dumm anzuzeigen, normalerweise passiert darauf ja auch noch Logik. Dabei kommt es dann sehr darauf an, was du pro Sprite an anderen Rechenaufwand hast.
"Normwege" gibt es für die wenigsten Probleme. Wenn man über seine Lösungen wirklich nachdenkt wird man selbst erkennen, ob die Lösung akzeptabel ist oder nicht.
Leider wird häufig nicht genug nachgedacht und irgendwelcher Tutorialcode halbverstanden hin un her kopiert, dass führt dann fast immer zu schlechten Lösungen.
Wenn du dir bei einem deiner Programme nicht sicher bist, dann kannst du deine Problemlösung ja hier schildern. Da es hier schon ein paar leute gibt die etwas mehr Erfahrung im Programmieren haben wirst du dann sicher entsprechend auf Probleme hingewiesen.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
ja klar, dafür ist der bereich ja da...Schlingel hat geschrieben:Wenn es mal halbwegs Spielbar und halbwegs fertig sein sollte, das es einer Version 1.0 würdig ist kann ich es ja mal im Feedback präsentieren ...
ich freu mich drauf.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.