Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

[SFML] Spiel ruckelt stark. Hardwareproblem, Treiberproblem oder andere Ursache?

Werbeanzeige

Tenac

Frischling

  • »Tenac« ist der Autor dieses Themas

Beiträge: 7

  • Private Nachricht senden

1

16.04.2013, 15:08

[SFML] Spiel ruckelt stark. Hardwareproblem, Treiberproblem oder andere Ursache?

Hallo !
Ich hoffe ihr könnt mir bei meinem Problem helfen.
Ich habe vor kurzem angefangen ein Spiel mit der SFML zu programmieren.
Das Spielprinzip ist nicht neu. Es handelt sich um ein Breakout-ähnliches Spiel.
Ich habe ein Netbook mit Intel Atom N270 und 1 GB Arbeitsspeicher. Als Betriebssystem nutze ich LUbuntu.
Und zum Programmieren nutze ich Codeblocks.
Beim Ausführen des Programms wird der Prozessor zu ca. 40% ausgelastet. Als Frameratelimit
habe ich per SFML-Befehl 60 fps gesetzt. Diese werden allerdings nicht erreicht.
Das Programm läuft mit ca. 29 fps und unregelmäßigen noch schlechteren Werten.
Das ganze sieht dann schon sehr sehr ruckelig aus.

Nun meine Frage: Kann das am Grafikprozessor liegen, falls der Intel Atom-Prozessor einen solchen
verbaut hat? Kann man, da die CPU nicht voll ausgelastet ist, nicht den CPU mehr Arbeit übernehmen lassen?
Ich habe auch etwas zur Hardwarebeschleunigung der SFML gegooglet und habe gelesen, dass solche Verfahren,
wann immer möglich, schon aktiv sind in der SFML.


Zur Info beschreibe ich kurz, wie ich vorgegangen bin, beim Programmieren, um die Klötze zu zeichnen,
die man kaputt machen muss.
Beim Spielstart werden 5 png-Dateien in sf::Images in einer Spriteklasse geladen. Danach werden in der Klasse
5 Sprites erstellt, die die bereits erstellten sf::Images benutzen. Diese Sprites sind die Klötze in 5 verschiedenen Farben/Designs.
Nun werden bei jedem Durchlauf der Hauptschleife, durch ein Array festgelegt, die Positionen jedes benötigten Sprites durch .SetPosition mehrmals
geändert und direkt durch App->Draw() "gezeichnet".


Dadurch werden bis zu 210 Klötze pro Frame gezeichnet. Kann das bereits ein Netbook so sehr auslasten?
Oder ist mein Vorgehen schon falsch/ ineffizient ?


Würde mich über jede Art von Antwort freuen.


Hier noch ein Screenshot des Spiels, falls ich es zu undeutlich beschrieben habe: http://s1.directupload.net/images/130416/thwblngq.jpg

m3xx

Alter Hase

Beiträge: 434

Beruf: Student

  • Private Nachricht senden

2

16.04.2013, 15:11

Also mit Code könnte man eher helfen, aber ein Intel Atom, mh könnte mir auch vorstellen das das zu viel ist.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

3

16.04.2013, 15:13

Du zeichnest deine 210 Sprites wohl einzeln, gut vorstellbar, dass das das Problem ist. Bin mir net sicher, inwiefern es in SFML da einfache Möglichkeiten gibt, das zu optimieren. Das Stichwort lautet jedenfalls Batch Drawing, erfordert in SFML aber evtl. dass man direkt mit OpenGL hantiert...

Edit: Eine einigermaßen einfache Lösung führt evtl. über sf::VertexArray...
m4studios

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

4

16.04.2013, 15:14

Hast du OpenGL-Treiber? Wie laufen andere OpenGL-Sachen auf Deinem Rechner?

@dot: Sehr unwahrscheinlich, dass das ein Problem darstellt.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

5

16.04.2013, 15:22

Gut, ich hab weder Erfahrung mit der Performancecharakteristik von SFML noch mit dem Verhalten auf einem Atom, aber 200 Drawcalls auf einem schwachen Gerät sind imo nicht unbedingt zu verachten, wobei die 40% CPU Auslastung nicht direkt für die CPU als offensichtliches Bottleneck sprechen, wobei man beachten sollte, dass es sich um einen Single Core mit Hypterthreading handelt und ich mir grad net sicher bin, wie Aussagekräftig die 40% da nun sind (überhaupt: 40% Auslastung durch den Prozess oder 40% Auslastung systemweit!?). Ich ging natürlich davon aus, dass OpenGL prinzipiell funktioniert, aber du hast absolut recht, dass erstmal interessant wäre, wie es auf der Maschine generell um OpenGL steht, insbesondere da Intel ja bekannt für seinen extrem tollen OpenGL Support ist...
m4studios

