Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

Evrey

Treue Seele

Beiträge: 245

Beruf: Weltherrscher

  • Private Nachricht senden

31

22.03.2014, 21:55

Zu 1.: ... das geht? Aber selbst wenn, so wäre das ein ziemlich großer Payload an Meta-Daten und die GraKa müsste dennoch ständig Texturen wechseln, bloß in dem Fall ohne CPU-Kommunikation.

Zu 2.: Wird schwierig, wenn man ohne Z-Koordinaten arbeitet. Man könnte da höchstens schauen, ob zwei aufeinander folgende Layer z.B. die selbe Textur verwenden, und so einen Binde-Vorgang sparen.

C-/C++-Quelltext

1
2
3
4
int main(int _argc, char** _argv) noexcept {
  asm volatile("lock cmpxchg8b %eax");
  return 0;
} // ::main
(Dieses kleine Biest vermochte einst x86-Prozessoren lahm zu legen.)

=> Und er blogt unter Hackish.Codes D:

Schwarzefee

Treue Seele

  • »Schwarzefee« ist der Autor dieses Themas

Beiträge: 155

Wohnort: Ost-Sachsen

Beruf: Programmierer

  • Private Nachricht senden

32

23.03.2014, 12:22

Hi,

Zitat

Ich hab das so gelöst, dass ein Layer aus Quads einem Tileset zugeordnet ist, und damit pro Layer nur einmalig das Tileset, also die Textur gewechselt werden muss.


Also müsste ich die Map (pro Layer) einfach in verschiedene, gleich große Bereiche unterteilen. Jeder Bereich hat dann eigene Buffer und nur 1 Texture.
So müssen ja nur die Bereiche gerendert werden, die auch wirklich zusehn sind.

Bleibt immernoch die Frage, wie ich das mit den Texture-Koordianten mache. Muss ich da jede Frame den Texture-Koordinaten Buffer neu an die Graka schicken?


Gruß

Evrey

Treue Seele

Beiträge: 245

Beruf: Weltherrscher

  • Private Nachricht senden

33

23.03.2014, 17:05

Zitat

So müssen ja nur die Bereiche gerendert werden, die auch wirklich zusehn sind.
Momentan habe ich das noch so gelöst, dass der gesamte Layer gerendert wird, also bei einer 256² Tiles großen Map im schlimmsten Fall alle 256²*NumLayers Tiles.
(Selbstverständlicher Weise ist es in der Praxis höchstens der unterste Layer, der wirklich voll werden könnte.)
Da will ich vielleicht erst noch testen, wie stark die Leistungs-Einbrüche durch das Rendern unsichtbarer Quads sind, aber prinzipiell ließen sich die Layer auch in einzelne Sektoren aufteilen, die auf Sichtbarkeit geprüft werden können, ja.

Zitat

Bleibt immernoch die Frage, wie ich das mit den Texture-Koordianten mache.
Momentan habe ich das für QuadLayer so ähnlich wie SFML gelöst, dass ich Vertex-Position, -Farbe, und -Textur-Koordinate gemischt in ein Array verfrachte. Ob ich das irgendwann ändere ist nicht sicher, da es äußerst unwahrscheinlich ist, dass eine Tilemap im laufenden Spiel umgebaut wird. Für solche Fälle gibt es andere Layer-Typen.
Sprites habe ich noch so realisiert, dass alle Vertices ebenfalls durchgemischt in einem Puffer liegen, allerdings erst on demand zur GraKa hochgeladen werden. Da will ich ebenfalls erstmal die Leistung testen, da ich mir nicht recht sicher bin, was langsamer ist: Ständig zwei Matrizen hoch laden, oder vier komplexere Vertices. Ich vermute momentan eher Ersteres.

Man liest es schon an jeder Ecke raus: Teste einfach mal die Möglichkeiten aus. Bastle dir notfalls ein kleines Test-Progrämmelchen, falls du ungern deine Engine oder whatever es ist umbauen möchtest, und lerne aus den Ergebnissen.

C-/C++-Quelltext

1
2
3
4
int main(int _argc, char** _argv) noexcept {
  asm volatile("lock cmpxchg8b %eax");
  return 0;
} // ::main
(Dieses kleine Biest vermochte einst x86-Prozessoren lahm zu legen.)

=> Und er blogt unter Hackish.Codes D:

Schwarzefee

Treue Seele

  • »Schwarzefee« ist der Autor dieses Themas

Beiträge: 155

Wohnort: Ost-Sachsen

Beruf: Programmierer

  • Private Nachricht senden

34

23.03.2014, 17:29

Hi,

jo ich bin schon am basteln und rumtesten ;)

