SBissay wrote:

ma15fo43 wrote:

Merci, super explication !! Je comprends mieux, maintenant. Et l'exemple sur les prix des objets était super aussi X) par contre je ne comprends pas ton dernier exemple
Celui-là :

SBissay wrote:

(élément (élément (Itérateur) de [Index v] :: list) de [Liste v] :: list)

Ça c'était juste une blague, faut pas chercher…

Mais si tu veux vraiment savoir….
Pour comprendre à quoi ça sert : Si ma liste contient des éléments, mais que je souhaite m'en occuper dans un certain ordre sans modifier la liste (pour une raison quelconque dont on se fiche), alors je peux créer une nouvelle liste qui va contenir l'ordre dans lequel je veux m'occuper de ces éléments, par exemple (4, 3, 1, 2, 5).
Ensuite, pour avoir l'élément qui est à la 4 ème position de l'ordre, eh bien je dois appeler

(élément (élément (4)  de [liste des odres v] :: list) de [liste de départ v] :: list)

(Désolé, je vais avoir du mal à être plus clair que ça, par contre…)

Aaaah compris ^^ mais du coup… ça sert (presque) à rien ^^

SBissay wrote:

Ça c'était juste une blague, faut pas chercher…

Ok XD

SBissay wrote:

Mais si tu veux vraiment savoir….
Pour comprendre à quoi ça sert : Si ma liste contient des éléments, mais que je souhaite m'en occuper dans un certain ordre sans modifier la liste (pour une raison quelconque dont on se fiche), alors je peux créer une nouvelle liste qui va contenir l'ordre dans lequel je veux m'occuper de ces éléments, par exemple (4, 3, 1, 2, 5).
Ensuite, pour avoir l'élément qui est à la 4 ème position de l'ordre, eh bien je dois appeler

(élément (élément (4)  de [liste des odres v] :: list) de [liste de départ v] :: list)

(Désolé, je vais avoir du mal à être plus clair que ça, par contre…)

C'est bon, j'ai tout compris, merci

Hop, un nouveau projet artistique !

Le résultat :


Le concept : 100 particules (invisibles) se baladent à une vitesse constante dans une direction choisie aléatoirement au lancement du projet.
Lorsque 2 particules sont suffisamment proches (à moins de 50 px l'une de l'autre), une ligne est tracée entre les deux particules.

SBissay wrote:

Hop, un nouveau projet artistique !

Le résultat :


Le concept : 100 particules (invisibles) se baladent à une vitesse constante dans une direction choisie aléatoirement au lancement du projet.
Lorsque 2 particules sont suffisamment proches (à moins de 50 px l'une de l'autre), une ligne est tracée entre les deux particules.

Encore une fois, je suis bluffé ! C'est d'une simplicité et d'une beauté !
Un grand bravo !
Je vais me répéter, mais tu es vraiment le griffpatch français !

Bouboufez wrote:

Encore une fois, je suis bluffé ! C'est d'une simplicité et d'une beauté !
Un grand bravo !

Merci, content que ça ne plaise pas qu'à moi

Bouboufez wrote:

Je vais me répéter, mais tu es vraiment le griffpatch français !

Groumpf.

SBissay wrote:

Bouboufez wrote:

Encore une fois, je suis bluffé ! C'est d'une simplicité et d'une beauté !
Un grand bravo !

Merci, content que ça ne plaise pas qu'à moi

Bouboufez wrote:

Je vais me répéter, mais tu es vraiment le griffpatch français !

Groumpf.

Lol
Sinon super beau, je vais tout de suite à la chasse au like et favo !!

Tiens, encore du nouveau :



Ce coup-ci, c'est généré à grands coups de courbes de Bézier cubiques dont les points de contrôle se baladent sur des pseudo-cercles (parce qu'ils se déforment) suivant le principe des wheels curves (voir cet excellent projet).

Je pense que je vais peut-être regrouper tout ça dans un studio, ça serait peut-être plus clair…

SBissay wrote:

Tiens, encore du nouveau :



Ce coup-ci, c'est généré à grands coups de courbes de Bézier cubiques dont les points de contrôle se baladent sur des pseudo-cercles (parce qu'ils se déforment) suivant le principe des wheels curves (voir cet excellent projet).

Cool !

SBissay wrote:

Je pense que je vais peut-être regrouper tout ça dans un studio, ça serait peut-être plus clair…

Yep ^^

Bon, eh bien voilà le studio : Studio.

Et pour fêter ça, encore un projet (je devrais bosser…) : ici.


