# Culling von Image-Objekten



## Peace (8. Mrz 2009)

Guten Tag Forum,

//Ausgangssituation:
da ich in den Ferien etwas Zeit habe wollte ich mich auch mal an die Entwicklung von Java-Spielen wage, bevor man aber loslegen kann, braucht man erstmal eine Grundstruktur, um die vielen Bilder, die sich auf dem JFrame tummeln sollen anständig zu verwalten.

Diese Grundstruktur sieht bei mir so aus:
(Pix und Kino sind eigene Klassen)

- der JFrame ist von einem einzigen „Kino extends JPanel“ - Objekt ausgefüllt

- diese Kino-Classe hat eine Liste von „Pix“ – Objekten, die jeweils neben einem Image-Objekt noch zahlreiche Variablen für Position, Drehung, Scherung usw. und schließlich ein AffineTransform-Objekt enthalten

- in jedem Arbeitsschritt (bestimmt durch ein Timer-Objekt) wird innerhalb des Kino-Objekts für jedes Pix aus seinen genannten Variablen (die sich jederzeit ändern lassen) eine AffineTransformation berechnet und an das Pix zurückgegeben

- zum Schluss wird mit „this.repaint“ und der überschriebenen paintComponent jedes Image eines jeden Pix-Objektes mit der zugehörigen AffineTransformation auf das JPanel (Kino) und damit auf den JFrame gemalt

Das tolle an der ganzen Sache ist, dass man viele Bilder nach Lust und Laune darstellen und beliebig manipulieren kann, einfach ein neues Pix mit den gewünschten Parametern in die Liste des Kino-Objekts einfügen oder bei einem schon bestehenden die Variablen verändern.

Ich denke, das ist eine solide Grundlage für JEDES Java-Spiel und wenn Ihr wollt (entweder um einen besseren Überblick über mein folgendes Problem zu bekommen, oder für jeden, der sofort mit dem eigentlichen Spiele-Entwickeln anfangen will) kann ich den Code auch mal Posten (natürlich auf das Nötigste beschränkt).

//das Problem:
Es lassen sich also viele Bilder dort einfügen und dynamisch verändern (hauptsächlich für Animation für Bewegungen u.Ä.), auf meinem R40 Laptop bis zu 4000, ab dann beginnt es zu stocken.

Ganz klar: zu viele AffineTransotmation-Berechnungen, zu viele Bilder müssen gemalt werden. 

Lösung: Culling, also nur die Bilder berechnen und malen, die aufgrund ihrer Position (die ja im zugehörigen Pix gespiechert ist) tatsächlich im JFrame zu sehen sein werden.

Vor Berechnung und Zeichnung des Bildes lasse ich für jedes Pix entscheiden (und speichere das Ergebnis in einem boolean (auch im Pix)) ob es im JFrame zu sehen sein wird. Und dieser boolean wird vor Berechnung und Zeichnung abgefragt.  

Problem: es hilft nicht, mit und ohne Culling kein Unterschied. 

Hat jemand von Euch Erfahrung mit dem Culling von Image-Objekten oder gar ein anderes Konzept zur Darstellung und Manipulation (beliebig-)vieler Bilder auf einem JFrame?

mfG Peace

p.s. entschuldigt das viele Geschreibsel, werde mich in Zukunft kürzer fassen


----------



## 0x7F800000 (8. Mrz 2009)

1) "Kino" und "Pix" sind äußerst bescheuerte Klassenbezeichner, erst recht in irgendeinem Speil. Was ist "Pix"?! Habe ich weder im Wörterbuch noch sonstwo gefunden, bei der Wikipedia gibt es nur Vorschläge wie "Performance Investigator für XBox" Ääähm? ???:L

2) Mit Hilfe von Culling können falsch orientierte Dreiecke bzw. Polygone bei 3D Grafik innerhalb der Grafikkarte eliminiert werden. Auf 2D-Grafik ist das imho nicht sinnvoll anwendbar.

Objekte, die in dem gezeichneten bereich nicht sichtbar sind, zu entfernen ist eine sehr sinnvolle idee. Am einfachsten wäre es imho, jeder Figur (bzw jedem PerformanceInvestigatorFürXBox^^) eine Bounding-Sphere, d.h. einfach nur einen radius, zuzuordnen. Damit kann man überflüssige Figuren sehr schnell rauswerfen, das dürfte die Performance erheblich steigern:toll:


----------



## Peace (8. Mrz 2009)

Hallo Andrey,

//zu 1.)
Ich kann doch meine Klassen so nennen wie ich will. (oder? :rtfm
Kino heißt so, weil es quasi die „Leinwand“ ist, auf der ständig das zu sehende Bild aktualisiert wird.
Das Wort „Pix“ sollte erstens kurz sein (damit man beim Aufruf des Konstruktors nicht immer ewig tippen muss) und zweitens mit „Bildelement“ oder „Zu sehendes Teilchen“ assoziiert werden.

//zu 2.) 
es geht doch nur um das Prinzip des Cullings

//zum Rest:
Genau das mache ich schon, hab auch alles getestet (z.B. ob bestimmte Pixs gemalt werden oder nicht), theoretisch ist alles perfekt, kann mir nicht erklären, warum es nicht fuzt.???:L


----------



## 0x7F800000 (8. Mrz 2009)

Peace hat gesagt.:


> Ich kann doch meine Klassen so nennen wie ich will. (oder? :rtfm


Was ist das denn für ein Argument? ???:L Der Compiler verbietet es ja auch nicht, klassen mit einzelnen Kleinbuchstaben zu benennen, oder methoden zu schreiben, die folgende gestalt haben:

```
private Graphics2D jhagdjs(int a, float b, Object g){
   int r=23;
   boolean bsadj=true;
   for(int z=124; z>11321231; z--){
      g=null;
   }
   return null;
}
```
aber nur weil es der compiler erlaubt, muss es ja noch lange keinen Sinn machen.



> Kino heißt so, weil es quasi die „Leinwand“ ist, auf der ständig das zu sehende Bild aktualisiert wird.


Wenn es "quasi die Leinwand" ist, dann nenn es doch "Canvas", evtl. mit irgendeinem speziellen suffix, da kann sich wenigstens jeder irgendwas drunter vorstellen.


> Das Wort „Pix“ sollte erstens kurz sein (damit man beim Aufruf des Konstruktors nicht immer ewig tippen muss) und zweitens mit „Bildelement“ oder „Zu sehendes Teilchen“ assoziiert werden.


Wenn es irgendwie krass abgekürzt werden muss, kannst du es ja am ende durch Code-Obfuscator jagen... Ich weiß nicht, was die ganze sonstige Erdbevölkerung dazu meint, "Pix" wird bei mir jedenfalls mit nichts assoziiert. :noe: Andererseits hört sich das hier:


> Ich denke, das ist eine solide Grundlage für JEDES Java-Spiel und wenn Ihr wollt (entweder um einen besseren Überblick über mein folgendes Problem zu bekommen, oder für jeden, der sofort mit dem eigentlichen Spiele-Entwickeln anfangen will) kann ich den Code auch mal Posten (natürlich auf das Nötigste beschränkt).


irgendwie so an, als wolltest du deinen code mit anderen Leuten teilen, da würde es doch imho durchaus Sinn machen, die Klassen auch irgendwie Sprechend zu bennen.



> //zu 2.)
> es geht doch nur um das Prinzip des Cullings


Ist in 2D nicht sinnvoll anwendbar, wie gesagt.


> //zum Rest:
> Genau das mache ich schon, hab auch alles getestet (z.B. ob bestimmte Pixs gemalt werden oder nicht), theoretisch ist alles perfekt, kann mir nicht erklären, warum es nicht fuzt.???:L


Dann solltest du vielleicht erstmal dein Programm durch einen Profiler jagen, bevor du irgendetwas optimierst. Vielleicht macht die berechnung von 4000 Affinen Transformation im vergleich zum Zeichnen von 100x100 Pixeln einfach nichts aus. Dann hast du irgendetwas optimiert, was gar kein Flaschenhals darstellte. Wenn es richtig schnell sein muss, würde ich eh direkt JOGL oder ähnlich hardware-nahe bibliotheken empfehlen, dann läuft der zeichenvorgang an sich vielleicht schneller.


----------

