Achja. Was mir gerade noch aufgefallen ist. Hat nichts mit dem Beitrag an sich zu tun. Wenn du vor hast so große Quellcodes zu Posten dann Zip sie lieber und hänge sie als Posting an deinen Beitrag an. Dann kann sich jeder aussuchen ob er den Quellcode sehen will oder nicht. Es gibt nämlich immer noch Analagmodem Benutzer. Die werden es dir danken.

Ganz so umfangreich wollte ich es nicht machen.
Aber immerhin hab ich folgende Verbesserungen durchgeführt:

1. glBegin(quakquak) und glend; vor und hinter die hauptzeichenschleife gepackt
2. meine eigenen definitionen giVertex etc durch original OpenGL befehle ersetzt (die anderen dienten dazu, dass man nicht immer opengl ins hauptprogramm einbinden muss. hatte jedoch vergessen, dass mir OpenGL in der Partikelunit zur Verfügung steht
3. Die Möglichkeit alles in den Speicher und nicht über CPU laufen zu lassen verbessert. Beim Vorbereiten des PSystems wird über einen Schalter festgelegt, ob eine Liste im Speicher angelegt werden soll. Somit entfallen ALLE neuberechnungen der Partikel, sobald ihre Lebenszeit abgelaufen ist. Lediglich die LiveTime wird durch die zuvor gespeicherte ersetzt.

Ich hoffe man kann mein komsiches Deutsch verstehen

_________________
Rock is a message.
Hear the message an you will rock!

So, hab alles nochmal Überarbeitet und ne auf mich zugeschneiderte Version von Tak2004's PerfMon eingebaut. Aber bin immernoch nicht zufrieden. Bei mir ballert der erstmal hoch auf 60FPS und sackt dann kurz danach runter auf ca. 30FPS.

Ich wäre dankbar, wenn ihr euch das mal anguckt und mir dann sagt, wieviel FPS es bei euch macht.

http://akwclan.servegame.org/external/fire3.rar

EDIT:
Folgende Interaktion ist mit dem Programm möglich:
Mausrad: Zoom
Pfeil nach oben: Perfmon ein
Pfeil nach unten: Perfmon aus

_________________
Rock is a message.
Hear the message an you will rock!

Hi,
also der link ist tot und wegen der FPS ich vermute das da was echt daneben ging mit der Implementierung von GLPerfmin, denn 60FPS ist verdammt wenig, wenn du nicht gerade ne GF2 hast!?

MfG TAK2k4

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

Projekte: https://github.com/tak2004

Yo. Der Server scheint tot zu sein.

Und wegen der FPS. Hast du rein zufällig VSync an? Also in deinem Grafiktreiber? Was allerdings nicht erklärt warum es dann auf 30 runter geht. Das ist nämlich verdammt wenig.

Jetz mal, weil wirs hier vom "schnellen" system haben.
Fast alle Partikel werden doch immer zum betrechter hin gezeichnet?!
Und immer diese Billboards...
würde es nicht sinn machen, alle partikel zu anfang zu zeichnen, statt mittendrinne und dann mit der matrix rumfuchteln?!

_________________
www.audi32.de

Da Partikel geblendet werden, empfielt es sich die Partikel zu letzt und ohne beschreibung des Tiefen Puffers zu rendern.

Denn wenn du sie am Anfang in den Tiefen Puffer schreiben läßt tritt ein sehr unschöner Effekt auf(man sieht durch die Partikel auf den Hintergrund). Zeichnest du sie hingegen ohne Beschreibung des Tiefen Puffers, werden deine Partikel fast immer überzeichnet.

MfG
Flo

PS: Hab es selber noch nicht getestet. Es ist nur so eine Vermutung von mir.

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Ich hab dein code mal überflogen und mir fiel noch auf du könntest aus der Texturid:cardinal einfach mal ein Texturidlist:array of cardinal machen so kann man jeden verstrichenden schritt eines Partikels ein Image zuweisen. Eine möglichkeit wäre z.B. texid:=round((leaftime/Texcount)*time); dann würde er Prozentual die bilder auf die zeit aufteilen wenn du aber willst das image 1 nur 1mal kommt dann solltest du deine imageliste anpassen und die anderen texturen einfach doppelt nacheinander reinpacken.

Optimierung naja viele kleinigkeiten machen das system ein wenig schneller.
1)vermeide doppelte rechnungen z.B.
pos[0]:=-Size+Current[0];
pos1[0]:=Size+Current[0];
glvertex(pos[0],...
glvertex(pos[0],...
glvertex(pos1[0],...
glvertex(pos1[0],....
anstatt
giTexEdge(1); giVertex(-Size+Current[0], Size+Current[1], 0.0+Current[2]);
giTexEdge(2); giVertex(-Size+Current[0], -Size+Current[1], 0.0+Current[2]);
giTexEdge(3); giVertex(Size+Current[0], -Size+Current[1], 0.0+Current[2]);
giTexEdge(4); giVertex(Size+Current[0], Size+Current[1], 0.0+Current[2]);

2)bei aufwendigeren rechnung sind Assemblerbefehle die am besten FPU nutzten ratsam
3)vermeide so oft wie möglich gleitkomma zahlen mit zu schleppen da diese viel zeit verbrauchen selbst bei simplen additionen
4)Stell die genauigkeit der nach dem Kommawert berechneten stellen runter, da man meistens eh nicht so viele braucht wie standard ist.
Delphi bietet ein Befehl dafür der mir leider entfallen ist der weisst der FPU an das er nach sovielen stellen abbrechen kann und nicht 8 und mehr stellen nach
dem Komma rechnet.
5)versuche so wenig und so klein wie möglich die arrays zu halten, denn für dich sieht die speicheradressen aus ob sie alle nacheinander wären aber diese adressen verweisen auf eine 2 liste die die wirklichen adressen hat die im schlimmsten fall quer über den speicher verstreut werden können und dann zeit beanspruchen.
6)versuch OGL Befehlstechnisch befehle einzusparen z.B. ein glcolor befehl wenn möglich vor dem zeichen fest zu legen und nicht jedes mal mit den gleichen schnee wieder hinzuschreiben
7)halte die Grafiken für die Partikel sehr klein
bei partikelsystemen die viel platz einnehmen wie Wolkenformationen sollte man überlegen eine überprüfung auf sichtbarkeit ein zu führen
9)nutzte bei grösseren Partikelgrafiken Mipmaps

