Question à propos de votre utilisation d'extgraph - Page 3

snow> tu ne comprends décidemment rien à rien sur la compatibilité... les 89/92+/V200 ont le même AMS à peu de choses près, c'est un miracle que KK ait réussi à faire son BackGammon pour 92...

snow, cherche pas a avoir le dernier mot alors que tu as tort

kevin> joli smash

Miles >

Je n'ai pas dit le contraire.

liquid >

Pourquoi aurai-je tort ? Je pense qu'on a tous les deux raison mais
on a des idées dans le sens opposé.

Donc chacun son truc.

erf

BlueSilk
:

Kevin Kofler :
Quel est le problème? Je teste tout sur émulateur, même les programmes TI-89/92+/V200. C'est bien plus pratique que de tout envoyer à la vraie calculatrice à chaque fois. Je connais les défauts de VTI et je sais comment tester sous VTI des trucs qu'il n'émule pas directement (par exemple les histoires de protection - je les connais suffisamment bien pour les émuler dans ma tête avec les données fournies par VTI).

Le problème, c'est de faire des programmes que les gens connaissent. Je ne vois pas comment quelqu'un parviendrait à faire reconnaître son travail exceptionnel, s'il l'a hélas fait sur une TI-80.

Évidemment qu'il ne s'agit pas de ne programmer que pour la TI-92, mais aussi pour la TI-92.

Si on travaille entièrement sur ému c'est qu'il y a peu de calcs. Dans ce cas, c'est comme travailler sur un émulateur PlayStation3, on est sûr de rien quand il s'agit de savoir si ça va être remarqué par quelqu'un.

En effet, il n'y a pas grand monde avec une TI-92. Il y a Ximoon, mais il n'a toujours pas testé mon portage de Backgammon sur sa calculatrice. Je ne sais qu'il marche que d'après VTI.

Il y a nettement moins de 3840 octets à gagner, donc ça ne vaut pas le coup.

Et si je te dis que je trouve bien plus pratique que les deux plans se suivent ?

En quoi est-ce plus pratique???
Tu as 2 plans, un clair et un foncé. Ils sont logiquement indépendants, donc c'est normal d'y accéder par 2 variables différentes. Et dans ce cas, ben qu'une soit à un décalage fixe de l'autre ou non, on s'en fiche!

Avoir une façon de programmer qui nous arrange c'est aussi un gain.

Mais là, ça n'arrange rien du tout.

Non, la routine de gris a une interface bien définie, et l'interface ne changera pas parce que monsieur BlueSilk ne l'aime pas. C'est aux librairies graphiques et aux programmeurs de se plier à l'interface des niveaux de gris, pas l'inverse.

Pourquoi ? Ce sont les programmeurs qui les ont mis en place. Si son fonctionnement les emmerde, c'est à cette interface de se plier aux programmeurs et aux libs graphique.

Non, la librairie système définit l'interface, si tu n'es pas content, programme pour une autre plateforme avec une autre librairie système.

L'interface est telle qu'elle l'est pour des raisons de compatibilité antérieure et pour les raisons déjà décrites (économie de RAM - si je permets de changer les plans, tout le monde va le faire sans réfléchir, et je veux justement interdire
de gaspiller 3840 octets sans raison).

Pourquoi, encore une fois ? Tu pourrais le permettre, et mettre le fonctionnement actuel par défaut.

Pourquoi devrais-je rajouter quelque chose à l'interface de nos routines de niveaux de gris (donc les alourdir) juste pour encourager une idée stupide de ce style?

Je ne vois pas pourquoi on gaspillerait 3840 octets sans raison
valable.

Pour être plus pratique pour le programmeur.

Ce n'est pas une raison valable. Surtout parce que c'est faux.

PS: As-tu bientôt fini de changer de pseudonyme? Ils m'énervent, ces gens qu'on finit par ne reconnaître même plus tellement ils changent de nom!

Ximoon :
bah voyons tu le fais comment le motion blur en 4nvg ?

On a quand-même 4 valeurs pour calculer dessus. Je peux essayer d'implémenter une routine comme ça. Mais je pense aussi que ça rendra mieux en 8 niveaux de gris.

Miles
: c'est un miracle que KK ait réussi à faire son BackGammon pour 92...

