Découverte format image Python IM8C TI-83 Premium CE 5.5

[critor]

Dans sa mise à jour 5.5.1 gratuite, Texas Instruments rajoute de formidables possibilités historiques à ta TI-83 Premium CE :

• mise à jour en 5.5 de l'application SciTools
• mise à jour en 5.5 de l'application Periodic
• mise à jour en 5.5 de l'application Python (TI-83 Premium CE Édition Python uniquement)

Python 5.5 offre de nouveaux modules intégrés pour tes scripts Python :

• time, certes déjà présent mais maintenant listé au menu et donc officiel
• ti_system, avec diverses possibilités :
  
  • détection des simples pressions de touches clavier, y compris avec un clavier USB externe !
  • affichage dans la console à la ligne que tu veux
  • exportation de listes de nombres du contexte Python vers l'environnement de la calculatrice
  • importation dans le contexte Python de listes existant dans l'environnement de la calculatrice vers
  • et donc plus généralement un début d'intégration du Python à l'environnement mathématique de la calculatrice; plus besoin de traiter les tâches numériques à part, l'application Python 5.5 va enfin pouvoir servir s'articulier naturellement au sein de la résolution de problèmes et tâches complexes !
  
• ti_plotlib, une bibliothèque graphique pour tracer dans un repère othogonal, conformément aux programmes de Mathématiques et Physique-Chimie, comparable à matplotl chez Casio ou encore matplotlib.pyplot, et gérant ici les diagrammes suivants :
  
  • nuage de points
  • diagramme en ligne brisée
  • droite de régression linéaire
• ti_graphics pour contrôler directement les pixels de l'écran, comparable à kandinsky chez NumWorks ou encore casioplot
• ti_hub, pour les projets d'objects connectés à l'aide de l'interface TI-Innovator Hub
• ti_rover, pour les projets de robotique à l'aide du TI-Innovator Rover

Mais ce n'est pas tout car Python 5.5 gère également la possibilité inédite de rajouter des modules Python complémentaires :

• ce_turtl, comparable à turtle
• ce_box pour les diagrammes en boîte
• ce_chart pour les histogrammes et aires entre courbes
• ce_quivr pour les diagrammes utilisant des champs de vecteurs

Dans notre exploration de ti_graphics, nous avions découvert une fonction a priori hautement intéressante pour afficher des images, drawImage().
Nous n'avions hélas pas réussi à la faire fonctionner correctement.

Nous découvrions par la suite que les images affichables en question était des variables d'application (fichiers .8xv) à charger en mémoire de la calculatrice.
C'est très malin, drawImage() va donc chercher ses données en externe ce qui évite de consommer du tas/heap Python, surtout que les images pouvant rentrer dans 17K n'atteindraient même pas les dimensions timbre poste.

Aujourd'hui nous disposons enfin d'images compatibles au bon format .8xv !

Voici donc ci-contre le couple mythique de super-héros Tristan et Iseult :

Code: Select all

import ti_graphics as scr
from ti_system import disp_wait

scr.drawImage('BOY_200', 15, 30)
scr.drawImage('GIRL_200', 125, 30)

scr.setColor((255, 0, 0))
scr.drawString('T', 155, 122)

scr.setColor((0, 255, 0))
scr.drawString('I', 175, 117)

Ce qui est exceptionnel c'est la vitesse de tracé, à peine une fraction de seconde pour l'affichage de ces deux énormes images !
Peut-être matière à réutiliser cela pour l'affichage de sprites au sein de futurs superbes jeux en Python pour ta formidable TI-83 Premium CE Edition Python !

Et également de quoi aborder facilement le traitement d'image en SNT puis NSI !

Autre gros avantage, la fonction drawImage() marche aussi bien avec une image placée en mémoire principale (RAM) qu'en mémoire d'archive (Flash).
Tant mieux, de quoi économiser la RAM de 150K déjà lourdement sollicitée par tes scripts et modules complémentaires Python.

En passant notons la taille de l'image BOY_200, 10,830 Ko pour seulement 94×200=18800 pixels.
Nettement moins de 2 octets par pixel alors que nous sommes ici sur un écran 16 bits, et même moins d'1 octet par pixel, il y a clairement une compression à l'oeuvre.

L'exploration du fichier .8xv associé à l'éditeur hexadécimal nous révèle un commentaire intéressant en entête, Created by img2appvar 1.0.0.
Malheureusement nous ne disposons pas de l'outil img2appvar, et ignorons même totalement si il sera publié.

