Hello,
J'aimerais pouvoir éviter ce genre de cas :
http://imgur.com/zbymPRE
Des idées ?

J'ai déjà essayé de remplacer les collisions par d'autres sensors (genre ray ou radars), mais ça me donne beaucoup plus de problèmes.

Merci.

Salut, je connais pas Blender mais j'utiliserais pas un moteur physique ou des collisions si complexe juste pour un Tetris Mais un quadrillage avec des cases "pleines" ou "vides".

Par contre, si c'est autre choses, je sais pas Tu veux faire quoi exactement

Réduit a peine la taille des blocs. Essayer de casser le système de collision de base ou d'en recomposer un autre est vain, ce serait la solution la plus simple. Visiblement, il considère, a juste titre, que des boites partageant une même coordonnée sur un de leur bord sont en collision, et ça ne sert a rien d'essayer d'aller a l'encontre de ce principe simple et générique.

MouchMan, j'essaie effectivement de créer un Tetris et quelqu'un sur un forum anglais m'a répondu la même chose que toi
Mais comme mon niveau en python est pas très avancé, le moteur physique me semble le plus simple.

Je vais essayer en réduisant la taille des blocs, VDD.

Des coins arrondis/biseautés si tu ne veux rien changer.

Perso, j'ai passé beaucoup de temps avant d'utiliser un moteur physique, justement parce que j'étais pas assez bon

Mais essaye un truc avec des matrices quand même Pour savoir si un bloc en (x, y) peut descendre, il suffit de savoir si (x, y-1) est vide.

Si tu débutes, je pense que ça serait plus simple de faire des tetraminos qui descendent "case par case".

Justement, mes tetrominoes descendent à intervalles réguliers jusqu'à ce que ça il y ait une collision en fait.

Et on peut vraiment vérifier si une coordonnée est vide sur Blender ? Sans utiliser les sensors ?
Parce que les matrices j'ai pas encore vu, c'est sensé être dans mon programme de cours de maths de l'année prochaine en fait

Nan mais quand je dis matrice, je pense à des tableaux dans un tableau Genre ça http://pastebin.com/1wBBRGjG

Et puis Tetris, on dirait pas comme ça mais c'est pas si évident que ça à faire, un sokoban c'est déjà plus simple

Mon but reste quand même de combiner Blender et Python (c'est dans le cadre d'un projet scolaire justement), donc ouais, si je tente avec des tableaux, Blender devra faire office de modélisation du jeu.
Je vais tester ça (car c'est mal barré les collisions ...).

C'est vrai qu'un Sokoban, ça à l'air izzy à faire; je tenterais ça aussi (plus j'ai de matière, mieux c'est).

Mais je vois pas comment tu fais pour associer Blender et Python Blender c'est pas sensé être un logiciel de modélisation 3D ?

M'fin, chais pas, avec python en ISN, pour faire des jeux en 2D, moi j'ai utilisé Pygame

A la base, mon Tetris est en 3D, c'est juste la caméra que je lui mets qui rend ça en 2D (Le troisième axe tu t'en fiches complètement pour le Tetris).

Blender, c'est en effet un logiciel de modélisation, mais il possède aussi un moteur de jeu appelé le Game Engine et c'est super puissant pour aucune notion de programmation (le Sokoban avec les logics bricks du Game Engine, n'importe qui peut le faire en fait).
Mais justement, que ce soit dans la modélisation ou dans le Game Engine, Python te facilite quand même la vie pour les opérations de masse.

Parce que là, je pensais reproduire un Tetris pour tester mes compétences, car ultimement, mon but c'est de faire mon propre 'petit' jeu en 3D (mais comme j'ai pas d'inspiration pour le moment ...) et c'est vraiment à ce moment-là que Blender me servira.

Oh okay, je pensais que tu programmais toi même Et donc là, je sais pas si ça va te servir s'que je t'ai dis sur les tableaux

Le problème avec mon programme, c'est que tous mes blocs descendent de 1 toutes les x secondes, ce qui fait qu'en fait, si je réduis la taille, j'aurais pas de collision.
J'ai essayé de les tronquer, ou d'arrondir les coins, mais ça me donne des trucs étranges aussi : les blocs s'arrêtent pas toujours.
Donc il y a un réel problème au niveau de ma manière de procéder.

C'est le problème qu'a relevé le second. Ce que je pourrais essayer de faire c'est d'éviter le mouvement saccadé et y aller avec la gravité; là, réduire la taille m'aiderait.
Mais après j'ai le problème avec les collisions de côté .. Arg complexe

Ah. D'habitude, arrondir les coins résout pas mal de problèmes sur les collisions aux limites.

Il ne te reste donc que le tableau à deux dimensions : lorsqu'une pièce s'arrête, elle remplit les cases correspondantes. Pour savoir si tu peux tomber ou non, il te suffit de regarder toutes les cases situées sous l'élément le plus bas de ta pièce.

Ouaip, je vais tenter avec les listes; je pense avoir assimilé le concept de parcours d'une liste dans une liste, surtout le fait qu'il faut la parcourir depuis le bas, sinon ça ne joue pas.

Ouaip c'est bon, les listes marchent impéc' et j'ai intégré ça à une représentation sur Blender.

Le problème, c'est que, pour une raison inconnue, plus j'ai de cubes au sol, plus ça lag.

Désolé pour le triple post :
Pour faire des rotations, je suis censé faire comment avec des listes dans une liste si ce n'est coder toutes les possibilités ?

C'est une possibilité. Tu peux également te poser la question "Comment passer d'une pièce à une pièce tournée ?". Étant donné que tu ne fais que des rotations à 90°, tu devrais trouver une solution élégante.

Pour ton problème de lag, c'est anormal : il y a trop peu d'éléments en jeu pour que ça soit naturel, tu dois probablement créer des listes pour des besoins temporaires et ne jamais les détruire. Ou alors tu parcoures trop ces dernières.

C'est les questions que je me suis posées en fait.
Mais pour une rotation, il faut un centre de rotation et si je le mets sur une partie de mon tetrominoe ou bien n'importe où, chaque partie bougera différemment. Ce qui fait que finalement, je vais me retrouver à programmer toutes les possibilités.
La rotation à 180° passe encore, car j'ai juste à inverser le tableau et à retourner les coordonnées de mon tetrominoe, mais 90° ...

Sinon, ma liste est jamais détruite, mais c'est vrai que je la parcours constamment (vérifier si je touche pas les bords, vérifier si je touche pas du sol, les inputs et les mouvements, vérifier les coordonnées pour la représentation sur Blender; c'est vrai que ça fait beaucoup, mais c'est un peu obligatoire de tout le temps checker ça nan ?).

Pour la rotation à 90°, tu peux voir ça comme un changement de repère. Trace une pièce, le zigzag, par exemple, sur un bout de papier quadrillé où tu marqueras l'origine et que tu découperas. Amuse toi à faire des rotations avec et de garde pour un point p la différence entre sa coordonnée initiale et sa version tournée.

Pour les tests de collisions diverses, pourrais-tu publier ton code sur pastebin ou autre ? J'aimerais voir comment tu gères ça, tu as peut-être zappé un truc pas évident pour quelqu'un qui découvre ce genre de structures de données.