Autor |
Beitrag |
Xion
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Mo 29.11.10 23:24
Hi,
folgender Code:
Delphi-Quelltext 1: 2: 3: 4: 5: 6:
| for X:= 0 to 142 do for Y:= 0 to 4*48-1 do begin OpenGL.SwitchColor(X/200,Y/200,0,1); OpenGL.Paint2DPixel(X,Y); end; |
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
| procedure TOpenGL.SwitchColor(R,G,B,Alpha: single); begin glColor4f(R,G,B,Alpha); end;
procedure TOpenGL.Paint2DPixel(X: Integer; Y: Integer); begin glBegin(GL_POINTS); glVertex2i(x, VRenderTo.ClientHeight-Y); glEnd(); end; |
ausgeführt auf meinen alten Notebook: 20ms (siehe Fenstertitel).
ausgeführt auf dem PC meines Vaters : 100ms (dabei hat der viel mehr Rechenleistung und ne viel bessere Grafikkarte)
An sich ist ja selbst 20ms schon zu viel für 143x192 Pixel. Die Leistung ist meist nicht das, was ich von OpenGL erwarten würde. Aber der enorme Unterschied bei einer so einfachen Funktion ist doch enorm. Selbes Problem übrigens beim Zeichnen von Rechtecken.
Denkbar dass es irgendeine Einstellung im Grafikkartentreiber ist (nix gefunden). Aber selbst mit der übelsten Eintellung sollte doch die Grafikkarte die paar Punkte in weniger als 100ms zeichnen können? Das hätten die Grafikkarten ja schon vor 10 Jahren leicht geschafft. Ich vermute daher dass ich da in OpenGL was falsch mache. Wenn sich also jemand mit auskennt, immer her mit den Tipps
//Edit:
Mir ist klar dass man einen Farbverlauf anders zeichnet. Ich zeichne hier normal (nach einer komplexen Berechnung von 20ms) ein 2D-Float-Array.
//Edit2:
Also wenn ich nur einmal glBegin/glEnd mache, bin ich gleich ne Ecke schneller  Macht sich nur dann nicht so schön als procedure...
Einloggen, um Attachments anzusehen!
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Jann1k
      
Beiträge: 866
Erhaltene Danke: 43
Win 7
TurboDelphi, Visual Studio 2010
|
Verfasst: Mo 29.11.10 23:52
Problem könnte hier sein, dass du für jeden einzelnen Punkt glBegin und glEnd erneut aufrufst, versuch mal deinen Code derart umzugestalten:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8:
| glBegin(GL_POINTS); for X:= 0 to 142 do for Y:= 0 to 4*48-1 do begin SwitchColor(X/200,Y/200,0,1); glVertex2i(x, Y); end; glEnd(); |
Im DGL-Wiki wird glBegin(GL_POINTS) als langsam beschrieben, vielleicht wäre es sogar schneller anstatt der Punkte ganz kleine GL_QUADS zu zeichnen.
Edit: Sehe gerade, dass du das für Rechtecke schon ausprobiert hast.
|
|
Bergmann89
      
