internal error - Page 5

non non, pas d'excuses foireuses !
pour le mode FOO comme tu disais, ct un exemple

hum, bon ok

Tiens, faudrat que je regarde CLib, voire ce que c.
En ce qui concerne FLib, elle est hors-jeu. Extrèmement lente (plus lente que le TI-Basic lui même pour les fonction équivalente) et énorme (2*8Ko). Son (gros) point fort est la stabilité.
Vertel est moins stable (faudrat que je te montre mes dernière trouvaille, Vertyos, avec la B8) mais trés largement plus rapide et beaucoup plus petite (8Ko pour la version develloppeur) et infiniment plus puissante.

Kevin>un prog basic qui tourne à 100FPS, j'aimerais voire
En TI-Basic, le vitesse est quand même le point le plus important, tant que la stabilité reste acceptable (à la limite, ça se corrige, l'instabilité).

Aze, tu te rappelle varedit (je pense) ??
Tu m'était combien de temps pour traduire et afficher une page hexa et quel taille cela te prennait ??

A aussi, pour v_read et v_writ, le mieux ce serait de rajouter un argument pour donner le type de données à (r)envoyer (décimale, char hexa, éventuellement binaire et octale) plutot que de modifier v_strn.

mac > oui, quand meme, je me rapelle ^^
(meme s'il esy un peu passé à la trappe )
je mettais 9 secondes pour afficher une page de 80 octets je crois

va falloir que je refasse un test si tu veux
(et que le le vertelise aussi )

et pour l'addon de vertel, une fonction comparable à mkpic de flib pourrait etre la bienvenue (mais pour toutes sortes de fichiers par contre)
avec les char d'echapement ca serait sans failles

Aze>ça va, je met 6 secondes pour 88 octet, et je peut encors l'accélérer, faut juste que je parle de certain trucs avec Vertyos (et je te conseil par ailleur d'attendre avant de le vertéliser)

mkpic et CyclePic aussi

cyclepic> mouais, faut pas deconner quand meme là
atendre ?
ok, pas de pb

a sisi, c pratique pour faire des nvg sans utiliser les nvg

MacIntoc
: En TI-Basic, le vitesse est quand même le point le plus important, tant que la stabilité reste acceptable (à la limite, ça se corrige, l'instabilité).

La stabilité est toujours ce qui compte le plus!
Une des raisons pour lesquelles j'aime tellement bien les jeux TICT est qu'ils ne plantent pas!
Si tu me ponds du BASIC qui plante plus que du C (cf. jeux TICT), tout en ayant la lenteur du BASIC (et ce n'est pas une librairie rapide qui va résoudre ce problème inhérent au BASIC), c'est poubelle direct.

faut le vouloir pour planter vertel je trouve !

(ha, non, tiens xc'est vrai, j'ai eu un address error avec un de mes progs l'utilisant, mais je ne saurais trop dire comment c'est arrivé (dessinage du perso bien en dehors de l'ecran à cause d'un bug (qui a été corrigé puisque le jeu a été effacé )

Kevin>euh... Vertel ne plante que trés rarement (et s'il plante, je pense pas qu'il en soit le responsable réel, le systeme ne devait pas être trés stable avant), mais il lui reste encors quelques bugs.

Je suis totalement d'accord avec KK. Surtout que si ça crashe en BASIC, on perd BEAUCOUP de choses, car on n'archive généralement pas un prog quand on le débogue. (surtout qu'on a bien tendance à perdre patience dans ces cas-là)

MacIntoc >
t quand même dur avec FL en disant qu'il a fait une lib extrêmement lente (plus que du basic??????? un exemple stp, j'aimerais voir). Moins rapide que vertel, ok, mais vertyos a fait en sorte que les arguments soient gérés plus vite (possibilité de faire des secs, etc).
Et puis ya des fonctions qu'on ne trouve pas dans vertel (remarque que l'inverse est vrai aussi lol )
Mais ne critiquons pas trop ce qui nous a servi pendant des années!!!

sisi, c'est pas completement faux :
si tu bench un appel à une seule fonction de flib et à son equivament basic, flib est plus lente, mais ca ne marche que si l'appel à flib ne contient qu'une seule instruction
si tu fais un gros appel et l'equivalent en basic pur, flib sera plus rapide
(et ptet mem plus rapide que vertel sans les listes je crois )

Une des raisons pour lesquelles j'aime tellement bien les jeux TICT est qu'ils ne plantent pas!

C'est vrai que les jeux de la TICT sont spécialement stables et bien programmés. Ca n'est pas facile...

nounoun>avant de connaitre les réelle possibilités de Vertel, g était encors plus dur que Vertyos.
Si tu veut un test, c simple, affiche plusieur une string avec un for en utilisant flib, puis, dans un autre programme, en utilise output.
Ou alors, essyes ce petit programme : DispG ClrDraw 340->key:25->x:25->y while pxlTest(x,y) or k=264 PxlOn y,x getKey()->l when(l>336 and l<345 or l=264,l,k)->k when(k=338,max(y-1,0),when(k=344,min(y+1,104),y))->y when(k=340,min(x+1,239),when(k=337,max(x-1,0),x))->x Endwhile
en remplacant successivement le pxlOn par l'équivalent FLib, Vertel voire CLib (si la fonction existe).

voire CLib (si la fonction existe ).

Heu... Quand-même! Clib n'est pas si arriéré que ça (elle a env. 50 fonctions) alors elle peut quand-même afficher un pixel! (fct 9) et tester avec la 10. Il y a même l'aggrandissement, le remplissage, gestion d'écrans temporaires, map d'images à partir de matrice, attente de touches en idle, bitmap blur, boîtes de dialogues, messages wrapés, ...

bitmap blur ???

Pas très intelligent comme fonction. Juste là pour faire trois niveaux de gris vu qu'il n'y a pas de support gray (comme FL)...
ça affiche une image et ça applique un "fast blur" (pixel=(pixel+pixel de gauche)/2) sur celle-ci.

a ok. En effet, je suis pas sur que ce soit trés utils

[cite]Pas très intelligent comme fonction. Juste là pour faire trois niveaux de gris vu qu'il n'y a pas de support gray (comme FL)... [\cite]

T'es sur que FL n'en a pas? Moi je crois que si.

Ma Intoc-> ok, mais ce genre d'exemple est fait pour avoir flib le plus pénalisé possible et le tios le plus favorisé possible...
C'est pas équitable !

T'es sur que FL n'en a pas? Moi je crois que si.

Justement! Ce que je voulais dire par là, c'est que FLib a un support de gris, mais pas Clib. Il y a juste cette fonction, qui est loin d'être un vrai support gris.

ok, parceque FLib, comme Vertel d'ailleurs utilisent les fonctions grayon et grayoff du TIOS

Le TIOS ne gére pas les niveaux de gris, vertel et flib utilise juste les routines de gris de TIGCC.

Ma Intoc-> ok, mais ce genre d'exemple est fait pour avoir flib le plus pénalisé possible et le tios le plus favorisé possible...
C'est pas équitable !

Nan, dans cette exemple, c Vertel qui est le plus favoriser

MacIntoc-> lol, on sent le parti-pris

geogeo-> Je suis quasiment certain que le TIOS a ses propres routines d'affichage de gray, mais qu'elles ne sont pas utilisées par AMS

nounoun> bah tu nous les trouves

geogeo-> Je suis quasiment certain que le TIOS a ses propres routines d'affichage de gray, mais qu'elles ne sont pas utilisées par AMS

Les niveaux de gris sont un hack, et TI n'a jamais exploiter cette focntionnalitée maheuresement, tout AMS est en noir et blanc et non en 4 niveaux de gris.Encore un avantage non exploité...

Nan les niveaux de gris ne sont pas vraiment un hack. Il sont gérés en soft, c'est différent. Et leur implémentation est tout à fait propre. Sinon les ti-92 (et donc 92+hw1) disposaient de ports permettant de faire des nvg en hardware, même si ça n'a jamais été exploité autrement que dans des programmes de tests (pour la petite histoire, pour utiliser ces nvg il fallait considérer que l'écran faisait 256px de large, donc ça rendait en plus inutilisables toutes les routines graphiques existantes).

ces ports ont été supprimés sur les hw2

Même sur les TI-89 HW1, ils correspondent à autre chose.

ok c'était du hard mais c'était prévu par ti quoi