Lionel Debroux (./214) :
Tu refuses catégoriquement un certain nombre de souhaits que nous sommes plusieurs à porter, même si on les implémentait pour toi... et c'est nous qui refusons de collaborer ?

Parce que vos souhaits n'apportent rien en pratique, par exemple:
* remettre le support pour VTI ne sert à rien parce que TiEmu fait tout ce que VTI faisait et plus,
* mettre les plans consécutifs sur HW1 ne sert à rien parce que les plans sont et ont toujours été 2 objets totalement indépendants (je ne vois pas pourquoi plan0+3840 devrait correspondre à autre chose qu'un buffer overflow, un plan est un tableau de 3840 octets, lire en dehors de ces 3840 octets est un débordement) et il est parfaitement possible d'en tenir compte dans les programmes (et ça a toujours été fait avant que Sasume a mal interprété la documentation (qui a été clarifiée depuis) lors du développement du TileMap Engine et que Sasume et toi avez rebaptisé ce bogue "fonctionnalité" et demandé que TIGCCLIB s'adapte à votre bogue, en refusant mon patch qui corrige ce bogue).

et ont de nombreux désavantages, par exemple:
* maintenance plus compliquée, une option inutile polluant les dialogues et le fait d'encourager l'utilisation d'un émulateur bogué et abandonné depuis des années dans le cas du support de VTI,
* gaspillage de 3840 octets de RAM sur HW1 (ou alors abandon de la compatibilité: les routines de gris copient LCD_MEM sur le plan foncé lors de GrayOn et l'inverse lors de GrayOff sur HW >=2 pour la compatibilité avec les programmes écrits pour HW1, donc on ne peut pas utiliser LCD_MEM comme sauvegarde de l'écran comme ça a été proposé) dans le cas des plans consécutifs. Il y a aussi le problème de l'évolutivité future: se fixer la contrainte que plan0+3840==plan1 réduit la flexibilité des modifications futures. Un exemple concret: il y a du travail pour les vérifications des bornes des tableaux dans GCC (pas encore supporté dans TIGCC), on pourrait éventuellement aussi envisager des vérifications dans un émulateur comme TiEmu avec l'aide des informations de débogage (ce qui éviterait le coût de la vérification en temps d'exécution on-calc). Si tu dépasses du plan0, une telle vérification des bornes relèverait un débordement, et elle aurait raison de le relever, parce que dans la plupart des cas, ce sera vraiment un bogue du programme. En établissant ça comme une manière valide d'accéder au plan1, vous empêchez la possibilité de détecter ce débordement.

Dans certains cas (plans consécutifs), il s'agirait aussi d'inverser une décision qui a été prise par toute l'équipe, y compris de grands noms comme Zeljko et Thomas.

La coopération n'implique pas accepter tout et n'importe quoi (essaie de mettre un lecteur MP3 ou un logiciel (hors firmware) non-libre dans Fedora, par exemple), il faut savoir accepter que certaines de ses idées soient rejetées et écouter les arguments pour un tel rejet. Et il faut accepter que les personnes qui sont impliquées dans un projet depuis longtemps et ont beaucoup contribué prennent les décisions, pas les personnes qui ont peu ou pas contribué (à ce projet particulier, pas à n'importe quoi), même s'il s'agit d'utilisateurs de longue durée. Dans le monde du libre, on appelle ça la méritocratie, presque tous les projets libres fonctionnent comme ça.