SDL - wenig Frames

[the_brain]

Hi, ich programmiere ein Spiel mit SDL - tilebasierend.
( http://www.lanadminsystem.de/cgi-bin/Lanas.pl?OPENANNO )

Dabei habe ich das Problem, dass ich einfach nicht genug Frames bekomme.
Zur Zeit ist es so, dass ich jedes einzelne Tile auch einzeln Blitte (denn ich will die schließlich später auch noch animieren) - das scheint aber ewig zu dauern. Hat jemand ne Idee wie ich blitts reduzieren kann?

[Simeon]

Ich hab gute Erfahrungen damit gemacht nicht die Buffer zu swapen sondern nur das was neugezeichnet wird mit SDL_UpdateRect(screen,x1,y1,x2,y2); upzudaten um mehr performance rauszuschinden.

[the_brain]

also bei jedem blit ein update des rect?

[the_brain]

wenn ich das so mache, flackert der bildschirm ständig....

[SeeksTheMoon]

ich kenne mich jetzt null mit SDL aus; verwendest Du einen DoubleBuffer? Dann sollte das Flackern verschwinden.

[the_brain]

ja, den verwende ich - daran kanns nicht liegen - wenn ich nach allen blits die ich im laufe eines frames so machen den kompletten screen mit sdl_flip update, dann flackert es ja auch nicht - nur wenn ich nach jedem blit sdl_updateRect mache

[`kk]

In welcher Reihenfolge machst du das?
Ich wuerde erst die Rects updaten und dann Flippen.
Ansonsten weiß ichs auch nicht. :)

[Lin728]

Was mich interressieren würde ist. ob du die Tiles nach dem Laden schon ins Displayformat konvertiert hast.

Ich hab noch so ein altes Loki-Buch über SDL zu Hause, worin beschrieben wurde dass man um gute Performance zu erreichen die Tiles zuerst ins Displayformat konvertieren muss. Leider weiß ich den Funktionsnamen nicht auswendig :-(

[the_brain]

ja, ich konvertiere die surfaces mit SDL_DisplayFormat(Alpha)
erst update ich das Rect und dann flippe ich (aus... :-D) den bildschirm (bzw. den speicher)

schade - falls jemand mal nen blick in den source werfen will, der ist auf www.lanadminsystem.de in der downloadsektion zu haben (manchmal ist er auch in der aktuellen techdemo integriert - falls nicht, ist er einzeln downloadbar)

vielen dank für die bisherigen vorschläge - leider hat keiner geholfen - vielleicht bin ich ja einfach zu blind um etwas zu finden.

weiss vielleicht jemand, wie man unter linux seinen code profilen kann? es gibt doch tools, die messen wie lange sich ein programm in welcher funktion aufhält.... gibts sowas für linux?

gruss
martin

[bischi]

Das Vorgehen, das du beschreibst, ist richtig, wenn du kein Flackern willst (im Hintergrund zeichnen, nachher swappen - aka Doppelbufferung). Kann es sein, dass du unter Linux einfach keinen (guten) Grafikkartentreiber installiert hast? Ich kann beispielsweise auf meinem Laptop CS2 in anständiger Auflösung spielen(unter Windows) und habe (unter Linux) beim Tuxracer 3Frames/Sec...

MfG Bischi

[Lin728]

@Bischi: Tuxracer ist ein OpenGL-Spiel welches ohne OpenGL beschleuningung net ordentlich laufen kann. Bei 2d-spielen ist das meist anders -

Verwendest du Bilder mit ColorKey(Transparenz) oder Alpha-Kanal? Alpha-Bilder auf X-basierenden Platformen is sowieso ein bisschen ein dont -woweit ich weiß unterstützt SDL die RENDER extension noch nicht. Wenn ja, verwendest du RLE?

[bischi]

@Bischi: Tuxracer ist ein OpenGL-Spiel welches ohne OpenGL beschleuningung net ordentlich laufen kann. Bei 2d-spielen ist das meist anders - da ein paar bilder blitten schon die grindigsten Treiber hinbekommen.
Hinbekommen schon - aber geschwindigkeitsmässig? Weisst ja nicht, wie das im Hintergrund von sdl aussieht (ich zumindest nicht) - war nur so ne Idee - ich würds zur Sicherheit mal noch auf ner anderen Plattform testen, bevor ich nen riesigen aufwand betreiben würde, falsche Schuldige zu finden ;)

MfG Bischi

[the_brain]

hehe - unter linux rennt das bei mir (auf meinem 2100+) mit 50-60 frames - unter windows wurde mir von einigen leuten eine framerate von 5 gemeldet (unter macos auch nicht besser).

bei der linuxversion hat es schon einigen leuten geholfen die binaries selber zu bauen - aber so ein sprung kann doch trotzdem nicht sein - das spiel sollte doch locker auf nem 500mhz rechner ohne 3d-karte laufen.