Libgdx Spielfeld

Hey Leute…
ich habe jetzt mal angefangen den Umgang mit Libgdx zu erlernen, und naja… folgendes:

Ich zeichne das Spielfeld, und dachte mir so ich füge etwas Text hinzu.
Resultat:

bitte warum…??
Ich zeichne halt mit

for(...){
    batch.draw(region, x, y ...); //die sechsecke
    font.draw(batch, "test" + hexagon.getMapx() ...) //den text
}

wenn ich aber - und jetzt kommt die pointe - das hexagon.getMapx() entferne, dann passiert das nicht.
(An der Stringkonkatenation liegt es nicht, es liegt an dem Methodenaufruf irgendwie)

Aber - es sieht so aus:

die seltsamen Streifen sind verschwunden, aber die grünen “texturausschnitte” am ende der klammern in dem fall tauchen auf…

was mache ich falsch? Oder ist der fehler vielleicht ganz wo anders und das ist das Endresultat wie das bei Opengl halt mal passiert?
(Nach dem Motto man baut einen Bug ein der seine Auswirkung 10 Jahre Später auf einem anderen Handy eines anderen Betriebssystems zeigt…
ich habe das ganze auch auf stackoverflow gefragt, aber da ich mir dachte ich war lang nicht mehr aktiv melde ich mich auch mal hier ^^
textures - Libgdx strange batch behaviour - Stack Overflow)

Die Implementierung von OpenGL obliegt beim Hersteller. Wenn also ein Bug auftritt dann liegt da Problem bei dem Hersteller deines Smartphones.

Ich kenne mich mit LibGDX jetzt nicht aus aber denke solche Grafik “bugs” schonmal gesehen zu haben.
Direkt fällt auf dass die Streifen die “grün schwarze” Farbe des Hintergrunds besitzen.
Einzelne verzogene Texel sind darin sichtbar.
Teile der Textur dieser Streifen haben einen unterschiedlichen Alpha Level.

Es deutet alles darauf hin das ein Zeichenfehler im OpenGL Kontext vorliegt. Sowas sieht man häufig bei Memory Fehlern.

Du sagst es liegt am Aufruf der Methode und nicht an der String annotation.
Hast du mal bei der zweiten “wtf” Variante, die du als Beweis dafür anbringst, in der Schleife trotzdem
int x = getMapx();
ausgeführt und geschaut ob der Fehler weiterhin auftritt?

Ohja, … fehlt nur noch ein komplett Grün-Schwarzer FileChooser :smiley:

Mal im Ernst: Es ist schwierig, d.h. wenn man nicht selbst schon “den” Fehler mal hatte (und behoben hat), und man das nicht per KSKB testen kann, kann man erstmal nur raten. Meine Tipps wären deswegen ähnlich im Trüben stochernd wie die von TMII:

  • hexagon.getMapx() aufrufen aber nicht für den String verwenden
  • hexagon.getMapx() NICHT aufrufen, aber “zufällige” andere Strings als “wtf” verwenden - z.B. auch die, die MIT hexagon.getMapx() entstehen WÜRDEN
  • Fonts sind IMMER kacke. Kann man da zum Testen mal andere Fonts oder Schriftgrößen einstellen?
    Verändert sich das irgendwie, wenn man zoomt oder draggt (falls das geht…)

ich werde morgen mal ein kskb reinstellen, wenn ich es bis dahin nicht hinbekomme.
Danke für die Vorschläge.

Habt ihr denn die Möglichkeit ein Projekt mit Libgdx für Android mal eben laufen zu lassen?

Ja der Fehler bleibt bestehen, wenn man draggt. anscheinend ist da irgendwo ein “fest verankerter” geometrie memory bug oder so…

Jupp ich entwickle größtenteils auf Android, wenn ich das Projekt einfach in Android Studio importieren kann dann sollte das kein Problem darstellen

ok ich bin komplett verwirrt… offenbar liegt es daran dass der resultierende string 5 zeichen lang ist [x:y]…
bestätige ich gerade, probiere alles mögliche aus.
jap. liegt daran… bei 6 zeichen ist oben rechts die ecke eingeschnitten oder wie man das nennen will.

ich versuch jetzt mal andere fonts oder ne andere größe.

gucke ob ich später ein kskb bastel… ich müsste ja die texturen iwi ersetzen mit PixMap’s oder so?
Muss mal gucken

*** Edit ***

ok also es liegt offenbar irgendwie an der verbindung mit den hintergrund hexas die gemalt werden.
alleine die schrift da passiert nichts. gut, irgendwie auch logisch. ich teste weiter.
ein string mit " " erzeugt die streifen übrigens auch nicht ". " auch nicht. … what the fuck

*** Edit ***

ok offenbar entsteht der fehler nur wenn der string 5 bzw 6 zeichen lang ist und von diesen kein zeichen ein leerzeichen ist.
wenn ich den string dann um ein leerzeichen verlängere entsteht gar kein fehler mehr. (auch nicht von 5 auf 6)

*** Edit ***

verwendeter font und größe spielen keine rolle.
was zum…

ich werde aus diesen komischen streifen auch nicht wirklich schlau

*** Edit ***

offenbar zieht sich immer ein dreieck vom ende des ersten felds (unten links) zu allen anderen… kann das sein?
und das gönnt sich irgendwie die texture des felds…

*** Edit ***

ok das mit den leerzeichen war quatsch. ein leerer string mit " " funktioniert genauso (nicht).

*** Edit ***

okay also anscheeeeinnendd…
liegt es irgendwie daran, dass meine geometrie von den hexas falsch ist…
vielleicht habe ich einen fehler im “algorithmus” eingebaut…
weil wenn ich daraus einfach ein dreieck mache (gehardcoded) dann gibts keine fehler mehr
gucke jetzt

yes… das ganze lag an meiner geometrie irgendwie war da irgendwas mit den indicies kaputt…

sorry :frowning:

Hast du die Hex-Grid-Geometrie selbst erstellt? (Ich hatte gesucht, und es sah aus, als gäbe es da für libgdx ja schon ein paar Klassen…)

yes… Das sah auch danach aus, dass die Indices “falsch verdrahtet” wurden. Alle zeigen nach “rechts oben” Richtung (+…, +…). Das ähnliche Problem hatte ich auch schon mal, allerdings ohne high level Bib. und in 3d.

Eine falsche Zusammensetzung der Indices liegt an den VBOs.

uhm… ja… ich habe das selbst gebastelt, weil ich dachte es ist nicht so viel arbeit und eigentlich kann man da ja auch nichts falsch machen.
offensichtlich ja schon ._. problematisch wirds halt nur, wenn der fehler nicht sofort sichtbar ist… sondern erst wenn man versucht einen
text mit 5 zeichen länge zu zeihnen. ZUSAMMENHANG? da kommt man ja nicht drauf…

zum glück wollte ich die koordinaten in der form [x:y] rendern, sonst wäre mir immer noch nicht aufgefallen dass da was faul ist :smiley: