Types und Performance

Übersicht BlitzBasic Allgemein

Neue Antwort erstellen

Foppele

Betreff: Types und Performance

BeitragFr, Dez 14, 2007 9:44
Antworten mit Zitat
Benutzer-Profile anzeigen
Moin,
Ich hatte neulich die Idee, anstatt viele verschiedene Types zu definieren mich auf ganz wenige BasisTypes
zu beschränken. Dieser BasisType würde dann alle Felder enthalten die man so brauchen könnte und zusätzlich ein Field wo drinsteht, was das jetzt für ein spezieller Type ist.

Der Vorteil wäre, das man wenn man will alle Types aufeinmal ansprechen kann, z.B.
For g.gameObjectType=EACH gameObjectType -> updatePosition(g\mesh).

Wenn man dann spezielle Types ansprechen will kann man das Field mit der Typesorte abfragen, z.B.
For g.gameObjectType=EACH gameObjectType

If g\sorte = Monster then killPlayer()

Oder man fragt andere Fields ab die für verschiedene Typesorten gelten, z.B.

If g\lifespan = 0 then destroyObject().


Ich fände das sehr komfortabel so zu programmieren,
aber hat das vielleicht auch Nachteile?
Geht vielleicht unangemessen viel Rechenzeit dabei drauf, ständig ALLE Types durchzugehen?
Oder findet Ihr die Idee sonst irgendwie blöd? Ich muss dazu sagen dass ich erst vor kurzem angefangen habe zu programmieren.

BladeRunner

Moderator

BeitragFr, Dez 14, 2007 10:28
Antworten mit Zitat
Benutzer-Profile anzeigen
Du hier beschreibst ist im Wesentlichen das Konzept der Polymorphie.
In richtig objektorientierten Sprachen kannst Du dir einen Basistype anlegen und dessen Eigenschaften an andere Types weitergeben (Vererben). Nun können also verschiedene andere Types mittels der selben Methoden angesteuert werden und haben dennoch eingenständige Eigenschaften.

Das Problem was Du unter BB hast ist genau das was Du als Vorteil erachtst: Es gibt eine globale Liste für alle Instanzen die Du erschaffst. Und das wird in der Menge sehr langsam, denn es macht durchaus einen Unterschied ob Du nur alle 230 Monster durchgehst um auf einen Treffer zu prüfen oder ob Du 5000 Spielrelevante Types durchläufst.
Zudem erschaffst Du mittels deiner Methode einen ziemlichen Overhead, da Du ja jedem Type auch Informationen mit auf den Weg gibst die er gar nicht braucht. Du schleppst also tote Daten mit dir. Bei richtig Objektorientiertem Vorgehen hat die Basis nur das in sich was allen abgeleiteten Objekten gleich ist, und wird dann individuell erweitert. Zudem kannst Du in anderen Sprachen deine Listen individuell gestalten und somit den Zugriff wieder verschlanken.
Wenn solche Konzepte dir aber nahe liegen solltest Du vielleicht ernsthaft einen Umstieg zu BMax erwägen, denn das bietet diese Möglichkeiten.
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI

Stolzer Gewinner des BAC#48, #52 & #92
 

BIG BUG

BeitragFr, Dez 14, 2007 10:35
Antworten mit Zitat
Benutzer-Profile anzeigen
Es empfiehlt sich durchaus, auf diese Weise vorgehen. Generell hat man so auch nicht wirklich Speedverlust.

Wie Blade schon angedeutet hat, sollte man bei selbst programmierter Kollision bei vielen Objekten sollte dann ggf. eine Optimierung vornehmen. Also nicht unbedingt einfach 2 geschachtelte For - Each über die gesamte Objektliste verwenden. Da man hier aber auch manuell durch den Type gehen oder diese auch in Arrays hängen kann, ist sowas aber eigentlich auch kein Problem.

Ok, unnütz mitgeschleppte Daten hat man eigentlich immer, aber auch hier kann man einerseits optimieren(unterschiedliche Objekte benutzen die gleichen Variablen für unterschiedliche Sachverhalte) und andererseits sind bei den heutigen Speichergrößen die paar Felder mehr auch keine Tragik.

Ich schreibe zur Zeits sowieso an einem Tutorial was in diese Richtung schiesst.
B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

Foppele

BeitragFr, Dez 14, 2007 13:06
Antworten mit Zitat
Benutzer-Profile anzeigen
O.K.
Danke schon mal für die Antworten. Ihr seit euch ja nicht wirklich einig was den Performanceverlust durch die lange Typelist und die überflüssigen Daten angeht, deswegen werde ich mal eine Testsituation programmieren.
Aber 5000 Types, so weit muss man es ja nicht kommen lassen Confused , höchstens für Partikel, aber für die kann man dann ja nen Extratype anlegen.
Bmax kommt für mich im Moment leider nicht in Frage wg. mangelnder 3D Unterstützung, nichts gegen 2D Spiele aber das ist halt mehr so mein Ding.

BladeRunner

Moderator

BeitragFr, Dez 14, 2007 13:11
Antworten mit Zitat
Benutzer-Profile anzeigen
Big Bug hat schon recht, man kann für vieles einen Workaround konstruieren, aber es ist halt komfortabler sich einer Sprache zu bedienen die direkt alle Möglichkeiten bietet.

Und was 5000 Typeinstanzen angeht, die kommen je nach Game sehr schnell zusammen, und da wird es dann langsam sehr interessant überflüssigen Ballast wegzulassen.
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI

Stolzer Gewinner des BAC#48, #52 & #92

aMul

Sieger des Minimalist Compo 01/13

