Suchergebnisse

Das wäre dann ein Aufwand von O(n²)... Da bin ich gespannt, welche Performance er zusammen bringt, wenn er Tausende Instanzen untereinander vergleicht (Distanzchecks sind auch nicht gerade das schnellste). Vor allem wenn man vor hat eine Physikengine zu schreiben, sollte man sich über soetwas Gedanken machen.

Zitat: „Hmm, ... jede Instanze fragt also jede andere Instanze ab. Ich denke da an Ressourcen (CPU) die dadruch in die Knie geht“ Man sollte natürlich nicht jede Instanz mit jeder anderen auf Kollisionen prüfen, da braucht man schon eine gute Strukturierung, um unnötige Überprüfungen zu vermeiden. Spontan fallen mir Quadtrees ein. Zu deiner Rendermethode will ich mich jetzt nicht äußern.

Kurz: Ähnlich wie im GM, mit Klassen und Instanzen dieser Klassen. Wenn du aber noch gar keine Ahnung von C# und OOP hast, dann kannst du das ganze gleich wieder vergessen. Lern erst mal richtig die Sprache und ihre Konzepte bevor du dich an ein Spiel oder eine Physikdemo ranwagst. Immerhin musst du ja das ganze auch Rendern, was wiederum das Lernen einer Bibliothek oder API (z.B. Direct3D) erfordert.

Vorschlag: Füge doch ein optionales Argument hinzu, welches den Seperator festlegt.

Du optimierst an der falschen Stelle. Alle Vertices die du renderst werden sowieso auf Direct3D-Ebene transformiert, auch mit der Identitätsmatrix. D.h. der größte Aufwand, nämlich die Matrixmultiplikationen, ist immer da. Durch das vorherige Drehen würde nur der Overhead durch den Funktionsaufruf verschwinden, den man vernachlässigen kann. Außerdem müsstest du, wie Chris schon erwähnt hat, den Ladecode manipulieren und wissen wie Matrixmultiplikation geht bzw. wie eine Rotationsmatrix aussieht.…

Kopier sie doch einfach vor dem Schreiben ins working directory, verändere sie mit den ini-Funktionen und kopier sie wieder zurück.

Zitat von MewX: „Zitat von Clonk_Fan: „Kanns kaum erwarten den Grill wieder anzuschmeißen :)“ Ich habe heute gegrillt. Ha!“ Und dann noch über den "Winter" beschweren.

Zitat: „... und dass die Sonne im neuen Jahr auch wieder aufgeht und den Winter vertreibt.“ Hoffentlich nicht...

Ich habe unlängst einmal einen kleinen Software-Renderer geschrieben, der auf SDL basiert. Er kann nichts besonderes, nur Wireframe-Objekte darstellen, nicht einmal Culling habe ich eingabaut. Die Theorie habe ich aus diesem Buch gelernt (wirklich zu empfehlen), aber diese Artikelreihe sollte für dich reichen. Btw: Wenn du die View um den Würfel drehen willst, musst du logischerweise deine Viewmatrix ändern.

Du musst die Reihenfolge der Rotationen beachten. Mr.Diesel's Code rotiert zuerst um die Z-Achse und dann wird erst die Neigungung um die X-/Y-Achse beachtet. Das hat den selben Effekt, als würdest du den Rotor zuerst neigen und dann um die lokale Z-Achse drehen.

Zitat: „Sometimes you temporarily want to save the current transformation, for example to add an additional transformation and then restore the old one (this often happens when drawing hierarchical models). To this end you can push the current transformation on a stack and later pop it from the stack to make it the current transformation again.“ Das sagt eigentlich schon alles. Wenn du zum Beispiel deine aktuelle Transformation speichern willst, du jedoch kurzzeitig eine andere brauchst kannst d…

Sicherlich ist es möglich, nur mit der GM-Funktionalität alleine geht es leider nicht.

Zitat: „Moderne Spiele (wie Far Cry) benutzen Delta Timing.“ Das hat nichts mit modern zu tun, Delta Timing wird so ziemlich in jedem Spiel verwendet, abgesehen von GM-Spielen natürlich. Zitat: „Dabei wird anhand der Frames und der verstrichenen Zeit berechnet, um wieviel sich der Spieler in die jeweilige Richtung bewegt hat“ Nicht ganz richtig, es wird berechnet wie lange eine komplette Schleife dauert. Dieser Wert wird dann als Faktor für z.B. Bewegungen verwendet: Quellcode (1 Zeile) Zitat: „…

Schau dir mal die file_find_* -Funktionen in der Hilfe an.

Beachten sollte man, dass die Stärke des Bresenham-Algorithmus darin liegt, dass er weder Winkelfunktionen noch andere kostspielige Operationen wie z.B. sqrt() braucht und somit sehr effizient arbeitet.

Lies dir mal das durch, sollte kein Problem sein das auf dein Problem zu übertragen.

Zitat von MewX: „Zitat von Verwurster: „Hoffentlich wird das kein dunkler Skin um sich dem neuen Look von gmhmtl5 anzupassen...“ Doch, im Winter werden wir sämtliche Skins so umändern, dass ihr helle Schrift auf dunklem Untergrund lesen müsst.“ Ich hoffe das ist nur ein schlechter Witz...

Zitat: „ Du kannst keine scharfen Kannten durch Antialiasing wegbekommen [Edit: Ich spreche hier von 3D-Edges/Kannten ]. Das einzigste was hier hilft, ist die View-Dimensionen an die Display-Dimension anzupassen “ Das stimmt nicht. Die Auflösung zu ändern, bringt da überhaupt nichts. Antialiasing ist genau das, was man braucht um die Kanten zu glätten. SDX und ich haben mal eine DLL entwickelt, mit der man direkt auf das D3D-AA zugreifen kann. Damit ist es auch möglich z.B. 8x AA zu aktivieren, …

Ich glaube du verstehst nicht ganz wie Blendmodes überhaupt funktionieren. Wenn du ein Sprite, Surface oder was auch immer auf dein Surface zeichnest, wird die finale Farbe für jeden Pixel durch eine bestimmte Operation zwischen den beiden gegebenen Farben berechnet. Was du hier beschreibst, schreit nach bm_subtract. Das heißt die Farbwerte von deinem Blendsprite werden von denen auf deinem Surface subtrahiert -> Weiß RGB(1, 1, 1) dunkelt komplett ab, sodass Schwarz entsteht; Schwarz RGB(0, 0, 0…

Zitat: „das Problem bei bm_subtract ist, dass dann der Inhalt auf der bestehenden Surface gelöscht wird.“ Achso, du willst es also rückgängig machen können? Tja das ist nicht möglich, auch bei bm_add kommt es zu Farbverlust. Stell dir vor die Farbe eines Pixels auf der Surface ist ( 0.5, 0.7, 0.3 ), nun wird ( 0.5, 0.5, 0.5 ) hinzugefügt. Das würde zur Farbe ( 1.0, 1.0, 0.8 ) führen, da die Werte geclampt werden, d.h. sie können ein Maximum nicht überschreiten. Wie man sieht haben sich die Relat…