Plus d'excuse pour ne pas s'en servir : Xlib - Page 7

Heureusement qu'il y a nitro, et sa pensée toujours raisonnable
Je suis entièrement d'accord!

PpHd a écrit :

Mais arretez de dire que genlib est complique. Utilisez-la ! Vous verrez, c'est simple (forcemenet lorsqu'on comprend pas l'amglais )

Un des besoins primaires en informatique est quand meme de bien comprendre l'anglais

Nitro > tu vends tes progs sur console ?

Genlib est loin d'emuler une console.. d'ailleur je ne vois pas en quoi elle en emule une, sachant qu'elle a que des fonctions basiques.
De plus sur un 68k, on ne prog pas de la meme maniere que sur une console:
>HW limité
>RAM limité
>ROUTINE GRAPHIQUES en ram

Conclusion:
Certaines personnes sont a coté de la plaque.

Genlib est tout sauf une lib graphique dite evoluée pour les 68k:

>Genlib ne presente que des sprites par transparence:
Oui sur les consoles ca marche comme cela, mais sur console on a plus
de 4 niveaux de gris.
>> consequence, les jeux genlib font une emulation 4 niveaux de gris,
et sont souvent tres sombre: seiken ....

>Genlib n'est pas optimisée niveau algo:
Dans 99% des jeux, les perso missiles evoluent de pxl en pxl, genlib
recalcule tout a partir de l'addresse du debut du gl_plan
>> perte de temps non negligeable, 20% de perte en rapidité par rapport a X.

> Fonction hallo.
Seul fonction qui emule des routines maskée sans en proposée.
Cette fonction est tres lente sans proposer de veritable mask.
>> elle etait 2 fois moins rapide que les routines de X maskée

> Fonction gl_drawlevelmachinchose
Fonction dite optimisée, emulant les modes de diverses console.
Cette fonction ne gere pas les annimations automatiquement, consequence
l'annimation du Background/level doit se faire en C/ASM tout en respectant
le format de gl_drawlevelmachinchose.
>> Perte de temps catastrophique pour les niveaux avec beaucoup d'annimations

