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

1

30.04.2014, 11:15

SDL2: Prozentuelle Berechnung aller Farben in einer SDL_Texture

Hallo,

ich bin noch ziemlich frisch in Sachen C++ und SDL und habe einige Realisierungsprobleme bei meinem ersten Spiel.

Ich habe ein paar Fragen, ich hoffe ihr könnt mir diese beantworten:

1. Ich habe eine SDL_Texture, auf der ich jeden Frame pro Spieler ein circa 100x100px großes Rechteck rendere, die Position ist abhängig von der Spielerposition. Ist es da ein guter Ansatz, SDL_RenderFillRect zu nehmen? Oder sollte man die GPU dafür nicht benutzen?

2. Später habe ich als Resultat ein buntes Bilder mit n+1-Farben (schwarzen Hintergrund zugezählt), wobei n abhängig ist von der Spielerzahl. Wie bekomme ich nun raus, welche Farbe ein einzelner Pixel hat? Benutzt man dafür die Funktion "SDL_RenderReadPixels"? Wenn ja, kann mir jemand ein Beispiel für den Aufruf der Funktion geben?

Es werden sicher noch mehr Fragen folgen.

Vielen Dank im Voraus!

Jannik

Architekt

Community-Fossil

Beiträge: 2 481

Wohnort: Hamburg

Beruf: Student

  • Private Nachricht senden

2

30.04.2014, 11:29

Zum Auslesen der Pixel würde ich dir zu SDL_LockTexture raten. die Doku sollte selbsterklärend sein.
Zu 1: Afaik wurde SDL_RenderFillRect genau für solche Dinge gemacht. ;)
Der einfachste Weg eine Kopie zu entfernen ist sie zu löschen.
- Stephan Schmidt -

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

3

30.04.2014, 11:35

Aus einer Textur zu lesen ist eine ganz schlechte Idee. Das ist vermutlich doch sogar überflüssig. Wozu willst Du das denn machen, jannik?
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Architekt

Community-Fossil

Beiträge: 2 481

Wohnort: Hamburg

Beruf: Student

  • Private Nachricht senden

4

30.04.2014, 11:41

Guter Punkt. Aus der vorherigen SDL_Surface zu lesen sollte besser sein.
Der einfachste Weg eine Kopie zu entfernen ist sie zu löschen.
- Stephan Schmidt -

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

5

30.04.2014, 11:45

Ich vermute er will auf einen Kollisions-Test hinaus, den er einfacher wohl mit Rectangles als logische Koordinaten bekommt statt per Pixel-Test.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

6

30.04.2014, 11:51

Danke für die Antworten. Das habe ich mir fast schon gedacht...

Natoll.. Was bringt mir das Rendern der Rects in die Textur wenn ich Sie später nicht auslesen kann.
Ich hab das ja nun alles auf SDL_Texture's ausgelegt. Ich sehe da nun drei Möglichkeiten:
a.) Muss ich die Textur komplett durch ein Surface ersetzen?
b.) Muss ich ein SDL_Surface parallel laufen lassen und da auch reinmalen?
c.) Zum Berechnen die Texture wieder in ein Surface umwandeln, geht/muss das?

Wie würdet ihr das machen?

Edit:\\
Ich will auf keine Kollisionsüberprüfung hinaus, ich will einfach berechnen in Prozent, wieviel Farbe jeder Spieler auf dem Spielfeld verteilt hat.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

7

30.04.2014, 11:55

Um das berechnen zu können müsstest Du ALLE Pixel auslesen, was so oder so ganz schlecht ist. Wenn Du die Rechtecke hast, weißt Du doch schon wer wie viel Prozent besitzt. Es ist jedenfalls deutlich besser das anhand der Rechtangles auszurechnen als es abzuzählen anhand der Pixel - auch wenn vielleicht etwas komplexer.
In eine Textur zu rendern bringt Dir etwas - Du kannst etwas anzeigen. Genau das ist auch nur der Sinn von Zeichen-Operationen, sie erstellen etwas visuelles. Für Logik-Operationen ist das nicht gedacht.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Architekt

Community-Fossil

Beiträge: 2 481

Wohnort: Hamburg

Beruf: Student

  • Private Nachricht senden

8

30.04.2014, 11:58

Was genau soll das denn überhaupt werden,? Fangen wir doch mal von vorne an. Ansonsten könntest du auch das ganze Spielfeld in kleine Tiles einteilen, die jeweils durch eine Farbe besetzt werden:

Zitat

|Rot|Grün|Schwarz|
|Blau|Weiß|Gelb|

Diese Tiles oder Felder wären dann immer gleich groß. So wären die Farben sehr einfach zu identifizieren.
Der einfachste Weg eine Kopie zu entfernen ist sie zu löschen.
- Stephan Schmidt -

9

30.04.2014, 12:20

Die Spieler haben halt die Möglichkeit, andere Farben zu überschreiben.

@Archi:
Ich verstehe, was du meinst. Mir wäre es am liebsten gewesen, wenn dies pixelgenau geschehen würde.

Ich geb dir mal ein übertriebenes Beispiel:
Mein Spieler soll also ein Rechteck 50x50 immer unter sich befüllen.
Er steht grad @ 30;30 und hat eine size von 50x50. und der nächste Tile in seiner Richtung wäre @ 30;50 mit ner size von 50 x 50. Dann stände er ja theoretisch drauf, aber nicht komplett, also würde er nur einen Teil der Fläche mit seiner Farbe belegen, aber das geht ja nicht, weil mein Tile nicht zwei Farben kann. Und auch wenn ich die Tiles feiner mache, kann ich mir nicht vorstellen, dass es dann besser gehen würde... Und wenn ích die Tiles zu klein mache, habe ich doch später wieder 100000 Tiles, was ich mir auch nicht sehr performant vorstellen kann...
Ganz zu schweigen von der Kollisionsdetection, die ich mir sehr komplex vorstlele, besonders wennn es zu dynamischen Spieler- und Feldgrößen kommt.

Verstehst ihr mein Problem?´
Vielleicht könnt ihr mir ja ein wenig die Angst nehmen...

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

10

30.04.2014, 12:26

Dann berechne doch immer nur die Stückchen neu, die überschrieben werden und verwende eine Byte-Matrix für die Spielerzugehörigkeit. Ein Flood-Fill auf Rechts inklusive der Überschreibungs-Prozent-Zählung ist jetzt nicht gerade der Hammer. Aber sicher besser als wenn Du ständig alle Pixel testest, was richtig übel ist. Schon bei nur 800x600 Pixeln Spielfläche sind das halt 480.000 Zählungen.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Werbeanzeige

Ähnliche Themen