Suchergebnisse
Suchergebnisse 1-20 von insgesamt 26.
Hier noch ein Programm das seinen Quellcode ausgibt: Quellcode 1 Q Programmiersprache ist HQ9+
Wenn eine mit GCC erstellte .exe einige MB groß ist liegt es höchstwahrscheinlich daran dass die Symbolinformationen noch drin sind. Die kann man mit dem strip Utility (linux, msys) entfernen.
SDL steht für "Simple DirectMedia Layer". Das sind nur Routinen für Grafik, Eingabe, Timing und ähnliches. Deine Spielgrafiken wirst du da nicht finden. Die sind wahrscheinlich nur auf der CD...
Zitat von »"Eldarion72"« edit: hat man dann nicht das problem das sich evlt schon koordinaten verschieben während des renderns? weil das müsste dann ja in 2 threads ablaufen. Man rendert den Zustand vom letzten Update. Wenn sich während des Renderns beim Update was ändert sieht mans erst im nächsten Renderframe. Mir gefällt die Methode recht gut. Hab bisher immer zuerst das Update gemacht und danach rendern + anzeigen, was ja nicht so günstig zu sein scheint weil dann die gesamte Hauptschleife ...
Zitat von »"rewb0rn"« Zitat von »"LagRange"« Es geht hauptsächlich darum dass aufwändigere Physikinteraktionen die Framerate ganz schön drücken können. Man spart einiges an Rechenzeit wenn man die nicht so oft aufruft. eben deswegen habe ich konstante framezeiten. für welche anderen elemente lohnen sich zusätzliche berechnungen? Meine Überlegung war dass wenn sich z.B. Physikberechnungen nicht mit der gewünschten Framerate von 50fps durchführen lassen diese eben nur mit 20fps laufen, Grafikausg...
Es geht hauptsächlich darum dass aufwändigere Physikinteraktionen die Framerate ganz schön drücken können. Man spart einiges an Rechenzeit wenn man die nicht so oft aufruft. Ausserdem kann man (in manchen Simulationen) Bewegungen zwischen einzelnen Physikaufrufen interpolieren, was dann auch bei niedrigen Updateraten zu flüssigen Bewegungen führt.
Ich bevorzuge es keine sleep Anweisungen in meine Hauptschleifen einzubauen, sondern lass die Grafikausgabe lieber mit maximaler Geschwindigkeit laufen (jeder freut sich über hohe FPS-Werte :lol: ) Wenn ein Teil vom Programm (z.B. Physikengine) empfindlich auf variierende Framezeiten reagiert, wird das nicht in jedem Frame aktualisiert sondern in fixen Zeitintervallen. Pseudocode: C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 unsigned int time, delta, last, delta_phyics; delta_ph...
Zitat von »"David_pb"« Jo, ich denke das Problem liegt an den zwei unterschiedlichen Verwendungen des *-Operators im Bezug auf Zeiger. Nur bei der Deklaration/Definition eines Zeigers wird dem Compiler per * mitgeteilt das es sich hier um einen Zeiger handelt. Ansonsten wird der *-Operator zum Dereferenzieren des Zeigers, also quasi der Umwandlung in die gezeigte Variable, verwendet. Wenn man den Unterschied kapiert hat, dann sind Zeiger nurnoch halb so schlimm! wenn man C-/C++-Quelltext 1 int ...
Ich könnte mir eine Methode vorstellen die mit Musik so etwas ähnliches wie ASCII-Art macht. Einfach gesagt: den Stream in kleine Chunks aufteilen und durch möglichst gut passende MIDI-Samples ersetzen. Eventuell könnte man vorher das Audiosignal in Subbänder und/oder die Chunks per temporaler PCA oder ICA in einzelne Tracks aufsplitten, die mehr oder weniger verschiedene Instrumente repräsentieren könnten. Das ist aber reine Spekulation :roll: Das Ergebnis wäre vermutlich nicht besonders gut (v...
All diese #pragma Direktiven sind nur für den MS Compiler, oder?
Wie siehts aus wenn man die member des structs als union mit einem Array gleicher Größe deklariert... sollten die dann nicht schön hintereinander im Speicher liegen?
Mein persönlicher Geschmack: Nicht jede Zeile dokumentieren. Das macht alles irgendwie unübersichtlich. Der Code sollte an sich möglichst selbsterklärend sein ("Globale Instanz von cRandom" z.B. ist schon allein aus der Deklaration ersichtlich). Sprechende Variablennamen innerhalb von Blöcken reichen um deren Aufgabe zu erklären. Wichtig ist aber die Dokumentation von Klassen, Methoden, globalen Funktionen, etc. so dass man gleich weiß was diese machen, ohne die Implementierung ansehen zu müssen...
Geht auch ohne Buch. Es gibt unzählige OpenGL Einsteigertutorials im Netz. Aber wie Gurke schon gesagt hat, es braucht einiges mehr als 3D Grundkenntnisse um sowas hin zu kriegen. Unter anderem gute Grafiker
Für einfache Karten, die nur Land/Wasser unterscheiden sollen würde ich einen Game-of-Life ähnlichen Algorithmus verwenden: 1. Karte mit Rauschen initialisieren 2. Neuer Wert für jedes Feld = Mehrheit der Nachbarfelder (wenn gleich keine Änderung) Schritt 2 solange wiederholen bis das Gewünschte Ergebnis erreicht ist oder sich nichts mehr ändert. Diese Methode ist einfach, schnell und gibt schön zusammenhängende Land- und Wassermassen.
Zitat von »"David_pb"« Includeguards sind halt Standardkonform, drum ja auch nochmal der Compilercheck (#if _MSC_VER > 1000). Aber warum doppelt? Gibt es irgend welche Vorteile wenn man die Pragmadirektive beim MS Compiler einsetzt? (nicht dass ich den verwenden würde :badgrin: )
Zitat von »"ccl_destroyer"« Und wie kann ich die 4 fenster so erstellen, dass jedes fenster etwas anderes anzeigt (also 3d-ansicht,draufsicht, seitenansicht von links und von rechts, und so dass die renderstates für die einzelnen fenster einzeln anpassbar sind)? In jedem Fenster mit anderer Projektionsmatrix rendern (z.B. orthographic für 2D-Ansichten)
Ich nehme an es liegt daran dass der Operator im Prinzip eine Funktion ist und das was rechts davon steht ist der Parameter. Haben wir eine Funktion (oder anderen Operator) als Parameter wird diese zuerst ausgeführt. Hier führt das ganze zu einigen verschachtelten aufrufen - das jeweils "zweite" foo() steht weiter drinnen in der Verschachtelung und wird daher zuerst ausgeführt... Ich hoffe das macht Sinn edit: argh, zu lange herumformuliert... ist das erste foo() nicht auch ein parameter?
Ich kenn zwar das Buch nicht, aber es klingt als ginge es darum dass die Instanz in einer Unterfunktion erstellt wird und man sie irgendwie an die aufrufende Funtkion übergeben will. So in etwa: C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 class myclass { //... }; myclass unterf( ) { myclass inst; // ... return inst; } int main( ) { myclass inst2; inst2 = unterf( ); }
Manche müssen sich immer noch mit den 'alten' Methoden herumschlagen: Muss morgen Früh mein Projekt zur EEG-basierten automatischen Erkennung von Bewegungsabsicht verteidigen. Würde lieber die Zeit produktiv verbringen und an meinem Spielchen weiter schrauben
Zitat von »"koschka"« (Komischerweise zeigen die im Artikel aber Regionen vom Posterior Kortex und nicht vom Präfrontalen Kortex). Ist der Posterior Kortex nicht Straßenecke Sehzentrum? Ich hab zwar ein Grundsatzproblem mit den medizinischen Richtungsbezeichnungen, aber die Farbkleckse scheinen doch schön im vorderen Bereich zu sein.
24.04.2024, 14:56
Zum Seitenanfang