Beiträge: 1742
Erhaltene Danke: 72
Win7 x64, Ubuntu 11.10
Delphi 7 Personal, Lazarus/FPC 2.2.4, C, C++, C# (Visual Studio 2010), PHP, Java (Netbeans, Eclipse)
|
Verfasst: Di 30.11.10 00:12
Hey,
Quads sind nicht schneller als Punkte, weil man dann 4 Vertex übergeben muss. Ich denke eher, dass das Prblem hier der CPU ist. Die schleife wird immer noch auf dem CPU ausgeführt, und wenn der langsam ist, dann is die Zeichenroutine halt auch langsam. Kann das hinkommen? Hat dein Notebook nen bessreen CPU als der PC von deim Vater?
Wenn du wirklich werd auf Performance legst, dann solltest du die VBOs (Vertex Buffer Objects) angucken. Da werden die Daten auf der grafikkarte abgelegt und können beim zeichnen gleich von dort abgerufen werden.
Wenn du unbedingt eine Prozedur haben willst, dann übergib der Prozedur dein Array und Zeichne alles in der Prozedur. Eig. hast du der OpenGL-Prozedur ja auch nur nen anderen Namen gegeben.
€: was mir grad noch einfällt: wie misst du die Zeit? Einfach mit GetTickCount? Weil das sehr ungenau ist, da sollte man lieber zu QueryPerformanceCounter greifen.
MfG Bergmann
_________________ Ich weiß nicht viel, lern aber dafür umso schneller^^
|
|
Xion 
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Di 30.11.10 09:16
Bergmann89 hat folgendes geschrieben : | Hat dein Notebook nen bessreen CPU als der PC von deim Vater? |
Nee, auf jeden Fall nicht. Hab hier aufm Notebook einen Intel Pentium M mit 1.6GHz. Mein Vater hat nen Dual Core (ok, ich nutze nur einen davon) aber der hat definitiv mehr Leistung. Bei der Berechnung davor ist er auch deutlich schneller.
Bergmann89 hat folgendes geschrieben : | Da werden die Daten auf der grafikkarte abgelegt und können beim zeichnen gleich von dort abgerufen werden. |
Ich hab das jetzt noch nicht angeguckt, aber da sich die ganze Fläche jedesmal ändert muss ich doch so oder so alles übertragen.
Bergmann89 hat folgendes geschrieben : | €: was mir grad noch einfällt: wie misst du die Zeit? Einfach mit GetTickCount? Weil das sehr ungenau ist, da sollte man lieber zu QueryPerformanceCounter greifen. |
Das mag ungenau sein, aber Faktor 6 ist ja doch eindeutig und außerdem ruckelt es bei meinem Vater, also das ist schon eindeutig.
Das mit dem auslagern von glBegin,glEnd bringt knapp 50%  Aber die Differenz von Faktor 6 bleibt.
//Edit:
Mein Beginn des Zeichnens sieht so aus:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17:
| procedure TOpenGL.InitDraw; begin glClearColor(0,0,0,0); glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT); glMatrixMode(GL_PROJECTION); glLoadIdentity; gluPerspective(45.0, VRenderTo.Width/VRenderTo.Height, NearClipping, FarClipping); glMatrixMode(GL_MODELVIEW); glLoadIdentity;
glEnable(GL_NORMALIZE); glEnable(GL_DEPTH_TEST);
LightsCount:=0;
glLightModelfv(GL_LIGHT_MODEL_AMBIENT, @light_model_ambient[0]); end; |
Das dauert zwar nicht lange aber vielleicht ist da irgende eine Einstellung, die mir dann das 2D-Zeichnen unnötig verlangsamt. Hab grad keine Zeit, werde das heute Abend mal durchchecken. Da ist natürlich jetzt auch 3D-Zeug dabei, aber ich rufe vor dem 2D Zeichnen immer erst noch folgendes auf:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9:
| procedure TOpenGL.SwitchTo2DMode; begin glDisable(GL_LIGHTING); glMatrixMode(GL_PROJECTION); glLoadIdentity; glOrtho(0,VRenderTo.ClientWidth,0,VRenderTo.ClientHeight,0,-1); glMatrixMode(GL_MODELVIEW); glLoadIdentity; end; |
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Bergmann89
      
