Recherche avancée

Sur d’autres sites (4046)

• SNES Hardware Compression

  16 juin 2011, par Multimedia Mike — Game Hacking

  I was browsing the source code for some Super Nintendo Entertainment System (SNES) emulators recently. I learned some interesting things about compression hardware. I had previously uncovered one compression algorithm used in an SNES title but that was implemented in software.

  SNES game cartridges — being all hardware — were at liberty to expand the hardware capabilities of the base system by adding new processors. The most well-known of these processors was the Super FX which allows for basic polygon graphical rendering, powering such games as Star Fox. It was by no means the only such add-on processor, though. Here is a Wikipedia page of all the enhancement chips used in assorted SNES games. A number of them mention compression and so I delved into the emulators to find the details :

  • The Super FX is listed in Wikipedia vaguely as being able to decompress graphics. I see no reference to decompression in emulator source code.
  • DSP-3 emulation source code makes reference to LZ-type compression as well as tree/symbol decoding. I’m not sure if the latter is a component of the former. Wikipedia lists the chip as supporting "Shannon-Fano bitstream decompression."
  • Similar to Super FX, the SA-1 chip is listed in Wikipedia as having some compression capabilities. Again, either that’s not true or none of the games that use the chip (notably Super Mario RPG) make use of the feature.
  • The S-DD1 chip uses arithmetic and Golomb encoding for compressing graphics. Wikipedia refers to this as the ABS Lossless Entropy Algorithm. Googling for further details on that algorithm name yields no results, but I suspect it’s unrelated to anti-lock brakes. The algorithm is alleged to allow Star Ocean to smash 13 MB of graphics into a 4 MB cartridge ROM (largest size of an SNES cartridge).
  • The SPC7110 can decompress data using a combination of arithmetic coding and Z-curve/Morton curve reordering.

  No, I don’t plan to implement codecs for these schemes. But it’s always comforting to know that I could.

  Not directly a compression scheme, but still a curious item is the MSU1 concept put forth by the bsnes emulator. This is a hypothetical coprocessor implemented by bsnes that gives an emulated cartridge access to a 4 GB address space. What to do with all this space ? Allow for the playback of uncompressed PCM audio as well as uncompressed video at 240x144x256 colors @ 30 fps. According to the docs and the source code, the latter feature doesn’t appear to be implemented, though ; only the raw PCM playback.

• Anomalie #4751 : Refonte du jeu d’icônes : retours et commentaires

  29 avril 2021

  C’est un immense et chouette boulot que tu as fait avec toutes ces icones personnalisées !
  Et c’est très bien.

  J’espère n’énerver personne pour la suite :p
  J’ai principalement 2 remarques :

  - la première et principale concerne l’icone de rubrique, qui pour moi ne se détache pas assez du fond (ça dépend du thème aussi et où elle est utilisée). Tu as proposé un contour sympa sur le plugin archiviste. Ce contour, plus un peu de couleur serait probablement intéressant.

  - la seconde concerne l’épaisseur des traits, qui n’est pas toujours identique (plus fin généralement) sur certaines icones. C’est pas dramatique, mais par cohérence si c’était la même taille ça serait cool. Je pense à notamment à
  - "suivi des révisions" ,
  ou "plan du site" (celui du bandeau du moins)
  - ou "vider le cache" (qui lui est plus gros)

  une 3è : chez moi l’icone "agenda interne" a un reflet contrairement aux autres (à moins que ce ne soit du au plugin agenda)
  - une 4è : l’icone "gestion des plugins" est un peu comme la rubrique, jaune sans contour, dans certaines situations elle se détache mal

  Le reste des remarques sont des détails et mes préférences, sans drame apparent, à voir selon les humeurs et d’autres avis :

  - certaines icones sont en fond plein (mots par exemple), ça sort un peu de l’apparence filaire des autres
  - une petite touche de couleur sur certaines icones était sympa (article, ou mot, a perdu sa touche de couleur par exemple)
  - le A (français) des icones de langues a le trou du A central à peine visible en petit. Il semble très légèrement trop épais quoi
  - « fonctions avancée" : 1 seul outil avec un engrenage ?
  - "identité du site" : je suis pas fan du terminal (je n’avais absolument pas compris l’analogie), mais s’il est conservé, mettre un peu plus de contraste entre les gris ?
  - je n’ai pas vu comment était la boite du compagnon récemment, mais son logo, je ne suis pas sûr de l’intérêt d’avoir son contour plus épais que les autres
  - SVP : je ne comprends toujours pas l’analogie (tu as repris la même qu’avant donc… bon…)
  - Plugin "Dev" : chez moi il a une icone différente des autres plugins du core ?
  - le "auteur" (le vert surtout, et jaune aussi) sont pas facile à voir. Peut être qu’augmenter la taille du buste par rapport à la tête aiderait ?

  ---

  Et sinon, la vue des logos des plugins du core est trop chouette ! C’est magnifique cet ensemble !

• Anomalie #4543 : Accessibilité des chargements ajax (live regions)

  3 septembre 2020, par RastaPopoulos ♥

  En positionnant ces attributs, avec ces valeurs, sur des div englobantes, cela génère dans les lecteurs d’écran la lecture automatique des contenus qui ont été mis à jour.

  Certes la lecture peut être interrompue par l’utilisateur, mais cela revient, à mon avis à imposer quelque chose qui n’a pas été forcément souhaité. De cette manière le propriétaire du site impose une expérience différente aux utilisateurs de lecteur d’écran.

  Je ne suis pas sûr de comprendre : lancer la lecture des contenus mis à jour c’est bien très exactement ce qu’on cherchait à faire avec ces attributs il me semble. Donc ça fait bien ce qu’on cherche à faire. À la louche, je pense que 99% des utilisations de rechargement ajax SPIP (avec le critère ajax + des liens ".ajax" ou des forms) concernent parfaitement des cas avec une interaction donc un rechargement qui est explicitement demandé par l’utilisateurice : clic sur un lien qui recharge un bloc ajax OU clic sur un bouton qui recharge un formulaire en ajax. Ce n’est donc pas du tout quelque chose d’imposé et de forcé : l’utilisateurice demande une ressource (lien ajax) ou poste un formulaire (ajax) qui sont alors chargés dynamiquement SANS recharger toute la page : on veut donc bien effectivement que le lecteur d’écran se mette à relire le morceau qui vient d’être chargé !

  Ne pas utiliser ces attributs lorsqu’il n’y a pas d’interactions / rechargement ajax . Exemple sur un formulaire, cela n’a pas de sens : on rempli un form et puis on valide le form. A priori (si j’ai bien compris le fonctionnement) il n ’y a aucune raison d’utiliser de live region.

  Ces attributs sont sur des forms ajax, pas les forms non-ajax, non ? Quand on poste un formulaire ajax, alors seulement son bloc se recharge, et à l’intérieur de ce bloc, les contenus ont changé : des erreurs sont affichés, ou un message de retour final est ajouté, etc. C’est donc bien totalement voulu (l’utilisateurice a volontairement cliqué) et on veut que ça relise ce morceau puisque des contenus ont changé dedans, et souvent très important pour un formulaire (erreurs à corriger etc).

  Du coup je ne comprends pas leurs remarques : on a l’impression que tout ce qu’ils disent part du principe que ce sont des choses rechargées en arrière-plan par une volonté du dév (ce qui peut arriver dans 1% des cas, super rare), alors que non non, c’est bien à chaque fois un clic volontaire (lien ou bouton) de l’utilisateurice.