Bah, c'est surtout une méthode.
S'il me manque un ROM_CALL:
* soit je le réimplémente en me servant directement des variables globales auxquelles Fargo permet d'accéder (par exemple SetCurClip, la gestion de la VAT, ...), en me contentant parfois d'une approximation suffisamment bonne pour ne rien changer au fonctionnement de mon jeu (par exemple ma routine de lecture de touches n'appelle ngetchx que si une touche est dans le buffer, le remplacer par une lecture de kb_vars n'a rien changé au fonctionnement; autre exemple: je n'ai besoin que du timer APD, donc OSTimerExpired et semblables ignorent complètement le numéro du timer et lisent directement les variables d'APD).
* soit je vais le chercher dans la ROM (par exemple DlgMessage). Il serait d'ailleurs plus propre de mettre à jour Fargo pour ça que de rechercher la routine dans le programme lui-même, mais bon...

Kevin > Bon, pas envie de répondre, ça floode. Et pis, BlueSilk devrait rester BlueSilk un petit moment, ça colle bien à son avatar.

Et puis, laisse le soin à Sasume de faire le Motion Blur. T'as pas inclus extgraph ou toute autre lib n'utilisant pas de ROM Call,
tu vas pas commencer à faire des trucs graphiques maintenant

D'ailleurs c'était mon idée
Donc je mettrai ça dans ma DLL.

Je te signale que Backgammon utilise une routine de sprites à moi!

Kevin: Ne t'inquietes pas. On le reconnait rapidement lorsqu'il change de pseudo...

Kevin > Résultat: il se retrouve sur TI-92.

PpHd >

J'ai une autre question à propos d'ExtGraph.
On prévoit de fournir des fonctions qui permettront d'afficher des sprites seulement à des coordonnées multiples de 16 (ces fonctions seront très rapides puisqu'elles ne nécessiteront aucun shifting).
On affichera donc un sprites en appelant la fonction adéquate et en précisant les coordonnées x et y.
La question est : x et y doivent-ils représenter des numéros de ligne et de colonne (de 16 pixels), ou bien doivent-ils représenter les coordonnées réelles du sprites (qui devront alors être des multiples de 16 - enfin, de toute façon, on effacera les 4 derniers bits) ?
Selon vous quelle solution est la plus cohérente ?

Moi je penche pour la première.

perso, j'utiliserais un mix des deux (), à savoir n° de colonne pour x et n° de ligne (au sens physique) pour y (enfin ça me paraît plus logique)

J'utilise cette technique pour Arkanoid et je serais partant pour la deuxième.

Pour la 1ere (je trouve illogique d'avoir une coordonnée qui ne peut prendre que 0, 16, 32, etc... et qui rend toutes les autres coordonnées invalides, ou du moins inutiles).

Ce serait plus "esprit Extgraph" de prendre la deuxième, pourtant

Perso je pense qu'un bon compromis serait de prendre la première solution, et de faire une macro neuneu-friendly pour ramener la deuxième solution à la première (de toute façon, un shift en plus à chaque fois, c pas ça qui fera grossir le prog).

esprit Extgraph ?

Esprit Extgraph = pas vraiment de format de données (remplacé par des tonnes de paramètres), un maximum de trucs calculés en run-time par la lib, plein de code dupliqué... tout ça pour permettre une soi-disant "flexibilité" et une "facilité d'utilisation".

Résultat, un bloat incroyable. Mais j'imagine (enfin, j'espère) que Extgraph a en partie laissé tomber cet esprit pour la v2.0...

Enfin bon, Extgraph n'a pas le monopole là-dessus : le fait que dans AMS, les HANDLE ne soient pas des multiples de 4 est aussi du même acabit... (et pleins d'autres trucs dans AMS, en fait )

Pfff... Viens pas t'étonner si Kevin fait le même genre de posts envers GTC... Vous êtes tous les deux aussi nuls (pour ne pas employer un autre mot).

Je ne fais qu'expliquer les choix de conception qui font qu'Extgraph 0.x est si lente, ctou (et pareil pour AMS).

Maintenant :
1- c'est probablement dû à une conception à l'arrache tout en voulant limiter au maximum les risques de bugs (les ingés de chez TI devaient avoir des contraintes de malade)
2- je reconnais que le terme "esprit extgraph" est moyennement approprié, parce que ce serait faire un amalgamme. Je dis juste que c'est l'esprit qui a présidé à la conception de l'API d'Extgraph 0.x, et ça tu ne peux pas le nier...

Bah. Tu sais très bien ce que j'ai voulu dire (enfin... vu le post #79 "1-" je me demande, en fait), et j'ai aucune envie de rentrer dans vos débats stériles. Je dis simplement que tu vaux pas mieux que lui...

