Archiv verlassen und diese Seite im Standarddesign anzeigen : positionsberechnung fuer paletten
raptor666
14.12.2004, 08:12
hi all,
ich habe eine palette mit 20 positionen, 4 positionen in x-richtung und
5 positionen in y-richtung. (punkte a in der skizze unten)
die palettenpositionen sollen berechnet werden aus 3 eckpunkten, also
nullpunkt, letztes nest in x-richtung und letztes nest in y-richtung.
soweit hab ich das auch schon geloest, auch wenn die punkte nicht
achsparallel liegen.
ich verwende zwei zaehler, einen fuer die position in x-richtung und
einen fuer die position in y-richtung.
der zaehler x-richtung wird solange incrementiert bis die anzahl der nester
in x-richtung erreicht ist und dann wieder auf null gesetzt wobei der
zaehler y-richtung um 1 incrementiert wird.
so werden die nester in aufsteigender x-richtung und aufsteigender y-richtung
abgearbeitet.
die positionen errechnen sich aus der anzahl nester in einer richtung und der
laenge zwischen nullpunkt und letztem nest in dieser richtung.
ich suche jetzt eine einfache moeglichkeit die berechnung auch anzuwenden,
wenn es noch ein nest im schnittpunkt von 4 quadratisch nebeneinander
angeordneten nestern gibt. (punkte b in der skizze)
a a a a
b b b
a a a a
b b b
a a a a
...
ich hoffe ihr versteht wie das ganze gemeint ist.
irgendwie kommen mir alle meine loesungsansaetze zu kompliziert vor, vielleicht hat jemand von euch nen tipp wie man das ganze unkompliziert und effektiv loesen koennte.
danke schon mal
gr33tz
hi all,
ich habe eine palette mit 20 positionen, 4 positionen in x-richtung und
5 positionen in y-richtung. (punkte a in der skizze unten)
die palettenpositionen sollen berechnet werden aus 3 eckpunkten, also
nullpunkt, letztes nest in x-richtung und letztes nest in y-richtung.
soweit hab ich das auch schon geloest, auch wenn die punkte nicht
achsparallel liegen.
a a a a
b b b
a a a a
b b b
a a a a
...
ich hoffe ihr versteht wie das ganze gemeint ist.
gr33tz
So wie ich's verstehe ist das ganze ein Halma-Spielfeld
und es soll herausgefunden werden, inwieweit Züge legal
sind... Hm.
Wie wäre es, die b b b Reihe einfach um 1/2 nach links
zu verschieben, dann kämen sie genau "unter" die a a a a
Reihe und das wäre leichter zu berechnen. Wenn dann die
"Zeile" ungerade ist, weiß man, daß es eine b-Zeile ist.
(Die z.B. einen Punkt kürzer ist).
Die Bezüge zwischen allen Punkten würde ich dann als
Tabelle machen. Also: Ein Punkt hat 6 Nachbarn.
2 "Addier" Tabellen (eine für x, eine für y)
hochlinks hochrechts rechts runterrechts runterlinks links
X-Addier: 0 +1 +1 +1 0 -1
Y-Addier: -1 -1 0 +1 +1 0
Die Zielpunkte sind dabei so um den Punkt (X) angeordnet:
1 2
6 X 3
5 4
Wenn der Zielpunkt auf eine "ungerade" (also b) Reihe
trifft (also Startpunkt = a und Zug = hoch/runter), dann
muß man noch 1 von der ZielX-Koordinate abziehen.
Man kann natürlich andere PunktReihenfolgen wählen.
Dabei fällt auf, daß bei X-Addier nur bei "links" eine -1
steht. Dies liegt daran, daß man halt "in Gedanken" die
Palette auf ein "Quadrat-Gitter" normalisiert.
(Btw: Eine ziemlich einfache, kurze und elegante Methode,
um die Ränder des Spielfelds festzulegen, wäre, einfach
jedem Punkt einen 6-Bit-Wert zuzuordnen, der angibt, in
welche Richtungen man ziehen kann und in welche nicht.
Da man sowieso Bytes benutzt, kann ein weiteres Bit
benutzt werden, um den Punkt selbst an/auszuschalten.
(Man könnte auch einfach "um die Tabelle herum" einen
1 Punkt breiten "Rand" aus ausgeschalteten Punkten ziehen.
Dann braucht man nur zu prüfen, ob der Zug zu einem
"illegalen" Punkt führt.)
Man könnte die Reihe sich auch so denken:
a a a a a a
b b b b b b
a a a a a a
b b b b b b
a a a a a a
Dann könnte man AUCH mit so einer "Bezugstabelle"
arbeiten, muß aber nicht "ungerade" Reihen
berücksichtigen, weil alle die gleichen Eigenschaften
hätten. Es sind lediglich die "überstehenden" Punkte
"abzuschneiden". (Z.B. mit der "Punkt an/aus"-Methode
oder dem "Bitmuster" für "gültiges Ziel" oder beides.)
Ich habe versucht, mich kurz zu fassen (gelingt mir nur
selten), daher ist das noch etwas unvollständig. Wenn ich
den Schmarrn genauer erklären soll, meld Dich nochmal.
(Wenn Lust auf PrivateMail: forum(at)igames.inside1.net )
Hoffe, ich habe überhaupt verstanden, was Du wolltest.
Kann ja auch sein, daß ich da jetzt was reininterpretiere
und ich total am Thema vorbeigeredet habe.
raptor666
14.12.2004, 16:17
also erstmal danke fuer deine ausfuehrliche antwort.
So wie ich's verstehe ist das ganze ein Halma-Spielfeld
und es soll herausgefunden werden, inwieweit Züge legal
sind... Hm.
nein, leider nicht.
es ist wirklich eine technische anwendung und ich brauche nur die positionen (keine gueltigen zuege herausfinden ;) )
Wie wäre es, die b b b Reihe einfach um 1/2 nach links
zu verschieben, dann kämen sie genau "unter" die a a a a
Reihe und das wäre leichter zu berechnen. Wenn dann die
"Zeile" ungerade ist, weiß man, daß es eine b-Zeile ist.
(Die z.B. einen Punkt kürzer ist).
so in der art habe ich mir das auch schon gedacht, aber das ganze kann auch etwas in der x-y-ebene gedreht sein - also nichtmehr achsparallel - und dann wird das ganze etwas aufwaendig und unuebersichtlich wie ich finde.
aber wahrscheinlich wird mir nichts anderes uebrig bleiben als mit 1/2 nestabstaenden in den ungeraden reihen zu rechnen, zumindest faellt mir nichts besseres ein.
Hoffe, ich habe überhaupt verstanden, was Du wolltest.
Kann ja auch sein, daß ich da jetzt was reininterpretiere
und ich total am Thema vorbeigeredet habe.
naja, so ein klitzekleines bisschen schon :D :D
Das scheint mir echt ziemlich kompliziert zu sein, was du da machst. Ich würde den Positionen aufsteigende Nummern geben. Die unterste Schicht 0 bis 3, dann 4-6, usw. Wenn das nicht geht, einfach zwei Umrechnungsfunktionen:
BASE = 4
Nummer --> Koordinaten:
Eingabe: nr
y = nr div (2 * BASE -1)
x = nr - y
if (x >= BASE) {
y = y + 1
x = x - BASE + 0,5
}
Koordinaten --> Nummer
Eingabe: x, y
nr = (y div 2) * (2 * BASE - 1) + (y mod 2) * BASE + floor(x)
raptor666
16.12.2004, 09:53
also ich glaub ich poste am besten mal den loesungsansatz den ich soweit schon mal habe fuer die _normalen_ paletten.
wie gesagt die palette kann in der x-y ebene leicht gedreht sein.
pos_y_max
|
x x x x
x x x x
x x x x
x x x x
x x x x
/ |
pos0 pos_x_max
die punkte pos0, pos_x_max und pos_y_max werden eingelernt (jeweils x/y), die restlichen punkte werden berechnet.
als erstes berechne ich den versatz von einem punkt zum naechsten sowohl in x als auch in y richtung.
delta-x_x = (pos_x_max_x - pos0_x) / (anzahl_pos_x-richtung - 1)
delta-x_y = (pos_x_max_y - pos0_y) / (anzahl_pos_x-richtung - 1)
delta-y_x = (pos_y_max_x - pos0_x) / (anzahl_pos_y-richtung - 1)
delta-y_y = (pos_y_max_y - pos0_y) / (anzahl_pos_y_richtung - 1)
danach kann jede position durch einen offset in x und y richtung berechnet werden.
also 2.reihe von unten waere offset_y = 1
3. position von links waere offset_x = 2
position_x = pos0_x + (offset_x * delta-x_x) - (offset_y * delta-x_y)
position_y = pos0_y - (offset_y * delta-y_x) + (offset_y * delta-y_y)
ich hoffe das ganze ist einigermassen verstaendlich.
von der berechnung her habe ich das ganze relativ simpel und kompakt gehalten, denke ich.
fuer andere paletten brauche ich nur die 3 neuen punkte und die angabe wieviel reihen/spalten vorhanden sind.
wenn ich pos0 in ein anderes eck der palette lege und die punkte pos_x_max und pos_y_max entsprechend lege kann ich ganz einfach die reihenfolge aendern wie die palette abgearbeitet wird.
nun suche ich eben eine einfache moeglichkeit eben die oben erwaehnten zwischenpunkte zu berechnen, auf dieses schema aufbauend.
gr33tz
vBulletin® v3.8.6, Copyright ©2000-2012, Jelsoft Enterprises Ltd.