Spiel wird immer langsamer,..zu langer Code?

Übersicht

BlitzBasic

Allgemein

	Okyo Betreff: Spiel wird immer langsamer,..zu langer Code?	Sa, März 10, 2007 1:02 Antworten mit Zitat
Hi, hoffentlich kann mir jemand helfen... kann das sein das mit der Codelänge (2500 Zeilen) das Spiel immer langsamer wird? wenn ich ca. 500 xbeliebige Zeilen lösche,dann wird es wieder schneller, an der Datengröße (Modells,Texturen usw) kann es nicht legen,diese habe ich testweise extrem reduziert oder ausgetauscht, trotzdem war das Spiel sau langsam...! Auslösung bei 640,480, oder auch bei 800,600 Wie kann ich das Problem lösen? danke im vorraus

Okyo

Betreff: Spiel wird immer langsamer,..zu langer Code?

Sa, März 10, 2007 1:02
Antworten mit Zitat

Hi, hoffentlich kann mir jemand helfen...

kann das sein das mit der Codelänge (2500 Zeilen) das Spiel immer langsamer wird? wenn ich ca. 500 xbeliebige Zeilen lösche,dann wird es wieder schneller, an der Datengröße (Modells,Texturen usw) kann es nicht legen,diese habe ich testweise extrem reduziert oder ausgetauscht, trotzdem war das Spiel sau langsam...! Auslösung bei 640,480, oder auch bei 800,600

Wie kann ich das Problem lösen?
danke im vorraus

	Gameprogman	Sa, März 10, 2007 1:12 Antworten mit Zitat
An der Codelänge kanns eigentlich nicht liegen, denn im Vergleich zu anderen Projekten sind 2500 Zeilen relativ wenig. Außerdem ist BB eine ziemlich schnelle Programmiersprache. Das problem könnte darin liegen, dass zu viel im Hintergrund berechnet wird.
www.bandradr.de ! Awesome !

Gameprogman

Sa, März 10, 2007 1:12
Antworten mit Zitat

An der Codelänge kanns eigentlich nicht liegen, denn im Vergleich zu anderen Projekten sind 2500 Zeilen relativ wenig. Außerdem ist BB eine ziemlich schnelle Programmiersprache. Das problem könnte darin liegen, dass zu viel im Hintergrund berechnet wird.

www.bandradr.de ! Awesome !

	TheMatrix	Sa, März 10, 2007 1:17 Antworten mit Zitat
Schau mal, ob die eventuell ausversehen ständig was im Code nachlädst. Sei es ein Image, Font, Datei usw. Teste mal 16-Bit, dass macht es einwenig schneller. Ansonsten gucken, wie es mit Schleifen etc. aussieht. Hast du eine Schleife die zig mal durchläuft und massig bearbeitet, zieht das die Perfomance. Gruß, Manu
°_° °.° °~° °v° .. -.-

TheMatrix

Sa, März 10, 2007 1:17
Antworten mit Zitat

Schau mal, ob die eventuell ausversehen ständig was im Code nachlädst. Sei es ein Image, Font, Datei usw.

Teste mal 16-Bit, dass macht es einwenig schneller.
Ansonsten gucken, wie es mit Schleifen etc. aussieht. Hast du eine Schleife die zig mal durchläuft und massig bearbeitet, zieht das die Perfomance.

Gruß, Manu

°_° °.° °~° °v° .. -.-

	coldie	Sa, März 10, 2007 11:05 Antworten mit Zitat
Wie Matrix bereits angedeutet hat wirst du wahrscheinlich irgendeine Datei wiederholt in eine Variable laden, ohne dass die alte gelöscht wird. Dabei wird häufig die alte Information nicht einfach nur überschrieben, sondern es wird eine Zusätzliche Information hinzugefügt (z.B. bei einer 3d-Datei). So etwas passiert schnell wenn man nicht aufpasst, und es muss auch keine Fehlermeldung geben.

coldie

Sa, März 10, 2007 11:05
Antworten mit Zitat

Wie Matrix bereits angedeutet hat wirst du wahrscheinlich irgendeine Datei wiederholt in eine Variable laden, ohne dass die alte gelöscht wird.

Dabei wird häufig die alte Information nicht einfach nur überschrieben, sondern es wird eine Zusätzliche Information hinzugefügt (z.B. bei einer 3d-Datei). So etwas passiert schnell wenn man nicht aufpasst, und es muss auch keine Fehlermeldung geben.

	Christoph	Sa, März 10, 2007 11:37 Antworten mit Zitat