Non, la seule chose qu'il fallait comprendre c'est que si ils veulent garder des fonctions qui ressemblent en termes d'API à celles d'Extgraph 0.x (ce qui diminuerait les risques de bugs, quitte à en payer le prix niveau rapidité et bloat, comme je l'ai expliqué dans ./78), il vaut mieux utiliser la deuxième forme. Si ils comptent refaire tout à zéro (tout en gardant en parallèle l'API existante, évidemment), alors il vaut mieux utiliser la première forme, à mon avis.

Si tu l'as pris comme un flame contre Extgraph, ben tu t'es planté. Je dis juste qu'il y a deux "philosophies", l'une qui va dans le sens de la simplicité, l'autre dans le sens de l'efficacité.

Nan mais heu... T'es en train de continuer dans ta lancée et moi dans la mienne, le problème c'est qu'on parle pas de la même chose. C'est pas grave, continuez, c'est bien.

Perso je pense que ces fonctions ne servent a rien sinon a augmenter la taille de la lib.

Si, ces fonctions peuvent être utiles, je pense, par exemple, le jeu bobti89 (grav) pourrait être client de ce genre de fonctions.

Pollux> Que signifie "bloat" ?
Et comment garder en parallèle l'API actuelle si on reprend tout à zéro ?

"bloat" = lourdeur excessive. <semi-troll> Exemple : Mozilla </> (mais Firefox est largement mieux )

Cela dit, c'est vrai que des trucs comme le fait d'avoir deux plans entièrement indépendants sont pas évidents à "émuler" à partir d'une nouvelle API (i.e. on peut émuler genlib avec Extgraph mais pas le contraire ). Mais on peut qd même faire qqch : par exemple, avoir des variables globales qui représentent les ports d'affichage, et éventuellement patcher le contenu des routines pour qu'elles n'aient pas à aller les chercher en PC-relatif. Ca économiserait de la taille sur le programme (pas de paramètres en trop, surtout qu'au-delà de 4 ou 5 paramètres chaque paramètre supplémentaire coûte cher) et ça irait plus vite.

Le problème, c'est que c'est une lib statique, donc la solution de patcher les routines est moyennement faisable.
Mais c'est vrai qu'on a des problèmes effectivement avec le nombre trop important de paramètres pour la plupart des routines. Si on utilisait des variables globales pour stocker l'adresse des planes courants, on n'aurait pas ce problème.

Oui, c'est pour ça que je trouve qu'Extgraph est "trop flexible" actuellement. De même que pour les sprites, on doit spécifier l'adresse des plans séparément... C'est un peu bête, parce que les routines ne sont pas assez flexibles pour permettre autre chose que deux plans totalement séparés, donc il n'y a grosso modo que trois possibilités : plan fort puis plan faible, ou bien plan faible puis plan fort (et àmha, c'est un peu dommage de pas standardiser ça, parce que ça peut être source d'incompatibilités), ou bien deux sources de sprites séparées (ce qui est largement la solution la moins efficace au niveau temps de calcul, et au niveau maintenabilité).

Tant que j'y suis dans les suggestions, ça pourrait être une bonne idée de se restreindre aux hauteurs multiples de 2, ou plutôt 4 (même si la fonction accessible à l'utilisateur peut être une macro spécifiant la hauteur en pixel non décalée vers la droite, pour limiter les bugs; et ça n'a pas bcp d'incidence sur la performance puisque cette hauteur risque d'être constante). En plus ça permettrait aux routines de sprites en niveaux de gris de n'être que des appels de routines de sprites en noir&blanc, sans avoir un gros impact sur la performance (à condition d'utiliser un format planaire comme l'actuel)

Pour ce qui est du format de sprite, on a effectivement l'intention d'écrire des fonctions qui gèrent des sprites dont les deux plans sont à la suite.
Mais le problème, c'est que la lib atteint une taille monstrueuse.
Enfin, ce n'est pas vraiment un problème, mais ça me rebute. Et puis pour maintenir la lib, c'est assez galère.
Par exemple, si je trouve une optimisation sur la façon dont on affiche nos sprites clippés, je dois modifier une 40aine de fonctions...

Pour ce qui est de restreindre la taille des sprites à un multiple de 2, j'en ai déjà parlé à XDanger, mais il n'est pas très chaud...
Moi perso, je pense que c'est un bon choix. Ça permet quand même une certaine flexibilité à l'utilisateur.
Au fait, cette restriction permet de dérouler la boucle interne d'affichage du sprite sans ajouter de code compliqué au début pour vérifier la parité de la hauteur du sprite. C'est bien pour ça que tu me le suggérais ou bien ça permet d'autres optimisations auxquelles je n'ai pas pensé ?