Mh also ich kenn das so das integer 2=2 ist und single 2 auch 2 ist.
Also das single genauer ist aber halt viel früher seine grenze erreicht.
So zumindestens würde ich es interpretieren, da wenn ich ne transformation mache von 1 in richtung x es auch wirklich nur um 1 in richtung x transformiert wird und wenn ich ne transformation von 0.4 mache ist das auch ne transformation von 0.4.
Ao zumindestens bei normalen vectoren richtungsvectoren sind ja eh auf 1 normalisiert also maximaler integer ist 1 und minimaler ist -1. Kannst ja mal in nen wiki gucken sollte bestimmt schon was drin stehen sonnst googlen und rein schreiben ^^
MfG TAK2k4

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

Projekte: https://github.com/tak2004

Ich würde in dem Punkt TAK2004 auch zustimmen, denn diese Festlegung des Bereiches macht nur bei zum Beispiel Farbwerten Sinn. Dort würde dann zum Beispiel bei einem Aufruf von glColor3bu der Wert 255 auf 1.0 abgeändert.

MfG
Flo

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

Guck mal ins Wiki bei glGetFloatv. Wenn du einen Integerwert damit abfragst, wir er entsprechend gemappt. Daher kam meine aussage.

Und mit Min war tatsächlich -32k gemeint. Denn du würdest sonst (bei 0 startend) ja die hälfte deiner genauigkeit einbüsen.

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

So, tatsächlich habe ich auf mehreren Seiten gefunden, dass z.B. float(2.0) tatsächlich integer(2) entspricht. Ist diese Aussage richtig, stellt mich dass vor das Problem: Wie soll ich dann z.B. ein translate(0.3, 0.4, 0.9) mit Integern ausführen.
Einzige Möglichkeit wäre doch dann alles in einser Schritten darzustellen, was die Sache meiner Meinung nach unnötig groß macht. (Jeder von uns weiß, wie groß ein 1.0x1.0 Quadrat groß ist, wenn man es nicht weit nach Z reinschiebt)
Im Prinzip ist also ein Integer extrem ungenau, was das Zeichnen angeht. Denke ich jedenfalls so.

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

Ja beim verschieben stimmt das wohl auch so. Da kann man halt nur ganzzahlig verschieben. Wer Kommazahlen will muss halt die Floatversion benutzen. (Nur dafür existieren diese ja). Wenn man allerdings z.B. die aktuellen Farbwerte als Integerzahl durch glGetIntegerv liefern läßt, werden sie so wie's gesagt wurde in den Bereich min..max abgebildet.

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

Hmmm.. Naja. Ich denke es reicht auch so langsam mit dem optimieren. Hab nämlich grade eben alles kaputtoptimiert *g*
Für meine Verwendungszwecke muss ich auch nicht unbedingt so viele Partikel haben. Ich wollte halt nurmal die Grenzen des Systems ausloten und evtl. erweitern.

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

Da stellt sich mir die Frage, ob es irgendeinen (Geschwindigkeits-)Vorteil bringt, wenn ich glTranslatei(1, 1, 1) anstelle von glTranslatef(1.0, 1.0, 1.0) schreibe, oder ist das bloß Spielerei?

edit: Selber denken macht klug, soweit ich weiß wirds wohl nen kleinen Vorteil geben, da Integerwerte direkt über Register übergeben werden, Floatwerte nur über den Stack.

_________________
...die Idee ist gut, doch die Welt noch nicht bereit...

Bei dem "reparieren" von meinem Quelltext hab ich jetzt eine sehr interessante Entdeckung gemacht. So bald die Framerate absinkt und ich die Maus bzw. das Mausrad zum zoomen bewege, steigt die Framerate. Zuerst dachte ich, dass ist deswegen, weil ich rauszoome und der quasi weniger berechnen muss. Aber nach dem ranzoomen in Grundstellung blieb der ne ganze Weile noch auf 60FPS, bevor der wieder abgesunken ist.
Kann es sein, dass Windows irgendwie Prozessorleistung oder so von dem Programm abzieht und wieder zuteilt, sobald ich irgendeine "Interaktion" ausführe?

Und dann noch eine Frage:
Wie kann ich VSync ausschalten? Unter DOS mit Assembler weiß ich es. Aber das zeigt bei meinem XP irgendwie 0 Wirkung und endet meistens mit einer Fehlermeldung.

EDIT
@dopefish:
Ja, tatsächlich bringt es was. Denn die CPUs können (wie zuvor bereits jemand erwähnt hat) Ganzzahlen schneller abackern als so zerkrutzte Kommazahlen. Obwohl bei modernen Prozessoren kaum noch ein Unterschied vorhanden ist (*g* hab ich in meinem Hardwarebuch gelesen)

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

