Suchergebnisse

Guten Abend, ich bin vor Kurzem auf die Idee gekommen eine sehr abgespeckte Spielekonsole zu bauen Um zu gucken was für Mikrocontroller ich brauche habe ich recherchiert und ein Testprojekt angefangen. Ziel ist es erstmal ein großes 3D Modell einzulesen und mittels eines Viewports auf eine Bitmap zu zeichnen. Funktioniert auch alles soweit. Mit höchster Optimierungsstufe auf einem AMD Athlon II X2 250 3,00Ghz Prozessor schaffe ich 100 mal rendern in 3,39s (shadeless) (Versteckter Text) und 4s (f…

Hi, danke für die Antwort. Habe das move mal direkt weggelassen. Zitat von jvbsl: „jeden Vertex projection*transform neu ausrechnest“ Wo mache ich das denn? Im vec_to_raster berechne ich v_camera = transform*vertex und v_screen = projection*v_camera. Wobei ich v_camera für die Z-Koordinate brauche. Kann ich da noch etwas pro Frame berechnen? 0.5*dev_x berechne ich jetzt im Voraus. Für dev_y bringt das nichts, ich rechne ja (1 - (v_screen.y + 1) * (0.5)) * dev_y. Vereinfache ich den Term für dev_…

Transform ist der Transform des Viewports. So habe ich Vertex dann im Koordinatensystem der Kamera und kann Z für den Z-Buffer benutzen und gucken ob er zwischen near- und farplane liegt. Hmm also v_screen = transform*projection*vertex funktioniert. Hatte es erst andersrum versucht, deswegen dachte ich es klappt nicht. FP hatte ich auch als Floating Point aufgefasst und in dem Kontext benutzt. Fixed Point -> Ganzzahl. Bin nur zu doof alles auf int umzustellen

Den Bresenham's Line versteh ich noch nicht wirklich. Wie löst der mein Visibility Problem? Woher weiß ich welches Dreieck sichtbar ist und wie ich die Attribute (Colour, Normals, Uvs etc) interpolieren muss? Die Z-Koordinate ist nicht mehr verwendbar, die wird ja auch transformiert. Ich hab in der Matrix Klasse jetzt einfach ne Funktion hinzugefügt die X, Y und W mit Matrix1 multipliziert und Z mit Matrix2. Obs schneller geworden ist kann ich nicht sagen: Windows Update Alles ist extrem langsam…

Teilweise klappt es sogar, llerdings nicht richtig. Die Werte werden nach dem Verrechnen so klein, dass es zu Z-Fighting kommt. So wie oben geschrieben mach ich's jetzt so: C-Quellcode (14 Zeilen) Z wird zwar nicht normalisiert wenn w des Transform != 1 wäre, aber wenns da mal zu Fehlern kommen sollte kann ichs einfach nachrüsten. Aktuell läufts ja so ab:1. Ich loope durch alle Dreiecke 2. Es wird durch alle Pixel innerhalb der Boundingbox des Dreiecks geloopt 3. Es wird geprüft ob das Pixel auc…