Niveaux de gris - Page 3

Heu vu que je n'ai jamais programmé en kernel, j'ai jamais utilisé ça, mais vu les derniers essais de 7/8 gris sur HW2, je serais bien tenté de dire qu'au moins gray7 ne marche pas sur HW2. Et comme je n'ai jamais vu de gris nettement mieux que ceux de TIGCClib, gray4 ne doit pas être fabuleuse non plus :-/

Mais as-tu essayé le mode anti-clignotement (F2 pdt le jeu)? Le clignotement (en tous cas chez moi) est quasiment égal à celui de TIGCC mais les niveaux meilleurs. Cependant ce n'est pas le top (le gris foncé recommence fortement à pointer sur le gris foncé). A croire qu'il faut choisir: une bonne fréquence OU un nivelage incorrect. Mais bon, parfois je tripe un peu sur ces fréquences de gris: et si on avait une fréquence qui serait plus ou moins celle des yeux, il n'y aurait aucun problème;
-> il est donc impossible de faire une fréquence ET un nivelage "potable" tant qu'on cherche à obtenir ces valeurs par clignotement!

Le reglage "anti clignotement" à part baisser le contraste il fait pas grand chose, ça clignote toujours autant.

On ne doit pas avoir la même TI, ou bien nettoie ton écran
La différence est super-nette (clignotement environ trois fois plus rapide! Tu ne vas pas me dire) Mais c'est clair qu'après il faut remonter le contraste pour voir la différence. Mais bon, même en anti-clignotement la fréquence n'est pas parfait. J'en suis conscient (et même la routine de TIGCC est loin d'être parfaite)

Brunni :
On ne doit pas avoir la même TI, ou bien nettoie ton écran

Bah ué tu dois avoir un model spécial, quelqun d'autre peut essayer ?

La différence est super-nette (clignotement environ trois fois plus rapide! Tu ne vas pas me dire) Mais c'est clair qu'après il faut remonter le contraste pour voir la différence. Mais bon, même en anti-clignotement la fréquence n'est pas parfait. J'en suis conscient (et même la routine de TIGCC est loin d'être parfaite)

Nan mais c'est même pas parfait là... Ce que j'essaye d'expliquer depuis le début c'est que la routine de TIGCC est très largement acceptable et que la tienne est inutilisable (clignote BEAUCOUP trop quelque soit le mode), c'est tout.

L'algorithme de TIGCCLIB est le seul couramment utilisé. Universal OS utilise à l'origine le même code (ça a divergé depuis, mais l'algorithme reste le même), PreOs utilise le même algorithme avec du code différent. Tous les autres algorithmes (mis à part celui de Brunni) sont plus anciens et clignotent affreusement ou ne marchent pas du tout sur HW2.

Celui de Brunni est plus récent ce qui ne l'empeche pas de clignoter aussi affreusement

Mais bon, le problème qu'il y a c'est que si tu testes le premier niveau de mario3, ça va VRAIMENT clignoter à mort vu que quasiment tout l'écran est recouvert de gris et que c'est uni. Même avec la routine de TIGCC ça clignote dans ce cas... En fait, le problème qu'il y a, on ne peut pas facilement le résoudre. Et puis mon algo n'est certainement pas le meilleur (peut-être que si j'utilisais celui de TIGCC...) vu que je ne suis pas un "pro". En plus, c'est bien les premières lignes de code ASM que j'aie écrites.
Mais bon, avec mon projet actuel, j'utilise ma routine mais ça ne clignote pas DU TOUT. J'utilise seulement une technique de tramage intelligente qui fait que:
1. Le tramage ne rend pas l'écran trouble avec le défilement
2. Vu que les surfaces d'un même niveau de gris sont restreintes, le problème du premier niveau de Mario 3 est réglé
3. Ce mode de tramage ne fait pas faiblir l'écran contrairement à celui de Mariole.
Donc en gros, c'est MIEUX qu'avant.

Brunni
: Mais bon, le problème qu'il y a c'est que si tu testes le premier niveau de mario3, ça va VRAIMENT clignoter à mort vu que quasiment tout l'écran est recouvert de gris et que c'est uni. Même avec la routine de TIGCC ça clignote dans ce cas...

Arrete de comparer TIGCC a tes gris et surtout arrete de dire n'importe quoi... Je suis en train de développer un jeu avec des niveaux de gris largement utilisés ça ne clignote pas un poil.

Donc en gros, c'est MIEUX qu'avant.

Tant mieux, à voir.

Non mais je veux bien que les niveaux de gris sont meilleurs avec TIGCC (ma fréquence est d'environ 80% celle de TIGCC en mode anti-clignotement) et que ça peut gêner des gens mais bon... Je donnerai le choix entre GrayOn ou ActGris!
Mais perso ça ne me gêne pas du tout.

He bah t'as des yeux bizzares, parceque chez moi c pas jouable
y'a qu'à demander l'avis de ceux qui ont testé mario 3.

Teste le test et après tu pourras me dire ce que t'en penses. Sauf que le mode anti-clignotement n'y est pas disponible.

Bah si ce sont les clignotements qu'il te reproche pas besoin d'être devin pour prédire ce qu'il risque de te dire nan?

Lien direct stp ton site met 3 heures à s'afficher chez moi et en plus je trouve jamais ce que je cherchait dessus.

1. Le clignotement (à part dans le premier niveau de Mario 3) ne me gêne pas A MOI, donc je pense que je ne serai pas seul dans ce cas
2. Il y aura le choix (mode GrayOn ou bien le mien)
3. Il faut voir la qualité dans un VRAI projet avant de parler. Mario 3 n'en est pas un.

Moi j'avoue que j'ai une 92II donc hw1, donc je n'aurais jamais la chance de tester tes fabuleux jeux.
c'est quoi mario 3 alors ?

Bof... un projet que j'ai arrêté. Je voulais que ce soit une surprise. Cependant je vais le garder, car il y a pas mal d'éléments positifs pour le moteur du jeu (mon meilleur moteur étant pour l'instant celui de knight kid qui va sortir bientôt. Cette fois je ne prends pas de risque à l'annoncer puisqu'il est déjà terminé. Reste à faire... je ne sais pas... faudra que je voie! Il y a même déjà le générique, donc... ah oui! Un petit effet de transition pour le menu titre -> sauvegardes, le compatibiliser avec les 92+ et c'est tout!). Pour mario3, j'en parle dans le forum Moteur 2D (rubrique software, donc là où tu te trouves!)

Moi j'avoue que j'ai une 92II donc hw1, donc je n'aurais jamais la chance de tester tes fabuleux jeux.

Je rappelle une fois de plus que:
La routine de gris n'apporte une amélioration que sur une HW2 mais elle fonctionne complètement sur VTI et sur HW1. De plus, seul le mode anti-clignotement n'est pas accessible à une TI-92+. Sinon une 92+ HW2 ou une V200 auront aussi un nivelage meilleur.
Compris, donc il n'y a aucun problème et tu pourras jouer à mes (fabuleux) jeux même sur ta HW1!

He bah t'as des yeux bizzares, parceque chez moi c pas jouable y'a qu'à demander l'avis de ceux qui ont testé mario 3.

Je te répète que les niveaux de gris ne sont pas faits pour être testés avec Mario 3 mais avec le test qui se trouve sur mon site. Sinon pour les yeux bizarres t'as un peu raison mais je ne vais pas m'étendre sur le sujet.

1- On parle bien des niveau de gris nan? pour se rendre compte il faut tester sur un écran de vraie TI, sinon le rendu n'est absolument pas le même, quel que soit le hw. Donc tester tes nvg sur vti ne m'avancerait à rien.
2- J'ai dis 92II, pas 92+. Je n'ai pas été vérifier mais ça m'étonnerait que je puisse y faire tourner tes jeux...

Ximoon
: 2- J'ai dis 92II, pas 92+. Je n'ai pas été vérifier mais ça m'étonnerait que je puisse y faire tourner tes jeux...

Bah, TIGCC 0.95 rulez. D'ailleurs, je viens d'implémenter les tables de relogement compressées (format Fargo 0.2.1) dans le linker en développement. Donc plus besoin de module de compatibilité 0.2.0.

Kevin> Oui, mais ça m'étonnerait qu'il ait mis la main sur le linker
Sinon pour les tables de relogement compressé,

Sinon pour les tables de relogement compressé,

C'est vraiment

ca fait quoi ?

Ça réduit la taille des tables de relogements.

Et c'est quoi une table de relogement!

http://www.ticalc.org/archives/mail/assembly-92/1997_August/msg00052.html

Some machinecode instructions adress memory absolutely - like jumps
to a specific location.. If a fargo program is loaded to an adress,
say $12000 - and makes a jump to another position in the program at,
say $12100, it will only work as long as that program is not moved
to another location in memory. And since The TI92 OS does this to
its variables regurlarly, the Fargo core MUST recalculate these
adresses .. so if the TI92 OS moves our program to $11880, Fargo must change the jump instruction so it jumps to $11980 instead.

C'est toujours à peu près valable maintenant, sauf que AMS reloge les programmes _nostub lui-même s'ils utilisent le format de relogement AMS. L'utilisation de formats de relogement personnalisés (format style kernel, format compressé etc.) est possible en _nostub, mais à ce moment, le programme doit se reloger lui-même. Le linker de TIGCC 0.95 permettra d'utiliser le format standard ou les formats personnalisés au choix.

Par contre en temps d'execution ça donne quoi?

C'est relogé au lancement (et avec un format non-redondant, dérelogé à la sortie; le format natif AMS est un format redondant qui n'a pas besoin de dérelogement, ce qui a le désavantage de consommer 2 fois plus de place par relogement). Le temps pris est minime (et il ne faut pas oublier qu'on évite de consommer le temps de relogement qui sinon serait pris par EX_patch, qui reçoit une table de relogement vide, comme en mode kernel). Pendant l'exécution du programme lui-même, il n'y a aucune différence.

Et encore une chose, si je veux executer un prog dans un autre prog, cela fonctionnera parfaitement?

Oui. Ça fonctionne comme en mode kernel, sauf que le programme se reloge lui-même plutôt que de faire recours à un TSR externe (le kernel).
Et ça vaut le coup: le code de relogement prend très peu de place, donc on économise de la place sur les gros programmes par rapport au format de relogements de AMS.