[venom]

Bravo satinas j'ai hâte de tester ça. C'est beau en tout cas.

Venom doit justement nous faire un programme en C pour ce dernier.

laisse tomber je suis en PLS une galère sans noms...


Pour opengl non c'est pas une API windows. C'est une librairie tout OS.






@++

[satinas]

On ne peut plus envoyer d'exe vers gmail, boudiou !
Venom, passe-moi ton mail en MP, merci.

[venom]

Merci satinas,

J'ai bien reçu







@++

[Temps-x]

Bonjour,

satinas, j'avous que je ne suis pas capable de faire ça, pourtant Rapidq à plein d'exemple sur l' OpenGL

Reste plus cas générer un G-code, là !! faut voir avec F6FCO le spécialiste

A+

[satinas]

Merci, pourtant la partie OpenGL c'est à peine 10% du programme, et je ne pensais pas que le reste serait aussi long, on part toujours la fleur au fusil. OpenGL me faisait peur au début, surtout quand on consulte les bouquins qui en parlent, mais cet exemple permet un démarrage rapide avec Qt :
https://ftp.jaist.ac.jp/pub/qtproject/l ... torial.pdf

[F6FCO]

Je viens d'aller voir ton pdf... je reste sur l'assembleur pour le moment

On ne peut plus envoyer d'exe vers gmail, boudiou !

Et en le zippant ? Envoie le moi aussi stp, il pourrait peut-être me servir d'outil pour développer mes algorithmes.

PS: C'est bon, çà charge

Re PS: suis en train de jouer avec, carrément génial

[F6FCO]

Bon, la scoumoune !
Tout fonctionnait enfin bien niveau méca, j'en étais arrivé au stade du code pour la reconnaissance des couleurs et le servo de serrage de la pince gauche me lâche, il est devenu inerte. Plus question de faire tourner le cube, stoppé en plein élan. Je viens d'en commander un autre il devrait arriver dans 8 jours.
En attendant je bascule sur le projet séchoir.

[F6FCO]

Salut les gens,
En attendant de recevoir mon servo j'avance le code.
Après reconnaissance toutes les valeurs de couleur des facettes seront contenues dans un tableau, donc une variable de 54 octets pour 54 facettes, et le plus gros du boulot de résolution va se faire au sein de ce tableau. Pour cela pas besoin du robot je travaille avec le simulateur de MPLAB, je fais des tests et je scrute le résultat dans la fenêtre File Register.
J'aurai pu travailler en mémoire programme avec TABLAT, TBLPTRH, TBLPTRL, TBLRD, TBLWT mais je trouve que ce n'est pas assez souple d'utilisation pour ce que je veux faire, je trouve plus simple de travailler comme dans les langages évolués, je déclare un tableau et je travaille à l'intérieur avec des MOVFF pour déplacer les valeurs. J'ai créé un tableau sous la forme d'une variable de 54 octets, une deuxième encore de 54 octets en tant que mémoire tampon dans la RAM, les deux tableaux occupant trop de place dans la RAM débutant à 0X0C, j'aurais écrasé une variable système (dont je ne sais pas du tout à quoi elle peut servir mais pu importe) alors j'ai déclaré une autre zone de variables juste après à l'adresse 0x0100 qui me laisse toute la place voulue.

Et je rejoins Satinas sur l'utilisation des tableaux, j'ai pensé au départ utiliser les matrices mais n'ayant pas de calculs à faire dedans, juste des manipulations pour changer les valeurs de place à chaque rotations elles ne sont pas d'une grande utilité. Et l'arrangement des valeurs au sein du tableau sous forme d'un cube déplié les manipulations sont un peu acrobatiques donc je vais faire comme lui du point à point. Ca va être long et fastidieux de créer les transpositions mais c'est le passage obligé et je m'y retrouverai lors des manipulations pour la résolution.

Pour m'aider je me suis fabriqué un petit aide-mémoire bien pratique

P1070056.JPG

[satinas]

Salut,
Les matrices c'est bon pour les langages évolués qui proposent des fonctions translation, rotation, inversion, etc. C'est pourquoi cela me gênait car cela masque des tas de calculs intéressants à faire, en plus il faut phosphorer pour les utiliser, ces matrices. Dans ces vidéos il m'a largué dès qu'il est passé aux matrices.
Dans mon cas je calcule aussi tous les layers intermédiaires, pour pouvoir leur appliquer des rotations, si tu ne t'occupes que des 6 faces sur un cube 3x3 cela simplifiera pas mal les choses.
Les fonctions de résolution n'ont pas été simples, et tout est codé en dur. Il faudrait faire un langage de script pour étudier et programmer les diverses méthodes de résolution sans coder à chaque fois. C'est pas le truc que j'aurais fait en asm, t'es courageux
Je vais vous envoyer une nouvelle version, après ajout du mode pas à pas, et il y avait un bug dans la zone de saisie, le fait de taper shift faisait perdre le curseur.

[F6FCO]

Impressionnant le gars, il te code çà en live tout en rigolant . Je ne connaissais pas.
Si tu aimes bien te prendre la tête avec des algorithmes tout en jouant vas faire un tour sur Codingame https://www.codingame.com/start/fr/ Mais attention: ADDICTION ! J'y étais inscrit il y a quelques années mais j'ai arrêté, passionnant mais trop chronophobe.

Il faudrait faire un langage de script pour étudier et programmer les diverses méthodes de résolution sans coder à chaque fois.

C'est un peu ce que je compte faire, coder les routines de base des rotations et modifs du tableau en temps réel, et ensuite les intégrer dans des des macros, il faut qu'au final çà reste concis et lisible sinon ce serait vite imbuvable.