@Komma vs Ganzzahl
Ich hab hier ein tolles assembler buch und hab mal ein kurzen blick reingeworfen.
Also es kommt drauf an wenn alle mathematischen berechnungen über die FPU gehen dann sind nur unterschiede zwischen 32,64 und 80 Bit Variablentypen zu merken aber zwischen fließkomma und Ganzzahlen nicht. Die ALU beherscht keine Kommarechung und ist nur für ganzzahlen aber ob dort rechnungen schneller oder langsamer als auf der FPU sind stand nicht drin :/. Also merke es kommt nicht drauf an ob komma- oder ganz-zahlen sondern auf variablengrösse.
Wenn man ein datentyp nutzt der 16Bit dick ist wird die FPU mit 80Bit(standardmässig wird höchste prezision genommen dauert auch am längsten) rechnen und dann mit ein grossen genauigkeitsverlust ihn in die 16Bit quetschen. Also einfach mal googeln wie der Befehl aus der math unit lautet um die Präzision einzustellen.
Es ist auch möglich der FPU zu sagen wie gerundet werden soll dafür gibs 4 modis mit unterschiedlicher geschwindigkeit(1)>5 aufrunden und <5 abrunden 2)immer abrunden 3)immer aufrunden 4)abschneiden). Wer noch ein bischen mehr wissen will hab mich mal heut ein bischen zum Thema FPU eingelesen und kann vieleicht auch noch ein paar fragen zum diesem Thema beantworten.

@Partikelsystem
Ich denke das es ausreicht an optimierung man muss ja nicht übertreiben aber eine möglichkeit wäre noch dein code mal compilieren zu lassen und dem compiler anweisen nicht den asm code zu löschen dann kannst dich auf die suche nach dem heiligen Gral machen und vieleicht ein paar schritte durch eigene asm Pasagen zu ersetzten. Heutige Compiler sind keine Perfekten ASM interpreter und irgendwas machen die immer schlechter als möglich.
MfG TAK2k4

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

Projekte: https://github.com/tak2004

http://wiki.delphigl.com/index.php/GlGetFloatv
Also ich weis nicht wie du darauf kommst....

Und um das mal klar zu stellen:
Die Übergabe von Integerwerten an OpenGL, statt Fließkommer Werten macht wenig Sinn da, da OpenGL sowieso mit Fließkommerzahlen rechnet (z.B.: Matrizen).

Im schlechtensten Fall ist also glVertex3i sogar langsamer als glVertex3d.(Ich vermute mal das OpenGL mit dem Typ Double rechnet)

MfG
Flo

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

Siehe hier:


(Das weiß ich, weil ich das übersetzt hab )

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

bei mir ist das manchmal so das wenn ich den mauszeierg schnell über den windows start button hin und her bewege Delphi anwendungen manchnmal deutlich schneller arbeiten... vieleicht sendet dann windows mehr events raus und onidle wird öfters aufgerufen oder so...

Die Frage ist, ob es möglich ist, dem Programm so viel "Priorität" oder was auch immer zu geben, dass es nicht langsamer wird. Da ich als alter DOS Hase relativ wenig Plan der Windows Interna habe wäre es sehr interessant zu wissen, ob das geht. Hab zwar schon von Prozesspriorität gelesen, aber ich weiß nicht, ob das was damit am Hut hat. Ich will das ja auch nicht als "wichtigste Anwendung im System" laufen lassen. Halt nur.... ähh schneller

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

Habe gerade eine Erfahrung der besonderen Art gemacht.
Habe meine Parikeldemo mit FPC kompiliert bekommen und erreiche selbst bei fast doppelter Anzahl Partikel immernoch ein besseres Ergebnis als mit Delphi. Ist das nicht der Hammer?

DANKE AN TAK2004, der mich erst auf die Schiene von FPC gebracht hat

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

Kleiner tipp wenn dein Partikelsystem mit noch mehr FPS sehen willst schmeiss mal ne Fedora Core 3 OS auf dem PC und lass es mal von cedega emulieren.
Ohne Scherz meine alte Leveldemo mit Physik,Player und so weiter war unter Fedora mit emulieren schneller als unter winxp. Wobei zu sagen ist ich hatte sogar noch mit der GF5200 mehr FPS als mit der 5600XT unter XP. Nun arbeite ich mit mit SDL und muss nicht mehr emulieren und hab noch ein bischen mehr FPS dazu bekommen. Das tolle an FPC ist das ich zuhause unter mein XP progge und in der schule auf mein Notebook mit Fedora code und ich es immer gleich sehe was ich codee. Unter Delphi und Kylix ist dies auch möglich aber nicht ohne ein gewissen Konfigurationsaufwand. Was ich aber von Delphi her vermisse ist das ich bei Proton und VI keine Syntaxverfolständigung mehr habe und so alle befehle und strukturen auswendig wissen muss .
Kleiner tip bei FPC wird ein Tool namens UPX mit geliefert dieses sorgt für ein entschlacken von Windows Binarys und DLLs.
Einfach in einer Shell mal "upx -h" eingeben dann bekommst die syntax zum Tool und kannst es so um ca 40% Kompremieren.
MfG TAK2k4

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

Projekte: https://github.com/tak2004