Beiträge: 1742
Erhaltene Danke: 72
Win7 x64, Ubuntu 11.10
Delphi 7 Personal, Lazarus/FPC 2.2.4, C, C++, C# (Visual Studio 2010), PHP, Java (Netbeans, Eclipse)
|
Verfasst: Di 30.11.10 14:24
Hey,
glEnable(GL_NORMALIZE); ist sehr langsam, man sollte wenn möglich darauf verzichten und die Daten lieber per Hand normalisieren. Das brauchst du ja auch nur für die Normalen beim Licht, oder? Is dein light_model_ambient ein Array aus 4 Integer, oder aus 4 Float werten? Bei Integer-Werten muss OpenGL das nochma umrechnen, die Float-Werte übernimmt es glaub ich gleich so.
Was noch interessant wäre: Was haben die beiden PCs für ne Grafikkarte? Sind die neusten Treiber installiert?
Ich komm zum Bsp auch nur auf 30ms (mit der Version in deinem Beitrag oben). Ich hab nen Phenom II T1090 un ne HD5970. Treiber sind auch aktuell. Könnte auch sein, das du irgendwas benutzt, was zu alt für die neuen Karten is und die Anwendung deshalb im Softwaremodus rendert.
Nochma zu der Sache mit den VBOs, die sind schneller, da du die Daten gleich auf die Karte schreiben kannst und nicht erst zwischenspeichern und dann beim Zeichnen übergeben musst. Oder du kannst die Daten alle auf einmal übergeben (mit glInterleavedArray, das is aber glaube in dem Tutorial zu den VBOs nochma erklärt). Das würde sich bei deinen Daten natürlich anbieten, da du sie ja eh schon in einem 2D-Float-Array vorliegen hast.
€: Noch ne Frage: wie bzw. wo misst du die Zeit?
MfG Bergmann.
_________________ Ich weiß nicht viel, lern aber dafür umso schneller^^
Für diesen Beitrag haben gedankt: Xion
|
|
Xion 
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Di 30.11.10 18:26
Bergmann89 hat folgendes geschrieben : | glEnable(GL_NORMALIZE); ist sehr langsam, man sollte wenn möglich darauf verzichten und die Daten lieber per Hand normalisieren. Das brauchst du ja auch nur für die Normalen beim Licht, oder? Is dein light_model_ambient ein Array aus 4 Integer, oder aus 4 Float werten? |
Ich arbeite ja garnicht mit 3D oder Licht in diesem Projekt (hab halt eine Klasse für beides)
Bergmann89 hat folgendes geschrieben : | Bei Integer-Werten muss OpenGL das nochma umrechnen, die Float-Werte übernimmt es glaub ich gleich so. |
Ja, da müsste ich nochmal nachgucken...wobei ich X und Y natürlich nicht als float habe, ist ja der Index eines arrays
Bergmann89 hat folgendes geschrieben : | Was noch interessant wäre: Was haben die beiden PCs für ne Grafikkarte? Sind die neusten Treiber installiert? |
Also ich habe hier auf dem Notebook (wo es schnell ist) eine ATI MOBILITY RADEON 7500. Auf meinem alten Notebook lief es auch schnell, da wurde aber seit 3 Jahren nix mit den Treibern verändert. Was bei meinem Vater drauf ist kann ich im Detail nicht sagen, es ist auf jeden Fall was ordentliches mit aktuellen Treibern, da laufen auch Spiele drauf. Auf meinem "Übergangsnotebook" war es auch übel langsam. Das hatte ich aber nur ca 1 Monat.
Bergmann89 hat folgendes geschrieben : | Ich komm zum Bsp auch nur auf 30ms (mit der Version in deinem Beitrag oben). Ich hab nen Phenom II T1090 un ne HD5970. Treiber sind auch aktuell. |
Tja auf meinem schwachbrüstigen Notebook sind es 10-20  Irgendwie komisch...aber der Unterschied ist nicht so extrem.
Bergmann89 hat folgendes geschrieben : | Könnte auch sein, das du irgendwas benutzt, was zu alt für die neuen Karten is und die Anwendung deshalb im Softwaremodus rendert |
Ja...aber ich benutze ja eigentlich garnichts...also Pixel zeichnen dachte ich immer ist so einfach, da kann man nichts falsch machen
Bergmann89 hat folgendes geschrieben : | Noch ne Frage: wie bzw. wo misst du die Zeit? |
Wie gesagt, ob die Zeit im Detail stimmt ist ja egal, der Unterschied ist auch ohne angezeigte Zeit deutlich (ok, hier nicht, die Farben sind ja statisch  )
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20:
| procedure TForm1.Timer1Timer(Sender: TObject); var t: cardinal; X,Y: integer; begin OpenGL.InitDraw; OpenGL.SwitchTo2DMode;
t:=GetTickCount;
for X:= 0 to 142 do for Y:= 0 to 4*48-1 do begin OpenGL.SwitchColor(X/200,Y/200,0,1); OpenGL.Paint2DPixel(X,Y); end;
Form1.Caption:=inttostr(GetTickCount-t); OpenGL.Draw; end; |
Der Timer hat ein Intervall von 25 = 40FPS (so in etwa...).
Der Vollständigkeit halber noch:
Initialisierung von OpenGL (einmal beim Programmstart) 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34:
| function TOpenGL.InitializeOpenGL(RenderTo: TWinControl): boolean; begin
Zeichenflaeche:= GetDC(RenderTo.Handle);
Result:=InitOpenGL;
RenderingContext:= CreateRenderingContext( Zeichenflaeche, [opDoubleBuffered], 32, 24, 0,0,0, 0);
ActivateRenderingContext(Zeichenflaeche, RenderingContext);
VRenderTo:=RenderTo;
glShadeModel(GL_SMOOTH); glClearColor(0, 0, 0, 0); glDepthFunc(GL_LEQUAL); glEnable(GL_DEPTH_TEST); glEnable(GL_CULL_FACE); glEnable(GL_LINE_SMOOTH); glClearDepth(1.0); glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST); InitQObj0;
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
NearClipping:=0.1; FarClipping:=1000; end; |
Draw 1: 2: 3: 4: 5: 6:
| procedure TOpenGL.Draw; begin glFlush; glFinish; SwapBuffers(Zeichenflaeche); end; |
//Edit:
VBO hat folgendes geschrieben: |
Da sich dieses Tutorial (und v. a. diese Methode der Vertexdatenübergabe) an die fortgeschritteneren wendet, |
Der Satz schreckt mich irgendwie ab  Ich hab eigentlich sehr wenig Ahnung von OpenGL und zeichne bestenfalls mal ne rotierte Textur wo hin oder ne Kugel. Vielmehr wie Rechtecke mit Texturen und Pixel brauch ich auch garnicht
//Edit2:
Ich hab jetzt mal das ganze auf 500x500 vergrößert, damit man mehr sieht. Da dauert es bei mir 120ms.
Einloggen, um Attachments anzusehen!
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Bergmann89
      
