Un nioob de Genlib - Page 3

geogeo
: Xlib et GraphX prennent énormément de place pour pas grand choses, sont pas très agréable en programmant avec et surtout certaine fonctions élémentaires sont oublié.

Stop les bêtises !!!

GraphX Xlib Genlib prennent de la place pour une vitesse accrue, chose indispensable pour des jeux de bonne fluidité.
Le truc qui me fait bien rire, c'est que ExtGraph sera aussi grosse que GraphX (routines à 2 shifts déroulées 2 fois) alors que Messieurs KK et LD condamnaient GraphX à sa sortie pour la place qu'elle prenait, expliquant que les 12 FPS d'ExtGraph étient suffisants
M'enfin, ils ont reconnu s'être trompés. Les fonctions d'ExtGraph vont prendre des kilos et la lib va gagner en FPS...

GraphX et Xlib sont très agréables à utiliser.

Les "fonctions élémentaires oubliées" peuvent se récupérer chez la "concurrence "(X ou EG) et être utilisées dans un jeu GX : lit la doc avant d'avancer de telles choses. Ma lib n'est pas si hermétique que ça.

PiNGoO
: on peut toujours utiliser les routines de tigcc de sprites ...etc, pas comme pour GraphX

Faux ! mais d'où vient cette idée que beaucoup affirment ? Le contraire est expliqué en gros dans la FAQ de GX !

XDanger
: Certes, mais tu peux dire tout plein de conneries, de la provocation, et après mettre un smiley content pour tenter de le faire passer pour de l'humour. Certains ici sont spécialistes de ça...

Non, c'est toi qui ne saisit jamais. On va te le répéter combien de fois ?

En tout cas, il faut initialiser la librairie, ce qui n'est pas le cas avec ExtGraph.

Argument foireux
Il faut activer les NDG avec EG. Ca revient à taper XOn ou GX_PowerOn.

pour les sprites etc de tigcc, j'avai cru lire ça enfin c'est toi le createur de la lib, et si tu dis qu'on peut...
pour "initialiser" par contre je me suis mal exprimé, mea culpa

http://alineasofts.free.fr/graphx/fichiers/documentation/accueil.htm#cdadfdabqg

geogeo : Xlib et GraphX prennent énormément de place pour pas grand choses, sont pas très agréable en programmant avec et surtout certaine fonctions élémentaires sont oublié

