Hier koennt ihr eure meinungen zum projekt sagen.. Ich freu mich fur ein feedback.

_________________
Mich interesiert es nicht in welcher sprache du programmiers. Mich interesiert, was du in dieser sprache programmieren kannst.

Hallihallo,

Ich hab mir das mal geladen und muss sagen... alle Achtung, dafür das es ein CPU-Renderer ist, noch dazu selbstgebastelt!
Also mein alter AMD-4-Kerner schafft das mit durchschnittlich 47 Frames/Sekunde im kleinen Fenstermodus und wenn ich auf fast Fullscreen skaliere sinkt die Rate in den Keller. (irgendwie logisch). Aber witzig^^
Beim skalieren des Renderers verpixelt sich die Animation etwas, also...ist warscheinlich auf ne fixe Auflösung eingestellt, und skaliert einfach das Bild am Ende, oder?
Aber echt geile Idee =)

_________________
Ich teile manchmal heimlich durch Null. - Alber Einstein

Danke Ida. Und es erbietet nur mit einem thread, mit dem haupt-thread. Die aflosung solte sich beim wechseln der greose des fensters auch andern. Ich hab den direct-draw noch nicht so bug-free. Ich konzentriere mich mehr auf das engine. Wen ich probleme mit der direct-draw kriege, warted die opengl, oder gdi auf mich Ich hab auch einen 4-kerner aber ein intel. Schoen zu wissen dass es auch am AMD leuft.

_________________
Mich interesiert es nicht in welcher sprache du programmiers. Mich interesiert, was du in dieser sprache programmieren kannst.

Hi,

sieht wirklich interessant aus, dein Projekt und läuft auch auf meinem Rechner flüssig (~70-90FPS). Dafür alle Achtung!

Beim Überfliegen des Quelltextes ist mir jedoch aufgefallen, dass dieser leider recht unstrukturiert ist, was der Weiterverwendbarkeit nicht unbedingt zu Gute kommt. Auch sind Include-Dateien in Pascal (welches schließlich ein Unit-System besitzt, das einen C entwickler neidisch werden lässt) nicht wirklich state-of-the-art

Auch solltest du deinen Software-Renderer und alles drum herum logisch Sauber davon trennen - insbesondere sollte der Software-Remderer keinerlei Abhängigkeiten zu Betriebsystemfunktionen oder externen Bibliotheken haben. Mein Tipp: Unterteile deinen "src"-Ordner in mehrere Unterprojekte (wie "renderer", "loader", "utils"), wobei diese keinerlei Abhängigkeiten zueinander haben sollten. Insbesondere sollte der Renderer keine eigene Ausgabe haben, sondern lediglich auf ein Bitmap im Speicher rendern. Um die Ausgabe kann sich ja der Anwender des Renderers kümmern/kannst du ja deine aktuelle Methode (DirectDraw) im "utils"-Unterprojekt bereitstellen.

Wie gesagt, dein Projekt ist soweit schon super, wenn du es aber nicht nur als "Techdemo" siehst, sondern auch andere Leute daran Teil haben möchtest, ist oben beschriebenes Vorgehen jedoch einiges besser.

Andreas

_________________
http://audorra.sourceforge.net//http://andorra.sourceforge.net

Tja ich weis das der src code nicht so sauber aussieht. Ich habe sehr viele ideen und hab keine zeit fur die shoenheit des codes oder fur die kommentare. Aber ich nehm mir die zeit um die ordnung in das chaos zu bringen. Viele funktionen sind als prototypes fur das moment so sie sind enfach nur geschrieben um zu funktionieren. Spater werde ich sie zum units ordnen oder durch bessere functionen ersetzen. Nun zum include_deteien. Der freepascal kann nich assembler funktionen kopieren als wenn man hinter einer pascal procedure eine INLINE direktive schreibt. Also mach ich das mit der include-detai. Mit diesen trick hab ich kein push-pop-call-ret-slow-down fur die zeit-kritischen procedure wie die tile-proceduren. Ubrigens, die include deteien helfen mir den code besser zu lesen. Wie zb. die unit fenomenon_math. Wenn ich alle funktionen in eine datein reinstecke, hab ich problem eine function zu finden. Ida, danke fur die tips. Ich werde es mir merken. Aber biss der freepascal keine inline assembler routine kopieren kann, kann ich mit der include datei nichts machen. Und ubrigens manchmal hatte ich bei units probleme mit "circular depencies" oder wie es heisst.

Uber das project. Fur nechstes werde ich eine neue struktur fur die texture machen. Die ist je kodiert in 8x8 tilen aber da gibt es probleme wenn mann fur die bilinear interpolation 1 und 3 nachbar-texel lesen must und wenn man an der rechten und unteren ecke ist, must man die texel aus einer anderen tile lesen musen. Mit 9x9 tile ist das kein problem. Ok, die textur wird ein bischen groesser aber mir geht es um schnelligkeit. Wie so 9x9? tja ich kopiere aus einer enderen tile die texels fur die rechte and von einer enderen tile fur die unteren texels. Das hilf mir nicht von einer enderen tile zu lesen wen ich die 4 texels lese am rande der momentalen tile. Die Cpu-cache bleibt sauber.

_________________
Mich interesiert es nicht in welcher sprache du programmiers. Mich interesiert, was du in dieser sprache programmieren kannst.

