Plus d'excuse pour ne pas s'en servir : genlib - Page 2

>Tu appelles ça comment alors, reloger une librairie au format kernel dans un programme _nostub à travers un stub d'importation caché dans une librairie statique supplémentaire?

Bah c'est juste un loader de lib dynamique, tout comme FAT en plus complet... il se trouve que c'est le format utilisé par les kernel, alors une émulation de kernel à la limite... d'ailleurs je vais generaliser le processus et le releaser en lib statique comme ça tout le monde pourra utiliser n'importe quelle lib kernel en mode nostub, ça vous plairais ça n'est-ce pas !!!

>Nitro>>Ca te dit SNK vs CAPCOM de la NGPC ? Ou Metal Slug ?

Metal Slug NGPC ce serait parfait...
[edit]Edité par Nitro le 01-04-2002 à 15:19:31[/edit]

et il te faut tt les graph ?!

timad>oui, ce sera un jeudi.....

"ouh pitin !!!! on a deux extrémistes maintenant : en plus de Kevin y'a XDanger": Ca fait déjà un moment que je suis ici... J'y étais venu pour participer au débat kernel-nostub. Si tu veux d'autres partisans du nostub il n'y a aucun problème, il y en a beaucoup sur le forum officiel de TIGCC.

PpHd est un programmeur de talent, mais sa librairie est gâchée par des incompatibilités multiples, notoires !
FAT est beaucoup mieux fait que GenLib. Pour GenLib: Ne serait-il pas plus simple de faire exactement comme ExtGraph, une lib statique intégrée directement dans le programme, à la compilation ? C'est plus propre ! (ah, j'oubliais, c'est vrai que programmation kernel = sale).

Dorénavant, il ne faudra plus compter sur moi pour dire que GenLib est bien, que ce soit ici où ailleurs, tant que ce truc ne marchera pas correctement de partout, comme TIGCC.
Sur ce forum, les discussions passent souvent à la polémique dès qu'il s'agit de kernel/nostub.

>et il te faut tt les graph ?!

Juste ceux du 1er niveau ça suffira pour le tutorial... les 2 layers de background et toutes les frames de tous les sprites... avec neopocott on peut isoler les layers facilement.

oui je connais, j'ai deja pas mal bossé dessus


mais la j'ai un peut la fleme de m'y mettre !

Pourquoi je trouve genlib aussi nulle:

> supression d'une couleur:
perde de qualité, qui est obligatoire, puisque pphd ne presente pas de routine maské..(de vrai mask, pas des transaprences...)
> incompatibilité avec pas mal de chose:
En particulier avec tout programme voulant utilise que partiellement Genlib... en effet, lorsque l'on demarre le prog, il faut demarrer genlib et de meme quand ont l'arrete, il faut arreter genlib.. sinon dans pour les prog nostub, l'ecran n'est pas regeneré...
> Pas dans la mentalité nostub:
Dans tout programm, genlib insert une sort de pseudo stub... ce qui prend de la place pour rien
> Qqs bugs:
Cf topic Xlib, dans mon bench...
> Et pour terminé: grosse perte de rapidité pour les programmes en C... car genlib n'est pas optimisée pour le C.

Je pourai en sortir d'autres, mais cela sert a rien, puisque la majorité des personnes qui defende cette lib ne savent meme pas programmer en asm, ou alors ne se rendent meme pas compte des restrictions de cette lib...

On sait que tu la trouve nulle... pas la peine de le crier a tout va

>TiMad:
>> supression d'une couleur:
>perde de qualité, qui est obligatoire, puisque pphd ne presente pas de routine maské..(de vrai mask, pas des transaprences...)

Entièrement d'accord.

>> incompatibilité avec pas mal de chose:
>En particulier avec tout programme voulant utilise que partiellement Genlib... en effet, lorsque l'on demarre le prog, il faut demarrer genlib et de meme quand ont l'arrete, il faut arreter genlib.. sinon dans pour les prog nostub, l'ecran n'est pas regeneré...

Ça se contourne:
#define SAVE_SCREEN
#include <tigcclib.h>
#undef SAVE_SCREEN
#include <genlib.h>