heu, fo pas abuser qd même !
J'utilise Xlib pour KII depuis le tout début de KII, qui correspond aussi en gros au tout début de Xlib... et Xlib n'est pas désagréable à utiliser...
(fonctionnement simple, ma foi ; et, qui plus est, proche de celui d'allegro sur pc, ce qui permet de passer de l'une à l'autre sans se poser de questions)
fonctions élémentaires oubliées ? bah, rien ne t'empéche d'utilise extgraph avec Xlib,à la limite (meme format de plans), c'est tot à fait faisable cela dit, Xlib permet de développer un jeu rapide sans que j'ai l'impression qu'il me manque quoi que ce soit (enfin, je me débrouille, j'écris des fonctions... mais je ne ressent pas de manque ; je ne me suis samais dit "argh, Xlib fait pas ça ou ça")

En tout cas, il faut initialiser la librairie, ce qui n'est pas le cas avec ExtGraph

bah, pour faire un jeu, avec extgraph, il faut :
- rediriger AUtio_int_1 et 5
- allumer les grays
avec XWlib, il faut
- appeller la foncitond 'init (ou alors, initialiser à la main, si la fonction ne te convient pas ; c'est à dire faire ce qui est fait pour extgraph au dessus)

Bon d'accord, Xlib ne prend pas beaucoup de place... Mais ce n'est pas le cas de GraphX et c'est normal.

Mais ce qui me dommage c'est quand même d'utiliser 2 librairies graphique, une pour combler les manques de l'autre, c'est surtout ça que je repproche car pour mon une librairie graphique doit être le plus complet possible sans que le programmateur pompe des fonctions sur d'autres librairie et encore mùoins qu'il programme des fonctions banal sans trop de raport avec son programme.


Au sujet de l'initialisation, je ne vois pas le mal mais en effet initaliser à la main peut être une bonne chose. Par exemple pour GraphX, rien que l'initialisation prend 20 Ko et si on n'utilise que les fonctions timers, 20 Ko c'est énorme.
Ce n'est plus mon cas car maintenant je code la fonction de timers et je n'utilise plus cette librairie, si je l'utilise ça sera pour un programme demandant beaucoup de vitesse.

Bon d'accord, Xlib ne prend pas beaucoup de place... Mais ce n'est pas le cas de GraphX et c'est normal.

Quoi ???? Mais qu'est-ce que tu racontes ???????????

Par exemple pour GraphX, rien que l'initialisation prend 20 Ko et si on n'utilise que les fonctions timers, 20 Ko c'est énorme.

ttttt !!! GX est plutôt prévue pour le graphisme, pas pour les timers uniquement.
Pareil avec toutes les libs : fonction de grays + sauvegarde du LCD + réservations des plans 0 et 1... ça fait beaucoup de ko pour tout le monde.
Pour GX, tu ajoutes : les deux plans du TSB + la table des multiples de 30.

Quoi ???? Mais qu'est-ce que tu racontes ?????? ?????

ttttt !!!
Pareil avec toutes les libs : fonction de grays + sauvegarde du LCD + réservations des plans 0 et 1... ça fait beaucoup de ko pour tout le monde. Pour GX, tu ajoutes : l'installation de la gestion des timers + les deux plans du TSB.

C'est pourquoi je dis qu'une initialisation à la main est mieux dans ce cas mais pas possible avec GraphX.

Bah oui puisque GX n'est pas prévue pour qu'on n'utilise que les timers. JE ferais peut-être timers.h/.a un jour.

godzil
: D'ailleur la GPL ne demande pas que les sources soir forcement a cotédes binaires, mais juste que les sources soit dispo sur simple demande

Sauf que ton offre doit être écrite (sur papier, signée), pas électronique.

JackosKing
: 1. bon deja la rapidité de Extgraphlib je la connais puisque JackieChan et moi discutons par minimessage (lui au moins admet certains defaults de Extgraphlib).

Il est trop modeste.

2. Extgraphlib ne peut pas etre aussi rapide que gen et X pour le simple fait que vous ne fetes pas de difference entre certains shift (ce que toute bonne lib graphique fait..)

Ça multiplie la taille au moins par 2 pour pas grand chose de gagné.

3. Le nombre de fonctions, parlons en, bon alors on a le droit entre sprites clippés, non clippés (supper... autant dire que ca sert a rien ..).

Non clippé = plus rapide, donc si on sait qu'on est en train de dessiner au milieu de l'écran, ou si on dessine toujours de l'aligné (tous les jeux ne scrollent pas forcément pixel par pixel), autant utiliser les non-clippées.

4. J'aime trop la mentalité on integre notre lib dans tigcc... trop bien encore uen chose qui va gonfler les programmes fait avec tigcc, comme si ils n'étaient pas si gros que ca..

Crétin, si on n'utilise pas leurs routines, la taille du programme ne changera pas du tout! Tu n'as toujours pas compris ça???

et plus cela montre bien votre coté ouverture a la concurence, votre lib est tellement bien que vous etes oibligé de l'imposer dans un pac officiel de tigcc, qui est un compilateur il me semble, ca ressemble a VC++ et DirectX...

Et ben, tu vois bien qu'on n'est pas les seuls à le faire...
Et si on ne peut pas intégrer les vôtres, c'est pour des raisons de licence et d'intégrabilité (hacks des routines de gris etc.). On l'a déjà expliqué plein de fois!

LE pire c'est que vous critiqué sans cesse les log non libre ou les log qui ne respectent pas les licences etc, mais vous vous etes pire.. vous etes du genre, faut bannir les autre (ex su ce frm pour telle chose) et des qu'on vous le fait vous pleurnichez...

N'importe quoi!

nEUrOO
: geogeo: tu te trompes sur pas mal de choses ... programmer avec XLib ou GraphX est tres simple, d'ailleurs, ce sont les deux libs les plus simple je trouve.

Je ne suis pas d'accord.

Quelles fonctions élémentaires ont été oubliées ?

XOR, juste à titre d'exemple.

JackosKing
:

Pour Extgraph, c'est vraiment la librairie parfaite pour son confort de programmation et surtout le peu de place quelle occupe malgré quelle est pas très rapide pour certaines choses

Confort de programmation, pour moi c'est ca:

XOn()
XClrGPlan();
XGNSprite(10,10,toto);
XSwap();
XWait(Esc);
XOff();
la au moins tu te concentres que sur la programmation du jeu et non pas sur les trituration a faire à coté..

Avec TIGCCLIB et ExtGraph:
if (!GrayOn()) return;
ClearGrayScreen();
GraySprite16OR(toto,16,10,10,GrayGetPlane(DARK_PLANE),GrayGetPlane(LIGHT_PLANE)); /* je ne sais pas à 100% si c'est le bon ordre des paramètres */
ngetchx();
GrayOff();
Ce n'est pas plus dur.

ssentielle et le mode X8 pour les sprites et 32x32

je l'ai deja dit et le repete, le mode X8 est lent allez bencher un mode X8 contre le XSmall, vous verez bien la diff! et on pert pas de place si on sait programmer 2 3 ligne de C.

X8, ce n'est pas du 8×8, c'est du (8x)×y!

Mais merde y à pas que la vitesse qui compte dans une librairie graphique.

Pour un morpion certe, pour un jeu un peu plus bourin si

Non, il n'y a pas que la vitesse qui compte.

nEUrOO
: C'est vrai que c compliquer d'initialiser une librairie ...

Mais pourquoi faut-il initialiser la librairie? Il devrait suffir d'initialiser les gris (GrayOn)!

Thibaut
: GraphX Xlib Genlib prennent de la place pour une vitesse accrue,

Pas grand chose quoi.

chose indispensable pour des jeux de bonne fluidité.

Non. Optimisez vos jeux, tout n'est pas de la faute des librairies graphiques.

Le truc qui me fait bien rire, c'est que ExtGraph sera aussi grosse que GraphX (routines à 2 shifts déroulées 2 fois)

Elle ne le sera pas, en tout cas pas la version qui sera intégrée à TIGCCLIB! XDanger et jackiechan, si vous déroulez, je forke.

M'enfin, ils ont reconnu s'être trompés. Les fonctions d'ExtGraph vont prendre des kilos et la lib va gagner en FPS...

Pas du tout.

GraphX et Xlib sont très agréables à utiliser.

Non.

Les "fonctions élémentaires oubliées" peuvent se récupérer chez la "concurrence "(X ou EG) et être utilisées dans un jeu GX : lit la doc avant d'avancer de telles choses. Ma lib n'est pas si hermétique que ça.

Autant n'utiliser que ExtGraph dans ce cas.

XDanger
: En tout cas, il faut initialiser la librairie, ce qui n'est pas le cas avec ExtGraph.

Argument foireux Il faut activer les NDG avec EG. Ca revient à taper XOn ou GX_PowerOn.

Mais pourquoi faut-il une routine spéciale quand GrayOn marche très bien?

squale92
:

En tout cas, il faut initialiser la librairie, ce qui n'est pas le cas avec ExtGraph

bah, pour faire un jeu, avec extgraph, il faut : - rediriger AUtio_int_1 et 5

Pas du tout. Rien ne t'empêche d'utiliser ngetchx(); ou kbd_queue. ExtGraph ne t'oblige à utiliser aucune méthode particulière pour la lecture des touches.

Thibaut
:

Par exemple pour GraphX, rien que l'initialisation prend 20 Ko et si on n'utilise que les fonctions timers, 20 Ko c'est énorme.

ttttt !!! GX est plutôt prévue pour le graphisme, pas pour les timers uniquement.
Pareil avec toutes les libs : fonction de grays + sauvegarde du LCD + réservations des plans 0 et 1... ça fait beaucoup de ko pour tout le monde. Pour GX, tu ajoutes : les deux plans du TSB + la table des multiples de 30.

Pfff, n'importe quoi... 20 KO sont quand-même énormes!!! GrayOn prend 1 seul KO! Ta librairie prend 20 fois plus!

ca y est, bon je vais repondre aux messages en plusieurs temps:

Avec TIGCCLIB et ExtGraph:
if (!GrayOn()) return;
ClearGrayScreen();
GraySprite16OR(toto,16,10,10,GrayGetPlane(DARK_PLANE),GrayGetPlane(LIGHT_PLANE)); /* je ne sais pas à 100% si c'est le bon ordre des paramètres */
ngetchx(); GrayOff();

=> ouain mais la t'as pas le douible buffering et de plus c'est pas compatible TI89 ti 92 V200, donc au chiotte.

X8, ce n'est pas du 8×8, c'est du (8x)×y!

le XSmall est plus rapide pour ce genre de situation et prend moins de place si on utilise la routine de sprite.

Non, il n'y a pas que la vitesse qui compte.

Pour u jeu graphique ca compte a 90%

Pas grand chose quoi.

tout ce qui manque a Ext!

Autant n'utiliser que ExtGraph dans ce cas.

ca c'est ce que vous voulez imposer! mais vous savez que tout le monde a le droit d'utiliser la lib qu'il veut .. (du moins en france c'est le cas,bien que vous essayez d'imposer une lib par le biais d'un compilo ..)

