4. kleine 2d-framework sortierungs-problem

kleine 2d-framework sortierungs-problem

  • M

    Okay weiß nicht ob ihr euch unter dem titel was vorstellen könnt; also:
    Bastel grad nen kleinen sdl+opengl framework für 2d-only. Ja nur ists schon ne weile her mit opengl und mit 2d erst recht... Im Prinzip will ich fragen ob man ein depth testing auch im 2d modus von opengl machen lassen kann. (Wieso das so wichtig ist nachher...) Also das ich z.b. überall ne dritte koordinate dazugebe die an der darstellung ansich nichts ändert aber auf den depth test anspringt. ich habs versucht mit glOrtho(...,...,...,...,0,1); und dann der dritten korrdinate zwischen 0->1 aber das funtkioniert mal so nicht.. Weiß jemand vielleicht wie man das machen kann?

    Okay, jetzt wozu ich das brauche:
    Bei mir gibts 3 Arten von "sprites": {einfach ein bild, animierte sprites, bone-animierte sprites (oder so ähnlich)}
    okay: nun sollen alle vorhandenen immer in einer liste sein, sodass man nicht für jedes per hand render() aufruft (z.b.). ich könnte jetzt für alle drei typen ein interface anlegen mit einer funktion render() die einfach aufgerufen wird.... aber das will ich nicht weil ich dann pro frame ein dutzend virtuelle aufrufe habe... und man das ja vermeiden könnte indem man

    ein interface für einen "Renderer" anlegt mit einer virtuellen funktion render(). jeder von den renderen hat dann noch andre funktionen zum dazugeben von neuen sprites usw. Nun würde man einfach von allen renderen der reihe nach einmal die funktion render aufrufen und die erledigt den rest (in einer schleife) <= und hier ist auch der haken... kein sorting möglich, da ja einfache bilder und bone-animierte sprites abwechselnt verschiedene z-werte (sag ich mal) haben können... . schöner sch*** ...

    Noch ne kleine skizze denn ich hab sicher scheiße erklärt:

    class basic_renderer
{
virtual void render(void)=0;
};

class ani_renderer : pubic basic_renderer
{
vector<ani_sprite> m_sprite;
int m_size;

int add_sprite(...);

void render(void)
{
  for(int i=0; i<m_size; ++i)
  {
    //sprites zeichen
  }
}
};

//so halt alle renderer
//und dann im haupt objekt:

class graphics
{
  vector<basic_renderer*> m_renderer;
  int m_size;

  void render_scene(void)
  {
    for(int i=0; i<m_size; ++i)
      m_renderer[i]->render();
  }
};

//also so ungefähr

    Ich hoffe es weiß hier wer weiter...
    Wenn ihr meint es ist okay, für jedes sprite ne virtuelle funktion anzulegen und halt jedes frame auch zu benutzen und meine variante wäre nie schneller... dann wäre das ganze problem natürlich gelöst... Wär trotzdem toll wenn jemand weiß wie ich hier das depth testing von opengl für meine zwecke gebrauchen kann... 😃

    danke für die bemühungen.. ich weiß, der text ist *****-lang... aber ich kann mich eben nicht kanpper artikulieren.
    mfg Manuel

    0
  • C

    Es ist in Ordnung für jedes Sprite einen vtable lookup zu machen, das kost nicht die Welt, nicht in diesem Zusammenhang, also mach ruhig das mit den virtuellen Funktionen(dafür sind sie da) und mach so das DepthTesting.

    Mit OpenGL würde es auch gehen, imho nicht mit glOrtho.
    Du musst manuell eine Projektionsmatrix angeben diehalt die grössen X und Y nicht anhand von Z verändert.
    (such einfach mal nach Projektionsmtrizen für 2D und knall dir da die Z-Koordinate mit rein, dann könnte auch OpenGL den DepthTest übernehmen.)
    Auf die virtualFunctionCalls brauchst du trotzdem nicht zu verzichten, das sind so wenige in deinem Zusammenhang das sie dort noch keine Performanceeinbussen machen. Bei nen paar Millionen Calls per Frame vielleicht, aber da kommt der Performancekiller schon früher an anderer Stelle.

    0
  • M

    Okay... hab grad herausgefunden, dass es auch ein stück einfacher geht:
    einfach glOrtho(...,...,...,...,-1.0f, 1.0f); setzten und depth testing funktioniert.

    Zu der komischen idee... naja du hast schon recht das mich die paar virutellen funktionen mal nicht die welt kosten... aber es ist ja auch nicht nur das sie virtuell sind! Es ist schonmal der fakt das ich überhaupt für jedes sprite ne funktion aufrufen muss, der mich so stört. Das ist doch verschossene performance..

    Jeder call + davor auch noch dereferenziern... hab ja nix gegen die virtuelle funktion ansich! ABer das ich da jeden frame sagen wir mal hundert funktionen aufrufe... das ist doch verschwendung! Und ich mein das system muss ich ja dann auch für collisionstest und so verwenden...

    Wenn ich dann an opengl im speziellen denke, dann fallen mir noch die vielen state changes ein, die ich damit unweigerlich provoziere. Klar ein schnelles system steckt das vielleicht weg, aber ich finds schon blöd, wenn man dann einen hi-end pc für ein schlechtes 2d spiel braucht...

    Allerdings ist meine methode leider recht schwierig umzusetzten, da mir immer neue probleme einfallen... vielleicht greif ich ja "vorerst" auf die simplere variante zurück, oder code mal ein paar andere sachen wie resourcen-system oder so... denn wenn ich da so weitermach ohne genauen plan, das hilft ja auch keinem.

    Nagut danke für die hilfe
    mfg Manuel

    0
  • C

    Scheiss drauf, ehrlich ...

    Wenn dein Framework es nunmal verlangt, dann solltest du für jedes Sprite diese Methode aufrufen. Wie gesagt, solche Optimierungen im voraus bringen rein garnichts. Geschweige dann das das wirklich was kostet. Die Compiler können heutzutage schon sowas von optimieren das man sehr saubere Frameworks schreiben kann und trotzdem schnell ist. Im Gegenteil, ein sauberes, übersichtliches Framework wird dir letztendlich sogar mehr Performance bringen als ne kleine Optimierung wo ein paar FunctionCalls und dereferenzierungen wegfallen.
    Glaub mir ... 😉

    0
Anmelden zum Antworten