Un identifiant sur 4 octets IM8C débute de plus la partie données, et est donc à rajouter à la liste des types officiels de variables d'application que Texas Instruments est en train d'étoffer :

• PYCD : script Python
• PYMP : module complémentaire Python
• IM8C : image Python

Bref, il s'agit donc ici du format d'image IM8C.

Quelques altérations d'octets nous permettent d'en apprendre un peu plus à son sujet :

• il utilise une palette avec au maximum 256 couleurs, chacune précisée au format RGB-565
• les données image sont par la suite compressées au format RLE

Il y a même 2 octets permettant de rendre transparente une des couleurs de la palette !

Bref, nous avons maintenant a priori tout ce qu'il faut pour te concevoir un convertisseur d'images pour tes futures créations. A bientôt...

Téléchargement : OS + applis TI-83 Premium CE 5.5.1

[Dogm]

Bah le voilà le module pour remplacer l'ASM

[critor]

En effet, n'est-ce pas superbe ?

Ce qui était super compliqué en asm te prend maintenant 1 ligne en Python 5.5 !

[Lionel Debroux]

En C/C++, c'est évidemment plus compliqué qu'en Python, mais nettement plus simple qu'en ASM eZ80, il ne faut pas exagérer

Est-ce que ces fonctions de sprite sont clippées ?
Combien de tas reste-t-il disponible après avoir importé ces modules ?
Quelle est la performance de l'affichage de 20x15 sprites de 16x16 pour remplir l'écran 320x240 ? C'est tout sauf exceptionnel d'afficher un gros sprite en une fraction de seconde, et je pense qu'avec ce test qui nécessite, comme le set_pixel, une communication entre l'ATSAMD21 et l'ASIC à base d'eZ80, qui se fait manifestement avec un lien lent, on va s'approcher de la performance du set_pixel...

[critor]

La consommation de tas due à ti_graphics a déjà été traitée, dans les 1.5K :
viewtopic.php?f=41&t=23857
Pas catastrophique donc.

C'est nettement plus rapide que l'affichage d'une image en Python sur NumWorks, avec une boucle de set_pixel() faute d'alternative.
Pour la Casio Graph 90+E qui est très performante en graphismes Python grâce à son double buffering exclusif à ce jour, c'est moins sûr.

Pour le reste des tests demandés, il va falloir que l'on se fabrique un convertisseur.

[zardam]

Le setPixel passe par un UART à 115200 bauds, et en ASCII (le même que pour la console), ce qui explique en grande partie ses "performances". Je suppose que drawImage doit faire de même.

[DoOmnimaga]

Donc aurons nous enfin notre Reuben Quest partie 1 à 10? (vu qu'il faudrait séparer le jeu en 10 parties pour n'en charger qu'une à la fois sur la calculatrice)

[critor]

Le setPixel passe par un UART à 115200 bauds, et en ASCII (le même que pour la console), ce qui explique en grande partie ses "performances". Je suppose que drawImage doit faire de même.

A la différence que le setPixel() fait également passer dans le tuyau les coordonnées et couleur du pixel concerné.

drawImage() ne fait passer dans le tuyau que les coordonnées du coin supérieur gauche et le nom de l'image à afficher.
La récupération en mémoire des données de l'image en question se passe hors du contexte Python.
Le drawImage() ne devrait donc pas être sensiblement plus lent que le setPixel().
Avec des images pas trop grosses parce que ça a quand même un coût (même si ce n'est pas le coprocesseur Python qui l'encaisse), on devrait donc pouvoir afficher jusqu'à 49 tiles par seconde, ou encore jouer des animations jusqu'à 49 fps.

[zardam]

Oui, exactement !

Pour la complétude, un setPixel sans passer par le module ti_graphics :

Code: Select all

import sys, ti_system

for x in range(320):
  # setPixel(x,50,(0,0,0))
  sys.stdout.write("\x1b["+str(x)+";50;0;0;0;2G\x03")
  # handshake
  sys.stdin.read(1)

ti_system.disp_wait()

Edit :
Le caractère envoyé par la calculatrice en réponse est \x06.

Pour scr.drawImage('BOY_200', 15, 30), on obtient (avec un handshake pour chaque ligne) :
- \x1b[12G\x03
- BOY_200\x03
- \x1b[15;30;13G\x03

[Lionel Debroux]

Un introducteur "\x1b[" et cette syntaxe avec des ; font irrésistiblement penser à https://en.wikipedia.org/wiki/ANSI_escape_code , même si TI n'a manifestement pas pas suivi toute la syntaxe - on attendrait un introducteur de commande devant la valeur x.
Le \x03 final est un ETX (End of Text).