Mais pourquoi faut-il une routine spéciale quand GrayOn marche très bien?

Gray on ne suffit pas...

Pas du tout. Rien ne t'empêche d'utiliser ngetchx(); ou kbd_queue. ExtGraph ne t'oblige à utiliser aucune méthode particulière pour la lecture des touches.

Xlib non plus.. parle de ce que tu connais et non de ce que tu ne connais pas!

Pfff, n'importe quoi... 20 KO sont quand-même énormes!!! GrayOn prend 1 seul KO! Ta librairie prend 20 fois plus!

Il me semble que c'est 20 Ko en ram ce qui se justifie beaucoup plus...

D'une, c'est faux pour les Sprite8 qui ont deux shifts depuis des mois. De deux, faire des routines avec deux shifts et une boucle déroulée deux fois, avec un format de sprite optimisé, est sur la todo list...

Tiens vous changez d'avis.. c'est cool a la tigcc team, on critique qqc en disant que c'est con comme methode et on le prend ensuite.

Bien sûr que ça sert ! Si tu sais que tu ne dessines aucun sprite en-dehors de l'écran (ce qui est le cas pour beaucoup de softs ne nécessitant pas beaucoup de puissance graphique, citons TI-Chess, TI-TiltMaze, TI-Miner...), qu'as-tu à faire d'une routine de sprite clippée qui est plus grosse et plus lente qu'une routine non clippée qui suffit dans ce cas précis ?

