Italian animazione domino

[LordZenzo]

salve a tutti
avete presente il domino?
bene il 1 cade sul 2
quindi cadono 1 e 2 fino al 3
poi il 2 e 3 fino al 4
poi il 3 e 4 fino 5 e cosi via
lo avevo pensato cosi

Sub ruota1_AnimationEnd
    RuotaB
End Sub
Sub ruota2_AnimationEnd  
End Sub
Sub RuotaA  
    If Not(MuoveA.IsPaused) Then  MuoveA.Start(Pezzi(Xa,Ya))
End Sub
Sub RuotaB
    Xb=Xa
    Yb=Ya
    Xa=Xa+1
    Log(Xa & " " & Xb)
    If Xa=5 Then Return
    If Not(MuoveA.IsPaused) Then MuoveA.Start(Pezzi(Xa,Ya))
    If Not(MuoveB.IsPaused) Then MuoveB.Start(Pezzi(Xb,Yb))
End Sub

Sub Label1_Click
    Xa=1
    Ya=1
    RuotaA
End Sub

ma fa cosi
inizia con 1
poi 1 e 2
poi 1, 2 e 3
poi 1,2,3 e 4
poi 1,2,3,4 e 5 e cosi via


nb. vorrei evitare di usare una matrice di animazioni se possibile

 

[LucaMs]

Non c'ho capito un tubo (come al solito ) ma ti consiglio di usare la libreria NineOldAndroids per le tue animazioni.

 

[LordZenzo]

Non c'ho capito un tubo (come al solito ) ma ti consiglio di usare la libreria NineOldAndroids per le tue animazioni.

e certo che non ci capisci un tubo!!! sono mattoncini!!!
ma non sarà troppo complicata?

 

[LucaMs]

ma non sarà troppo complicata?

La libreria o l'app?

Cmq, non ha importanza: tutto è complicato (ma vai a spiegarlo agli utenti di Google Play che vogliono tutto gratuito e perfetto... ah, e pure senza pubblicità!)

 

[LordZenzo]

La libreria o l'app?

la prima
ma anche la seconda che hai detto

 

[LucaMs]

E' un po' complicata, ma non molto più delle altre.

O meglio, è più complicata ma solo perché ha più funzionalità, più informazioni.

