Hi, der Titel sagt es ja bereits:

Ich hatte mit einem Projekt begonnen, es wird ein Cossacs, Warcraft 3 und Spellforce ähnliches Strategiespiel.
Alles logische klappte prima, aber die Framerate...
Naja, also habe ich nochmal von vorne angefangen, weil ich den Fehler auch nach tagelanger Suche im Quelltext einfach nicht finden konnte.

Aber: Selbst in der aller primitivsten Urversion geht die Framerate schon bei nur 2(!!!) Flächen von 140 auf 35 runter, bei 30 Flächen geht sie auf 9-13 runter.

Kann mir jemand erklären, warum das so dermaßen langsam ist?!?

Ich hab 2,4 GHZ, 256 MB DDR-RAM und eine OnBoard GraKa, an der es kaum liegen kann, da z.B. Call of Duty tadellos drauf läuft.

Ich render per OnIdle, habe Backface-Culling an und verstehe die Welt nicht mehr.

Danke für alle Antworten!

MFG gmgler

_________________
Geniale Menschen sind selten ordentlich, ordentliche selten genial (Albert Einstein)

Hochstwahrscheinlich wird OGL nur emuliert, d.h. keine Hardware-unterstützung. Du brauchst entsprechende Garka-Treibers vom Hersteller. CallOfDuty benuzt DirectX als schnittstelle, IMO.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Danke für die schnelle Antwort.
Aber warum ist die Framerate dann vorher bei 140?
Wenn keine Flaeche auf dem Bildschirm ist, aber alle Flächen nach wie vor gerendert werden, arbeitet OpenGl doch trotzdem?

(Sollte Sniper Recht haben, ist dieses Topic leider in der falschen Kategorie)

MFG gmgler

_________________
Geniale Menschen sind selten ordentlich, ordentliche selten genial (Albert Einstein)

Lass dir mal mit diversen Tool (oder per glGetString(GL_VENDOR)) ausgeben was du für eine OpenGL Implementation hast. Wenn da dann was mit Microsoft drinne steht, dann gibts an snipers Aussage keinen Zweifel mehr. Dann läuft nämlich alles in Software.

Wobei ich mich frage ob du da auch schon mal andere OpenGL Titel ausprobiert hattest? Wenn die nämlich liefen (oder als Vendor nicht MS auftaucht) und nur dein Program so komisch langsam ist solltest du uns mal ein bisschen Code zeigen. Aber denke mal auch, dass es an dem liegt was sniper gesagt hat.

[edit] Na ja. Ich denke mal, dass die Implementation recht schnell ausschließen kann ob eine Fläche sichtbar ist oder nicht. Und erst wenn sie überhaupt sichtbar ist muss der Rasterizer angesprochen werden, der dann die entsprechenden Bereiche füllt.

PS: Das mit dem Topic sollte kein Problem sein. Wobei es hier ja auch seine Berechtigung hat.

Hi, und wenn es nur als "Software" liefe, wie könnte ich das ändern?

Hab mal einen Screenshot von der Konfiguration meiner GraKa in Bezug auf OpenGl gemacht, vielleicht hilft das weiter?

MFG gmgler

_________________
Geniale Menschen sind selten ordentlich, ordentliche selten genial (Albert Einstein)

Ich kenne das gleiches Symtom von VIA onboardgrafikkarten. Ich hab den Treiber aktualisiert und dann auch noch festgestellt das selbst die basisfunktionen OGL1.0 nicht mal vollständig vorhanden waren. Die Power hielt sich in grenzen aber kam an ende mit DX gleich auf.
Wenn die Power am ende ist, kannst du auch noch die farbanzahl auf 8Bit runter schrauben und kleinere auflösungen wählen wobei erstes mehr bringen wird.
Wenn du SDL nutzt um ein fenster zu erstellen solltest du mal gucken ob er überhaupt ein fenster im Grafikkartenspeicher erstellt oder im ram. Da dieses auch unterschiede macht. Musst mal nach SDL_HWSURFACE und SDL_HWACCEL gucken und ob diese unterstütz werden findet man in SDL_GetVideoInfo.

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

Projekte: https://github.com/tak2004

Also, neuesten Treiber hab ich installiert, geht wesentlich besser, aber bei 100 flächen geht die Rate auf 12 runter. Ok? Schlecht? Sehr schlecht?

MFG gmgler