Le temps que prend le clipping est négligeable...
Le probleme c'est que certaines personnes vont utiliser les 2 routines #nb#...

Admettons cet argument sur la taille. On verra ce qu'il en est, en vitesse et en taille, quand tu auras fait ton DrawLevel dans XLib...

faudrais savoir vous priviligiez la vitesse ou la taille, ca devietn de plsu en plus louche votre histoire...

C'est ton droit.

Oui mais ce n'est pas tout le monde qui peu integrer sa lib a tigcc, d'où le probleme..
Imposer un lib, c'est comme imposer un os, donc vous critiquer microsoft, mais vous c'est la meme chose!

Je te rappelle aussi qu'il n'y a pas de fonctions équivalentes à XOn et XOff, qui pour moi enlèvent un peu de flexibilité à un programme...

En bref vous refetes un XLib like.. heu il est oèu l'interet?

Mais bien sûr. On se fout de la taille d'une librairie, si elle est statique.

tu as un raisonement limité en temps que developper qui est jamais sorti de son petit monde, quand on fait un jeu on utilise plusieurs routines, si vous fetes des routines independante, pour les petits prog vous etes gagnant pour le sgros perdant! maintenant fait un jeu et on en reparle..

JackosKing
:

Avec TIGCCLIB et ExtGraph:
if (!GrayOn()) return;
ClearGrayScreen();
GraySprite16OR(toto,16,10,10,GrayGetPlane(DARK_PLANE),GrayGetPlane(LIGHT_PLANE)); /* je ne sais pas à 100% si c'est le bon ordre des paramètres */
ngetchx(); GrayOff();

=> ouain mais la t'as pas le douible buffering

Et alors? Tous les jeux n'en ont pas forcément besoin.

et de plus c'est pas compatible TI89 ti 92 V200

C'est tout aussi compatible que ton exemple à toi.

X8, ce n'est pas du 8×8, c'est du (8x)×y!

le XSmall est plus rapide pour ce genre de situation et prend moins de place si on utilise la routine de sprite.

Fais-moi du 80×23 avec des XSmall...

Non, il n'y a pas que la vitesse qui compte.

Pour u jeu graphique ca compte a 90%

Mais en tout cas pas à 100%.

Autant n'utiliser que ExtGraph dans ce cas.

ca c'est ce que vous voulez imposer! mais vous savez que tout le monde a le droit d'utiliser la lib qu'il veut .. (du moins en france c'est le cas,bien que vous essayez d'imposer une lib par le biais d'un compilo ..)

Pfff...

Et pourquoi utiliser 2 librairies plutôt qu'une seule bien intégrée (ExtGraph en l'occurrence, parce que justement les autres ne proposent pas les fonctions dont il a besoin)?

Mais pourquoi faut-il une routine spéciale quand GrayOn marche très bien?

Gray on ne suffit pas...

Si.