Jo mehr fällt mir so momentan auh nicht mehr ein worauf ich so acht geben würde.
Wegen der geschichte mit rechnen mit kommawerten und FPU diese scheinen ein bischen übertrieben zu wirken aber gerade bei älteren Systemen machen sich solche dinge sehr schnell bemerkbar.

MfG TAK2k4

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

Projekte: https://github.com/tak2004

Ich werde versuchen das alles mal umzusetzen... Wird wahrscheinlich aber erstmal ne Weile dauern

_________________
Rock is a message.
Hear the message an you will rock!

Dabei fallen mir grade nochmal eine Frage ein:

Wie ist denn der Zusammenhang zwischen Integern und Singles bei OpenGL. Es gibt ja einmal die Möglichkeit glVertex3f(x,y,z) zu verwenden und einmal glVertex3i(x, y, z). Aber wie kann ich den eine "Kommazahl" als Ganzzahl benutzen?

_________________
Rock is a message.
Hear the message an you will rock!

Normalerweise werden die umgerechnet. und zwar so, dass
minimalerIntegerWert = 0.0 und
maximalerIntegerWert = 1.0

sind.

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

Meinst du damit, dass 32767 z.B. einer 0.0 und eine 32768 einer 1.0?

_________________
Rock is a message.
Hear the message an you will rock!

ich würde eher sagen 0 zu 0.0 und 32768 zu 1.0
irgendein Wert wird dann so umgerechnet: 1.0/32768*wert

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

Schön. Aber was wäre dann mit Werten wie 4.65 beim tranformieren der Matrizen?

Tut mir leid, wenn ich euch mit so doofen Fragen löchere, aber ihr wisst ja, wer nicht fragt bleibt dumm

_________________
Rock is a message.
Hear the message an you will rock!

Wenn man Vertex Programme und dann die allgemeinen Vertex Attribute anstelle von Texture Koordinaten,Farbe,Normale usw.. verwendet, kann man jeweils angeben, ob der Wert direkt genommen oder auf [-1..1] bzw. [0..1] für Byte Werte normalisiert werden soll.