Beiträge: 1742
Erhaltene Danke: 72
Win7 x64, Ubuntu 11.10
Delphi 7 Personal, Lazarus/FPC 2.2.4, C, C++, C# (Visual Studio 2010), PHP, Java (Netbeans, Eclipse)
|
Verfasst: Di 30.11.10 19:12
AHA,
da is doch der Fehler. Mit nem Timer bekommt man NIE genaue Messungen. Mach das ganze mal im OnIdle, da zeichnet er dann so oft wie er kann. Am bessten mit QuerryPerformanceCounter, wie oben schon geschrieben. Da GetTickCount nur ne maximale Auflösung von 16ms hat wird das bei so kleinen Zahlen mehr als ungenau. Das ganze kann man dann begrenzen, in dem man vSync an macht, dann passt sich die CPU-Last an die benötigten Frames an.
Wenn du kein Licht benutzt, dann solltest du es auch nicht unbedingt anschalten und du brauchst auch kein glEnable(GL_NORMALIZE); Das is eig nur für die Normalen (jedenfalls fällt mir grad nix anderes ein). Schalte etwas nur an, wenn du es auch wirklich benutzen willst! Und danach sollte man es auch wieder ausschalten. Sonst kommt man schnell durcheinander, was an war und was nicht.
Von dem "Fortgeschritten" solltest du dich nicht abschrecken lassen, solange du die Matrix- und die grundlegenden Operationen verstanden hast und anwenden kannst, darfst du dich als fortgeschritten betrachten  Das Tutorial ist auch relativ simpel gehalten und erklärt wirklich nur das, was man zum erstellen eines VBOs benötigt. Mit den Dingern kann man weitaus mehr anfangen, als man auf den 1. Blick vermutet.
Die Initialisierung von OpenGL haut soweit hin, auch wenn das AA veraltet ist und nich wirklich funktioniert (jedenfalls ging es bei mir noch nie^^). Für "echtes" AA gibts es extra RenderContexte. Deine Zeichenprozedur verwirrt mich noch etwas, da wird ja gar nix gezeichnet?! Das eigentliche Zeichnen hast du ja schon im Timer gemacht, in der Draw-methode schließt du das Zeichenn nur ab...
MfG Bergmann
_________________ Ich weiß nicht viel, lern aber dafür umso schneller^^
Für diesen Beitrag haben gedankt: Xion
|
|
Xion 
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Di 30.11.10 19:46
Bergmann89 hat folgendes geschrieben : | Das ganze kann man dann begrenzen, in dem man vSync an macht, dann passt sich die CPU-Last an die benötigten Frames an. |
Ui, hübsch, wie schalte ich denn vSync an? Hab gelesen das macht das glFinish im .Draw, aber das tut es scheinbar nicht, hab zumindest keinen Unterschied bemerkt (getestet auf nem Röhrenmonitor).
Auch wenn die Zeit ungenau ist, so ist doch die Tatsache trotzdem, dass es bei meinem Vater ruckelt, und bei mir nicht
Bergmann89 hat folgendes geschrieben : | Von dem "Fortgeschritten" solltest du dich nicht abschrecken lassen, solange du die Matrix- und die grundlegenden Operationen verstanden hast und anwenden kannst, darfst du dich als fortgeschritten betrachten |
Hehe, gut. Matrizen kommen mir schon zu den Ohren raus, die brauchen wir öfters im Studium
Bergmann89 hat folgendes geschrieben : | Deine Zeichenprozedur verwirrt mich noch etwas, da wird ja gar nix gezeichnet?! Das eigentliche Zeichnen hast du ja schon im Timer gemacht, in der Draw-methode schließt du das Zeichenn nur ab... |
Genau, es soll halt das fertige Bild auf den Monitor "gezeichnet" werden. Vielleicht der falsche Name dafür 
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Bergmann89
      