Pas du tout. Rien ne t'empêche d'utiliser ngetchx(); ou kbd_queue. ExtGraph ne t'oblige à utiliser aucune méthode particulière pour la lecture des touches.

Xlib non plus..

Donc le problème des interruptions concerne aussi XLib.

Pfff, n'importe quoi... 20 KO sont quand-même énormes!!! GrayOn prend 1 seul KO! Ta librairie prend 20 fois plus!

Il me semble que c'est 20 Ko en ram ce qui se justifie beaucoup plus...

C'est quand-même excessif.

JackosKing
:

D'une, c'est faux pour les Sprite8 qui ont deux shifts depuis des mois. De deux, faire des routines avec deux shifts et une boucle déroulée deux fois, avec un format de sprite optimisé, est sur la todo list...

Tiens vous changez d'avis.. c'est cool a la tigcc team, on critique qqc en disant que c'est con comme methode et on le prend ensuite.

Ça ne sera certainement pas la routine "normale", mais une avec un nom bien particulier qui sera juste là pour faire taire les gens comme toi.

Bien sûr que ça sert ! Si tu sais que tu ne dessines aucun sprite en-dehors de l'écran (ce qui est le cas pour beaucoup de softs ne nécessitant pas beaucoup de puissance graphique, citons TI-Chess, TI-TiltMaze, TI-Miner...), qu'as-tu à faire d'une routine de sprite clippée qui est plus grosse et plus lente qu'une routine non clippée qui suffit dans ce cas précis ?

Le temps que prend le clipping est négligeable... Le probleme c'est que certaines personnes vont utiliser les 2 routines #nb#...

Et alors, c'est leur problème, pas le nôtre.

Je te rappelle aussi qu'il n'y a pas de fonctions équivalentes à XOn et XOff, qui pour moi enlèvent un peu de flexibilité à un programme...

En bref vous refetes un XLib like.. heu il est oèu l'interet?

As-tu lu ce que tu cites?

Mais bien sûr. On se fout de la taille d'une librairie, si elle est statique.

tu as un raisonement limité en temps que developper qui est jamais sorti de son petit monde, quand on fait un jeu on utilise plusieurs routines, si vous fetes des routines independante, pour les petits prog vous etes gagnant pour le sgros perdant! maintenant fait un jeu et on en reparle..

Les routines sont indépendantes parce qu'elles doivent l'être. Ce que tu fais en des routines dépendantes (16×8, 16×16) est fait par la même routine de ExtGraph.

Fais-moi du 80×23 avec des XSmall...

XPic c'est pour les chiens??

Les routines sont indépendantes parce qu'elles doivent l'être. Ce que tu fais en des routines dépendantes (16×8, 16×16) est fait par la même routine de ExtGraph.

Le format X8 est obsolete pour les jeux graphiques evolués (graphiquement)

As-tu lu ce que tu cites?

et toi?

Ça ne sera certainement pas la routine "normale", mais une avec un nom bien particulier qui sera juste là pour faire taire les gens comme toi.

Heu pourquoi ne pas conseiller une autre lib alors? puisque ca ne suit pas vos idées...
Bon allez laisse tombé on a compris, vous voulez imposer votre compilo, avec vos lib, et vos ideaux (nostub, dll)!

C'est quand-même excessif.

Parle pas de ce que tu ne connais pas...

Donc le problème des interruptions concerne aussi XLib.

?? t'es betes ou quoi?

Et alors? Tous les jeux n'en ont pas forcément besoin.

Les jeu necessitant un puissance graphique evoluée si!

C'est tout aussi compatible que ton exemple à toi.

Fait un jeu avec XLib pour 89 , tu veras qu'il resteras quand meme compatible 92+ V200.. contrairement a Ext

Kevin Kofler
: XDanger et jackiechan, si vous déroulez, je forke.

Sacré Kevin... l'histoire se repete, mais on commence à avoir l'habitude.

monsieur impose ce qu'il veut.. super..

JackosKing
:

Ça ne sera certainement pas la routine "normale", mais une avec un nom bien particulier qui sera juste là pour faire taire les gens comme toi.

Heu pourquoi ne pas conseiller une autre lib alors? puisque ca ne suit pas vos idées...

Non, parce qu'il a dit explicitement qu'elles ne lui suffisent pas.

Kevin Kofler
:

nEUrOO
: C'est vrai que c compliquer d'initialiser une librairie ...

Mais pourquoi faut-il initialiser la librairie? Il devrait suffir d'initialiser les gris (GrayOn)!

