getcolor gibts sowas ?

  • Antworten:6
Sascha D.
  • Forum-Beiträge: 74

29.02.2012, 16:57:05 via Website

hallo leute,

ich dachte ich mache erst eine autostrecke mit kästchen a 32x32 pixel. aber die erkennung wo sich dann nen auto befindet wird sehr ungenau.

gibt es sowas wie getcolor ?

jetzt war meine idee ich mach einfach ein bild, was genauso groß ist wie die strecke und lasse das im hintergrund mitlaufen ohne anzuzeigen.
also strecke z.b. weiss und störungen schwarz.

erkennt er auf der stelle eben ne farbe dann ist es ein hindernis.

oder gibt es einen anderen trick um runde objekte zu erkennen ?

also ich bräuchte quasi ein bitmap.getcolor(x,y) oder sowas.

Antworten
Maximilian O
  • Forum-Beiträge: 990

29.02.2012, 18:38:21 via Website

Hey Sascha,
genau das selbe habe ich gestern auch gesucht und gefunden.

Die Methode heißt nicht Bitmap.getColor(), sonder Bitmap.getPixel(), diese liefert dir die Farbe als Integer zurück. Nun kannst du mit
1int r = Color.red(farbe);
2int g = Color.green(farbe);
3int b = Color.blue(farbe);
den RGB Wert bekommen.

Liebe Grüße Maximilian

— geändert am 29.02.2012, 18:39:01

Vergiss nie wieder Geburtstage, oder viel schlimmer, deinen Hochzeitstag - Birthdays Download

Antworten
Sascha D.
  • Forum-Beiträge: 74

01.03.2012, 09:07:07 via Website

danke, scheint das zu sein, wo nach ich gesucht habe.
dann kann ich jetzt mal mein testspielchen umschreiben.
vorher hatte ich kästchenerkennung. und dann kam mir die idee, die handys heute haben soviel speicher, da brauchst keine tiles machen, da kannst gleich ne 8mb grafik oder sowas laden.

oder liege ich falsch, dass ein bild mit 1600x1600 hinmalen schneller geht als ständig 25x15 kätchen ala 32x32 pixel ?

Antworten
reiti.net
  • Forum-Beiträge: 339

01.03.2012, 12:38:32 via Website

das kommt drauf an, wie du die Kästchen zeichnest und wie gross das display ist und ob skaliert wird oder nicht und mipmapping genutzt wird .. usw usw :-)

Für Deinen Fall sind Kästchen schneller, sofern du nur die zeichnest, die auch sichtbar sind

Zur Collision Detection - ja das geht auch mit Farben und das kannst du sogar in nem shader und offscreen-buffer machen .. bei einfachen geografischen objekten und ein bisschen space-partitionierung wäre die mathematische collision detection aber schneller und du könntest mit vektoren arbeiten um bspw. einen abprallwinkel herauszufinden.

Sonst geht's dir wie vielen Spielen in den 80ern, dass der Spieler an jeder kleinen Ecke hängen bleibt ;-)

Kreise lassen sich perfekt und schnell "kollidieren" indem du einfach den abstand zwischen deren mittelpunkt nimmst - ist der kleiner als 2xradius (sofern gleich gross) = kollidiert und du hast gleichzeitig den impact-vektor ;-)

Ich weiß auch nicht, warum hier color picking so populär ist .. performance technisch macht das erst bei über 10.000 objekten sinn (und dann ist es zu ungenau)

— geändert am 01.03.2012, 12:40:47

Antworten
Sascha D.
  • Forum-Beiträge: 74

01.03.2012, 13:46:03 via Website

hab nur mal aufm rechner in swing getestet wie schnell ganze karte ist oder eben kästchen.
gut ich habe die kästchen noch nicht optimieren lassen, aber da war die kästchenvariante 333 bilder pro sekunde
und die variante mit einer karte a 1600x1600 pixel 1000 bilder pro sekunde, also rechenaufwand fast nix trotz pixelfarberkennung und der scheint auch ganz genau zu erkennen, wo die strecke ende ist.
jetzt muss ich das selbe zeug nur mal ins handy portieren, obs da auch zügig nach meinen vorstellungen läuft.

Antworten
Sascha D.
  • Forum-Beiträge: 74

01.03.2012, 18:02:36 via Website

nee nicht opengl ich teste das immer erstmal in swing, weil da das compilieren schneller geht und dann bau ich das auf android SurfaceView mit canvas um.

Antworten