Auch ein schöner Performance-killer: Typeeinträge, die bestimmte Objekte (seien es Bilder, Meshs oder sontiges) in einem Typefeld speichern und nicht mehr löschen, falls es nicht mehr gebraucht wird: Code: [AUSKLAPPEN] [EINKLAPPEN] Type Gegner Field image End Type Wenn du in image ein Bild speicherst, muss du dieses mit Freeimage vor dem Löschen des Typeeintrags löschen: Code: [AUSKLAPPEN] [EINKLAPPEN] ;Laden Bla.Gegner=new Gegner Bla\image=loadimage("bild.bmp") ;Löschen freeimage Bla\image delete Bla.Gegner Ist mir schon mal passiert, das zieht schön an der Leistung, wenn du das Objekt nicht mehr löschst.

Christoph

Sa, März 10, 2007 11:37
Antworten mit Zitat

Auch ein schöner Performance-killer:

Typeeinträge, die bestimmte Objekte (seien es Bilder, Meshs oder sontiges) in einem Typefeld speichern und nicht mehr löschen, falls es nicht mehr gebraucht wird:

Code:

Type Gegner
Field image
End Type

Wenn du in image ein Bild speicherst, muss du dieses mit Freeimage vor dem Löschen des Typeeintrags löschen:

Code:

;Laden
Bla.Gegner=new Gegner
Bla\image=loadimage("bild.bmp")
;Löschen
freeimage Bla\image
delete Bla.Gegner

Ist mir schon mal passiert, das zieht schön an der Leistung, wenn du das Objekt nicht mehr löschst.

	Okyo Betreff: habs gelöst	So, März 11, 2007 3:02 Antworten mit Zitat
danke für eure schnellen antworten, ich habe alle Vorschläge versucht um das problem zu lösen,...dabei lag es ausschließlich an dem Befehl "Entityvisible"!!!!!!!!!!!! Diesen Befehl habe ich öfter gebraucht für die Gegner...der hat das Spiel um ca. 90% langsamer gemacht! Ich konnte mich kaum vom Fleck bewegen. Ich weiss überhaupt nicht warum?, sehe keinen logischen Zusammenhang!...habe dann gegoogelt und einige "Entityvisible" Erklärung/Tuts angeschaut, aber die haben das problem nicht geändert...deswegen musste ich leider den Befehl weglassen...schade denn jetzt sind die Gegner noch dümmer...;( Ich vermute, dass es wieder an den 3dsmeshes liegt, die b3d mit skepsis akzeptiert...

Okyo

Betreff: habs gelöst

So, März 11, 2007 3:02
Antworten mit Zitat

danke für eure schnellen antworten, ich habe alle Vorschläge versucht um das problem zu lösen,...dabei lag es ausschließlich an dem Befehl "Entityvisible"!!!!!!!!!!!!
Diesen Befehl habe ich öfter gebraucht für die Gegner...der hat das Spiel um ca. 90% langsamer gemacht! Ich konnte mich kaum vom Fleck bewegen. Ich weiss überhaupt nicht warum?, sehe keinen logischen Zusammenhang!...habe dann gegoogelt und einige "Entityvisible" Erklärung/Tuts angeschaut, aber die haben das problem nicht geändert...deswegen musste ich leider den Befehl weglassen...schade denn jetzt sind die Gegner noch dümmer...;(
Ich vermute, dass es wieder an den 3dsmeshes liegt, die b3d mit skepsis akzeptiert...

	Dreamora	So, März 11, 2007 4:02 Antworten mit Zitat
Nein hat es nicht. Es hat damit zu tun das EntityVisible unzählige Linecasts macht um zu überprüfen ob die objekte sich sehen können. Je weiter sie auseinander sind, desto schlimmer wirds. Will heissen: Ohne Quad / Oct Tree oder sehr kleine Welten ohne viele Objekte und ohne viele Polygone ist dieser Befehl Tabu. Damit garantierst du nur massive Probleme. Was auch notwendig ist, ist das du erst einmal überprüfst ob die KI den Spieler überhaupt sehen könnte noch bevor visible gecheckt wird. Denn wenn er mit dem Rücken zu dir steht ist visible komplette Zeitverschwendung. Das machst du zb durch eine "Blickfeldkamera" welche an die position und richtung der KI gesetzt wird mit seiner sichtreichweite etc und dann EntityInView ... Oder halt einfach direkt mathematisch, denn Radius und Winkel sind nicht schwer zu bestimmen und vermutlich schneller als die "fake" lösung. NUR wenn durch den check gegeben ist das die KI den spieler potentiell sehen könnte kommen weitere check überhaupt in frage. => Effizienteste Lösung: 1. OctTree. Was nicht im gleichen Node ist, kann sich nicht sehen da zu weit auseinander (KI haben prinzipiell nur kurze sichtbereiche!) 2. Innerhalb der Nodes kann mittels oben beschriebener techniken potentielles sehen getestet werden 3. wenn dann immer noch net ausgeschlossen ist, dass die KI dich sehen kann, kommt EntityVisible zum einsatz.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

So, März 11, 2007 4:02
Antworten mit Zitat

Nein hat es nicht.

Es hat damit zu tun das EntityVisible unzählige Linecasts macht um zu überprüfen ob die objekte sich sehen können.

Je weiter sie auseinander sind, desto schlimmer wirds.

Will heissen: Ohne Quad / Oct Tree oder sehr kleine Welten ohne viele Objekte und ohne viele Polygone ist dieser Befehl Tabu.
Damit garantierst du nur massive Probleme.

Was auch notwendig ist, ist das du erst einmal überprüfst ob die KI den Spieler überhaupt sehen könnte noch bevor visible gecheckt wird. Denn wenn er mit dem Rücken zu dir steht ist visible komplette Zeitverschwendung.

Das machst du zb durch eine "Blickfeldkamera" welche an die position und richtung der KI gesetzt wird mit seiner sichtreichweite etc und dann EntityInView ...
Oder halt einfach direkt mathematisch, denn Radius und Winkel sind nicht schwer zu bestimmen und vermutlich schneller als die "fake" lösung.

NUR wenn durch den check gegeben ist das die KI den spieler potentiell sehen könnte kommen weitere check überhaupt in frage.

=>

Effizienteste Lösung:

1. OctTree. Was nicht im gleichen Node ist, kann sich nicht sehen da zu weit auseinander (KI haben prinzipiell nur kurze sichtbereiche!)
2. Innerhalb der Nodes kann mittels oben beschriebener techniken potentielles sehen getestet werden
3. wenn dann immer noch net ausgeschlossen ist, dass die KI dich sehen kann, kommt EntityVisible zum einsatz.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	E. Urbach ehemals "Basicprogger"	So, März 11, 2007 9:16 Antworten mit Zitat
@Dreamora: Ab in die Tutorial-Sammlung, besser kann man's nicht erklären @Christoph: Hast schon recht, aber bei deinem Beispiel würd ich nicht für jeden Gegner ein Image deklarieren. Es wäre evtl. besser, wenn man den Gegner-Typ speichert (als Integer) und dann per Blitz Array auf das Image zugreift, ungefähr so: Code: [AUSKLAPPEN] [EINKLAPPEN] Type TEnemy Field imgRef% End Type Global enemyImages[1] enemyImages[0] = CreateImage(8,8) enemyImages[1] = CreateImage(16,16) Local enemy.TEnemy = New TEnemy enemy\imgRef = 1 Print "Image available: " + (enemyImages[enemy\imgRef] <> 0) WaitKey End @Okyo: Im Gegenteil, ein längerer Code bringt in den meisten Fällen (außer man macht es absichtlich falsch) einen Performanceschub. Hier mal ein kleines Beispiel: Code: [AUSKLAPPEN] [EINKLAPPEN] ;Speed-Test Const MAX_ITERATIONS = 1000000 Local Array1[MAX_ITERATIONS] Local Array2[MAX_ITERATIONS] Local I Local a Local time Color 255,255,255 Print "1:" Color 255,255,0 ;Kurz, aber übersichtlich time = MilliSecs() For I = 0 To MAX_ITERATIONS a = Array1[I] + Array2[I] Next Print MilliSecs() - time Print "" Color 255,255,255 Print "2:" Color 255,255,0 ;Langer Code, unübersichtlich, dafür schneller time = MilliSecs() For I = 7 To MAX_ITERATIONS Step 8 a = Array1[I] + Array2[I] a = Array2[I-1] + Array2[I-1] a = Array2[I-2] + Array2[I-2] a = Array2[I-3] + Array2[I-3] a = Array2[I-4] + Array2[I-4] a = Array2[I-5] + Array2[I-5] a = Array2[I-6] + Array2[I-6] a = Array2[I-7] + Array2[I-7] Next Print MilliSecs() - time WaitKey End In der unteren, längeren For-Schleife werden 8 Einträge auf einmal bearbeitet. Somit muss die Schleife nicht so oft zum Schleifenanfang springen. Generell gilt: Kümmer dich erst um die Übersichtlichkeit. Erst wenn eine mangelnde Effizienz des Codes festgestellt worden ist, sollte man optimieren. Übrigens müsste die von Dreamora beschriebene mathematische Lösung am schnellsten sein, einfach Radius und Winkel nehmen und schauen, ob die Person zumindest im Blickwinkel steht. Noch ein kleiner Tipp: Verwende nicht EntityDistance, nimm besser das Quadrat der Distanz, das lässt sich schneller errechnen
The box said, "Requires Windows XP or better", so I installed Ubuntu \| Linux is NOT Windows Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

E. Urbach

ehemals "Basicprogger"

So, März 11, 2007 9:16
Antworten mit Zitat

@Dreamora: Ab in die Tutorial-Sammlung, besser kann man's nicht erklären Wink

@Christoph: Hast schon recht, aber bei deinem Beispiel würd ich nicht für jeden Gegner ein Image deklarieren. Es wäre evtl. besser, wenn man den Gegner-Typ speichert (als Integer) und dann per Blitz Array auf das Image zugreift, ungefähr so:
Code:

Type TEnemy
Field imgRef%
End Type

Global enemyImages[1]

enemyImages[0] = CreateImage(8,8)
enemyImages[1] = CreateImage(16,16)

Local enemy.TEnemy = New TEnemy
enemy\imgRef = 1

Print "Image available: " + (enemyImages[enemy\imgRef] <> 0)
WaitKey
End

@Okyo: Im Gegenteil, ein längerer Code bringt in den meisten Fällen (außer man macht es absichtlich falsch) einen Performanceschub. Hier mal ein kleines Beispiel:
Code:

;Speed-Test

Const MAX_ITERATIONS = 1000000
Local Array1[MAX_ITERATIONS]
Local Array2[MAX_ITERATIONS]
Local I
Local a
Local time

Color 255,255,255
Print "1:"
Color 255,255,0

;Kurz, aber übersichtlich
time = MilliSecs()
For I = 0 To MAX_ITERATIONS
   a = Array1[I] + Array2[I]
Next
Print MilliSecs() - time

Print ""
Color 255,255,255
Print "2:"
Color 255,255,0

;Langer Code, unübersichtlich, dafür schneller
time = MilliSecs()
For I = 7 To MAX_ITERATIONS Step 8
   a = Array1[I] + Array2[I]
   a = Array2[I-1] + Array2[I-1]
   a = Array2[I-2] + Array2[I-2]
   a = Array2[I-3] + Array2[I-3]
   a = Array2[I-4] + Array2[I-4]
   a = Array2[I-5] + Array2[I-5]
   a = Array2[I-6] + Array2[I-6]
   a = Array2[I-7] + Array2[I-7]
Next
Print MilliSecs() - time

WaitKey
End

In der unteren, längeren For-Schleife werden 8 Einträge auf einmal bearbeitet. Somit muss die Schleife nicht so oft zum Schleifenanfang springen.
Generell gilt: Kümmer dich erst um die Übersichtlichkeit. Erst wenn eine mangelnde Effizienz des Codes festgestellt worden ist, sollte man optimieren.
Übrigens müsste die von Dreamora beschriebene mathematische Lösung am schnellsten sein, einfach Radius und Winkel nehmen und schauen, ob die Person zumindest im Blickwinkel steht.

Noch ein kleiner Tipp: Verwende nicht EntityDistance, nimm besser das Quadrat der Distanz, das lässt sich schneller errechnen Wink

The box said, "Requires Windows XP or better", so I installed Ubuntu | Linux is NOT Windows
Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

	Okyo Betreff: ok	Mo, März 12, 2007 2:31 Antworten mit Zitat
Ok, alles klar,..danke für eure Hilfe...Entityvisible habe ich komplett gestrichen...jetzt läuft wieder alles einwandfrei...wäre aber trotzdem genial gewesen mit entityvisible zu arbeiten...

Okyo

Betreff: ok

Mo, März 12, 2007 2:31
Antworten mit Zitat

Ok, alles klar,..danke für eure Hilfe...Entityvisible habe ich komplett gestrichen...jetzt läuft wieder alles einwandfrei...wäre aber trotzdem genial gewesen mit entityvisible zu arbeiten...

Übersicht

BlitzBasic

Allgemein

Nach Oben

BlitzBasic Portal

Spiel wird immer langsamer,..zu langer Code?

Betreff: Spiel wird immer langsamer,..zu langer Code?

Betreff: habs gelöst

Betreff: ok