Prima di ammattire con varie cosette (ad esempio come ho fatto io per capire come fare un'animazione semplicissima, una view spostata da A a B e poi da B a C !)
magari scaricati questo sorgente che mi era stato chiesto.

 

[LucaMs]

Ecco, come non detto; per quel "progettino" ho usato la AnimationPlus, non la NineOldAndroids.

Beh, magari ti sarà utile lo stesso

 

[LucaMs]

Se userai la NineOldAndroids, ti sarà utile questo post (malgrado io abbia scritto una cacchiata anche là, ma il codice è giusto).

 

[LordZenzo]

Prima di ammattire con varie cosette (ad esempio come ho fatto io per capire come fare un'animazione semplicissima, una view spostata da A a B e poi da B a C !)

ammattisco perche non si tratta di una semplice animazione
mi spiego
il mattoncino a cade sul b, ed insieme cadono sul c
a si appoggia su b, quindi anche b inizia ad appoggiarsi su c mentre a continua a scendere mentre scende b, insomma il gioco del domino
la difficoltà sta nel fare una animazione che non sovrapponga i mattoncini mentre si muovono

 

[udg]

Ciao,
non mi sono mai cimentato con le animazioni e la grafica in generale quindi è facile che dica una sciocchezza: hai considerato l'idea di un'animazione in tre step (es. 30, 60, 90 gradi) da applicare in sequenza ai vari mattoncini finché non raggiungono lo "status" 90 (e quindi sono a terra)?
Immagino qualcosa realizzata con un timer. Ad ogni tick avanzo di uno "status" i mattoncini al momento coinvolti. Quando un mattoncino raggiunge uno specifico status (es. 60) allora coinvolge il successivo e così via.
La posizione di partenza è ovviamente: 0-0-0-0-0; al primo tick avrei 30-0-0-0-0, al secondo avrei 60-30-0-0-0; al terzo 90-60-30-0-0, al quarto 90-90-60-30-0 e così via fino alla situazione 90-90-...90 con tutti i mattoncini a terra.

Ovviamente per una questione di fluidità gli step possono essere ben più di tre; l'importante è decidere a quale step corrispond eil contatto con il prossimo mattoncino.

udg

 

[LucaMs]

@udg ci sarà sempre molto ma molto utile; se anche non conosce qualcosa, ragiona sempre benissimo!

Io, che di solito Sragiono benissimo, in questo momento, invece... peggio, perché ovviamente, data l'ora, mi sono appena svegliato .

A naso (e qui dovreste fidarvi, data la mia dotazione ), leggendo soltanto al volo e senza pensarci granché, mi viene in mente che una di quelle librerie (o almeno una di quelle) ha la possibilità di posticipare le animazioni (qualcosa tipo delay ma potrebbe avere un nome diverso... magari se mi sveglio vado a dargli un cuc - ciao Mamo, in bocca al lupo).

Inoltre, le animazioni si possono "sommare" (raggruppare).

Penso sempre che la libreria più completa sia la NineOld...

Per ora posso darti soltanto questo spunto molto vago e magari pure sbagliato; se proprio dovessi decidere di spremere I due neuroni, dovrei trovare il coraggio di affrontare... beh, se siete curiosi...
https://www.b4x.com/android/forum/t...until-loop-e-company.68253/page-2#post-434569

 

[LucaMs]

se proprio dovessi decidere di spremere I due neuroni, dovrei trovare il coraggio di affrontare...

... ed essendo notoriamente vigliacco e ancora di più curioso, mi sono messo a provare a disegnare il "frame" iniziale e quello finale di un'animazione del genere.

Ora, il disegno fa ovviamente schifo, ma ho provato a farlo perché mi è venuto in mente che, tra gli altri fattori da considerare, ci sono le distanze tra le tessere e LO SPESSORE.

Anch'io non ho quasi mai affrontato animazioni grafiche; so che esiste un problema chiamato anche "collisione"; probabilmente, direi quasi certamente, dovresti essere in grado di calcolare questa collisione, la quale dovrebbe avviare ogni animazione. Appunto considerando anche distanze e spessori, si dovranno calcolare collisioni ma anche durata di ciasuna singola animazione o forse l'angolo di rotazione di ciascuna tessera, che, se non sbaglio, proprio per via dello spessore, dovrebbe variare, non essere uguale per ogni tessera.

Sragiornando mentre scrivo, mi viene da pensare che usare i timer, come suggerito dal maestro @udg, ti consentirebbe di rilevare meglio queste collisioni (sia per quanto riguarda l'inizio che la fine del movimento di ciascuna tessera).

Sempre Sragionando mentre scrivo... penso che dovresti chiedere a gente più esperta; sto pensando che esistano metodi molto più semplici e "diretti" (libGDX + box2D?):

https://www.b4x.com/android/forum/threads/my-first-game-libgdx-box2d.65173/

https://www.b4x.com/android/forum/threads/liquidfun.60602/

(la seconda è piuttosto fuori tema, ma talmente carina che ho voluto "linkarla" )


P.S. ecco, ho appena scoperto che c'è un membro italiano che ha già litigato con questa roba (libGDX + Box2D): @SSDM71. Speriamo si faccia vivo

 

[LucaMs]

Infine... trovato quanto fa per te, già bell'e pronto.

Uno degli esempi sviluppati da Informatix: Box2D_Dominos, che allego.

Avrai bisogno anche della sua libreria, libGDX.

 

[LordZenzo]

intanto grazie dei consigli, non sono davanti al pc ma dal tablet, percui provero nei prossimi giorni
chiaramente la collissione l'ho calcolata con i gradi di inclinazione ed ho usato prima due e poi tre step, il problema principe è proprio la collisione infatti la velocita di caduta del punto di contatto varia col variare dell'angolazione percui il punto di contatto non segue una linea retta uniforme e qui viene il primo problema, il secondo viene dalla libreria usata che non consente ad esempio di usare un qualsiasi punto per la rotazione, infatti se cade a destra ruota su un punto se cade a sinistra su un altro naturalmente e se cade verso l'alto su un altro ancora!

 

[LucaMs]

Beb il problema dovrebbe essere ancora più "grave" (a proposito di gravità ), perché il "punto di rotazione" (direi "fulcro") dovrebbe essere lo spigolo di base, destro o sinistro, chiaramente.

La cosa migliore è usare quanto ti ho suggerito nel mio post precedente; il "piccolo" problema è che la libGDX non è robetta, è molto complessa.
Però, partendo dal sorgente d'esempio, dovresti arrivare (non così semplicemente come si possa pensare, se uno non conosce quegli oggetti) a risolvere nel modo migliore.

 

[LordZenzo]

; il "piccolo" problema è che la libGDX non è robetta, è molto complessa.

azz...
ci sto capendo una mazza

 

[LucaMs]

azz...
ci sto capendo una mazza

PENSO, SUPPONGO, PRESUMO, che in quell'esempio dovresti solo trovare il modo di riempire con una "texture" i rettangoli che rappresentano i bordi delle tessere del domino.

Ovviamente anche come modificare dimensioni e posizione.