Incident Pays-Bas : mode examen HP Prime non conforme 2021

[Adriweb]

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

Ca semble corriger pas mal de choses reportées

[critor]

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.

[jean-baptiste boric]

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

En bien ou en mal?

[Hamza.S]

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

[critor]

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...

[Afyu]

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

[redgl0w]

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

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

[critor]

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: Select all

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 :

[critor]

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 :

[critor]

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 :