Forum TI-Planet.org

Comme déjà illustré dans une actualité précédente, le langage de programmation interprété de la nouvelle calculatrice couleur HP-Prime permet des manipulations d'objets graphiques pixel par pixel!
Nous vous illustrions cela avec des démos de scrolling et de zoom/scaling, qui n'étaient possibles qu'en faisant appel au langage de programmation assembleur (lorsque possible) sur les autres calculatrices graphiques.

Mais à partir du moment où l'on a accès individuellement à chaque pixel, sans même parler des transformations tenant compte de la couleur cela permet déjà d'avoir la totalité des transformations géométriques du plan possibles et imaginables!

Voici par exemple une démo de rotation d'une image de 60x60 pixels, par pas de 5 degrés:


Ça change des démos précédentes - on ne peut envisager ici d'utilisation temps réel vu que c'est très saccadé. La transformation programmée ici est en effet bien plus complexe que les précédentes, effectuant deux calculs trigonométriques pour chaque pixel de l'image.

Malgré la lenteur, il est toutefois déjà très honorable qu'elle soit possible.
Il est peut-être même possible de l'améliorer en utilisant des tables trigonométriques précalculées.



Remarquons toutefois que bizarrement, si je remplace l'image de 60x60 pixels intégrée dans le programme par une misérable image de 70x70 pixels, j'obtiens une erreur de mémoire immédiatement au lancement du programme. Le programme initial avec son image intégrée n'occupant que 38Ko, une telle erreur est totalement anormale pour une mémoire SDRAM intégrée de 32Mo, à moins d'un problème de fuite mémoire ou d'optimisation des instructions interprétées côté HP, ou d'un espace mémoire limité réservé à l'exécution des programmes interprétés.



Source programme:
http://www.omnimaga.org/index.php?topic ... #msg304222

...une misérable image de 70x70 pixels...

Bonjour ! La limitation vient en fait de la taille maximale d'une liste très petite... Il me semble que Tim Wessman(HP) évoque cela quelque part comme un héritage de la 39GII qui va être corrigé dans une prochaine version de ROM. J'ai remarqué le même genre de limitation curieuse dans les matrices limités à de petites tailles.

Dommage , je me suis amusé a afficher des gif animés mais je bloque pour y mettre des animations sympas à cause de cette limitation qui oblique à faire des contorsions pénibles (importer l'image par petits blocs pour intégrer des images externes ... J'ai fait des tests avec des images aléatoire et ca marche nickel (genre petite vidéo de 50 images ) Ralentissement obligatoire pour pas que çà aille trop vite !

Quelle est la taille maximale actuelle d'une liste HP Prime ?

Persalteas wrote:Quelle est la taille maximale actuelle d'une liste HP Prime ?

999 éléments par liste. Mais ce n'est pas un pb de mémoire car par exemple une liste contenant 999 élements qui sont eux même une liste de 999 éléments soit .... 1 millions d'éléments passe (au moins sur l'émulateur ) !

MAKELIST(MAKELIST(Y,Y,1,999),X,1,999)
mais
MAKELIST(X,X,1,1000) donne une erreur mémoire émul et hdw

j'espère que ce bug sera vite corrigé.

Vilaine limitation, en effet. Elle est héritée de la HP-39gII qui a beaucoup moins de mémoire, mais sur la Prime, elle est artificielle et arbitraire, et mérite de disparaître au plus vite.

Avec le rotations, il serait possible au lancement du programme de sauvegarder chaque pré-rendu de chaque rotation d'une image dans un autre GROB avec la commande BLIT_P et de les rapeller au besoin, dépendant de l'orientation de l'écran. Je pense notamment à CubeField ou CubeRunner, ou des rotation d'images prédéfinies pourrait contourner la lenteur (quoique bien plus rapide que sur les sutres caltos) du temps réel.

DJ poursuit ses expérimentations, avec un programme PPL de rendu pseudo-3D de sprites qui fonctionne bien et vite



Source de l'info: http://www.omnimaga.org/index.php?topic=17406