Hi,
ich bin dabei mir ein kleines Strategiespiel zu bauen. Ich habe zu anfang
SDL benutzt, bin aber schnell auf die probleme gestoßen, die Prefect in seinen neuen Tuts angesprochen hat. Nun hab ich eine kleine OpenGL engine fertig, welche auch ein kleines vising system drin hat, um nicht immer die ganze karte zu zeichen. Am Anfang dachte ich mir nichts dabei, weil es so relativ schnell ging. Aber, heute in der Schule war das große erwachen.
Wir haben dort PIII 600 mit TNT2 und es ruckelte abartig. Klar, die Rechner sind nicht aufs zocken eingestellt und es ist viel Software drauf, die sehr Systemhungrig ist. Aber es ist mir zu langsam. Lange Rede, kurzer sinn:
Display Lists entfallen bei mir, weil es nicht so viele Objekte gibt, wo ich genau sagen kann, dass diese immer zusammen auf dem Bildschirm sind.
Meine frage ist nun, kennt sich bei solchen Problemen jemand aus? Also, weil jemand Tricks, mitdenen man das Spiel auch auf rechnern, welche nicht gerade zum Spielen geeignet sind, ordentlich zum laufen bekommt? Ich meine, HL geht auf den rechnern auch gut zu Spielen (halt blos nicht so richtig mit OpenGL). Wenn jemand was weis, wäre ich für eine Antwort sehr dankbar. Wenn sich hier jemand durch flamen Präsentieren will, soll ers doch bitte lassen und wieder im Sandkasten mit seinen Spielzeugautos der Held sein.
Danke....

Die Welt geht unter, gehen sie mit!

Zitat:

welche auch ein kleines vising system drin hat

georg-wicherski@pixel-house.net | http://www.pixel-house.net/ - Coding Resource| http://www.google.de/

naja ich könnte dir gl-vertex-arrays empfehlen. Solltest du z.B. deine Polygon-Daten als double speichern, so solltest du besser auf floats umsteigen! Dinge wie z.B. Backface-Culling solltest du besser nicht OpenGL überlassen, sondern direkt prüfen ob die Kamera hinter einer Polygon-Ebene liegt - da muss das Zeug nicht durch die ganzen "GL-Pipelines". Ich seh schon ein, dass sich meine Hinweise eher auf 3D-Shooter-Engines beziehen, aber vielleicht kannst du damit trozdem was anfangen. Die Sache mit dem Vising-System müsste eigentlich bei Strategiespielen einfachre zu realisieren sein als z.B. bei einer "normalen" 3D-Engine. Vielleicht kannst du da noch was verbessern...

@Diablo_bth: var und selbstgebrautes backfaceculling passt net zusammen, ausserdem muss es net 'durch die ganzen pipelines', backfaceculling wird schon sehr frueh vorgenommen, ausserdem spart das ungemein fillrate (das ist ja wohl das problem bei ner tnt2)

'KEINE PANIK' - aus der Triologie in fuenf Baenden von Douglas Adams

'FÜR DEINN FERD' - aus 'Gevatter Tod' von Terry Pratchett

hmmm, ich hab in sachen vising und allgemein openGL net so viel erfahrung, dass ich evtl. super algorythmen habe. naja, mein vising ist eigentlich n rel. komische sache, vorallem weil es noch n kleinen fehler hat, der aber nicht so schlimm ist. Und zwar ist das, wenn ein array (was meine karte darstellt) nur sagen wir 80 elemente in x und y hat, ich aber schon eins mehr male, damit der übergang flüssig ist, dann kann es ja passieren, dass ich irrgendwann mal am ende der karte bin. deswegen hab ich das n bissl "größer" und vielleicht net grade intiligent gemacht, aber was solls. Eigentlich wollte ich den fehler auch vermeiden, aber da muss ich nochmal pfeilen. Hier ist es nun:
if(scroll_x < 64) min_x = 0; else min_x = 1;
if(scroll_y < 64) min_y = 0; else min_y = 1;

if(scroll_x == (((MAP_H)<<6)+screen->h)) max_x = 0; else max_x = 1;
if(scroll_y == (((MAP_H)<<6)+screen->h)) max_y = 0; else max_y = 1;

ty = ((scroll_y>>6) + (screen->h>>6) + 1+ max_y);
tx = ((scroll_x>>6) + (screen->h>>6) + 1+ max_x);

for(y=(scroll_y>>6)-min_y;y < ty; y++) //vising
{
for(x=(scroll_x>>6)-min_x;x < tx; x++)
{

MAP_H und MAP_W sind die definitionen der größe der karte. x und y die loopvariablen, und scroll_x und scroll_y die linke obere ecke des bildschirms. screen ist ein zeiger vom typ SDL_Surface. mehr ist da ja eigentlich net...

Die Welt geht unter, gehen sie mit!

@ trk: wegen den problemen in der schule, mach dir nix draus, das liegt an den graka-treibern.
wenn ich zb cyanides oder diablos engine in der schule laufen lassen, hab ich immer ~1fps ->wahrscheinlich ist das das minimum,denn manchmal tut sich ne halbe minute gar nichts :P

„Und da wir uns ja seit heute etwas näher gekommen sind, kann ich nur sagen: Mir hilft da immer Norther volle Lautstärke (so wie jetzt), sodass die ganzen unrasierten, Wasserpfeife rauchenden, alternativen Wichsstudenten aus ihren, aus Bananenschalen und Abfall gebastelten, Sitzkissen fliegen.“

Hmm, jo, kannst echt Recht haben :D
wenn ich die Admins in der Schule so ansehe, hrhr
Die lassen nen Linux Server (denke so 600 MHz) als Datenserver mit ner
20 GB Platte (wie heute erfahren) und mit vollen extras (KDE usw) laufen. Der soll dann Daten von 300 Schülern aufnehmen können, hrhrhrhr
Naja, ich progel dann mal fröhlich weiter :D

Die Welt geht unter, gehen sie mit!

Also, ich hab auch ne TNT2, und die kann den kompletten Bildschirm bei wenig Overdraw - dafür alle Blits mit Alphablending (!) - locker 100x pro Sekunde refreshen. CPU ist dabei ein Athlon 550 Mhz.

Es wird also wohl eher daran liegen, wie du die Daten selbst übermittelst. Aber selbst Vertex Arrays und Display Lists sollten bei so einer Konfiguration nicht notwendig sein - wie gesagt, bei meinem 550Mhz/TNT2/AGP gibt's keine Probleme mit ganz normalen glVertex-Calls.

Schritt 1 ist also, die Treiberversion usw. zu prüfen (glGetString). Womöglich verwendest du nen Softwarerenderer...

Schritt 2 ist es, unnötige Statechanges zu vermeiden. glEnable/glDisable und glBindTexture sind absolute Performancekiller. Wenn du (was bei einem RTS naheliegend ist) Tiles zum rendern verwendest solltest du in Erwägung ziehen, alle (bzw. viele) Tiles in eine einzige große Textur zu packen.

Schritt 3 ist es, die Spielelogik selbst zu optimieren. Evtl. verwendest du ungünstige Datenstrukturen zum Speichern der Karte... um das einigermaßen zu bewerten bräuchte man aber mehr Infos (inklusive Code/Header).

Display-Lists: Für ein Spiel mit Tilemap kannst du sehr gut Displaylists für die Karte selbst verwenden. Dabei würde ich immer quadratische Tilebereiche zu einer Displaylist zusammenfassen - je nach dem, wie groß die Tiles sind. Dann rufst du einfach immer die Lists auf, deren zugehörige Polygone zumindest teilweise sichtbar sind (bei quadratischen Flächen ist das simpel). Natürlich mußt du dann noch die Modelmatrix entsprechend modifizieren (glTranslate) um zu scrollen.

Wie gesagt würde es mich aber wundern, wenn dieser Schritt bei einem 600Mhz/TNT2-Setup für ordentliche Performance notwendig wäre.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Hmm, danke Prefect, bist echt super :D
aber, ich kann mit dem begriff "Tilemap" oder "Vertex array" und so nicht viel anfangen :(
vielleicht hab ich das zeug schon, aber ich bin mit solchen begriffen nicht so gut zugange :(
und, wie genau meinst du das mit der display list in der map?
also, mein prob ist dabei eigentlich eins:
ich will ja immer so wenig wie möglich zeichen.
Und das wird ja von der Display List schon wieder extrem eingeschränkt...

Die Welt geht unter, gehen sie mit!

Tilemap bedeutet einfach, daß die Karte des Spiels intern aus "Planquadraten" zusammengesetzt ist. Tile heißt Kachel, und genau das ist es auch. Quasi alle Strategiespiele verwenden Tiles.

Vertex Array ist genau das was es besagt. Ein Array aus Vertices. Du übergibst OpenGL damit ein einziges Mal ein Vertex Array an OpenGL, und in Zukunft teilst du OpenGL nur noch mit, welche Indices des Arrays fürs Rendern verwendet werden soll. Damit kann man die benötigte Grakabandbreite für Geometriedaten reduzieren.

Display Lists: Ich sehe ja ein, daß du so wenig wie möglich zeichnen willst. Aber vergleiche z.B. mal folgenden Code (pseudo-Code):

Quellcode:
... bestimme minx/miny/maxx/maxy je nach Scrollposition ...

for(y = miny; y <= maxy; y++) {
    tile_t *t = tiles[y * height + minx];
    for(x = minx; x <= maxx; x++, t++) {
        float x1, y1;

        x1 = x * TILESIZE - scrollx;
        y1 = y * TILESIZE - scrolly;

        GL_Bind(t->texture);

        glBegin(GL_QUADS);
            glTexCoord2f(0, 0); glVertex2f(x1, y1);
            glTexCoord2f(0, 1); glVertex2f(x1, y1+TILESIZE);
            glTexCoord2f(1, 1); glVertex2f(x1+TILESIZE, y1+TILESIZE);
            glTexCoord2f(1, 0); glVertex2f(x1+TILESIZE, y1);
    }
}


mit:

Quellcode:
... bestimme minx/maxx/miny/maxy der Display Lists ....

glTranslate(scrollx, scrolly, 0);

for(y = miny; y <= maxy; y++) {
   int i = basedisplist + (y * dispwidth) + minx;
   for(x = minx; x <= maxx; x++, i++)
       glCallList(i);
}


Angenommen du verwendest 48x48 Tiles auf einem 1024x768-Bildschirm. Das ergibt 22x17=374 sichtbare Tiles.
Wenn du jetzt Display Lists für 5x5-Quadrate erstellst, dann sind von diesen jeweils 5x4=20 sichtbar. Das macht natürlich 500 Tiles. Andererseits ist es für OpenGL trivial, die überschüssigen 130 Tiles zu clippen, und du ersparst dir das Berechnen der Koordinaten, du sparst womöglich das Hochladen der Koordinaten auf die Grafikkarte, und du kannst die Texture-Binds besser koordinieren. Zudem sind Display Lists generell schneller, weil alle benötigten Daten vom Treiber schon in der optimalen Form vorliegen.
Vieles davon hängt natürlich vom Treiber und von der Hardware ab. Vielleicht sind 5x5-Quadrate auch nicht optimal, und andere Größen wären besser. Auf jeden Fall ist die Methode wert, ausprobiert zu werden.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

ahhh, ok, verstehe, thx
*schaffe schaffe optimiere* hrhr ;-)

Die Welt geht unter, gehen sie mit!

Zitat:

Prefect postete
Vertex Array ist genau das was es besagt. Ein Array aus Vertices. Du übergibst OpenGL damit ein einziges Mal ein Vertex Array an OpenGL, und in Zukunft teilst du OpenGL nur noch mit, welche Indices des Arrays fürs Rendern verwendet werden soll. Damit kann man die benötigte Grakabandbreite für Geometriedaten reduzieren.

das ist FALSCH
eine normale vertex array liegt im system ram.
die beschleunigung liegt darin, dass du sagen kannst 'rendere alle punkte index 0 bis 999 als 3eckstrip' und nicht 'glBegin(...); 1000x glVertex(...); glEnd();'
man spart also den overhead der vielen funktionsaufrufe.

was du eventuell meinst ist CVA (Compiled Vertex Array)
das ist eine extension zu vertex-arrays, die die funktionen glLockArray() und glUnlockArray().
nach glLockArray() kann (!!) der treiber alle daten des mit glVertex/Color/sonstwasArryays(...) angebenen arrays zur graka transferieren.

'KEINE PANIK' - aus der Triologie in fuenf Baenden von Douglas Adams

'FÜR DEINN FERD' - aus 'Gevatter Tod' von Terry Pratchett

Hmm, interessant.
Könntet ihr mal ein Paar funktionen betrf. CVA posten?
Woher bekomm ich dann eigentlich (gute) genaure Infos?

georg-wicherski@pixel-house.net | http://www.pixel-house.net/ - Coding Resource| http://www.google.de/

wo koennte man wohl infos ueber opengl bekommen? hm... www.opengl.org ? nee... das waer' ja zu einfach

'KEINE PANIK' - aus der Triologie in fuenf Baenden von Douglas Adams

'FÜR DEINN FERD' - aus 'Gevatter Tod' von Terry Pratchett

Hmmm, wie ist das eigentlich mit textur größen?
habe gehört, das alte karten nur bis 256*256 können.
wenn ich meine texturen nun aber in ein "sprite" packe, oso,
dann hat das z.b. 256*1024.
wenn ich jetzt aber immer nur 256*64 zeichne, geht das dann trozdem überall?

Die Welt geht unter, gehen sie mit!

Ach, und noch eine "dumme?" frage.
Ich will mit OpenGL etwas auf den bildschrim schreiben.
Wie mache ich das, sodass es auch unter Linux geht?
Oder geht das schon mit dem, was auf nehe beschrieben ist?
Sorry, aber mit Fonts hab ich 0 erfahrung

Die Welt geht unter, gehen sie mit!

1. also mit der 256x256-Textur-Größe trifft zumindest für ältere Vodoo-Karten zu ( hab ich zumindest mal gehört ). Generell kann man sagen, dass 1024er Auflösungen nicht gerade Performance-steigernd sind, deswegen habe ich z.B. in meiner Engine ein Limit von 512x512 Pixeln eingestellt. ( ältere Engines wie z.B. HL sogar auf 256x256 )

2. Auf Nehe werden unter anderem Fonts vorgestellt, die einfach auf eine font-Textur zugreifen anstatt auf die windoof-fonts. Dies müssten eigentlich ohne Probleme auf anderen Plattforman zu realisieren sein, da sie nur auf die gl-API angewiesen sind.

Das maximale Texturgröße kannst du per glGetInteger abfragen (GL_MAX_TEXTURE_SIZE oder so).

Tron, eigentlich hab ich mich ja schon immer gefragt, was Vertex Arrays sollen ;) Für solche 2D-Anwendungen scheinen sie auf jeden Fall relativ sinnlos.
Weißt du zufällig, wie groß der Funktionsoverhead tatsächlich ist? Ich werde wohl mal nen Debugger anstrengen.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

der funktionsoverhead ist RIESIG
ich hab mal ne ganz billige landscapeengine geschrieben (einfach ne heightmap)
zuerst alles per immediatemode (glVertex), dann per VA (Vertex Array)
die fps haben sich locker verdoppelt.
ich benutzte 257x257 vertexe in tri-strips und pushe auf meiner gforce 256 DDR knapp 5*10^6 tris (256*256*2*knapp40fps, vorher unter 20)
ich vermute die beschleunigung koennte noch groeser sein, aber das teil war dann wohl bandbreiten-limitiert (heutige busse sind einfach zu lahm)

btw: probiert NIEMALS sowas riesiges in ne displaylist zu stopfen, davon sinkt die fps nur, da so grose vertexhaufen nicht gut verarbeitet werden koennen, dh. die fps sind niedriger (zumindest koennen das die detonator nicht)

<edit>
ich denke nicht, dass VAs fuer 2d anwwendungen sinnlos sind
</edit>

'KEINE PANIK' - aus der Triologie in fuenf Baenden von Douglas Adams

'FÜR DEINN FERD' - aus 'Gevatter Tod' von Terry Pratchett

Hi, ich habe ein neues Problem, aber evtl. passt es hier ja sogar.
Ich habe nun die Beta 1 meines spieles eigentlich soweit fertig.
Diese basiert auf glOrtho
Nun dachte ich mir: "Hey, wäre doch super, wenn man das Spiel auch in 3D darstellen kann" und so weiter und so fort. Nun habe ich aber ein Problem.
glOrtho lässt es ja nicht zu, dass man wirkliche 3D darstellung benutzt.
Und ohne glOrtho funktioniert mein Button Handling nicht mehr.
Nun habe ich folgendes vor (Pseudo Code)

initialisiere_opengl();
sichere_projektionsmatrix();
glOrtho();

...

if(!game_running)
{
male_menu();
}else
{
male_sidebar();
restor_saved_matrix();
male_spielfeld();
male_figurern();
glOrtho();
};

würde sowas funktionieren? und wenn ja, weis jemand ungefähr wie (namen von funktionen etc). Und würde es das Spiel sehr ausbremsen?
Ich wäre für eine Antwort sehr dankbar´.
Cu
Kane

Die Welt geht unter, gehen sie mit!

Sollte funktionieren. Andererseits wäre es wohl sinnvoller, sich das Speichern der Matrizen zu sparen, und einfach, vom Prinzip her, folgendes zu machen:

Setze Projektionsmatrix Sicht aufs Spielfeld
Rendere Boden
Rendere Einheiten etc..
Setze Projektionsmatrix auf Ortho
Rendere Menü

Immerhin mußt du ja nur zweimal die Matrix verändern, und die Matrix für die Sicht aufs Spielfeld wird sich sowieso sehr oft ändern, daß es nicht lohnt die Matrix zwischenzuspeichern. Die Matrix für Ortho sollte OpenGL relativ schnell erstellt haben, so daß sich ein Speichern wahrscheinlich auch hier nicht lohnt.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.