BeitragFr, Dez 14, 2007 16:38
Antworten mit Zitat
Benutzer-Profile anzeigen
Um unnötigen Speicherverbrauch zu minimieren könnte man mit Banks arbeiten. Also das der Type zwei Felder hat, eins wo drin steht was es nun ist, und eins worin das Handle einer genau passenden Bank gespeichert ist. Allerdings muss man hier wieder bedenken, dass Poke-Peekbyte/-short/-int wiederum langsamer ist, als das arbeiten mit "normalen" Variablen.

Wenn es ein größeres Projekt werden soll, kann ich eine Mischung aus diesen ganzen Methoden empfehlen.
Also:
- verschiedene Type für verschiedene Sachen(Partikel, Spieler, Monster, Schüsse)
- Felder wo drinsteht, um was genau es sich den nun handelt
- zugeschnittene Banks

Ansonsten halt eine Objektorientierte Sprache.
Panic Pong - ultimate action mashup of Pong and Breakout <= aktives Spiele-Projekt, Downloads mit vielen bunten Farben!
advASCIIdraw - the advanced ASCII art program <= aktives nicht-Spiele-Projekt, must-have für ASCII/roguelike/dungeon-crawler fans!
Alter BB-Kram: ThroughTheAsteroidBelt - mit Quelltext! | RGB-Palette in 32²-Textur / Farbige Beleuchtung mit Dot3 | Stereoskopie in Blitz3D | Teleport-Animation Screensaver

Foppele

BeitragSa, Dez 15, 2007 1:38
Antworten mit Zitat
Benutzer-Profile anzeigen
Hier ein kleines Testprogramm, natürlich nur annäherend unter realistischen Bedingungen:
Die Typelist wird 20x pro Schleife durchsucht.
Bei 30 Fps kann ich ca. 2500 Types erstellen bis ich 100% CPU Auslastung habe.

Code: [AUSKLAPPEN]

Graphics3D 640,480,32,2
SetBuffer BackBuffer()
frametimer= CreateTimer(30)



light=CreateLight()
   LightColor light,50,50,50
    PositionEntity light,10,10,10

Global cam=CreateCamera()

   PositionEntity cam,0,0,-5
   RotateEntity cam,0,0,0
    CameraClsColor cam,100,100,200
   
Type testType
Field test
End Type
Global t.testType

cube = CreateCube()

Global v = 1

   
;---------------------------------------------------------------------------------------------------------------------------------

While Not KeyHit(1)


If KeyDown(28) Then

   For x=0 To 10
   
      t.testType = New testType
      t\test =0
      typecount= typecount + 1
      
   Next
   
EndIf


If KeyHit(57) Then v = v + 1
If v = 3 Then v = 1


TurnEntity cube,0.1,0.1,0.1


typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
typeTest()
   
   
UpdateWorld
RenderWorld

If v = 1 Then Text 10,30,"Type Field bearbeiten"
If v > 1 Then Text 10,30,"Typelist nur durchsuchen"
   
Text 10,10,"Typezahl:"
Text 100,10,typecount
   
WaitTimer frametimer
Flip 0
   
   
Wend
;-----------------------------------------------------------------------------------------------------------------------------




Function typeTest()

For t.testType = Each testType
    
   If t\test = v Then
    t\test = Rnd(0,1)
   EndIf
   
   If t\test = v-1 Then
    t\test = Rnd(0,1)
   EndIf

Next
   
End Function
 

Dreamora

BeitragSa, Dez 15, 2007 1:56
Antworten mit Zitat
Benutzer-Profile anzeigen
Das hat nicht zuletzt damit zu tun, dass du das ganze mit dem WaitTimer beeinflusst.

Da die CPU nicht konstant durch andere Prozesse belastet wird, kann sie so einiges auffangen wenn man sie nicht aktiv zur Dauerpause zwingt.
Auf der anderen Seite wird man so etwas hier definitiv auch intelligenter regeln. Wüsste nicht von was man 2500 * 20 Einträge haben sollte die man alle gleichzeit aktiv haben müsste, dafür gibts die Möglichkeit festzustellen was aktiv ist und was nicht und inaktives garnicht erst "rumzuschleppen" zb.

Oder das zu tun was ich gerne mach: einen zweiten type der primär als Container für den ersten dient und die derzeit "aktiven" types beinhaltet für die Iteration.

zb. nötig wenn man sukzessive Daten abarbeiten will die sich durch die Abarbeitung verändern können und eventuell nochmal eine abarbeitung benötigen.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Foppele

BeitragSa, Dez 15, 2007 2:12
Antworten mit Zitat
Benutzer-Profile anzeigen
Kannst du mir das mit dem Waittimer nochmal erklären, das hab ich nicht verstanden.
Ich habe mir das so angewöhnt mit fester Framerate, Waittimer und Flip 0, ich dachte das wär ne optimale Einstellung, die gerade verhindert dass die CPU zu Pausen gezwungen wird.
Mit dem Testprogramm wollte ich nur ausprobieren wieviel CPU Leistung exzessives Typelistendurchlaufen so verbraucht.

Silver_Knee

BeitragSa, Dez 15, 2007 13:30
Antworten mit Zitat
Benutzer-Profile anzeigen
hahaha ich kenne dein Problem *fr0i* ich hab in cnRS unterschiedliche shiffe mdie variabel über ini eingelesen werden. Das läuft auch auf soooo ne liste raus. Meine Lösung: geordnete Listen. Ich hab mal in DEM OPTIMIERUNGSTHREAD was da zu geschieben: https://www.blitzforum.de/foru...246#260246 Viel spaß damit.

Neue Antwort erstellen


Übersicht BlitzBasic Allgemein

Gehe zu:

Powered by phpBB © 2001 - 2006, phpBB Group