Bin ja immer ein großer Fan von SW-rendering und von daher erst einmal ein dickes Lob auch von meiner Seite
Hier mal noch ein paar Denkansätze die mir so spontan einfallen:
-Polygone sollten nach Möglichkeit vermieden werden da sie in der Regel langsamer sind.
-Für ein bissl Eyecandy kannst du ohne Probleme auf Radiosity setzen (es sagt ja schließlich niemand das es für jeden Pixel Echtzeit sein muss oder? )
-Dein Renderer sollte nicht auf einer großen Schleife sondern stattdessen eher auf einen Eventsystem aufbauen.

_________________
Meine Homepage

Hey yunharla.

Zum polygonen. Tja mit der scanline technik ist es nicht so schwer einen polygon zu zeichnen aber mit der half-space ist es die reinste hoelle.

Uber die statische radiositeat habe ich nachgedacht und die von Source engine ist simple aber richtig gut. Tja aber ich mechte auch dynamishe schaten, so hab ich nachgedacht, das ich nur die sekunderen abprall lichtstrahle statish werden und die lichter auch. Dynamische lichten werden nur mit dem directen licht beluechten.
ODER
Ich denke auch uber diese technik nach http://www6.incrysis.com/Light_Propagation_Volumes.pdf
Aber das ist die weite zukunft

Der eventsystem ist auch eine gute idee. Ich denke momental arbeiten so die fenster, tastatur und maus funktionen, Die tastatur und maus sind modulere funktionen die sich selber bei der inizialisierung einhaken.


Ok jungs. Ich muss auch ein lob an euch geben. Sie geben mir richtig gute ideen uber welche ich nachdenken kann. Danke.

_________________
Mich interesiert es nicht in welcher sprache du programmiers. Mich interesiert, was du in dieser sprache programmieren kannst.

hatte in quake 2 das mal aus jucks eingebaut das dynamische Lichter für jeden betroffenen Lightmaptexel einen Strahl zurück zur Lichtquelle
schicken und das hatte so 20-40fps verlust ergeben (was natürlich ein Witz ist wenn man bedenkt wie schnell dieses alte Teil ist lol)

Ansonsten kannst du immer noch auf einen halbwegs modernen Rechner eine VM für MIMD aufsetzen die dann Radiosity in Echtzeit berechnet...
kam damit allerdings bisher nur auf eine 320*240 Auflösung da ich nicht unter 1kb an Speicher pro Thread kam

_________________
Meine Homepage

Tja zur programierung must man seine ideen ach mal testen und sehen was passiert und wie schnell es ist. Wie ich als ich die triangle-tile-coverage stack idee hatte. Und ich war wirklich uberascht. Oder jetzt. Ich habe an manchen stelllen die instruktion MOVNTDQ mit MOVAPS oder MOVDQA eingetauscht, und das program leuft jetzt mit 52 fps. Tja wie so habe ich dann die istruktion MOVNTDQ dort hingeschrieben? Frueher war der program vielecht nich so gut fur die cache optimaliziert und die instriktion MOVNTDQ war einfach besser fur die schnelligkeit. Abe jetzt, spater wenn die ram-zugriffe weniger sind und die daten sind mehr aus der cache als aus der ram gelesen sind die anderen zwei instruktionen besser. Bin auch uberrascht. Tja es ist schoen zu sehen wen die fps von 44 zur 52 hoch geht

_________________
Mich interesiert es nicht in welcher sprache du programmiers. Mich interesiert, was du in dieser sprache programmieren kannst.

Hallo jungs. Moechte mal fragen. Was meinen sie. Ist es so wichtig, das ich die per-pixel-clipping funktion mit der camera-ebene mache oder lass ich es bei per-tile-clipping ? Ubrigens... bilinear-filtering ist jetzt drin und es leuft mit 46 fps.

_________________
Mich interesiert es nicht in welcher sprache du programmiers. Mich interesiert, was du in dieser sprache programmieren kannst.

Kurzes Feedback:
Hardware: ATI Mobility FireGL V5700
Fenstermodus: ca 60FPS
Fullscreen (1920x1200): ca 10FPS

Im Anhang ein Screenshot wie es bei mir aussieht. Die Textur wirkt sehr psychedelisch.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ok-ok was fur ein cpu hast du? Ich denke die texture-sampling routine macht probleme. Versuche das altere demo : http://sourceforge.net/projects/phenome ... r/download. Wenn es normal leuft, dann weiss ich wo das problem ist.

Ich muss mal entlich eine sse-version-detection routine einbaunen.

_________________
Mich interesiert es nicht in welcher sprache du programmiers. Mich interesiert, was du in dieser sprache programmieren kannst.

Für Battlefield 3 haben die ein Software Renderer geschrieben, welcher für occlusion culling verwendet wird.
Dabei wird nur depthbuffer unterstützt und triangle des physik meshes durch gejagt.
Das ganze wird auf niederer auflösung gemacht und performt auf allen platformen wohl überragend gut, weil tonnenweise binding und draw anweisungen garnicht erst in die render pipeline gehen.

http://www.slideshare.net/DICEStudio/cu ... n-practice

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Sorry, aber das geht auch nicht. Das Ergebnis sieht genau so aus.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ja-ja, wies uber diesen trick. Ich denke dass fallout3 benutzt es auch. Danke fur den link. Ich war auf der DICE seite und fand andere interresante artikel. Danke.

_________________
Mich interesiert es nicht in welcher sprache du programmiers. Mich interesiert, was du in dieser sprache programmieren kannst.