> Toutes les fonctions sont clippées
C'est tres bien sachant que ca teste le clipping meme quand on en a pas besoin!
D'ailleur le cliping in fonction est plus lente que ce soit en prog C/ASM
(compter rien que le jsr/rts... plus ce que Kevin avait dit a ce sujet.
>> perte de temps pour les sprites qui reste on LCD ainsi que pour les sprites
en dehors de l'ecran (cf kevin), donc perte de temps totale

Les arguments ne manque pas, contrairement a ma patience.

Il est evidant que Genlib est plus programmer pour emuler que pour programmer.
Ses algo ne sont pas optimisés pour tourner sur 68k.
Bien quelle soit relativement rapide, il n'est pas difficile de faire plus rapide,
car contrairement a Genlib, X n'etait pas optimise au niveau instructions pour gagner
2 3 cycles par routine, mais optimisé niveau algo. D'ailleur sans vouloir critiquer Genlib,
il est possible de faire plus rapide en C pour certaines fonctions de sprites. D'ailleur
rien que pour vous le confirmer, demander a PpHd, pourquoi Genlib est si rapide pendant ses benchs.

1: il empeche le compilo d'optimiser les routines de Extgraphlib en utilisant des volatile.
Ce qui est ridicule sachant que les fonctions C ont pour but d'etre optimiser par le compilo.
2: Ses bench sont irrealistes par rapport aux situations de jeu, il cache les defaut de sa lib.
X etait plus rapide que Genlib on lcd... mais pphd arrive a le cacher dans ses bench.


Bon, apres ce message, une foule de personne vont me "gueuler" dessus, en me disant que j'exagere.
Peut etre devraient il faire confience à mes arguments, et regarder la verité en face.

Bon tout ceci pour dire que contrairement a mon dernier message dit "brutal" pour certain, que
le devellopement de X est arreté, et je ne programmerai plus sur 68k .
Mais comme je suis conscient que qqs personnes (bien que tres peux nombreuses) ont commencées à programmer
avec X. Je ne peux me permettre de les laisser tomber. C'est la raison pour laquelle, si ils veullent
que je programme /reprogramme des fonctions A TITRE PERSONNEL, pour qu'ils puissent terminer leur projet
je serai disposé a le faire ( juliensab@aol.com ).
Je tenais aussi a dire a squale92 que je tiendrai ma promesse, si il le veux toujours.

TiMad> je suis l'un des rares à utiliser Xlib.
Son fonctionnement me satisfait.
(je n'ai pas testé Genlib, je le précise, et quand j'ai choisi Xlib, ct soit Xlib soit Extgraph. Mes bench m'ont poussé à choisir Xlib, pour la vitesse... et aussi pour quelques facilité d'emploi)

Ok pr la promesse. merci.

TiMad a écrit :
lol...
rectification:
Pourquoi pct est aussi gros, bien que GSTools ne soit pas fini, il prend 5ko de moins.

>> je confirme cette phrase, mais j'ai jamais cracher sur pct, car c'est sans contestation le meilleur shell sur ti (c'est mon avis).
D'ailleur, j'avais fait part de ma methode pour les sous repertoire de GSTools, qui me semble beaucoup plus pratique que celui de pct. On avait echangé nos idées, un point c'est tout.. je vois pas ce qu'il y a de mal! Aujourd'hui pct est mort ce qui est bien dommage, mais je ne l'ai jamais critiqué...

Aujourd'hui, GSTools doit etre entierement reprogrammer (c'etait mon premier prog en C). ceci etant dit, j'ai plusieurs solutions... soit je recomplie une source deja existante et je met un (c) JS a la maniere de Nitro, soit je vous donnes mes beaux DM de thermo, algebre etc..., et alors dans ce cas, là, j'ai tout le temps pour programmer.
chaqun ses prioritées... mais pero, ca me fait bien rire, parce que pour faire gagner Genlib, vous allez jusqu'a faire des bench completement pouris qui ne signifient rien...
Vous la vendez a toutes les sauces, avec des arguments completement pouris...

Bon ceci etant dit, j'en ai marre de perdre mon temps avec des pauvres debiles.. j'ai d'autres choses bien interressantes a faire.

Adieu

tien pour la xeme fois timad (alias js) fait ses adieux a la commu

Tant de blabla pour ne rien dire TiMad... il est plus qu'evident que tu parles de choses que tu ne connais pas du tout.

>Genlib est loin d'emuler une console.. d'ailleur je ne vois pas en quoi elle en emule une, sachant qu'elle a que des fonctions basiques.

Tout comme une console.

>De plus sur un 68k, on ne prog pas de la meme maniere que sur une console:
>HW limité
>RAM limité
>ROUTINE GRAPHIQUES en ram

Exactement comme sur console.

>Certaines personnes sont a coté de la plaque.

Oui je vois ça.

>Genlib est tout sauf une lib graphique dite evoluée pour les 68k:

C'est clair, je dirais plutot que c'est un gestionnaire de base de données, non ?

>Oui sur les consoles ca marche comme cela, mais sur console on a plus
de 4 niveaux de gris.

Sur GB on a 4 niveaux de gris, sur GBC on a 4 couleurs, sur NeoGeo Pocket on a 4 niveaux de gris, et sur NeoGeo Pocket Color on a 4 couleurs. A chaque fois avec une couleur transparente... sans commentaire.

>Genlib n'est pas optimisée niveau algo:
Dans 99% des jeux, les perso missiles evoluent de pxl en pxl, genlib
recalcule tout a partir de l'addresse du debut du gl_plan
>> perte de temps non negligeable, 20% de perte en rapidité par rapport a X.

et ... ?

> Fonction hallo.
Seul fonction qui emule des routines maskée sans en proposée.
Cette fonction est tres lente sans proposer de veritable mask.
>> elle etait 2 fois moins rapide que les routines de X maskée

Et permet d'économiser 50% de place... comme tu l'as dit toi même RAM limitée.

> Fonction gl_drawlevelmachinchose
Fonction dite optimisée, emulant les modes de diverses console.
Cette fonction ne gere pas les annimations automatiquement, consequence
l'annimation du Background/level doit se faire en C/ASM tout en respectant
le format de gl_drawlevelmachinchose.

Exactement comme sur console. Il reste quoi a programmer alors si on ne peut plus gerer les animations comme on veut ?

> Toutes les fonctions sont clippées
C'est tres bien sachant que ca teste le clipping meme quand on en a pas besoin!
D'ailleur le cliping in fonction est plus lente que ce soit en prog C/ASM
(compter rien que le jsr/rts... plus ce que Kevin avait dit a ce sujet.
>> perte de temps pour les sprites qui reste on LCD ainsi que pour les sprites
en dehors de l'ecran (cf kevin), donc perte de temps totale

Il suffit de faire le test en dehors, je vois pas le problème...

>Les arguments ne manque pas, contrairement a ma patience.

Tes arguments sont pourris parce que tu n'as aucune connaissance dans ce domaine et tu n'as jamais fait de jeux. PpHd a fait sa lib en fonction des réels besoins de ses jeux (Fernando, SMA, CF) et en se basant sur le VDP de la mégadrive (dont le processeur est un 68k, toi qui a l'air de dire que les TI et les consoles ça n'a rien a voir).

>Ses algo ne sont pas optimisés pour tourner sur 68k.
Bien quelle soit relativement rapide, il n'est pas difficile de faire plus rapide,
car contrairement a Genlib, X n'etait pas optimise au niveau instructions pour gagner
2 3 cycles par routine, mais optimisé niveau algo.

Oui enfin on attend toujours ce fameux X. C'est bien beau de parler ...

>D'ailleur sans vouloir critiquer Genlib, il est possible de faire plus rapide en C pour certaines fonctions de sprites.

Il est possible oui ... et ?

>2: Ses bench sont irrealistes par rapport aux situations de jeu, il cache les defaut de sa lib.

Oui on a vraiment l'impression que tu les connais tres bien toi les conditions réelles des jeux.

>X etait plus rapide que Genlib on lcd... mais pphd arrive a le cacher dans ses bench.

Il faudra t'y faire, tous les sprites d'un jeu ne sont pas sur l'écran.

>Bon, apres ce message, une foule de personne vont me "gueuler" dessus, en me disant que j'exagere.

Tu te défends comme tu peux apres avoir craché sur tout le monde.. on commence à avoir l'habitude.

>Peut etre devraient il faire confience à mes arguments, et regarder la verité en face.

Quelle vérité ?

>Bon tout ceci pour dire que contrairement a mon dernier message dit "brutal" pour certain, que
le devellopement de X est arreté, et je ne programmerai plus sur 68k .

C'est pas la premiere fois qu'on entend ça...

Pim89 a écrit :
Nitro > tu vends tes progs sur console ?

http://pocket.ign.com/articles/069/069306p1.html
http://pocket.ign.com/articles/069/069823p1.html
On en a vendu une licence aux programmeurs de ce jeu:
http://pocket.ign.com/articles/089/089851p1.html
et on a fait ce jeu:
http://pocket.ign.com/articles/135/135496p1.html
qui n'est pas distribué car Cinemaware n'a pas trouvé de distributeur. On a quand même été payés

Timad = moi aussi il me faudrait une version "propre" de Xlib, presque finie (optimisée quoi) pour les fonctions déjà présentes (tanpis, continue pas les toutes nouvelles, il faut déjà que celles "essentielles" : Gplan, sprite ect) soient nickel je pense. Merci.

Euh TiMad tu veux faire une lib graphique performante (ce qui est louable en soi) ou juste essayer de couler Genlib?
Finis-la, fait une release publique (une lib que personne n'utilise pourrait aussi bien ne pas exister, même si c'est l'ultime révolution dans le genre) et arrête de crier à tous vents que c'est la meilleure (ah non pardon tu crie juste qu'elle est meilleure que Genlib).
Laisse les utilisateurs décider de laquelle convient le mieux à leurs attentes.

C'est fou comme tu peux etre denuer de raisonnement Nitro.
C'est bien de te la peter en disant que tu gagnes ta vie en programmant (cool), mais c'est pas pour autant que tu peux te permettre de sortir des arguments bidons:

>Exactement comme sur console.
Sur console, monsieur poura constater que les 3/4 des routines sont en hard sauf gp32 et compagnie. (tiens je croyais que tu programmais sur gba, alors arretes de me dire des betises comme cela).
>Ceux qui sont a cote de la plaque, je pense que tu es sur la scene. Au fait tu as deja programmer sur ti68k une routine asm pour afficher un pxl? non alors bon... ne parle pas de ce que tu connais pas, je vais pas te contredire sur la gba ou autre console.... parce que moi j'ai au moins l'intelligence d'avouer que je ne connais pas tout, et je ne conjecture pas sur des sujets que je ne connais pas.
> Oui ce n'est pas une lib graphique evoluee pour ti, au fait tu sais a combien tourne son rotorzoom pour parler de cela? non alors bon encore une reponse dans le vent. Genlib ne propose pas de routine reellement evoluée.

>Sur GB on a 4 niveaux de gris, sur GBC on a 4 couleurs, sur NeoGeo Pocket on a 4 niveaux de gris, et sur NeoGeo Pocket Color on a 4 couleurs. A chaque fois avec une couleur transparente... sans commentaire.

"A chaque fois avec une couleur transparente" oui mais pas toujours la meme, et de plus, leurs ecrans non pas des probleme de sous tension comme sur ti. A mais au fait tu le savait ca? non je crois pas.

>Genlib n'est pas optimisée niveau algo:
Dans 99% des jeux, les perso missiles evoluent de pxl en pxl, genlib
recalcule tout a partir de l'addresse du debut du gl_plan
>> perte de temps non negligeable, 20% de perte en rapidité par rapport a X.

Et par consequent, tu vas faire le lien logique comme un grand, a oui je vais te rappeller qqs elements de logique:
( P <=> Q ) <=> ( Q v ]P )
si mes souvenir sont bon...


Et permet d'économiser 50% de place... comme tu l'as dit toi même RAM limitée.
Heu chez moi ca fait que 30% de place.. t'es bien le seul a fait un mask par plan...sur ti (mega lol)

>Fonction dite optimisée, emulant les modes de diverses console.
Cette fonction ne gere pas les annimations automatiquement, consequence
l'annimation du Background/level doit se faire en C/ASM tout en respectant
le format de gl_drawlevelmachinchose.

Exactement comme sur console. Il reste quoi a programmer alors si on ne peut plus gerer les animations comme on veut ?

Sur une console, t'es pas restreint au niveau resource (relatif) ON EST SUR TI 10Mhz sans routines HARD; est ce que tu as compris?

>> Toutes les fonctions sont clippées
C'est tres bien sachant que ca teste le clipping meme quand on en a pas besoin!
D'ailleur le cliping in fonction est plus lente que ce soit en prog C/ASM
(compter rien que le jsr/rts... plus ce que Kevin avait dit a ce sujet.
>> perte de temps pour les sprites qui reste on LCD ainsi que pour les sprites
en dehors de l'ecran (cf kevin), donc perte de temps totale

Il suffit de faire le test en dehors, je vois pas le problème...

> le probleme c'est que tu as pas bien lu ce que j'ai marqué.

>>Les arguments ne manque pas, contrairement a ma patience.

Tes arguments sont pourris parce que tu n'as aucune connaissance dans ce domaine et tu n'as jamais fait de jeux. PpHd a fait sa lib en fonction des réels besoins de ses jeux (Fernando, SMA, CF) et en se basant sur le VDP de la mégadrive (dont le processeur est un 68k, toi qui a l'air de dire que les TI et les consoles ça n'a rien a voir).

Bien raisonnons par l'absurde tu connais : Euclide...
Si j'ai une console a 10Mhz et une calc a 10Mhz, alors je doit avoir les memes performances. > c'est absurde (routine Hard...) donc hypothese fausse
AU fait je vais me faire une lib qui se base sur une GFORCE (mega lol)


>> Tiens bisard, qu'est ce que je dois rendre pour la fin de mon année de prepa en Info? un projet qui a un fort rapport avec les jeux.. je te laisse deviner, puisque tu as l'air de tout savoir sauf peut etre raisonner?

Je n'ai pas cracher sur tout le monde.. seulement sur: PpHd et toi, ainsi que Pollux a une certaine epoque pour son gros fake de GTools (est ce que j'ai tord?).


Maintenant, il faut etre realiste, si je dit ca c'est pas pour vendre X, puisqu'elle ne sortira pas sur 68k. Mais y'en a marre de vos arguments bidons pour vendre votre projet.
D'ailleur Nitro qu'est ce que tu fous la, tu n'avais pas dit sur le forum GBA que c'etait le communauté la plus pourit que t'avais jamais vu?
C'est sympat pour les gas de cette communauté, non seulement tu craches sur tout le monde, mais en plus tu le fais dans leur dos...
Perso j'ai toujours dit ce que j'avais a dire sur le forum, je ne vais certaiment pas faire comme certain qui se servent des sms du forum ou icq pour insulter les gas de la commu.

Si cette communauté te semble pourit, c'est peut etre parce que certaines personnes (qui a dit toi et pphs) font passer leurs interets avant eux.

Au fait pourquoi je me serait tuer a "vendre " Xlib, sachant que il n'y a aucune licence, et que je ne demande aucune reconnaisance a ceux qui l'utilise?
Comme tu peux le voir, je me fou du nom que je me suis fait dans cette comu, je donne clairment le droit de tout pomper Xlib ca ne me derange pas. Je l'ai programme pour proposer une alternative a genlib qui pour ma part est une lib compltement inadapté a la ti.
D'ailleur pphs s'est permis de critiquer mes sources, mais je pourais en faire de meme avec les siennes.. mais je ne le ferai pas! D'ailleur il a toujours voulu nier la veritée...

Euh TiMad tu veux faire une lib graphique performante (ce qui est louable en soi) ou juste essayer de couler Genlib?
Finis-la, fait une release publique (une lib que personne n'utilise pourrait aussi bien ne pas exister, même si c'est l'ultime révolution dans le genre) et arrête de crier à tous vents que c'est la meilleure (ah non pardon tu crie juste qu'elle est meilleure que Genlib).
Laisse les utilisateurs décider de laquelle convient le mieux à leurs attentes.

>> Non je ne fais pas de lib.. d'ailleur maintenant c'est comme si elle n'avait pas existé. Le code source et la propriéte de tout le monde, et je me fou totalement de ma reputation
>> Il n'y aura pas de realase publique. je fais juste les derniere routines pour ceux qui ont commencé leur projet avec et apres j'arrete. Le code Xlib sera la propriétée du gas qui a fait le jeu. Je demande aucune reconnaisance.

Aucun commentaire.

TiMad a écrit :
Bon tout ceci pour dire que contrairement a mon dernier message dit "brutal" pour certain, que le devellopement de X est arreté, et je ne programmerai plus sur 68k .

NON! N'abandonne pas _X_Lib! En le faisant, tu donnes aux fanatiques de genlib une occasion de plus pour se la péter! Et il y a une partie importante de la communauté qui t'a toujours soutenu (moi par exemple)!

Mais si vraiment tu n'as plus envie de continuer _X_Lib, sors au moins ce que tu as (il me semble bien que tu as des routines pas encore sorties publiquement) pour que quelqu'un d'autre puisse la continuer. ( N'oublie pas de mettre une licence qui interdit l'utilisation dans les programmes pour kernel, je peux te donner un paragraphe en beau "legalese" si tu veux.)

erf Kevin.

moi aussi ça me fait chier s'il finit pas totalement la lib , car je la trouvais facile et rapide et vraiment adapté au C nostub.

>C'est fou comme tu peux etre denuer de raisonnement Nitro.
C'est bien de te la peter en disant que tu gagnes ta vie en programmant (cool), mais c'est pas pour autant que tu peux te permettre de sortir des arguments bidons:

Mes arguments sont basés sur mon expérience personnelle, et quand je vois ce que tu écris je ne peux pas m'empecher de rire.

>Sur console, monsieur poura constater que les 3/4 des routines sont en hard sauf gp32 et compagnie. (tiens je croyais que tu programmais sur gba, alors arretes de me dire des betises comme cela).

Ta phrase d'origine étant:
>De plus sur un 68k, on ne prog pas de la meme maniere que sur une console:
>HW limité
>RAM limité
>ROUTINE GRAPHIQUES en ram
Ce à quoi j'ai répondu que c'était strictement la même chose que sur console, et c'est le cas. On ne parle pas du hardware là, on parle des routines qu'on programme.. et sur GBA par exemple, les routines graphiques sont en général en ASM dans la RAM.

>Au fait tu as deja programmer sur ti68k une routine asm pour afficher un pxl? non alors bon... ne parle pas de ce que tu connais pas, je vais pas te contredire sur la gba ou autre console.... parce que moi j'ai au moins l'intelligence d'avouer que je ne connais pas tout, et je ne conjecture pas sur des sujets que je ne connais pas.

Bien sur que j'ai deja fait des routines graphiques sur ti68k. Mais le projet qui les utilise (ex-Nitro3D) n'est pas encore sorti. De plus j'ai été l'auteur pendant tres longtemps des findpixel les plus rapides et les plus petits en asm Z80 (sources sur ticalc.org). Donc je sais très bien ce que c'est que de faire des fonctions graphiques sur un LCD comme celui des TI. Et je sais également programmer sur pas mal de consoles. Donc je peux me permettre de parler de tout ça.


>Oui ce n'est pas une lib graphique evoluee pour ti, au fait tu sais a combien tourne son rotorzoom pour parler de cela? non alors bon encore une reponse dans le vent. Genlib ne propose pas de routine reellement evoluée.

Oui c'est vrai que la gestion des palettes, des tables de déplacement de scanlines, de rendu d'effets de lumières, .... tout le monde le fait.

>"A chaque fois avec une couleur transparente" oui mais pas toujours la meme

Dans Genlib la gestion des palettes ça sert à quoi d'apres toi ?

>et de plus, leurs ecrans non pas des probleme de sous tension comme sur ti. A mais au fait tu le savait ca? non je crois pas.

Le LCD de la GBC n'est pas pourri peut-etre. Ca n'empeche pas Nintendo de se passer de masks.

>Et par consequent, tu vas faire le lien logique comme un grand, a oui je vais te rappeller qqs elements de logique:
( P <=> Q ) <=> ( Q v ]P )
si mes souvenir sont bon...

Et tout ça pour dire quoi ?

>Et permet d'économiser 50% de place... comme tu l'as dit toi même RAM limitée.
Heu chez moi ca fait que 30% de place.. t'es bien le seul a fait un mask par plan...sur ti (mega lol)

Je veux dire qu'un mask prend 50% de place en plus... ce qui est trop quand on a plein d'animations.

>Sur une console, t'es pas restreint au niveau resource (relatif) ON EST SUR TI 10Mhz sans routines HARD; est ce que tu as compris?

Tu crois qu'un Z80 à 2 Mhz (GB et GBC) c'est pas limité au niveau ressource ? C'est pas parce que l'affichage est geré en hard que ça te laisse pour autant beaucoup de ressources. La NGPC c'est un proc 16-bit à 6 Mhz.. même la mégadrive est moins puissante (68k 8 Mhz)

>Il suffit de faire le test en dehors, je vois pas le problème...
> le probleme c'est que tu as pas bien lu ce que j'ai marqué.

Si tu fais référence à "ca teste le clipping meme quand on en a pas besoin" je te signal que même avec ça, Genlib est plus rapide que Xlib (cf. dernier bench)...

>Si j'ai une console a 10Mhz et une calc a 10Mhz, alors je doit avoir les memes performances. > c'est absurde (routine Hard...) donc hypothese fausse
AU fait je vais me faire une lib qui se base sur une GFORCE (mega lol)

Ca veut dire quoi ce que tu dis ? Encore un argument completement foireux. Qui a dit que Genlib devrait etre aussi performante qu'une mégadrive ?

>Tiens bisard, qu'est ce que je dois rendre pour la fin de mon année de prepa en Info? un projet qui a un fort rapport avec les jeux.. je te laisse deviner, puisque tu as l'air de tout savoir sauf peut etre raisonner?

Super, ça me fait une belle jambe. Il n'en demeure pas moins que tu n'as pas l'expérience de PpHd.

>Je n'ai pas cracher sur tout le monde.. seulement sur: PpHd et toi, ainsi que Pollux a une certaine epoque pour son gros fake de GTools (est ce que j'ai tord?).

Tu oublies Benoit, ce qui fait 4 personnes.

>Maintenant, il faut etre realiste, si je dit ca c'est pas pour vendre X, puisqu'elle ne sortira pas sur 68k. Mais y'en a marre de vos arguments bidons pour vendre votre projet.

Je ne vend pas Genlib (qui n'est pas mon projet)... simplement quand je vois la quantité de conneries que tu peux dire, je ne peux pas m'empecher de réagir.

>D'ailleur Nitro qu'est ce que tu fous la, tu n'avais pas dit sur le forum GBA que c'etait le communauté la plus pourit que t'avais jamais vu?

Oui c'est le cas. Et comme t'as pu le voir je ne suis pas le seul à penser ça.

>C'est sympat pour les gas de cette communauté, non seulement tu craches sur tout le monde, mais en plus tu le fais dans leur dos...

Ce n'est pas dans leur dos puisque c'est sur ce forum, et je n'insulte personne c'est une remarque d'ordre général.

>Si cette communauté te semble pourit, c'est peut etre parce que certaines personnes (qui a dit toi et pphs) font passer leurs interets avant eux.

Ni moi ni PpHd n'a un quelconque interet à défendre. Tout ce que je vois moi c'est que tu es simplement jaloux qu'il soit si populaire.

>Au fait pourquoi je me serait tuer a "vendre " Xlib, sachant que il n'y a aucune licence, et que je ne demande aucune reconnaisance a ceux qui l'utilise?

Tu ne vends pas Xlib, tu ne fais que critiquer Genlib...

>Je l'ai programme pour proposer une alternative a genlib qui pour ma part est une lib compltement inadapté a la ti.

On peut trouver qq chose inadapté sans pour autant critiquer à coups de "Genlib sux" et autres bench pourris. Prend exemple sur Kevin.

>D'ailleur pphs s'est permis de critiquer mes sources, mais je pourais en faire de meme avec les siennes.. mais je ne le ferai pas! D'ailleur il a toujours voulu nier la veritée...

Quelle vérité ? (j'ai l'impression de me repeter là)

vous etes pitoyable les gars !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

>> En le faisant, tu donnes aux fanatiques de genlib une occasion de plus pour se la péter!

Kevin, j'apprecie ce que tu fais en general, mais parfois tu es un peu a cote de la plaque toi aussi! tu crois que je suis pro genlib! je suis juste la en tant que spectateur, j'ai jamais utilisé genlib, j'ai juste lu la doc une fois!!!

Timad, n'a pas le coruage d'aller jusqu'au bout des choses, et il sait tres bien que son comportement ne peut amener qu'a de tels clash, il ne faut pas s'etonner, et timad donne encore un signe de sa puérilité!

D'ailleurs, je ne sais pas comment tu peux te permettre de critiquer nitro, pour moi cest une des personnes qui m'etonne le plus dans la communauté ti! Il fait a chaque fois ce que personne n'a fait!

je parle entre autre de son compilo /editeur en niveaux de gris sur ti
de son jeu en 3D! (j'attend encore, nitro, de voir une version plus evoluée!)

Et c'est tout a fait respectable de gagner sa vie en programmant! Il fait fasses a ce que tu ne dois pas connaitre JS, Le monde du travail!

Je crois qu'il fait parti des personnes qui sont les plus a meme de s'exprimer ici! voila

c pas trop grave, tu peux toujours trouver une solution avec des fonctions qui dessinnent des lignes ou même des rectangles vides (un rectangles dans un rectangles dans un rectangles ... ça fait un rectangle plein )

Nitro a écrit :
>Sur console, monsieur poura constater que les 3/4 des routines sont en hard sauf gp32 et compagnie. (tiens je croyais que tu programmais sur gba, alors arretes de me dire des betises comme cela).

Ta phrase d'origine étant:
>De plus sur un 68k, on ne prog pas de la meme maniere que sur une console:
>HW limité
>RAM limité
>ROUTINE GRAPHIQUES en ram Ce à quoi j'ai répondu que c'était strictement la même chose que sur console, et c'est le cas. On ne parle pas du hardware là, on parle des routines qu'on programme.. et sur GBA par exemple, les routines graphiques sont en général en ASM dans la RAM.

Il a certainement voulu dire "en RAM" par opposition à "matérielles", et j'avais compris tout de suite cela quand j'ai lu son message.

Et il me semble bien que les routines logicielles sur GB DMG et sur GBC sont sur la ROM des cartouches. Est-ce que je me trompe?

>Au fait tu as deja programmer sur ti68k une routine asm pour afficher un pxl? non alors bon... ne parle pas de ce que tu connais pas, je vais pas te contredire sur la gba ou autre console.... parce que moi j'ai au moins l'intelligence d'avouer que je ne connais pas tout, et je ne conjecture pas sur des sujets que je ne connais pas. Bien sur que j'ai deja fait des routines graphiques sur ti68k. Mais le projet qui les utilise (ex-Nitro3D) n'est pas encore sorti. De plus j'ai été l'auteur pendant tres longtemps des findpixel les plus rapides et les plus petits en asm Z80 (sources sur ticalc.org).

Le Z80 n'est pas un 68k! Le Z80 ressemble beaucoup plus au x86 qu'au 68k. Et c'est très différent.

>et de plus, leurs ecrans non pas des probleme de sous tension comme sur ti. A mais au fait tu le savait ca? non je crois pas. Le LCD de la GBC n'est pas pourri peut-etre. Ca n'empeche pas Nintendo de se passer de masks.

Regarde certains passages dans SMQ sur une vraie TI-89/92+ pour te rendre compte à quel point le LCD crée des problèmes dès qu'il y a beaucoup de noir (et même si le noir n'est que sur 1 plan, donc en fait dès qu'il y a beaucoup de non-blanc). Le LCD de ma vieille GB DMG est meilleur sur ce point-là!

>Et par consequent, tu vas faire le lien logique comme un grand, a oui je vais te rappeller qqs elements de logique:
( P <=> Q ) <=> ( Q v ]P )
si mes souvenir sont bon...
Et tout ça pour dire quoi ?

Que _X_Lib est (serait ) 20% pour rapide, je suppose.

>Sur une console, t'es pas restreint au niveau resource (relatif) ON EST SUR TI 10Mhz sans routines HARD; est ce que tu as compris?
Tu crois qu'un Z80 à 2 Mhz (GB et GBC) c'est pas limité au niveau ressource ? C'est pas parce que l'affichage est geré en hard que ça te laisse pour autant beaucoup de ressources. La NGPC c'est un proc 16-bit à 6 Mhz.. même la mégadrive est moins puissante (68k 8 Mhz)

La Megadrive a peut-être un 68k à 8 MHz, mais elle a aussi un Z80 pour le son (en peut-on aussi "abuser" pour des calculs?) et du matériel pour les graphismes. Elle doit être au moins aussi puissante que les TI-89/92+ HW2.

>D'ailleur Nitro qu'est ce que tu fous la, tu n'avais pas dit sur le forum GBA que c'etait le communauté la plus pourit que t'avais jamais vu?
Oui c'est le cas. Et comme t'as pu le voir je ne suis pas le seul à penser ça.

Sans commentaire.

>C'est sympat pour les gas de cette communauté, non seulement tu craches sur tout le monde, mais en plus tu le fais dans leur dos...
Ce n'est pas dans leur dos puisque c'est sur ce forum, et je n'insulte personne c'est une remarque d'ordre général.

Mais ce n'est pas dans le forum TI, mais dans le forum GBA, donc c'est bien sur notre dos. Moi, quand j'ai dit ce que je pensais de votre "communauté" de commerciaux, je suis allé dans votre partie du forum.

>Si cette communauté te semble pourit, c'est peut etre parce que certaines personnes (qui a dit toi et pphs) font passer leurs interets avant eux.
Ni moi ni PpHd n'a un quelconque interet à défendre. Tout ce que je vois moi c'est que tu es simplement jaloux qu'il soit si populaire.

Comment t'expliques-tu alors que PpHd fasse de la publicité pour GenLib sans arrêt? D'accord, il n'a pas d'intérêt commercial à défendre (il ne manquerait plus que ça), mais sache qu'il n'y a pas que les $$$ dans la vie!

>Je l'ai programme pour proposer une alternative a genlib qui pour ma part est une lib compltement inadapté a la ti.
On peut trouver qq chose inadapté sans pour autant critiquer à coups de "Genlib sux" et autres bench pourris. Prend exemple sur Kevin.

Merci pour le compliment. Dommage que tu me considères comme un membre d'une "communauté pourrie"...

>D'ailleur pphs s'est permis de critiquer mes sources, mais je pourais en faire de meme avec les siennes.. mais je ne le ferai pas! D'ailleur il a toujours voulu nier la veritée...
Quelle vérité ? (j'ai l'impression de me repeter là)

Que _X_Lib est plus rapide dans mon bench!

freka a écrit :
D'ailleurs, je ne sais pas comment tu peux te permettre de critiquer nitro, pour moi cest une des personnes qui m'etonne le plus dans la communauté ti! Il fait a chaque fois ce que personne n'a fait!

je parle entre autre de son compilo /editeur en niveaux de gris sur ti de son jeu en 3D! (j'attend encore, nitro, de voir une version plus evoluée!)

Sur ce point, je suis d'accord avec toi (et pas d'accord du tout avec TiMad), CC et AS sont excellents! Et SIDE n'est pas mal non plus!

>Il a certainement voulu dire "en RAM" par opposition à "matérielles", et j'avais compris tout de suite cela quand j'ai lu son message.

Sur console également tu peux programmer des routines graphiques toi meme, le hardware ne fait pas tout. La moitié des modes sur GBA par exemple te donnent un framebuffer linéaire, et dans ce cas tes routines tu les programmes exactement comme sur TI.

>Et il me semble bien que les routines logicielles sur GB DMG et sur GBC sont sur la ROM des cartouches. Est-ce que je me trompe?

Pour faire des routines rapides en Z80 tu es obligé de faire du self-modifying code et dans ce cas tes routines sont dans la RAM. De même, sur GBA si tu veux programmer en asm ARM (et non pas THUMB) tu dois le faire dans la RAM interne également pour des raisons de largeur de bus... mais tout ça ce ne sont que des détails.

>Le Z80 n'est pas un 68k! Le Z80 ressemble beaucoup plus au x86 qu'au 68k. Et c'est très différent.

Ca reste de l'assembleur, et le LCD est mappé de la meme maniere... simplement une routine graphique sur TI-68k c'est plus simple que sur TI-Z80 parce que le 68k est plus puissant de part son jeu d'instructions. Les techniques restent les memes.

>Regarde certains passages dans SMQ sur une vraie TI-89/92+ pour te rendre compte à quel point le LCD crée des problèmes dès qu'il y a beaucoup de noir (et même si le noir n'est que sur 1 plan, donc en fait dès qu'il y a beaucoup de non-blanc). Le LCD de ma vieille GB DMG est meilleur sur ce point-là!

Et je ne vois pas en quoi l'utilisation d'un mask améliore celà... par contre l'utilisation du halo rajoute indéniablement un confort visuel face à la qualité de l'écran (suffit de voir CF tourner).

>Que _X_Lib est (serait ) 20% pour rapide, je suppose.

Oui, ben on attend toujours... mais TiMad prefere passer son temps à descendre les autres.

>La Megadrive a peut-être un 68k à 8 MHz, mais elle a aussi un Z80 pour le son (en peut-on aussi "abuser" pour des calculs?) et du matériel pour les graphismes. Elle doit être au moins aussi puissante que les TI-89/92+ HW2.

C'est en tout cas la console la plus proche des TI en terme de puissance. Il est donc normal que PpHd se soit inspiré de celle-là.

>Mais ce n'est pas dans le forum TI, mais dans le forum GBA, donc c'est bien sur notre dos. Moi, quand j'ai dit ce que je pensais de votre "communauté" de commerciaux, je suis allé dans votre partie du forum.

Moi je n'avais nullement l'intention d'aller dans tel coin pour dire que telle ou telle communauté est pourrie, j'ai simplement répondu à ton attaque. Je me défend c'est normal.

>Comment t'expliques-tu alors que PpHd fasse de la publicité pour GenLib sans arrêt? D'accord, il n'a pas d'intérêt commercial à défendre (il ne manquerait plus que ça), mais sache qu'il n'y a pas que les $$$ dans la vie!

Est-ce que dans sa publicité il y a un quelconque "XLib sux" ? Il n'a jamais critiqué que je sache, simplement quand quelqu'un a besoin de qq chose qui est dans Genlib il le fait remarquer...

>Merci pour le compliment. Dommage que tu me considères comme un membre d'une "communauté pourrie"...

Tu as la mémoire courte dis-moi... je peux te sortir un log ICQ qui va te faire rougir, mais bon je ne suis pas la pour ça

>Que _X_Lib est plus rapide dans mon bench!

Et il ne l'est pas dans le mien, tu l'as toi même reconnu.

Franchement, comme si quelques sprites de plus ou de moins par seconde allaient changer le fun ou la qualité d'un jeu... les différences annoncées entre libs ne dépassent jamais les 5 %.

(D'ailleurs un programmeur qui veut se lancer dans un projet utilisera une lib non seulement performante, mais surtout bien documentée, accessible, et en développement actif.)

Arrêtez de sacrifier tout sur l'autel du graphisme; les jeux les plus joués sont quelques fois les plus simples graphiquement; je pense à Phoenix, Tetris, qui, eux, sont toujours sur ma calculatrice...

Nous sommes en train de saborder la communauté TI ; les topics qui ont le plus de succès sont ceux des éternels débats : genlib/pasgenlib, kernel/nostub, c/asm...

MadKeyboard a écrit :
Franchement, comme si quelques sprites de plus ou de moins par seconde allaient changer le fun ou la qualité d'un jeu... les différences annoncées entre libs ne dépassent jamais les 5 %.

(D'ailleurs un programmeur qui veut se lancer dans un projet utilisera une lib non seulement performante, mais surtout bien documentée, accessible, et en développement actif.)

Arrêtez de sacrifier tout sur l'autel du graphisme; les jeux les plus joués sont quelques fois les plus simples graphiquement; je pense à Phoenix, Tetris, qui, eux, sont toujours sur ma calculatrice...
Nous sommes en train de saborder la communauté TI ; les topics qui ont le plus de succès sont ceux des éternels débats : genlib/pasgenlib, kernel/nostub, c/asm...

pff mon pauvre ca fait un bail que ya plus de communauté !!!
js a tjr etait un gars ki avait besoin d'une tete de turc et la plupart du temps c de la jalousie a plein nez

en ce qui concerne les libs moi je voie une chose:

genlib: fernando,sma, chrono ,seiken
xlib:???

XLib> KII quand il sera fini.
(Bon, OK, je reconnais que c'est pas de la même qualité que CF (CF et KII sont les deux seuls jeux que j'ai actuellement sur ma TI), mais je n'essaye pas de me rapprocher de la qualité de CF : je n'ai pas (pas encore ?) l'expérience, ni les connaissances nécessaire)

Ah ! Tout plein de commentaires a repondre Je m'ennuyait la. Va faloir se faire les dents.

TiMad a écrit :
Genlib est loin d'emuler une console.. d'ailleur je ne vois pas en quoi elle en emule une, sachant qu'elle a que des fonctions basiques.

Les capacites hardware proposees par une console sont en generals tres simples. Meme pour le mode 7 de la snes, il faut gerer pas mal de chose par soi meme.

De plus sur un 68k, on ne prog pas de la meme maniere que sur une console:
>HW limité
>RAM limité
>ROUTINE GRAPHIQUES en ram

La RAM d'un console est dans 90% des cas plus rapides, donc les programmeurs recopient leur code graphique en RAM avant de l'executer.

Genlib est tout sauf une lib graphique dite evoluée pour les 68k:

Ce n'est pas une librairie. C'est un environnement de developement !

>Genlib ne presente que des sprites par transparence:
Oui sur les consoles ca marche comme cela, mais sur console on a plus
de 4 niveaux de gris.
>> consequence, les jeux genlib font une emulation 4 niveaux de gris,
et sont souvent tres sombre: seiken ....

Comme a dit Nitro, tu connais les GB,GBC, NGPC, ...

>Genlib n'est pas optimisée niveau algo:
Dans 99% des jeux, les perso missiles evoluent de pxl en pxl, genlib
recalcule tout a partir de l'addresse du debut du gl_plan
>> perte de temps non negligeable, 20% de perte en rapidité par rapport a X.

Arf, il me semblait pourtant que dans X on redessinnait tout aussi. Mais je peux me tromper
Et si le nombre de missilles devient grand, il vaut vraiment mieux tout redessinner.

> Fonction hallo.
Seul fonction qui emule des routines maskée sans en proposée.
Cette fonction est tres lente sans proposer de veritable mask.
>> elle etait 2 fois moins rapide que les routines de X maskée

Tu as mesure au moins avant de sortir ce chiffre ? Cette fonction es pas franchement lente. J'affiche sans pb une trentaine de spr 32x32 avec halo par frame avec deux plane affiche, plus des menus dans cf. Le tout sans ralentissement

> Fonction gl_drawlevelmachinchose
Fonction dite optimisée, emulant les modes de diverses console.

Elle l'ést

Cette fonction ne gere pas les annimations automatiquement, consequence
l'annimation du Background/level doit se faire en C/ASM tout en respectant
le format de gl_drawlevelmachinchose.
>> Perte de temps catastrophique pour les niveaux avec beaucoup d'annimations

T'a jamais programme sur console toi. C'est les tiles qu'on modifie, pas la matrice !
(Sauf si tu veux changer la palette).

> Toutes les fonctions sont clippées
C'est tres bien sachant que ca teste le clipping meme quand on en a pas besoin!

Ca reste negligeable la difference. deux cmp/deux bhi. Bof.

D'ailleur le cliping in fonction est plus lente que ce soit en prog C/ASM
(compter rien que le jsr/rts... plus ce que Kevin avait dit a ce sujet.
>> perte de temps pour les sprites qui reste on LCD ainsi que pour les sprites
en dehors de l'ecran (cf kevin), donc perte de temps totale

A condition de savoir ou il faut afficher. Et pout ca il faut rajouter un test.
Je signale juste que ca augmente la taille du programme de rajouter des tests avant l'appel de fonctions. Oui, j'avoue. J'ai aussi pense que ca serait plus simple

Les arguments ne manque pas, contrairement a ma patience.

Mais si, tu reviens toujours

[cite]
Il est evidant que Genlib est plus programmer pour emuler que pour programmer.
Ses algo ne sont pas optimisés pour tourner sur 68k.
[cite]
Parfait exemple : SMA, CF sont depasses techniquement par ...heu... mais....heu....

Bien quelle soit relativement rapide, il n'est pas difficile de faire plus rapide,
car contrairement a Genlib, X n'etait pas optimise au niveau instructions pour gagner
2 3 cycles par routine, mais optimisé niveau algo.

J'attends toujours de voir tes algos alors. Et si tu avais lu la doc, tu verrais que je dis dedans qu'il est parfaitement possible de faire plus rapide, mais que je me suis contente de cette implementation qui est la meilleure, selon moi, question compromis memoire/vitesse.

D'ailleur sans vouloir critiquer Genlib,
il est possible de faire plus rapide en C pour certaines fonctions de sprites. D'ailleurs
rien que pour vous le confirmer, demander a PpHd, pourquoi Genlib est si rapide pendant ses benchs.
1: il empeche le compilo d'optimiser les routines de Extgraphlib en utilisant des volatile. Ce qui est ridicule sachant que les fonctions C ont pour but d'etre optimiser par le compilo.
2: Ses bench sont irrealistes par rapport aux situations de jeu, il cache les defaut de sa lib. X etait plus rapide que Genlib on lcd... mais pphd arrive a le cacher dans ses bench.

Heu, au contraire, je donne un avantage a Xlib dans mes bench car je ne fais qu'un seul appel a XCopyGplane pour 10000 sprites. Il en faudrait bien plus pour que ca soit realiste. Ensuite si j'utilise volatile c'est que j'ai la flemme de faire un tableau de sprites a afficher. Tu connais beaucoup de jeu dont les sprites sont affiches de maniere sequentielles ?

Bon tout ceci pour dire que contrairement a mon dernier message dit "brutal" pour certain, que le devellopement de X est arreté, et je ne programmerai plus sur 68k .

Qui c'est qui avait raison ? A bientot. Conjecturation du nouveau pseudo:
Kover Keflin

PpHd a écrit :
Qui c'est qui avait raison ? A bientot. Conjecturation du nouveau pseudo:
Kover Keflin

TiMad a écrit :
Sur console, monsieur poura constater que les 3/4 des routines sont en hard sauf gp32 et compagnie. (tiens je croyais que tu programmais sur gba, alors arretes de me dire des betises comme cela).

Va dire ca aux programmeurs qui s'arrachent les cheveux sur PS2 pour la partie graphique Et les routines de lignes ? Et je te signales que le hdz n'est la que pour remplacer l'interruption horizontale.

>Ceux qui sont a cote de la plaque, je pense que tu es sur la scene. Au fait tu as deja programmer sur ti68k une routine asm pour afficher un pxl? non alors bon... ne parle pas de ce que tu connais pas, je vais pas te contredire sur la gba ou autre console.... parce que moi j'ai au moins l'intelligence d'avouer que je ne connais pas tout, et je ne conjecture pas sur des sujets que je ne connais pas.

C'est mechant comme argument

> Oui ce n'est pas une lib graphique evoluee pour ti, au fait tu sais a combien tourne son rotorzoom pour parler de cela? non alors bon encore une reponse dans le vent. Genlib ne propose pas de routine reellement evoluée.

Arf ! Il a trouve une fonction de rotozoom dans genlib. Je ne sais pas comment il a fait. C'est quoi le numero de la fonction ?

"A chaque fois avec une couleur transparente" oui mais pas toujours la meme, et de plus, leurs ecrans non pas des probleme de sous tension comme sur ti. A mais au fait tu le savait ca? non je crois pas.

C'est bien d'essayer de se rattraper. Au fait, as-tu lu la doc et la fonction set_filter

Heu chez moi ca fait que 30% de place.. t'es bien le seul a fait un mask par plan...sur ti (mega lol)

Tout depend quel est ta reference. Il est de coutume de prendre la ref qui donne le meilleur score (C'est pas moi qui est impose ces regles).

Sur une console, t'es pas restreint au niveau resource (relatif) ON EST SUR TI 10Mhz sans routines HARD; est ce que tu as compris?

Parfait exemple de la limitation des Ti-68k: SMA ou CF.
Le pire, c'est que sur 89 hw2, j'ai encore pas mal de cycles libres

Bien raisonnons par l'absurde tu connais : Euclide...
Si j'ai une console a 10Mhz et une calc a 10Mhz, alors je doit avoir les memes performances. > c'est absurde (routine Hard...) donc hypothese fausse
AU fait je vais me faire une lib qui se base sur une GFORCE (mega lol)

Oublie d'un detail : La megadrive a une resolution superieure et travaille en 64 couleurs. La ti a une resolution plus petite et en 4 couleurs. Et on ne perd pas de temps a communiquer avec le VDP, ce qui prend aussi des ressources.

Je n'ai pas cracher sur tout le monde.. seulement sur: PpHd et toi, ainsi que Pollux a une certaine epoque pour son gros fake de GTools (est ce que j'ai tord?).

Comme je suis quelqu'un de poli, je ne cracherais pas sur toi.

D'ailleur Nitro qu'est ce que tu fous la, tu n'avais pas dit sur le forum GBA que c'etait le communauté la plus pourit que t'avais jamais vu?

En grande partie, c'est a cause de toi qu'il a dit ca

Si cette communauté te semble pourit, c'est peut etre parce que certaines personnes (qui a dit toi et pphs) font passer leurs interets avant eux.

Tu as raison. Tous ceux que j'aide sur ce forum peuvent te le confirmer.
Et ce n'est pas parce qu'il utilise pas genlib que je ne l'aiderais pas. Par contre, s'il l'utilise, il aura le 'plus' (Pas vrai liquid) : assistance telphonique, envoie de programmes de developpement, ... Bref, l'apres-service genlib

Au fait pourquoi je me serait tuer a "vendre " Xlib, sachant que il n'y a aucune licence, et que je ne demande aucune reconnaisance a ceux qui l'utilise?

Parce que ca te ferais plaisir de voir que du monde respecte ton travail

Comme tu peux le voir, je me fou du nom que je me suis fait dans cette comu, je donne clairment le droit de tout pomper Xlib ca ne me derange pas. Je l'ai programme pour proposer une alternative a genlib qui pour ma part est une lib compltement inadapté a la ti.

C'est ton point de vue. Mais il change rapidement. je te rappelles qu'il y a un an, tu faisais la publicite de Genlib a donf !

D'ailleur pphs s'est permis de critiquer mes sources, mais je pourais en faire de meme avec les siennes.. mais je ne le ferai pas! D'ailleur il a toujours voulu nier la veritée...

Je t'en pris : fais-le !!!! Je ne demande qu 'a ameliorer les sources (Ca aussi c'est dans la doc ).

Kevin Kofler a écrit :
NON! N'abandonne pas _X_Lib! En le faisant, tu donnes aux fanatiques de genlib une occasion de plus pour se la péter! Et il y a une partie importante de la communauté qui t'a toujours soutenu (moi par exemple)!

Parce que c'était un lib statique
Et franchement, tu aurais vraiment pu t'en douter. Perso je savais qu'elle ne serait jamais fini.

Mais si vraiment tu n'as plus envie de continuer _X_Lib, sors au moins ce que tu as (il me semble bien que tu as des routines pas encore sorties publiquement) pour que quelqu'un d'autre puisse la continuer. ( N'oublie pas de mettre une licence qui interdit l'utilisation dans les programmes pour kernel, je peux te donner un paragraphe en beau "legalese" si tu veux.)

il faudra deja explique correctement ce qu'est un programme kernel ce qui est pas gagne. Je serais curieux de voir cette parti de la licence pour la detourner