Forum TI-Planet.org

en effet, changelog ici : https://www.hpmuseum.org/forum/thread-16670.html

Ca semble corriger pas mal de choses reportées

J'ai vu, merci. C'est téléchargé.

Pour le moment je n'ai toujours pas terminé l'annonce des nouveautés de la 1ère bêta, tellement il y a de choses à tester et dire.

Le pire étant que plus j'en teste, et plus je trouve de choses à dire.

critor a écrit:Le pire étant que plus j'en teste, et plus je trouve de choses à dire.

En bien ou en mal?

d'après ce que j'ai lu sur le tchat, les 2

J'atteins 15,6 Mo de heap Python avec une mémoire à peu près vide, de quoi coder et exécuter de formidables projets !


J'en connais qui peuvent aller se rhabiller...

critor a écrit:J'atteins 15,6 Mo de heap Python avec une mémoire à peu près vide, de quoi coder et exécuter de formidables projets !


J'en connais qui peuvent aller se rhabiller...

La TI-83 Premium CE Edition Python a également environ 16 Mo, non ?
Ah, on me dit à l'oreille que c'est environ 16 ko, et pas environ 16 Mo. Pardon

critor a écrit:J'en connais qui peuvent aller se rhabiller...

J'ai trouvé la solution pour numworks https://downloadmoreram.com/index.html

Bon, passons aux capacités de tracé par pixel du module hpprime.
Je parle bien de capacités et non de performances, même si elles en découlent.

Prenons la petite animation suivante :

Code: Tout sélectionner

from polycalc import *

screen_w, screen_h, my_draw_line, my_fill_rect, my_show_screen, test_esc_key = get_infos(("w", "h", "dl", "fr", "sh", "ek"))

def demog(n=64, front_color=(255, 0, 255)):
  n_max = 256
  n = min(n_max, n)
  dx = n_max // n
  dy = dx

  def get_dir(x, y, d):
    if(x >= screen_w - 1 and y <= 0):
      d = [0, dy]
    elif(x >= screen_w - 1 and y >= screen_h - 1):
      d = [-dx, 0]
    elif(x <= 0 and y >= screen_h - 1):
      d = [0, -dy]
    elif(x <= 0 and y <= 0):
      d = [dx, 0]
    return d

  x1, y1 = 0, 0
  x2, y2 = screen_w - 1, 0
  d1 = [dx, 0]
  d2 = [0, dy]
  colors = [ tuple([(255 - front_color[j]) * (n - 1 - i) // (n - 1) + front_color[j] for j in range(3)]) for i in range(n)]
  l = [[0,0,0,0] for k in range(n)]

  my_fill_rect(0, 0, screen_w, screen_h, (255, 255, 255))

  while not test_esc_key():
    x1 += d1[0]
    y1 += d1[1]
    x2 += d2[0]
    y2 += d2[1]
    l.append((x1, y1, x2, y2))
    for k in range(n):
      c = l[k]
      my_draw_line(c[0], c[1], c[2], c[3], colors[k])
    l.pop(0)
    my_show_screen()
    d1 = get_dir(x1, y1, d1)
    d2 = get_dir(x2, y2, d2)

demog()

Voici ce que donne la NumWorks N0110 :

C'est pas beau, kandinsky ne gérant hélas pas de double buffering.
En prime c'est lent car kandinsky est une bibliothèque graphique très pauvre, n'offrant entre autres pas de primitive draw_line(), et les lignes doivent donc ici être allumées pixel par pixel.

Par contre si on installe Omega, on obtient une fonction draw_line() - toujours pas beau mais nettement plus rapide :


Si on installe KhiCAS il y a une fonction show_screen() mais en pratique non, aucun double buffering ne semble géré - résultat comparable :

Sur TI-Nspire CX II on a bien du double buffering ainsi qu'une large bibliothèque graphique.
Mais il semble par contre y avoir de l'anti-aliasing qui interfère avec le bon affichage du script :


Si on passe sous KhiCAS ici apparemment on a toujours le double buffering, le problème d'anti-aliasing disparaît, et c'est même en prime légèrement plus rapide :

Et la HP Prime dans tout ça ?

Double buffering avec jusqu'à 8 calques hors écran, large bibliothèque de fonctions de tracé...

Pour éviter à mes lecteurs bien-aimés de faire une attaque, voici juste la bonne vieille HP Prime G1 de la rentrée 2013 :