# Brauche denkanstoß für kleines grafikframework



## jule37 (11. Mrz 2010)

hallo leute

ich baue grad ein kleines grafikframework das ich in einer gameengine verwenden möchte. ich möchte möglichst alle technischen aspekte wegkapseln, so dass es möglich ist diese auszutauschen ohne die engine umschreiben zu müssen.

die engine hat ein properties file, aus dem sie die klassennamen der zu erzeugenden objekte für die anzeige ausliest und dann diese per reflection instantiiert. so reicht es, das properties file zu ändern, um die engine auf einer anderen plattform laufen zu lassen. mit anzeige ist hier das fenster gemeint, in welches das spiel rendert. das hab ich nun vollständig generisch implementiert und das ist auch schön soweit.

mein problem ist grad folgendes: awt und swing fenster verwenden beide java.awt.Graphics und deren kinder um zu zeichnen. ich weiss nicht wie dies bei swt ist, bin mir aber ziemlich sicher, dass hier etwas anderes zum einsatz kommt. um die grafikschnittstelle zu abstrahieren habe ich mir einen wrapper für diese geschrieben, da die zu verwendende grafik ja auch vom verwendeten fenster abhängt. diese grafikschnittstelle wird vom fenster in den renderloop gegeben und dort von allen zu zeichnenden objekten verwendet.

aber irgendwie fühlt es sich falsch an die grafik zu wrappen. andererseits wäre es möglicherweise nicht sinnvoll direkt java.awt.Graphics zum rendern zu nehmen, weil man sich damit wohl auf swing und awt fenster für die anzeige beschränken würde. ich weiss gar nicht, wie es mit applets ist - was verwenden die für anzeigen?

möglicherweise hab ich mich grad einfach nur gedanklich festgefahren. vielleicht hat jemand von euch schonmal was ähnliches gebaut und kann mir helfen meinen kopf etwas zu entwirren? 

vielen dank


----------



## Marco13 (11. Mrz 2010)

Klingt nach einer Frage, die SO allgemein und "meta" ist, dass eine pauschale Univeralantwort darauf schwierig ist. Nur zwei Punkte: Bei Applets wird auch "Graphics" verwendet. Und wenn du davon mit einem "Wrapper" abstrahieren willst, klingt das nach sowas wie

```
interface GeneralGraphics 
{
    void drawLine(int x0, int y0, int x1, int y1);
}

class DefaultGraphics implements Graphics
{
    public void drawLine(int x0, int y0, int x1, int y1)
    {
        someGraphicsFromPaintMethod.drawLine(...);
    }
}
```

Vielleicht wäre ein Ansatz, "an der anderen Seite" zu abstrahieren. Im Sinne von "Paintern", die bestimmte Objekte (z.B. eine Spielfigur in einem Spiel) zeichnen können, und von denen es dann sowas wie ein "SwingPlayerPainter" und "SWTPlayerPainter" gibt... oder so ähnlich wie es mit bei Swing mit den "UIs" gemacht wird... ?!


----------



## Steev (11. Mrz 2010)

Ich habe es so gemacht, dass alle Grafikobjekte, Bilder usw. als Interfaces, wie Marco schon geschrieben hat, vorgeschrieben wurden. Ich bin dann nur hergegangen und habe das Standard-Java auf die Interfaces aufgesetzt. Dies sollte aber möglichst "engineintern" gemacht werden, so dass der Nutzer nur an die Interfaces rankommt.
Soll heisen: Wenn du das Backend umswitchs sollte der Nutzer immernoch dieselben Klassen und Struckturen nutzen können. Vorstellbar währen implementierungen wie so etwas:

GlobalEnviroment.createGraphics():YourGraphics

Gruß
Steev


----------



## jule37 (11. Mrz 2010)

danke für eure anworten.

das was ihr da beschreibt ist genau das, was ich grad mache. also schätze ich, dass dieser weg wohl notwendig ist.


----------