Mais je trouve idiot qu'un header se met à désactiver des règlages en prenant l'utilisateur pour un idiot! Pour NO_EXIT_SUPPORT, d'accord, si ce n'est pas compatible, on peut supprimer (même si à la place de PpHd, je mettrais tout simplement un #error), mais pour SAVE_SCREEN, c'est vraiment idiot.

>> Pas dans la mentalité nostub:
>Dans tout programm, genlib insert une sort de pseudo stub... ce qui prend de la place pour rien

D'accord.

>> Qqs bugs:
>Cf topic Xlib, dans mon bench...

Je n'ai pas vérifié, mais je te le crois.

> Et pour terminé: grosse perte de rapidité pour les programmes en C... car genlib n'est pas optimisée pour le C.

Avec TIGCC 0.94 et le passage par registres, ça devrait aller assez bien normalement. Mais c'est vrai que genlib a été prévu pour l'assembleur et pas pour le C.

>Sur ce forum, les discussions passent souvent à la polémique dès qu'il s'agit de kernel/nostub

C'est sur qu'avec des reflexions intelligentes du genre "ah, j'oubliais, c'est vrai que programmation kernel = sale" ...

>Mais je trouve idiot qu'un header se met à désactiver des règlages en prenant l'utilisateur pour un idiot!

C'est pour éviter de recevoir des questions de la part de ceux qui ne lisent pas les docs... et tu ne vas pas me dire que tout le monde ici lit les docs.

>Pour NO_EXIT_SUPPORT, d'accord, si ce n'est pas compatible, on peut supprimer (même si à la place de PpHd, je mettrais tout simplement un #error), mais pour SAVE_SCREEN, c'est vraiment idiot.

Genlib restaure deja l'écran tout seul (meme en nostub) alors je ne vois pas ce qu'il y a d'idiot ?

>Dans tout programm, genlib insert une sort de pseudo stub... ce qui prend de la place pour rien

C'est ça oui, les gens ne sont jamais contents de toutes façons. Vous vouliez Genlib en nostub, bah ça y est, et pourtant tout le monde continue de critiquer. Quelle attitude clienteliste...
Exemple:
TiMad> Pourquoi je trouve genlib aussi nulle
C'est ce que j'appelle cracher sur les nombreuses années de travail que PpHd a fourni pour faire cette lib, et je comprends qu'il soit fatigué d'entendre ces conneries à chaque fois qu'on parle de Genlib.

>la majorité des personnes qui defende cette lib ne savent meme pas programmer en asm, ou alors ne se rendent meme pas compte des restrictions de cette lib

Celle là c'est la meilleur.. c'est sur que PpHd niveau assembleur c pas terrible.. et tu n'as pas l'air de savoir ce que je faisais quand j'etais actif il y a quelques années, non plus.
Alors que toi c'est clair tu masterises, ya qu'a voir les questions stupides que tu poses dans la rubrique ASM... apprendre a lire les tutos et la doc de TIGCC ça t'aiderais surement.

>Pour GenLib: Ne serait-il pas plus simple de faire exactement comme ExtGraph, une lib statique intégrée directement dans le programme, à la compilation ? C'est plus propre !
>incompatibilité avec pas mal de chose: En particulier avec tout programme voulant utilise que partiellement Genlib... en effet, lorsque l'on demarre le prog, il faut demarrer genlib et de meme quand ont l'arrete, il faut arreter genlib

Je pense que vous n'avez toujours pas compris ce que c'est que Genlib... c'est pas un amat de fonctions qui peuvent etres utilisées independemment pour les petits programmes comme Extgraph. C'est un environnement complet qui ressemble au hardware d'une console de jeux, avec ses propres interruptions, etc... Si vous voulez Genlib en lib statique, le minimum vital (qui doit etre aux environs de 5 Ko) sera inclu dans tous les programmes, ça c'est une réelle perte de place. De plus, on peut mettre à jour une lib dynamique sans avoir besoin de recompiler les jeux, pour accelerer ou corriger les problemes d'incompatibilités.. mais bon ça on le repete a chaque fois et il y en a toujours qui ne comprennent pas.

>supression d'une couleur: perde de qualité, qui est obligatoire, puisque pphd ne presente pas de routine maské..(de vrai mask, pas des transaprences...)

Là c'est pareil, avant de critiquer faudrait deja avoir un peu plus de connaissances dans ce domaine. Si ça marche comme ça il y a une bonne raison: quasiment tous les systèmes de jeux video 2D fonctionnent comme ça, en particulier toutes les consoles 2D de Sega (SMS/GG/Genesis), la NGPC, et toutes les consoles portables de Nintendo (DMG/GBC/GBA). Je ne parle pas des autres car je n'ai jamais eu l'occasion de les programmer, mais je suis presque sur que c'est la meme chose dans les NES/SNES et la Lynx. Et pourquoi est-ce que la notion de masques n'a jamais existé sur ces consoles ? Tout simplement parce que ça prend enormement de place en plus pour pas grand chose de qualité visuelle. Personne n'a jamais critiqué la Gameboy en disant qu'il n'y avait que 3 couleurs pour les sprites, non ? Essayez d'imaginer SMA si pour chaque frame de chaque sprite il avait fallu rajouter un masque...

>supression d'une couleur: perde de qualité, qui est obligatoire, puisque pphd ne presente pas de routine maské..(de vrai mask, pas des transaprences...)


Oui sur GBA c la meme technique d'affichage k genlib, la couleur 0 (noire) est transparente et c'est vraiment hyper pratique et hyper rapide comme technique d'affichage.

La seule différence c k du coup sur GBA il reste 255 couleurs disponibles (ou 32767 si on travaille en 16 bit mais c tres rare pour les sprites) alors k sur TI il en reste plus k 3 !!!!
En clair on perd 25% de couleurs alors k sur des sytemes comme sur GBA on perd à peine 0,01% de couleurs
[edit]Edité par Aghnar le 01-04-2002 à 21:58:41[/edit]

Je ne parle pas seulement de la GBA... sur les 2 autres, DMG (Gameboy normale) et GBC c'est 3 couleurs aussi, donc autant de perte que Genlib.

Chic un topic plein a craquer de posts a critiquer Ca fait plaisir.
Je m'ennuyais.

Let's start.

>- C'est une librairie dynamique.
a mes yeux, c'est un gros plus. Il n'est pas necessaire de recompiler les programmes pouyr qu'il soit a jour. Un programmeur peut arreter de maintenir son programme, et il fonctionnera toujours.

>- Ça prend 16 KO pour la version "petite", et 18 KO pour la version standard.
Et ? Evidemment, si c'est juste pour gl_put_)sprite_16, c'est un peu juste.
Mais des qu'il y a un gl_put_plane, la ca devient tres interressant.

>- Pour l'utiliser en _nostub, il faut en plus linker avec une librairie d'importation, qui est une librairie statique prenant environ 3 KO dans chaque programme.
Ce n'est pas optimise. Ca ne prendra que 1,5 Ko a la fin.
Peut etre moins si je simplifie les exigences kernels de genlib (Par exemples, Heap ou les rom_calls).

> Donc autant utiliser ExtGraph, qui ne prend pas beaucoup plus de place dans le programme et qui n'a pas besoin d'une librairie dynamique en plus des 3 KO pris dans le programme.
On peut utiliser et ExtGraph Et Genlib.

>mais ca reste pas simple a utiliser, meme avec la doc est les exemples je m'en sort
>po faites un toto claire et y aura du monde .....
Et le french.txt, c'est ok ? (Dans genlib-v09922b) Sinon, Nitro bosse sur un tuto.

>non, aucun programme compilé en nostub ou kernel ne marche sur ma VTI (AMS 2.03), pas plus le bench que les autres (écran blanc dans le meilleur des cas, crash sinon) !
Envoies moi le save state de Vti, que je decouvre l'erreur.
Ca marche chez moi, et en nostub et en kernel.

>En plus, lorsqu'on compile sous nostub, ça ne fait rien: ça sort en mettant 'Library not found: genlib' !
forcement, ca reste une librarie dynamique.

>Genlib n'est pas vraiment nostub puisqu'elle importe si je ne m'abuse une sorte de mini kernel dans chaque programme....
genlib n'est pas nostub.
Mais un programme nostub peut importer genlib, alors ou est le probleme ?
je vous rappelle que nostub, c'est sans le header du noyau.

>pis XLib est vachement plus simple a utiliser ...
Lol ! C'est pareil.

>C gros 32*32 , je me demande pourkoi on utilise de tels sprites
ben moi, je vais jusqu'au 64x64 dans SMA, et dans Cf, jusqu'au 70x100

>La future version de Xlib vera bientot le jours


>si c'est po du 7 gray, c ilisible et ce serai le meilleur moyen de montrer qui sont les boss ici
Le 7 gray est moins lisible en scrolling, et fait plus mal aux yeux.
L'exemple est en 4 gray.

>Kevin confirme que les routines de gray de Genlib ne marchent pas sur VTI, contrairement à celles de TIGCC
Ben moi j'utilise HW_VERSION pour detecter l'hardware et donc la routine de niveau de gris. Donc je vois pas le probleme. Une trop vieille version peut etre ?
chez moi, ca marche niquel meme avec une tib (Sauf les fontes, mais bon).
Faut que j'aille sur le forum de la tigcc.

>Perso je n'aurai rien contre genlib, si elle n'etait pas si lente
perso, j'aurais rien contre Xlib s'il y avait un vrai DSCREEN.

>Mais les niveaux de gris de TIGCC fonctionnent sur VTI qu'on ait un dump entier ou seulement une mise à jour! Il y a juste 12 lignes d'assembleur à mettre pour détecter VTI (et elles y sont dans nos routines)!
En mode nostub, ce sont vos routines de detection hw que j'utilise.
En mode kernel, ce sont les memes.

>Tu appelles ça comment alors, reloger une librairie au format kernel dans un programme _nostub à travers un stub d'importation caché dans une librairie statique supplémentaire? Moi, j'appelle ça de l'émulation, et XDanger aussi apparemment.
Une importation de librairie !

>mais sa librairie est gâchée par des incompatibilités multiples, notoires !
Lequelles ? Je rappelle mon adresse e-mail pour tout probleme.

>FAT est beaucoup mieux fait que GenLib
Je t'ai reconnu Super-menteur.

>Ne serait-il pas plus simple de faire exactement comme ExtGraph, une lib statique intégrée directement dans le programme, à la compilation ?
Non. Car toutes les fonctions sont inter dependantes. En inclure une revient a inclure toutes les autres. En fait, il suffit d'inclure gl_init / gl_set_dscreen_function et tu auras besoin de 99% de la lib.

>C'est plus propre !
Mais non. C'est tres propre.

>programmation kernel = sale
Rien a voir.

>Dorénavant, il ne faudra plus compter sur moi pour dire que GenLib est bien
Tu l'avais dit ? A excuse moi alors.

> les discussions passent souvent à la polémique dès qu'il s'agit de kernel/nostub
C'est bien ca qui est cool.

>> supression d'une couleur:
>perde de qualité, qui est obligatoire, puisque pphd ne presente pas de routine maské..(de vrai mask, pas des transaprences...)
Et les Bgs, t'as essaye ? L'emulation du halo, est vraiment tres bien.
Et j'en ai marre de defendre les idees de Nintendo / Sega / Sony /Atari / ... bref de tous les constructeurs de carte graphiques / consoles.

>> incompatibilité avec pas mal de chose:
>En particulier avec tout programme voulant utilise que partiellement Genlib... en effet, lorsque l'on demarre le prog, il faut demarrer genlib et de meme quand ont l'arrete, il faut arreter genlib..
Lol. Tu connais la signification du mot 'Environnement de developement" ?
Tu peux demarrer genlib, ok. Mais apres tu peux configurer genlib pour revenir comme avant. C'est hyper flexible. Tu peux melanger AMS / Extgraph. /... tout en restant dans genlib.
Le seul truc, c'est qu'elle doit etre en amont. Ce n'est pas genant puisque les autres acceptent d'etre en aval sans problemes.

> sinon dans pour les prog nostub, l'ecran n'est pas regeneré...
LOL.
genlib le fait tout seul !

>> Pas dans la mentalité nostub:
>Dans tout programm, genlib insert une sort de pseudo stub... ce qui prend de la place pour rien
il faut bien importer la librarie. Si tu importes pas, tu auras pas.
Et le FAT engine, c'est pas du nostub peut etre ?
Et tictex ?

>> Qqs bugs:
>Cf topic Xlib, dans mon bench...
Ton bench est vraiment sur ? Ca fait 1 heure quíl tourne...

> Et pour terminé: grosse perte de rapidité pour les programmes en C... car genlib n'est pas optimisée pour le C.
Oui, c'est vrai. Je sauvegarde plus de registres que necessaires. Ca doit bien prendre 4 cycles de plus Mais je compense largement apres

>Je pourai en sortir d'autres, mais cela sert a rien, puisque la majorité des personnes qui defende cette lib ne savent meme pas programmer en asm,
Et moi ? Et nitro ?

>ou alors ne se rendent meme pas compte des restrictions de cette lib...
QUELLES RESTRICTIONS ? toutes tes arguments ne sont pas valables.



>Mais je trouve idiot qu'un header se met à désactiver des règlages en prenant l'utilisateur pour un idiot! Pour NO_EXIT_SUPPORT, d'accord, si ce n'est pas compatible, on peut supprimer (même si à la place de PpHd, je mettrais tout simplement un #error), mais pour SAVE_SCREEN, c'est vraiment idiot.
Si on a decide de ne pas tolerer SAVE-SCREEN, c'est que c'est toujours fait !
gl_init sauve l'ecran
gl_quit restaure l'ecran.

Ça se contourne:
#define SAVE_SCREEN
#include <tigcclib.h>
#undef SAVE_SCREEN
#include <genlib.h>

>Je n'ai pas vérifié, mais je te le crois.
Tu as tord de croire Timad :-
Surtout un 1er avril.

>C'est ce que j'appelle cracher sur les nombreuses années de travail que PpHd a fourni pour faire cette lib, et je comprends qu'il soit fatigué d'entendre ces conneries à chaque fois qu'on parle de Genlib.
Ca m'amuse plus qu'autre choses. Je sais que c'est la number one, et de loin.
Et avec la derniere techmologie que je vais implanter, ca va tout peter
mais c'est encore Top Secret.

>Je pense que vous n'avez toujours pas compris ce que c'est que Genlib... c'est pas un amat de fonctions qui peuvent etres utilisées independemment pour les petits programmes comme Extgraph. C'est un environnement complet qui ressemble au hardware d'une console de jeux, avec ses propres interruptions, etc... Si vous voulez Genlib en lib statique, le minimum vital (qui doit etre aux environs de 5 Ko) sera inclu dans tous les programmes, ça c'est une réelle perte de place. De plus, on peut mettre à jour une lib dynamique sans avoir besoin de recompiler les jeux, pour accelerer ou corriger les problemes d'incompatibilités.. mais bon ça on le repete a chaque fois et il y en a toujours qui ne comprennent pas.
99% d'accord. C'est bien de parler a des gens cultives de temps en temps.
(Le minimum est bien plus gros)

>Oui sur GBA c la meme technique d'affichage k genlib, la couleur 0 (noire) est transparente et c'est vraiment hyper pratique et hyper rapide comme technique d'affichage.
Et l'argument :
'Essayez d'imaginer SMA si pour chaque frame de chaque sprite il avait fallu rajouter un masque... "
Tu en fais quoi ? Ce qui importe pour la qualite graphique d'un jeu dans l'ordre decroissant :
+ La qualite des graphistes
+ Le nombre d'etape d'animation
+ La taille des images (resolution)
+ le nombre de couleurs.
Or mettre une couleur transparente permet d'augmenter de 50% le nombre de graphs disponibles, d'ou une meilleure qualite graphique.
C'est marrant, on critique genlib sur la qualite graphique, Or cf et sma qui utilise genlib sont clairement les plus beaux jeux. On se demande pourquoi ? Peut etre une approche plus intelligente de la gestion memoire ?

Oui, oui 3 posts. J'ai pas pu faire autrement.

Enfin deja ce qui serai cool c'est de rajouter une routine non maské et sans transparence.. car on pert du temps pour rien avec cette transparence.. alors que pour l'arriere plan, il n'y en a pas besoin.

Pour Gba, ok, mais eux, ils ne sont pas limité a 4 couleurs.. donc le sacrifice ne se voit pas...

Sinon pour le probleme de l'ecran regeneré, cf le bench.. j'ai pas reussit a le regenére, car je desactive genlib et j'utilise des fonctions apres...

Sonic tournerai tres bien avec des mask... mais le probleme serait en mem...

Pour Xlib, je proposerait les 2 methodes.. (maské et transparence..) ce qui ne pose pas de probleme, car la lib sera vraiment static... Mais il est domage que genlib n'en fasse pas autant..

50% heu pas tout a fait.. 30%

L'arriere plan est gere par gl_put_plane. Donc pas de probleme de transparence.
Appelle en dernier gl_quit. Et appelles gl_set_LCD_MEM s'il faut que tu continues a travailler apres.
>Sonic tournerai tres bien avec des mask... mais le probleme serait en mem...
C'est bien ce que je dis. Deja qu'avec la consommation actuelle qui reduit les besoins memoires, on me croitiques sa consommation, avec des masks se serait impossible.

Ensuite j'ai dit +50%. Ce qui est exact. Ce qui fait 33% du total.

C'est sur que les transparences ont des avantages.. d'ailleur, je penche de plus en plus vers cette solution...

Ce n'est pas pour rien si les grands editeurs de console de jeux, ont tous choisis cette methode.

PpHd convertit et convertira tout le monde !
XDanger : "tant que ce truc ne marchera pas correctement de partout"
Ha ouai bha tu dois pas dire de bien de beaucoup de chose alors ...
TiGCC n'est pas encore correct de partout et ne le sera peut être jamais comme tout les progs sur et pour Ti. "eternellement béta "

>C'est sur que les transparences ont des avantages.. d'ailleur, je penche de plus en plus vers cette solution...

Ca fait plaisir de voir que certains ne sont pas totalement bornés

Et puis je rappelle aussi que glaux (la librairie auxiliaire de Genlib) est completement static, et va s'agrandire tres bientot avec toutes sortes de fonctions pratiques pour accelerer le temps de développement.

Ceci étant dit, _X_lib présentera des fonctions maskées, car parfois elles sont plus qu'indispensable...

tiens en parlant de tigcc, la derniere version (qui ne marche pas chez moi) pourrait etre bien si je pouvais la tester......oui kevin m'a dit comment faire mais moi je sais pas koi faire avec un fichier *.tar.bz2

Winace ?

Juste au passage, la reflexion sur les mask c'est idiot car :
- 1er plan : 4 couleurs donc pas besoin de mask
- 2eme plan : 3 couleurs (mais comme on a le choix entre mask noir ou mask blanc, on a une palette suffisament grande pour la plupart des graphs, suffit de bien choisir lors des conversion, une chose que ne fais pas gstudio à ma connaissance)
- 3eme plan : 4 couleurs (simulés avec le halo)

Au final, on a 3 plans avec quasiment 4 couleurs à chaque fois là où la plupart des jeux n'en aurait que 2... en utilisant autant de mémoire !

Mais c'est vrai que peu de jeux sont aussi complexes

-

Je t'ai envoye une version qui fonctionne sur Vti par e-mail !

Désolé, je n'avais pas vu le post sur le forum de TIGCC...

PpHd, je ne peux rien t'envoyer, cf le post sur le forum des bug reports...
[edit]Edité par XDanger le 03-04-2002 à 19:46:45[/edit]

liquid > *.tar.bz2 : sous linux "tar xjf machin.tar.bz2" ou directement avec "ark" sous X.
Sous windows, tu peux utiliser cygwin, meme commande...

Je dirais plutot http://sources.redhat.com/bzip2/