Là le concept c'est que 3 points se baladent au hasard, et à chaque instant t l'unique cercle qui passe par ces 3 points est dessiné (ou la ligne si les 3 points sont alignés (mais une ligne peut être vue comme un cercle de rayon infini )).

Et paf :

C'est l'automne !

Fêtons ça avec un générateur d'arbres !


(cliquer sur l'image pour aller sur le projet)

SBissay wrote:

C'est l'automne !

Fêtons ça avec un générateur d'arbres !


(cliquer sur l'image pour aller sur le projet)

Si il y a qu'ils veulent comparer avec un de mes anciens projets qui génére aussi un arbres XD https://scratch.mit.edu/projects/93333246/ ( vous comprendre le “XD” après l'avoir vu !)

Bah il est pas si mal ton projet : c'était une bonne idée d'utiliser un mélange de vert et de bleu, c'est plus réaliste.

Le souci majeur c'est peut-être que le pinceau est trop épais et que les lignes droites sont peu vraisemblables. Essayer de faire les branches avec des arcs d'ellipse ou des courbes de Bézier pourrait rendre bien mieux.

Mais je maintiens que ce n'est pas nul. Et puis j'ai un peu plus d'expérience que toi, donc la comparaison est un peu biaisée

En tout cas, heureux que ça te plaise !

( Je sors un peu du sujet )
Pour mon Super Mario je galère un peu pour les hitbox des flammes : c'est à dire que si la flamme est vers le haut, et qu'elle forme un rectangle ( comme sur cette image ( en oubliant les longueurs )), Le X/Y de l'entité se situe au milieu du segment AB, la hitbox x est egale à AB/2 ( donc Xentitée + Hitbox_X = Xb,Yb = Yentiée ; Xentité - Hitbox_X = Xa,Ya = Yentiée ), la hitbox y est égal à CB. ( donc Xentitée + Hitbox_X = Xc,Yc = Yentiée + Hitbox_Y ; Xentité - Hitbox_X = Xd,Yd = Yentiée + Hitbox_Y ). Pour tester si un point se situe dans ces coordonnées, j'y suis arrivée. Mais après vient mon problème, certaines entitées surbissent une rotation, et là pour calculer si un point se trouve dans sa hitbox, c'est plus galère. Si tu as une idée ( PS, si il n'y a pas de crochet autour de AB ou CB, c'est pas un oublie c'est juste que sur le forum sa marche pas )

Alors oui, j'ai une idée : subir une rotation d'angle A c'est avoir son vecteur (x,y) multiplié par la matrice (*)
(cos A -sin A)
(sin A cosA)

Du coup, l'idée c'est de soit appliquer cette rotation aux coordonnées de la hitbox, soit d'appliquer la rotation inverse (d'angle -A) aux coordonnées de l'entité, avant de tester si le point est dans la hitbox comme s'il n'y avait pas de rotation.


Pour calculer l'application de cette matrice aux coordonnées (x, y), il faut faire :
x = x*cosA - y*sinA
y = x*sinA + y*cosA

(en faisant attention à ce que le calcul de y utilise le x initial, donc soit en passant par une variable temporaire, soit pas les entrées d'un bloc custom)

SBissay wrote:

Alors oui, j'ai une idée : subir une rotation d'angle A c'est avoir son vecteur (x,y) multiplié par la matrice (*)
(cos A -sin A)
(sin A cosA)

Du coup, l'idée c'est de soit appliquer cette rotation aux coordonnées de la hitbox, soit d'appliquer la rotation inverse (d'angle -A) aux coordonnées de l'entité, avant de tester si le point est dans la hitbox comme s'il n'y avait pas de rotation.


Pour calculer l'application de cette matrice aux coordonnées (x, y), il faut faire :
x = x*cosA - y*sinA
y = x*sinA + y*cosA

(en faisant attention à ce que le calcul de y utilise le x initial, donc soit en passant par une variable temporaire, soit pas les entrées d'un bloc custom)

Ok merci beaucoup ! Sa devrait énormément m'aider ! (sinon j'aurais pré programmer que 4 directions pour les flammes, droite gauche haut bas alors que là je peux en mettre beaucoup plus )

SBissay wrote:

Pour calculer l'application de cette matrice aux coordonnées (x, y), il faut faire :
x = x*cosA - y*sinA
y = x*sinA + y*cosA

x_entity_final = x_entity*cos(direction) - y_entity*sin(direction)
y_entity_final = x_entity*sin(direction) + y_entity*cos(direction) ?

C'est ça.

Je test

(Sinon fais voir le projet, ce sera plus facile de te montrer en remixant que de tenter d'expliquer sur le forum)