Beiträge: 1742
Erhaltene Danke: 72
Win7 x64, Ubuntu 11.10
Delphi 7 Personal, Lazarus/FPC 2.2.4, C, C++, C# (Visual Studio 2010), PHP, Java (Netbeans, Eclipse)
|
Verfasst: Di 30.11.10 19:53
Hey,
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12:
| procedure gluSetupVSync(const Enable: Boolean); var i : integer; begin if WGL_EXT_swap_control then begin i := wglGetSwapIntervalExt; if enable then begin if i <> 1 then wglSwapIntervalExt(1); end else begin if i <> 0 then wglSwapIntervalExt(0); end; end; end; |
Hab noch was gefunden, was dir helfen könnte. Du brauchst nichmal ein VBO, du kannst die Daten auch dirket aus dem RAM in den VRAM übergeben:
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39:
| type TVertex = packed record r, g, b, a: gluByte; x, y: glFloat; end;
var arr: array of TVertex;
procedure InitArray; var x, y, ID: Integer; begin SetLength(arr, 500*500); for x := 0 to 499 do for y := 0 to 499 do begin ID := 500*x + y; arr[ID].x := x; arr[ID].y := y; arr[ID].r := x * 255 div 500; arr[ID].g := y * 255 div 500; arr[ID].b := 0; arr[ID].a := 255; end; end; procedure Render; begin glClearColor(0,0,0,0); glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
glMatrixMode(GL_MODELVIEW); glLoadIdentity;
glInterleavedArrays(GL_C4UB_V2F, 0, @arr[0]); glDrawArrays(GL_POINTS, 0, Length(arr));
SwapBuffers(RC.DC); end; |
so läuft es bei mir mit knapp 700FPS. Wenn ich es mit glBegin und glEnd mache komm ich maximal auf 80 oder so. Ein VBO verspricht natürlich noch mehr Leisting, aber ich glaub das sollte so erstma für dich ausreichen, oder?
€: ändert sich bei deiner Berechnung eig nur die Farbe des Vertex, oder auch seine Position? Bzw. was is der Sinn des Ganzen?!
€2: ohne die Hardware deines Vaters zu kennen lässt sich das schlecht ein Fehler finden
MfG Bergmann
_________________ Ich weiß nicht viel, lern aber dafür umso schneller^^
Für diesen Beitrag haben gedankt: Xion
|
|
Xion 
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Di 30.11.10 20:13
Bergmann89 hat folgendes geschrieben : | so läuft es bei mir mit knapp 700FPS. Wenn ich es mit glBegin und glEnd mache komm ich maximal auf 80 oder so. Ein VBO verspricht natürlich noch mehr Leisting, aber ich glaub das sollte so erstma für dich ausreichen, oder? |
 Das ist ja mal geil, das muss ich sofort mal testen *sabber*