Ben non, ça ne suffit pas. Tu es en train de discuter d'un sujet dont tu ne connais pas grand chose, comme l'autre jour à propos de la simulation du petit filtre à geogeo.
Il y a des tables de précalcul à remplir (vitesse), des buffers à allouer (TSB), les tables des handles des buffers et des timers à initialiser à zéro, le noyau répartiteur des tâches et le gestionnaire de TSB à installer, des interruptions à désactiver si TRUE est passé en argument à GX_PowerOn (rien n'est désactivé si on passe FALSE), et d'autres détails que j'oublie.

Thibaut
: GraphX Xlib Genlib prennent de la place pour une vitesse accrue,

Pas grand chose quoi.

Tu vas rester bloqué toute ta vie sur tes petites opinions en oubliant qu'elles ne conviennent pas à tout le monde ?

M'enfin, ils ont reconnu s'être trompés. Les fonctions d'ExtGraph vont prendre des kilos et la lib va gagner en FPS...

Pas du tout.

Ben si ! Les nouvelles routines ont deux shifts, jackiechan l'a dit, et XDanger envisage de dérouler les boucles.

GraphX et Xlib sont très agréables à utiliser.

Non.

Tu pourrais avoir la gentillesse d'expliquer en quoi ExtGraph est la plus agréable ?
Ha, toi... tes idées, ta team chérie,... c'est forcément ce qu'il y a de mieux au monde
Si on veut être honnête, je pense qu'elles se valent.

Les "fonctions élémentaires oubliées" peuvent se récupérer chez la "concurrence "(X ou EG) et être utilisées dans un jeu GX : lit la doc avant d'avancer de telles choses. Ma lib n'est pas si hermétique que ça.

Autant n'utiliser que ExtGraph dans ce cas.

Sauf si on veut gagner quelques FPS. Tu dois laisser les utilisateurs choisir, Môssieur le Maître.

20 KO sont quand-même énormes!!! GrayOn prend 1 seul KO! Ta librairie prend 20 fois plus!

A mon avis, elle prend moins. Je ne sais pas où geogeo a vu ça. J'ai énuméré ce qui est responsable des quelques ko supplémentaires en RAM. Ceux qui ne sont pas content sont assez intelligents pour décider d'eux-même d'utiliser ExtGraph ou Xlib. Personne n'a besoin de ta propagande de merde.

Non, il n'y a pas que la vitesse qui compte.

Pour un jeu graphique ca compte a 90%

Mais en tout cas pas à 100%.

Le retour de la mauvaise foi... Ca ne te dérange pas de faire semblant d'être con quand c'est pour essayer de faire passer tes idées C'est pas cool ça !
Ce que veut dire JS, c'est que 90% du temps processeur est utilisé par la bibliothèque. On gagne donc plus de FPS à optimiser un peu la bibliothèque qu'à optimiser beaucoup le code du jeu.

Et pourquoi utiliser 2 librairies plutôt qu'une seule bien intégrée (ExtGraph en l'occurrence, parce que justement les autres ne proposent pas les fonctions dont il a besoin)?

Aucune raison de répondre à ça, tu connais la réponse. Si tu n'es pas sûr de toi, je la donne tout au long du post.

Il me semble que c'est 20 Ko en ram ce qui se justifie beaucoup plus...

C'est quand-même excessif.

Oui, c'est beaucoup, mais les programmeurs qui ont besoin de beaucoup de RAM peuvent utiliser d'autres libs. Heureusement qu'ils ont le choix, suivant ce qu'il considèrent d'important (nostub/kernel ? vitesse ? taille ? consommation RAM ? souplesse ?) !
Heureusement qu'il n'y a pas uniquement ExtGraph comme lib graphique Idem pour Xlib, GX, GenLib.
Tu ne comprends pas ça ?

Tu ne comprends pas ça ?

Le retour de la mauvaise foi... Ca ne te dérange pas de faire semblant d'être con quand c'est pour essayer de faire passer tes idées C'est pas cool ça !

Sauf si on veut gagner quelques FPS. Tu dois laisser les utilisateurs choisir, Môssieur le Maître.

Tu pourrais avoir la gentillesse d'expliquer en quoi ExtGraph est la plus agréable ?
Ha, toi... tes idées, ta team chérie,... c'est forcément ce qu'il y a de mieux au monde Si on veut être honnête, je pense qu'elles se valent.

Tu vas rester bloqué toute ta vie sur tes petites opinions en oubliant qu'elles ne conviennent pas à tout le monde ?