Tenac

Frischling

  • »Tenac« ist der Autor dieses Themas

Beiträge: 7

  • Private Nachricht senden

6

16.04.2013, 15:26

Danke für die schnelle Antwort. Der Code ist glaub ich viel zu lang, um den hier zu posten.
Versuche mal einen Teil, der helfen könnte, zu schreiben.

Als Beispiel für einen Block in der Sprite-Klasse:

Quellcode

 
1
2
3
4
5
6
7
8
9

sf::Image iBlock1;
sf::Sprite Block1;
/// Datei laden ( geschieht nur beim Programmstart einmal )
iBlock1.LoadFromFile("Data/Sprites/Skin1/Block1.png");
Block1.SetImage(iBlock1);

//// Die Funktionen der Sprite-Klasse , welche im Durchlauf der Hauptschleife genutzt werden:
void DrawBlock1(){App->Draw(Block1);};
void PosBlock1(float X, float Y){Block1.SetPosition(X,Y);};



Eine weitere Datei Bloecke.hpp enthält 3 Arrays, die XPosition, YPosition, und Status enthalten.
Ist der Status gleich 0, wird kein Block gezeichnet. Ist der Status gleich 1,2,3,4 oder 5, so
wird die jeweilige Farbe gezeichnet:

Quellcode

 
1

float XPos[210];float YPos[210];int Status[210];


Zum Rendern nutze ich flogenden Code

C-/C++-Quelltext

 
1

void CBloecke::Render(){    for(int i = 0; i < 210; i++)    {        if(Status[i] == 1)        {            Sprite->PosBlock1(XPos[i], YPos[i]);            Sprite->DrawBlock1();        }        if(Status[i] == 2)        {            Sprite->PosBlock2(XPos[i], YPos[i]);            Sprite->DrawBlock2();        }        if(Status[i] == 3)        {            Sprite->PosBlock3(XPos[i], YPos[i]);            Sprite->DrawBlock3();        }        if(Status[i] == 4)        {            Sprite->PosBlock4(XPos[i], YPos[i]);            Sprite->DrawBlock4();        }        if(Status[i] == 5)        {            Sprite->PosBlock5(XPos[i], YPos[i]);            Sprite->DrawBlock5();        }    }}


Ich hoffe das Einfügen des Codes funktioniert halbwegs. Bin noch nicht so erfahren mit dem Posten hier im Forum.

Tenac

Frischling

  • »Tenac« ist der Autor dieses Themas

Beiträge: 7

  • Private Nachricht senden

7

16.04.2013, 15:39

Danke für die vielen Antworten !
Das Spiel selbst verbraucht ca 25 % der CPU.
Habe eben gegooglet, um etwas über OpenGL-Treiber in Erfahrung zu bringen.
Demnach soll man den Befehl "glxinfo | grep "OpenGL version" im Terminal eingeben.
Das bringt mir folgendes Resultat: "OpenGL version string: 1.4 Mesa 9.0.3"

Ich kann leider nicht sagen, wie OpenGL sonst läuft. Habe leider sonst kein Spiel auf meinem Rechner.
Habt ihr einen Vorschlag mit welchem Programm/Spiel man das testen könnte.

Danke für die hilfreichen Antworten !

michi_95

Treue Seele

Beiträge: 159

  • Private Nachricht senden

8

16.04.2013, 15:49

Also ich hatte ein ähnliches Problem: SFML 2.0 - Sehr wenige FPS

Bei mir hat es, wie BlueCobold schon vorgeschlagen hat, geholfen den Grafikkartentreiber zu aktualisieren.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

9

16.04.2013, 15:58

Zitat von »Tenac«

Demnach soll man den Befehl "glxinfo | grep "OpenGL version" im Terminal eingeben.
Das bringt mir folgendes Resultat: "OpenGL version string: 1.4 Mesa 9.0.3"!

Das dürfte dann wohl Dein Problem erklären. Ich glaube nicht, dass SFML mit GL 1.4 zusammenarbeitet. Das hieße Software-Rendering, was ganz eindeutig nicht schnell ist.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Tenac

Frischling

  • »Tenac« ist der Autor dieses Themas

Beiträge: 7

  • Private Nachricht senden

10

16.04.2013, 16:20

Grafiktreiber scheint bei mir installiert zu sein. Es wird auch nur einer angeboten.
Ist es möglich ein Upgrade von OpenGL durchzuführen oder ist das Hardware-abhängig ?
Hab gerade über das Terminal nach Anleitungen alle OpenGL-Pakete installiert und
durch apt-get update und sonstiges versucht eine neue Version zu bekommen.
Der Befehl meldet mir aber weiterhin 1.4

Werbeanzeige

Ähnliche Themen