Bergmann89 hat folgendes geschrieben : | ändert sich bei deiner Berechnung eig nur die Farbe des Vertex, oder auch seine Position? Bzw. was is der Sinn des Ganzen?! |
Ich hab eine "FlowEngine" geschrieben. Am einfachsten: Ich hab ne Rechteckfläche, tropfe dort eine Farbe rein und die verläuft. Dann kann man noch Wände rein ziehen. Im konkreten Fall jetzt hab ich Partikel dort reingefüllt und schütte schwarze Farbe rein, wo gerade die Maus drüber steht  Will demnächst ein Spiel beginnen, und da hab ich mir gedacht, wenn ich es nichtmal schaffe 30k Pixel zu zeichnen, dann sollte ich mich erst schlau machen und nicht erstmal anfangen und dann feststellen, dass es anders viel besser ginge  [/quote]
Ich werd das jetzt mal einbauen, dann lad ich das ganze mal hoch...boah wenn das wirklich so schnell ist... *im Staub kriech* 
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Bergmann89
      
Beiträge: 1742
Erhaltene Danke: 72
Win7 x64, Ubuntu 11.10
Delphi 7 Personal, Lazarus/FPC 2.2.4, C, C++, C# (Visual Studio 2010), PHP, Java (Netbeans, Eclipse)
|
Verfasst: Di 30.11.10 20:35
Hey,
wenn sich wirklich nur die Farben ändern gehts noch schneller, wird aber dementsprechend etwas komplizierter. Geht zwar auch noch alles über den hauptspeicher (auch wenn VBOs dann hier wirklich sinnvoller sind) aber man muss dann die Position der Vertex von den Farben trennen und OpenGL sagen wo was liegt. Dann muss man nur noch die Farbwerte ändern und schon funktioniert das ganze super schnell ^^
MfG Bergmann
_________________ Ich weiß nicht viel, lern aber dafür umso schneller^^
|
|
Xion 
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Di 30.11.10 20:51
Hi,
also habs mal umgesetzt und in den Anhang gepackt(funktioniert immernoch per Timer, OnIdle hat auf Anhieb nicht geklappt). Die rot "schraffierte" Zone ist die berechnete.
Was genau sagt mir eigentlich der QueryPerformanceCounter? CPU-Takte? ("value of the high-resolution performance counter") Dann käme ich beim zeichnen (letzte Zahl) auf 1.6GHz/30k...hmm, zuviel FPS xD
Zu den Zahlen: Die erste ist reine Berechnung, die zweite ist das rüberschaufeln der Berechnung in das array (könnte man soweit umbauen, dass man das vielleicht nicht bräuchte) und die letzte dann das zeichnen an sich.
Auf jeden Fall ist es viel schneller geworden.
### Dateianhang gelöscht ###
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
Zuletzt bearbeitet von Xion am Di 30.11.10 21:13, insgesamt 1-mal bearbeitet
|
|
Bergmann89
      