Je trouve que tes remarques son assez agressive pour pas grand chose, c'est un débat ici. Tu devrais faire des efforts de ce côté là.

Tu as déjà oublié ce topic ? Tu n'es pas concerné par le débat, ça se voit.

Et puis je ne vois que "Ca ne te dérange pas de faire semblant d'être con quand c'est pour essayer de faire passer tes idées" qui pourrait être mal pris. Autant m'expliquer avant qu'il se sente agressé. J'ai bien dit semblant d'être con. Je lui dit indirectement que je sais qu'il est très intelligent, et que je regrette qu'il sorte ces remarques qui ne sont que mauvaise foi.

Je reconnais que je suis agressif sur l'ensemble, mais quel intérêt y a-t-il à rester amical quand celui qui est en face de toi se fou de ta gueule à faire semblant de ne pas comprendre qu'il n'a pas toujours raison et que ce qu'il pense c'est de la merde pour la majorité de la communauté française (qui est celle qui n'est pas influencée par la propagande) :/

sois il comprend pas ..
soit il est trop fils a papa et pense qu'il est le centre du monde..

C'est ce que j'ai toujours pensé. Il me fait peur.
Pour lui, il ne faut pas de diversité (pas de concurrence kernel/nostub, TIGCC/GTC, TICTboard/yAronet ("on est des isolationnistes", il faut la retinir celle-là ), ...), tout le monde utiliserait sagement ce qu'il préconise (ExtGraph, TIGCC, nostub, TICTboard), on cacherait toute la concurrence.
J'ai le sentiment qu'il pourrait être dangereux s'il se retouve dans la politique plus tard.

En attedant qu'on ait l'autorisation de répondre là-bas, voilà d'autres exmples qui me font croire qu'il se prend un peu pour le centre du monde :

histoire Xlib+DLL,

= Histoire J.S. qui ne lit pas ou ignore la documentation.

Voilà. Ceux qui se croient libres de faire leur programme comme ils veulent sont en fait soumis aux recommendations des Messieurs les Maîtres du monde. Si tu choisis d'être libre (normal) et de penser différemment de quelques fous, ton programme se fait ridiculiser sur toute la planète...

propagande pour le mode nostub,

Ce n'est pas de la propagande.

Ha bah nan bien sûr parler uniquement du mode nostub aux débutants, ou, quand on parle du kernel, présenter uniquement ses inconvénients en face des avantages du nostub, c'est pas de la propagande

comme TIGCC documentera ces fonctions et ne parlera pas des autres libs graphiques, les newbies n'auront pas même l'idée qu'il puisse y avoir d'autres fonctions d'affichage de sprites que FastSprite<...>).

Et alors?

Aucune explication à donner, c'est flagrant et sa fait très peur.

de toute maniere ne pas reconnaitre la concurence, ca c'est fait que par monopole (ex Microsoft), ou par faiblesse..

Ou par fierté de ses idées. En tous les cas, c'est dangereux pour les utilisateurs qui n'ont plus la liberté de penser.
Oligarchie, c'est pas le mot ?

Thibaut
:

Kevin Kofler
:

nEUrOO
:C'est vrai que c compliquer d'initialiser une librairie ...

Mais pourquoi faut-il initialiser la librairie? Il devrait suffir d'initialiser les gris (GrayOn)!

Ben non, ça ne suffit pas. Tu es en train de discuter d'un sujet dont tu ne connais pas grand chose, comme l'autre jour à propos de la simulation du petit filtre à geogeo.

Ce n'est pas que je n'y comprends rien, c'est que je me contrefiche de la qualité de ta simulation, ça reste de la simulation et pas de la pratique!!!
Fai-toi rentrer ça dans ta tête! La rigueur scientifique et toi, ça fait deux.