_________________
Geniale Menschen sind selten ordentlich, ordentliche selten genial (Albert Einstein)

Schon sehr schlecht, wenn man bedenkt, dass Call of Duty flüssig läuft. Benutzt du denn schon Texturen? Haben die eine zu große Auflösung, kann das zu Performance-Einbrüchen führen. Bei einer OnBoard-Karte dürfte da die kritische Grenze schon bei 256x256 liegen.

_________________
"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

Also 100 ist ein bisschen arg wenig. Zum Vergleich meine Uralte TNT2 kam mit 2000-4000 Flächen ganz gut klar. Aber alles darüber wurde schon kompliziert.

Ein OnBoard Chip ist im Vergleich zu einer richtigen Grafikkarte immer irgendwo beschränkt. Hinzu kommen dann noch solche Faktoren wie. Hat er eigenen Speicher oder benutzt er den RAM. Über was ist er mit dem RAM verbunden. PCI / AGP x / PCIe. Dann spielt nätürlich auch noch eine Rolle was der Chip überhaupt kann und wie Groß dein Fenster ist. Außerdem ist auch nicht unwichtig wie groß die Flächen sind. Um so größer die Flächen um so mehr muss der Chip machen.

Habe mir aber auch gerade mal ein paar Bilder von Cull of Duty angesehen. Also so schlecht sieht das ja auch nicht aus und eigentlich sollte da schon mehr als 300 Flächen dargestellt werden. Würde an deiner Stelle mal verschieden OpenGL Titel ausprobieren. Unreal (Tournament) würde sich da anbieten, da du zwischen OpenGL und D3D Renderer wählen kannst. Da gibt es bestimmt auch ne Demo von oder so. Einfach um mal zu sehen ob es jetzt an deinem Programm liegt oder ob bei dem Treiber die OpenGL Implementation einfach nur bescheiden ist. Was ist den das für ein Chip überhaupt?

Wenn es tatsächlich an einer schlechten OpenGL Implementation liegt, dann hast du schlechte Karten daran etwas ändern zu können. Außer du hältst nach einer richtigen Grafikkarte ausschau.

Hast du auch mal die GL-Fehler ausgewertet? Wenn OpenGL Fehler bemerkt kann das mitunter auch zu Frame-Einbrüchen kommen. Ich vermute aber auch mal, dass es am Treiber liegt.

Um den Hersteller deies Treibers heraus zu finden einfach mal diesen Befehl benutzen: http://wiki.delphigl.com/index.php/glGetString

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

Naja, Fehler gibt es keine, weil eigentlich nichts besonderes gemacht wird, ausser dass in einer Schleife 100 Flächen durchgegangen werden und mit textur(128*128) gerendert werden.

Die GraKa ist aber eine "INTEL EXTREM GRAPHICS" die OpenGl eindeutig unterstüzt, es gibt sogar einen seperaten Reiter für OpenGl-Einstellungen bei der Treibersoftware!

Was mich nur wundert, ist dass es bei Beispieldateien z.T. geht, zum Teil aber absolut langsam läuft.

Naja, danke, mehr kann ich nicht machen, ich hab den neuesten Treiber, und der wird auch nicht weiter verbessert, weil er, so INTEL "Bereits Optimal und Fehlerfrei liefe"

Naja, ich werd mir den Quelltext nochmal vornehmen, und wo möglich noch optimieren, wird schon klappen...

MFG gmgler

_________________
Geniale Menschen sind selten ordentlich, ordentliche selten genial (Albert Einstein)

Frühere Firma hatten wir Laptops mit Intel Chips. Die OpenGL Implementation in den Treibern ging zwar von der Geschwindigkeit her einigermaßen aber die hatten alle merkwürdige Randerscheinungen. Zu Not Poste mal deinen Code. Sonst würde ich sagen, dass der Chip nicht so dolle ist. Ist das eigentlich nen Laptop oder Desktop?

Es gibt auch direkt paar kleine Anwednungen die deine GL-Implementation mal durchleuchten und dir sagen was geht. Von wegen maximaler Texturgröße, anzahl Texturstages, welche Extensions, welche GL-Implementation, etc...

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

wie wärs denn, wenn du uns einfach mal eins deiner kompilate hier anhängst? dann können wir ja testen, wie es mit den fps bei uns aussieht.

_________________


"User Error. Replace User and hit Continue."