Sondage lib (nostub): Rapidite , facilite souplesse? - Page 1

Choix 1:
Une lib satique du genre Extgraphlib, qui a une vitesse plutot correcte (du genre extghlib), qui ne prend pas beaucoup de place et qui et tres facile d'utilisation

Choix 2:
Une lib qui propose des routines de sprites plus rapide que extgraphlib , mais moins rapide que genlib, tout en gardant une certaine souplesse d'utilisation, et peu de place (mais un lib qui se limite encora a des jeux pauvre graphiquement

Choix 3:
Une lib comme genlib en nostub, c'ad un lib tres peu souple mais qui a pour avantage d'avoir une tres grande rapidite d'execution, mais qui reste limite a des plan de taille LCDMEM

Choix 4:
Une lib qui gere tout l'aspet graphique, et qui permet au programmeur de l'utilise tres simplement; plus rapide que genlib, mais aussi plus gourmande a l'execution... Son avantage et qu'elle fera tout; son inconvegnant et pour les bons programmeur (elle gerea les gray ... toute seul, donc le bon programmeur ne poura pas faire ses propres routines

Choix 5:
La librairie pour faire que des jeux du genre bomberman, solarstriker.. limite exclusivement aux jeux gourmant, elle genere tout les shifts de sprites en precalcule pouvant demander plus de 120 ko de ram, c'est la plus gourmande de toutes, mais sans contestation la plus rapide

Choix 6:
La librairie nouvelle generation.. un librairie qui cree elle meme son code... j'explique, il suffit par exemple d'execute la fonction makke_lib(taille,hauteur,couleur,vs) et la librairie gerera sont propre code en ram...
Interet: vitesse beaucoup plus rapide que genlib, permettant de faire tout ce que l'on veut au niveau graphisme, c'est la 2eme plus rapide
Inconvegnant; lib plutot gourmande, et demande un tmps de chargement avant le jeu pouvant allez jusqu'a 2 seconde pour des jeux demandant une beaucoup de fonctions

erf bon le sondage a pas l'aire de plaire... dites moi ce que vous voulez...

j'ai légèrement l'impression que le choix est assez évident... Bon, zavez le truc lent, genlib et le truc qui se construit tout seul, qui est super puissant et qui fait tout

justement c'est plutot complique.. j'explique d'avantage la methode:
la routine se construit toute seule ok, mais il faut une routine pour chaque type de sprite (c'ad une routine pour les sprite de hauteur 3 une pour les sprite de hauteur 4 etc... ce qui peut devenir vite barbant a la longue au niveau de l'initialisation..
alors que le choix numero 4, c'est quasiment le meme principe sauf que: au lieu que ce soit la routine qui s'adapte au sprite c'est le sprite quie s'adapte a la routine par exemple pour un sprite de 9*9, a l'initialisation il sera cree en ram en 16 * 16 etc... ce qui au niveau de l'utilisateur sera beaucoup plus simple.... et moins contraignant...

la 3° solution me semble aussi correcte

moi aussi je pense a la 3° solut°

Moi aussi, plutôt la troisième solution (ou à la limite la 6ème, mais ça doit être chaud à programmer)...

Quel intéret, ce sondage ?
Tu compte faire une lib ?

une lib ou du moins fournir des routines du genre extgphlib

au passage, si qq'un a les fonctions sprite8, 16 et 32 en ASM plus rapide qu'extgraph, ça m'interresse grave

tu peux faire plus rapide meme en C,
mais c'est vrai que l'asm est plusse vélosse

oui mais cela restera encore beaucoup trop lent... par rapport a une routines asm

Petite precision cette lib sera pour les programmeurs NOSTUB
Bon sinon j'ai encore besoin de vous:
au niveau des fonctions vous voulez quoi exactement... (citez les toutes.. )
Et puis vous voulez:
des routines qui ne marche que sur des plan undef... et qui utilise donc sa propre routine de gray pour gagner en rapidite...
des routine comme genlib qui sont sur des plans de taille fix...

l'avantage des plan udef: c'est au niveau rapidite d'affichage des sprite on n'a pas besoin de couper les sprites... mais on perd du tmps lorsque l'on copie les plan dans les plan de grays...
alors que genlib perd du temps sur chaque sprite mais gagne du tmps sur la copie dans les plans de grays...

j'en sais rien.. donnez vos idee.. ca peut que m'aider et vous aider ..

bon, alors je veux:

- la possibilité d'avoir plein de calques (gray).
- des fonctions avancées d'operations sur les vecteurs et matrices (en ASM)
- refaire quelques fonctions de type scanf c plus simple pr faire des pitits programmes
- faire une version 'pour programmeurs basic'
- que le mode de programmation fasse que la difference de programmation 92+/89, ben y'en ait pas ... le mm code ...
- inclure la compression shrnklib ou semblable ...
- créer de nouveau logiciels PC pour les sprites ...

héhé, RDV dans 3ans

shrnklib n'est pas la meilleure compression pour TI-89/92+. ttpack compresse mieux, et est déjà utilisable en _nostub; il suffit d'inclure ttunpack.h que l'on trouve dans la TIGCC Tools Suite (où on trouve aussi ttpack.exe).
[edit]Edité par Kevin Kofler le 01-11-2001 à 23:46:43[/edit]

oué, mais tthpack n'est pas une compression uniqument de gfx ...

shrnklib non plus.

Perso je pense que le choix 3 est le meilleur pour les calcs. Sinon j'aimerais bien voir le 6 arriver.
Et puis franchement, il vaut vraiment mieux des LCD de taille fixe. J'ai fait les tests, et compte tenu du fait que le test du clipping, c'est 2 comparaisons, il faudrait beaucoup, beaucoup, beaucoup de sprites pour que ca prenne l'avantage.
Bon courage.
Le pre-shifting est, a mon avis, bien trop gourmand.

shrnklib compresse mieux les gfx. Teste Kevin !

PpHd g besoin de toi !!!! a propos de sprites !!