Il y a des tables de précalcul à remplir (vitesse), des buffers à allouer (TSB), les tables des handles des buffers et des timers à initialiser à zéro, le noyau répartiteur des tâches et le gestionnaire de TSB à installer, des interruptions à désactiver si TRUE est passé en argument à GX_PowerOn (rien n'est désactivé si on passe FALSE), et d'autres détails que j'oublie.

En résumé, tout plein de petits trucs inutiles dont ExtGraph se passe très bien.

Thibaut
:GraphX Xlib Genlib prennent de la place pour une vitesse accrue,

Pas grand chose quoi.

Tu vas rester bloqué toute ta vie sur tes petites opinions en oubliant qu'elles ne conviennent pas à tout le monde ?

Je te retourne ta question...
Arrête (ou plutôt "arrêtez", n'est-ce pas JackosKing?) de croire en le "dieu vitesse"!

M'enfin, ils ont reconnu s'être trompés. Les fonctions d'ExtGraph vont prendre des kilos et la lib va gagner en FPS...

Pas du tout.

Ben si ! Les nouvelles routines ont deux shifts, jackiechan l'a dit,

Ce sont les routines spéciales, pas celles qui sont intégrées. Ou alors cf. ci-dessous.

et XDanger envisage de dérouler les boucles.

S'il fait ça, je forke pour l'intégration à TIGCCLIB.

GraphX et Xlib sont très agréables à utiliser.

Non.

Tu pourrais avoir la gentillesse d'expliquer en quoi ExtGraph est la plus agréable ?

Format de sprites standard, routines simples d'emploi etc.

Non, il n'y a pas que la vitesse qui compte.

Pour un jeu graphique ca compte a 90%

Mais en tout cas pas à 100%.

Le retour de la mauvaise foi... Ca ne te dérange pas de faire semblant d'être con quand c'est pour essayer de faire passer tes idées C'est pas cool ça !Ce que veut dire JS, c'est que 90% du temps processeur est utilisé par la bibliothèque.

Ce n'est carrément pas ce qu'il a dit! Et en plus c'est faux.

On gagne donc plus de FPS à optimiser un peu la bibliothèque qu'à optimiser beaucoup le code du jeu.

Cf. ci-dessus.

Et pourquoi utiliser 2 librairies plutôt qu'une seule bien intégrée (ExtGraph en l'occurrence, parce que justement les autres ne proposent pas les fonctions dont il a besoin)?

Aucune raison de répondre à ça, tu connais la réponse. Si tu n'es pas sûr de toi, je la donne tout au long du post.

Bref, ta réponse est que le programmeur devrait se faire ch**r à utiliser un mélange de 2 librairies graphiques juste pour éviter le "monopole" de ExtGraph??? C'est carrément n'importe quoi.

Quant à ton message ./82, c'est carrément de la mauvaise foi.

Bien sûr, on est 50 personnes de mauvaise foi, à avoir tort donc, et Kevin est le seul lucide... Tu te prends pas pour de la merde. Tout le monde te répète la même chose mais tu nous prend toujours autant pour les merdes qui sont trop connnes pour comprendre le Maître. Ca ne fait que confirmer les posts #80 #81 et tous les autres qui ont été fait sur toi dans Coups de Gueule.


> En résumé, tout plein de petits trucs inutiles dont ExtGraph se passe très bien.

Oui, les timers sont inutiles pour ton petit jeu BackGammon, donc ils sont inutiles pour tout le monde. Idem pour le TSB, la désactivation des interruptions, etc.
ExtGraph est donc suffisante pour tout le monde. Bref, c'est la meilleure du monde, ne parlons que d'elle, tout le monde doit l'utiliser, faisons de la propagande en parlant en bien d'ExtGraph et en mal des "concurrents", voir en n'en parlant pas du tout.
Bravo : re-confirmation de ce qui a été dit précédemment.


> et XDanger envisage de dérouler les boucles.
>> S'il fait ça, je forke pour l'intégration à TIGCCLIB.

Bravo, re-re-confirmation !!! Tu as raison, les jeux sur TI sont trop rapides, il faut inverser la tendance => Imposons une ExtGraph lente !


> Format de sprites standard

Du moment que les éditeurs de sprites sont livrés avec, cet argument n'a pas de valeur. C'est le cas pour Xlib, et ce sera le cas de la prochaine version de GX.


> routines simples d'emploi etc

Idem pour GX et Xlib. Bref, sur le point de la simplicité, les trois se valent.

heu parce qu'il y à un standart au niveau des formats de sprites??, c'est quoi ce bordel.
Mias KK arrete de raconter des bêtises!!!!

C'est pas la peine que tu parles de sujets dont tu ne connais pas grand chose..

Le standard, c'est le format utilisé par TIGCCLIB et ExtGraph. Essaye de convertir un sprite avec un logiciel générique comme ImageStudio et il te sortira exactement ce format-là.

et pkoi ca serait celui la le format standart ? parce que tu l'a décidé?

un standart est définit par un organisme indépendant, tu n'es pas un organisme, encore moins indépendant

D'ailleurs le format à utiliser est au choix du programmeur. S'il veut un format x qui fonctione avec une librairie a ou un format y qui fonctione avec une librairie b ou n'importe quoi d'autre c'est son choix, alors "Le standard" -> .