Das mit den Texture-Koordinaten will ich versuchen so zu lösen:
Ich hab für Position, Texture-Koordinaten und Color wieder pro Layer(-teil) 3 Buffer.
Position und Color ändert sich ja so gut wie nie, die lass ich ungeändert in der GraKa (wenn sich doch etwas ändert, lad ich die Buffer halt einmalig neu hoch).
Den TextureCoords-Buffer ändere ich halt jede Frame. Als Optimierung fällt mir imo nur ein, dass ich pro Layer(-teil) noch einen Bool-Wert habe, ob überhaupt animierte Sprite in dem Layer(-teil) genutzt werden. Wenn nicht, muss der Texture-Buffer auch nicht geupdated werden.
Das bedeutet zwar immernoch, dass ich meist jede Frame den TextureCoords-Buffer neu hochladen muss, aber Position und Color nichtmehr.
Das sollte zumindest schonmal nen Geschwindigkeits-Vorteil gegenüber meine alten Variante bringen, wo ich immer bei jeder Frame alles an die GraKa geschickt hab.

Eine andere Frage hab ich noch:
Ich hab mal durchgerechnet, dass eine 500x500 Tiles Map rund 30-40MB an Daten (4 Vertices pro Quad, zu je 9*float). Das sollte doch vom Prinzip her kein Problem für moderne GraKas sein, oder?


Gruß

Schwarzefee

Treue Seele

  • »Schwarzefee« ist der Autor dieses Themas

Beiträge: 155

Wohnort: Ost-Sachsen

Beruf: Programmierer

  • Private Nachricht senden

35

24.03.2014, 10:29

Hi,

Zitat

Zu 1.: ... das geht? Aber selbst wenn, so wäre das ein ziemlich großer Payload an Meta-Daten und die GraKa müsste dennoch ständig Texturen wechseln, bloß in dem Fall ohne CPU-Kommunikation.


Wenn ich Layer zB 5 Texturen verwendet, würde ich einfach vor jedem Rendervorgang

C-/C++-Quelltext

1
2
3
4
5
6
7
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, texture1ID);
glActiveTexture(GL_TEXTURE0 + 1);
glBindTexture(GL_TEXTURE_2D, texture2ID);
[...]
glActiveTexture(GL_TEXTURE0 + 4);
glBindTexture(GL_TEXTURE_2D, texture5ID);

machen.
und im Shader dann einfach

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
if (texCoord.z == 0)
{
   gl_FragColor = texture(texture0, texCoord.xy);
}
else if (texCoord.z == 1)
{
   gl_FragColor = texture(texture1, texCoord.xy);
}
[...]


Würde das nicht gehn, bzw. wäre das zu langsam?


Gruß

DeKugelschieber

Community-Fossil

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

36

24.03.2014, 13:54

Viele Wege führen nach Rom. Du kannst auch einen anderen Buffer mit Integern füllen um dann die Textur auszuwählen...
Aber wenn es so läuft, mach erstmal damit weiter.

Schwarzefee

Treue Seele

  • »Schwarzefee« ist der Autor dieses Themas

Beiträge: 155

Wohnort: Ost-Sachsen

Beruf: Programmierer

  • Private Nachricht senden

37

24.03.2014, 14:04

Hi,

laufen tut im Moment noch garnix ;)
Bin immer noch dabei, erstmal das ganze Drumherum zu schaffen.

Im Moment mach ich mir erstmal nur Gedanken, wie es gehn könnte.
Mich interessiert halt erstmal, ob es überhaupt möglich ist und Sinn macht.

Es bringt ja nichts, irgendwas zu machen wie es gehen *könnte*, nur um dann fest zu stellen, dass es so *nicht* geht, und wieder von vorne zu beginnen.
Deshalb frag ich hier so oft nach, damit ein paar Möglichkeiten schon von vornherein von den "alten Hasen" ausgeschlossen werden können.


Gruß

DeKugelschieber

Community-Fossil

Beiträge: 2 641

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

38

24.03.2014, 15:34

Es geht, ob es schön ist musst du rausfinden, dadurch lernt mans am besten ;)

Evrey

Treue Seele

Beiträge: 245

Beruf: Weltherrscher

  • Private Nachricht senden

39

24.03.2014, 19:30

Zitat

Den TextureCoords-Buffer ändere ich halt jede Frame.
... und warum? Ist es vielleicht ein animiertes Tileset und du schaltest ständig zwischen diesen und jenen Tiles umher? Warum dann nicht einfach pro Animations-Frame einen neuen Textur-Koordinaten-Puffer füllen und jeweils diesen binden?

C-/C++-Quelltext

1
2
3
4
int main(int _argc, char** _argv) noexcept {
  asm volatile("lock cmpxchg8b %eax");
  return 0;
} // ::main
(Dieses kleine Biest vermochte einst x86-Prozessoren lahm zu legen.)

=> Und er blogt unter Hackish.Codes D:

Werbeanzeige