Zeit für gl...Pointer
-
Das is etz aber ärgerlich
-
Hm, was ist ärgerlich? Nimm ne DisplayList, dann gibts nix mehr zu beschleunigen. Lies mal, was ne DL ist, und was gl..Pointer macht, dann erübrigt sich Deine Frage sowieso...
-
Jo, weiss ich schon was des is, ich hab des von hellihjb beim ersten Lesen so verstanden, dass DLs die Geschwindigkeit nicht erhöhen, mein Fehler.
-
Noch was:
Display Listen brauchen ja viel Speicher, und man kann ja nicht jeden Frame mehrere Male gl...Pointer() aufrufen. Wäre es dann nicht schlauer, es doch über glBegin()...glEnd() abzuwickeln?
So wird es ja auch in Quake2 gemacht.
-
Display Listen brauchen ja viel Speicher
warum?
man kann ja nicht jeden Frame mehrere Male gl...Pointer() aufrufen
warum?
-
zu Warum Nummer 1:
Weil die ganzen Vertexdaten ja auch in die Liste einkompiliert werden, was bei vielen Vertices ja ganz schön Speicher frisst.zu Warum Nummer 2:
Hab ich mal gemacht, dann hats aber geruckelt wie Currywurst. Deswegen.
-
1. die display-liste enthaellt die selben vertex-daten die du rein getan hast.
davon liegt eine "kopie" im grafikspeicher und eine, fuer den fall dass die grafikkarte mal voll ist, im hauptspeicher - fuer gewoehnlich kein besonderes problem.2. alle daten die du in einem begin-end-block angibst, werden sowieso erstmal in einem buffer gesammelt. wenn du diesen buffer selber zur verfuegung stellst und per gl...Pointer() uebergibst, hast du dadurch nur vorteile.
wenn's dadurch langsamer geworden ist, hast du irgendwas grundlegendes falsch gemacht - oder ne ati-karte.
-
Ok, gut, wenn Speicher kein Problem darstellen sollte benutze ich DLs
und mach ich es einfach ohne gl...Pointer-Aufrufen jeden Frame.
Danke!
-
hellihjb schrieb:
ohne weiteres spart dir gl...Pointer nur die einzelnen api-aufrufe des glbegin-blocks.
die vertex-daten werden aber weiterhin aus dem hauptspeicher uebertragen.
dagegen helfen die extensions fuer vertex-buffer-objects.Ich habe mal die exe davon gestartet. Das läuft so ca. eine Sekunde lang schön flüseig und dann gibt es nen Aussetzer für ne viertel Sekunde usw.
Woran liegt das? Wenn dfas meine Hardware überfordern würde, müste es doch "gleichmäßig" ruckeln und nicht schön laufen und dann ganz aussetzten?
Getestet mit :
AMD Athlon 3000+
Geforce 4200
(Ich habe neueste Treiber und sonst nie Probleme mit Ruckeln)Edit. Im Fenstermodus sieht man die FPS und da habe ich 85
-
hellihjb schrieb:
2. alle daten die du in einem begin-end-block angibst, werden sowieso erstmal in einem buffer gesammelt. wenn du diesen buffer selber zur verfuegung stellst und per gl...Pointer() uebergibst, hast du dadurch nur vorteile.
wenn's dadurch langsamer geworden ist, hast du irgendwas grundlegendes falsch gemacht - oder ne ati-karte.Oder ne ATI-Karte?
Warum?
-
Oder ne ATI-Karte?
die grafikchips von ati bilden intern die strukturen von direct3d ab.
einiges der opengl-funktionalitaet muss darum im treiber konvertiert werden.
bei alten treibern (zur zeit von radeon8500) hatte das teilweise erhebliche geschwindigkeitseinbrueche zur folge - mittlerweile hat sich das aber alles erheblich verbessert.
trotzdem kann man die performance noch immer mit leichtigkeit halbieren wenn man - versehentlich - einen code-pfad im treiber erwischt, dem noch nicht sonderlich viel aufmerksamkeit geschenkt wurde.