ich habe schon einmal vor ein paar wochen hier eine Frage gepostet. Ich habe mehrere Antworten bekommen aber festgestellt, dass das Thema noch zu kompliziert für mich war.
Ich habe mich jetzt erstmal mit der Materie vertraut gemacht (Orthomodus) und vor allem ein paar vernünftige und ich hoffe auch ausreichend schnelle Algorythmen geschrieben.
Ihr könnt euch ja mal das Projekt ansehen. Auf Anfrage sende ich auch noch gerne mal den code.
FEEDBACK ERWÜNSCHT!
PS:
links rechts oben unten
leer = schießen
wenn game over: return
escape = exit
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von Accessor am Di Mai 04, 2004 14:26, insgesamt 1-mal geändert.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Für den Anfang wohl ne gute Übung in Sachen Orhtomdus. Mehr kann man da wohl leider nicht sagen, und ob deine Algoryhtmen brauchbar und schnell sind kann man doch nur erkennen wenns nen FPS-Counter gäbe.
und ob deine Algoryhtmen brauchbar und schnell sind kann man doch nur erkennen wenns nen FPS-Counter gäbe.
Mein Prog arbeitet bei exakt 33 FPS. Nie mehr oder weniger.
Wäre schließlich dumm, wenn es irgendwo anders schneller oder langsamer liefe :-)
Mein Taskmanager berichtet mir, dass es bei mir grad' mal ca. 30% Auslastung macht. Und die paar Pünktchen schluckt OpenGL doch locker weg?!
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Die FPS-Zahl zu begrenzen, nur damit eine Anwendung auf allen Rechner gleichschnell läuft (was nicht der Fall sein muss, denn was ist wenn ein Rechner mal keine 33FPS schafft?) ist keine gute Idee.
Besser ist hier einfach so schnell wie möglich rendern zu lassen (also Renderloop oder OnIdle-Event) und dann per Zeitmessung einen Zeitfaktor zu ermitteln (am besten über einen High-Performance-Counter) der wiederspiegelt wie lange gebraucht wurde um einen Frame zu rendern. Anhand dieses Faktors kann man dann alle Ereignisse auf allen Rechnern mit gleicher Geschwindigkeit laufen lassen. So mache ich das und die meisten anderen (auch kommerzielle Spiele) wohl auch.
Wobei ich inzwischen dazu übergegangen bin, den Computer pro Frame optional einige Millisekunden Idlen zu lassen - Benutzer von hitzegeplagten Notebooks (mein eigenes macht insofern keine Probleme) danken es einem, wenn die Anwendung im Gegensatz zu den meisten kommerziellen Spielen stabil läuft, und sich nicht schon nach zwei Minuten der Lüfter einschaltet ...
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
@Mars: Hey genau das Problem hab ich auch... Wie machst du das!? Da meine Programme der ganzen Zeit bei 100% Prozessorlast arbeiten, schlaucht das die Baterrie und die Nerven (wegen dem Lüfter) der Laptopnutzer.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Tja, das Problem kenn ich auch. Ich würde mal sagen: Sleep wirkt da Wunder Sleep hällt den aktuellen Thread für die Anzahl der angegebenen Millisekunden an. Oder gibt es noch eine andere Möglichkeit?
_________________ Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
SchodMC hat geschrieben:
Oder gibt es noch eine andere Möglichkeit?
Das einzige was man sonst machen könnte wäre nur dann das Bild neu zeichnen, wenn sich auch tatsächlich etwas verändert hat. Aaber das in ein Spiel einzubinden ist ein wenig sehr viel aufwand.
Ich glaube allerdings, dass wenn man eine Mischung aus HighPerformanceCounter und Sleep macht, dass man dabei am Besten weg kommt. Wenn man das schon machts, dann sollte man auf keinen Fall eine feste Anzahl von Millisekunden in das Sleep hängen. Auf schwächeren Rechner würde dies zu einer ungewollten Ausbremsung führen. Sehe ich jedenfalls so. Vielmehr würde ich in Abhängigkeit der Zeichengeschwindigkeit und der gewünschten FPS (sollte vom benutzer einstellbar sein) eine variable Anzahl an Millisekunden warten. So das man halt auf die gewünschte FPS kommt. 25 FPS reichen vollkommen ausreichen um ein flüssiges Bild darzustellen. Aber wie gesagt. Das sollte vom Benutzer irgendwo einstellbar sein.
Nur bei Änderungen zu Zeichnen bringt bei einem Spiel meist ohnehin nicht viel, als ja meistens irgendwelche bewegten Objekte (und sei es nur eine animierte Wassertextur) am Bildschirm sind.
Lossys Vorschlag entspricht auch meiner Lösung, wobei die so erreichte "feste" Framerate natürlich nicht als fixer Timer missbraucht werden sollte (schließlich kann es ja sein, wie von SoS bereits festgestellt, dass der Zielcomputer die erwünschte Framerate gar nicht erreicht) - und sollte vom Benutzer variierbar sein (sodass er selbst einstellen kann, ob das Ganze "Full Speed" oder mit x optionalen Frames läuft)).
Bei einer *fertigen* Applikation würde ich jedenfalls dafür plädieren, etwas ähnliches einzubauen - ich habe selbst schon miterlebt, dass Notebooks nach kurzer Zeit die Geschwindigkeit zurückschalteten oder sich im schlimmsten Fall ganz verabschiedeten, wenn man einfach frank und frei Rechenpower beansprucht.
Das sollte zwar nicht sein und ist auch nicht die Schuld des Programmierers - aber man mag den Leuten ja auch nicht sagen, dass sie ihre Hardware eigentlich auf den Müll schmeißen können, nachdem sie grad voller Stolz ihren 3.5 Ghz. Boliden präsentiert haben, der ja soo billig war und jeden Desktop locker in die Tasche steckt ...
...aber man mag den Leuten ja auch nicht sagen, dass sie ihre Hardware eigentlich auf den Müll schmeißen können, nachdem sie grad voller Stolz ihren 3.5 Ghz. Boliden präsentiert haben, der ja soo billig war und jeden Desktop locker in die Tasche steckt ...
*OffTopic on*: Oh ja. ein Kumpel von mir wollte 'nen Laptop kaufen. Und Aldi hatte ja ein gutes Angebot: einen Celeron mit 2.6 GHz! Ich meinte noch, er sollte lieber ein bisserl mehr Geld ausgeben, da Celeron langsame Prozessoren sind... Tja, was soll ich sagen: er hat auf das Aldi-System zurückgegriffen (so langsam wird's ja schon nicht sein), das Ding eigeschalatet und siehe da: das Teil schläft ja fast ein. Ich meine, ich bin mein AMD 3000+ Laptop gewöhnt. Schrecklicher vergleich. Da der Celeron nur 128K L2-Cache hat, sieht er gegen meinen AMD64 mit 1MB L2 Cahce natürlich lächerlich aus. Und das das Teil soooo langsam ist, hat sogar mich überrascht. Mein Kumpel meinte nur: "Warum so langsam? Sind doch immerhin 2.6 GHz im Rechner!" Na ja, was will man da sagen. P.S.: Ich bringe es einfach nicht fertig, ihn auf den defekten Pixel im Display aufmerksam zu machen... (wollte er mir auch nicht glauben ) Aber billig war er *OffTopic off*
Aber zurück zum Thema: Wenn ich es richtig weis, hat Doom3 die FPS auf 60 fix eingestellt (damit die Events alle synchronisiert werden können oder so). Ich finde eine FPS-Begrenzung nicht unbedingt schlecht (man kann ja, wie festgestgestellt, CPU-Power sparen), würde jedoch nicht damit das Timing auch nicht davon abhängig machen. Wäre also wirklich besser, nur dann ein Sleep einzuführen, wenn die mindest-FPS-Zahl überschitten werden kann. Und wie Lossy schon gesagt hat: in Verbinung mit einem HighPerformanceCounter lässt sich das ganze dynamisch regeln und anpassen. Dennoch sollte man IMO das ganze per Option dem User offen lassen. Denn es gibt ja immer noch absolut FPS g**** User da draußen (ätsch, mein Quake hat 3 FPS mehr als deines.) Na toll, wo doch ab 25 FPS aufwärts sowieso kein all zu großer Unterschied mehr bemerkbar ist, da ab 25 FPS das Auge eine Flüssige Animation wahrnimmt und mehr nicht bemerkt... (Ok, sagen wir 30 um auf der sicheren Seite zu sein )
_________________ Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Ich glaube die Sache mit dem "30 FPS sind genug..." kann man getrost als Humbug bezeichnen. Möglich dass das Auge (das ist sowieso von Person zu Person anders) jenseits der 30 FPS keine optische Verbesserung mehr erkennt, allerdings kann man bei der Bewegung klar den Unterschied zwischen z.B. 30 und 60 FPS erkennen. Spiel mal UT2k4 bei 30fps und dann mal bei 60fps (z.B. durch Deaktiveren des AAs oder niedrigeren Details), und dir wird der Unterschied sofort auffallen. Die 30fps Sache stammt irgendwie aus dem TV-Bereich, wo die 50 übertragenen Halbbilder natürlich flüssig erscheinen. Dass dies bei Computerspielen jedoch definitiv nicht genug is dürfte weitläufig bekannt sein.
P.S. : Sieh dir das hier an und du wirst mir sofort Glauben schenken...
Hmm, man lernt nie aus Gut, wenn man beides im Vergleich sieht, fällts natürlich auf. Wenn man ein Game mit 60FPS contra 30FPS spielt, dann ist das mit den 60 natürlich "flüssiger". Aber deswegen kann man das ja per Option einschalten lassen. Damit hat der User die Möglichkeit, die FPS-Zahl (eben per Optionen-Dialog) auf ein Maximun zu setzen und bei seinem Laptop den Geräusch-Pegel sowie den Strom-Verbrauch niedrig zu halten. Allerdings frag ich mich gerade, ob sich dass wirklich bemerkbar macht oder ob der Strom-Verbrauch und der Geräuschpegel (sowie Hitze-Entwicklung) bei der Verwendung des 3D-Chips sowieso hoch geht...
P.S.: Wenn ich ein Game zocke, ist mir beides egal:
1. Ich hab 'ne Externe Soundanlage -> Übertönt den Lüfter, so dass der nicht mehr so extrem störend wirkt
2. Ich Spiele mit Netzteil!
_________________ Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?
Ich vermute man benötigt bei Computerspielen höhere FPS, weil sie interaktiv sind und man die sofortige Reaktion erwartet. Das man zeitliche Unterschied unter 1/30s feststellen kann, sieht man ja am Flimmern eines 60Hz Monitors.
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.