>>+ Necessite de creer un fichier auxliaire pour l'inclusion des images (Un fichier assembleur, mais sans aucune ligne d'assembleur).
>Même pas. Tu connais ttbin2hex? ...
Mais c'est plus pratique comme ca.
>Ça sera une librairie dynamique du style de FAT Engine, n'est-ce pas? FAT Engine a besoin de tous les 64 KO disponibles pour une variable, donc dans ce cas
>particulier, c'est une bonne idée. Dans le cas de genlib, je ne suis pas vraiment d'accord avec ce que ça soit une bonne idée. C'est surtout une manière de pouvoir
>négliger totalement l'optimisation en taille en optimisant en vitesse. D'où gaspillage de place.
C'est la meme librairie que pour le mode kernel. Pas de differences.
Et le gaspillage de place n'est pas du tout important.
Surtout si on a quelques programmes utilisant genlib (ce qui est mon cas).
>>+ Calcule un halo autour des sprites pour bien les faire resortir de l'ecran.
>Ce qui donne un air artificiel aux graphismes.
Certes. Mais c'est a mon avis indispensable.
tous les jeux devraient faire pareil.
>Et tu as oublié de donner la raison pour laquelle ce halo est nécessaire:
>genlib ne permet que 3 niveaux de gris + une transparence. En plus dans ces 3 niveaux de gris, il n'y a pas de blanc (sauf si on change les options, et dans ce cas
>il n'y a pas de noir), et donc tous les jeux seraient sombres au point de ne faire rien voir sans ce halo.
Je prefere parler de 4 niveaux de gros, avec une couleur de transparence.
Et a mon avis, c'est la meilleure solution.
>>+ Est simple a utiliser meme si des personnes disent le contraire. Elles sont juste effrayes par la taille de la doc (Complete).
>Et par le fait qu'elle soit écrite en "chinois". Il faudrait commencer par définir des termes comme DHZ et HDZ de manière détaillée avant de les utiliser.
S'il ne s'agit que de ca, ce n'est pas bien grave.
>Tant que ça fonctionne, le langage de programmation employé ne devrait pas t'intéresser en tant qu'utilisateur (joueur). Tu es libre d'écrire tes propres programmes
>en C si tu préfères. Mais de là à descendre les programmes des autres parce qu'ils sont programmés en un langage plus efficace (même si tu ne comprends pas ce
>langage)...
Il y a un gouffre.
>>donc sa leur faciliterais la tache, en plus on va devoir se refarcir les lib
>>tel que filelib et tout, sa va encore mega planter, et sa sera le bordel
>>alors qu'avec TIGCC >>>>>> nostub direct.....
>Ce choix n'a vraiment rien à voir avec le langage de programmation utilisé. Il est tout à fait possible de programmer en _nostub en assembleur! C'est le fait d'avoir
>programmé en mode kernel qu'il faut critiquer, pas le fait d'avoir programmé en assembleur.
Je suis d'accord. Meme si je prefere le mode kernel qui me rajoute des possibilites.
Si t'es pas content, c'est le mode kernel que tu dois critiquer par l'assembleur.
Et en c, tu peux parfaitement utiliserr ces librairies.
>Je suis personnellement pour le _nostub, mais je suis quand-même pour l'assembleur. (Même si entre un programme en C qui marche et un programme en assembleur qui
>plante toutes les 5 minutes, je choisis le programme en C qui marche sans hésiter.)
Et entre un programme assembleur qui marche, et un programme C qui merde, je choisis le programme assembleur.
>>faudrat qu'on m'explique pourquoi y'en a qui utilise encore l'asm
>Parce que ça génère du code plus petit et plus rapide.
Parce que le code est 3x plus petit en taille, et 10x plus rapide.
>Et de la part d'un coauteur de PreOs (qui a écrit moins de 10% du code, mais quand-même): des "PREOS POWAAAAAAAAAA", on en a marre. Surtout s'ils sont accompagnés de
>"NOSTUBBE SUXXXXXX" (et apprends déjà à écrire _nostub ). Un des points forts de PreOs est de coopérer au maximum avec les programmes en _nostub: protection
>anti-plantage pour programmes _nostub, possibilité d'utiliser TICT Explorer comme shell primaire (avec SHIFT+ON), ... Donc je ne veux pas que son nom soit associé à
>des vulgarités contre le _nostub.
C'est vrai que ca devient lourd.