Beiträge: 1742
Erhaltene Danke: 72
Win7 x64, Ubuntu 11.10
Delphi 7 Personal, Lazarus/FPC 2.2.4, C, C++, C# (Visual Studio 2010), PHP, Java (Netbeans, Eclipse)
|
Verfasst: Di 30.11.10 20:56
Hey,
was geben die Zahlen an? Bei mir schwanken die um 20000...
QueryPerformaceCounter hängt von Takt ab, richtig. Deshalb muss man ja auch durch die Frequenz Teilen, um die richtige Zahl in ms zu bekommen. Ich komm damit annährend bis auf eine Millisekunde genau hin. Läuft es bei deinem Vater jetz immer noch langsamer als bei dir?
MfG Bergmann
_________________ Ich weiß nicht viel, lern aber dafür umso schneller^^
|
|
Xion 
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Di 30.11.10 21:06
Bergmann89 hat folgendes geschrieben : | was geben die Zahlen an? Bei mir schwanken die um 20000... |
 das ist der ungeteilte QueryPerformanceCounter
Bergmann89 hat folgendes geschrieben : | Läuft es bei deinem Vater jetz immer noch langsamer als bei dir? |
Das weiß ich wohl erst morgen oder so, erstmal per Mail rüberschicken usw.
Ich hab jetzt 22|2|8
Also 8ms statt 120ms ist schonmal nett  Damit könnte man problemlos den ganzen Bildschirm zumalen.
Werd mir die VBO wenn ich mal Zeit habe auch angucken.
Einloggen, um Attachments anzusehen!
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Bergmann89
      
Beiträge: 1742
Erhaltene Danke: 72
Win7 x64, Ubuntu 11.10
Delphi 7 Personal, Lazarus/FPC 2.2.4, C, C++, C# (Visual Studio 2010), PHP, Java (Netbeans, Eclipse)
|
Verfasst: Di 30.11.10 21:23
Ich hab 6|1|1 ^^
€: is deine Berechnung Timebased? Jetzt verlaufen die Farben viel schneller als vorher...
_________________ Ich weiß nicht viel, lern aber dafür umso schneller^^
|
|
Xion 
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Di 30.11.10 22:29
Normal ist die Berechnung schon timebased. Hatte hier einfach nur irgend einen festen Wert übergeben zum Testen...tztz, jede kleine Nachlässigkeit fliegt hier sofort auf
Wobei die Berechnung nur zu einem maximalen Wert timebased ist, also 10 Sekunden in einem Schritt geht nicht
Achja mein Vater hat:
18 | 3 | 3
Von daher, Problem bis zum letzten Zipfel perfekt gelöst 
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Bergmann89
      
Beiträge: 1742
Erhaltene Danke: 72
Win7 x64, Ubuntu 11.10
Delphi 7 Personal, Lazarus/FPC 2.2.4, C, C++, C# (Visual Studio 2010), PHP, Java (Netbeans, Eclipse)
|
Verfasst: Di 30.11.10 22:33
Gut zu wissen. Wenn du dann aus dem Proggi n Spiel gemacht oder das weiter entwickelt hast, lass ma von dir hören. Find das interessant, ma gucken was noch draus wird. Vlt haben wir bald ein neues Liquid War
MfG Bergmann
_________________ Ich weiß nicht viel, lern aber dafür umso schneller^^
|
|
BenBE
      
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Do 02.12.10 21:12
Kein Nerd-Sniping mit Spielen! 
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
Quake User
      
Beiträge: 159
|
Verfasst: Do 09.12.10 03:28
Wie Jann1k schon angemerkt hat, solltest Du nur EIN mal GLBegin und GLEnd aufrufen.
Dazwischen wird Ein volles Bild aufgebaut. Alles, was gemalt werden soll, muss vorab berechnet werden.
Punkte slltest Du in Punktlisten speichern.
Das ist ein systematischer Fehler in Deinem Programm.
|
|
|