Voir enfin la vie en beaux niveaux de gris... - Page 1

Peut-être le 50eme topic sur le sujet, si c'est le cas je suis désolé, je n'en ai pourtant pas vu d'autres...

Cette fois, voici la petite question :
Quand on programme sous TIGCC, on compile, ça démarre VTI, ça lance le prog, on l'essaye, il est en 4 ndg, il est beau, il est bien, on est content.

Mais après on l'essaye sur sa vraie Ti, et là on est déjà beaucoup moins content : Les gris sont bien moins beaux que sur VTI, en effet le gris foncé se distingue très mal du noir, et le gris clair est un poil trop clair. Apparement la fonction GrayAdjust est là pour remédier à ce problème, mais après une 20aine d'essais, impossible de trouver LE bon reglage. Pire encore, dès qu'un augmente ou qu'on baisse le contraste d'un degrée, ça change la façon dont le GrayAdjust réagit.

Y a-t-il un "reglage miracle", ou tout du moins une technique pour avoir des ndg acceptables sur real Ti, ou bien faut-il faire contre mauvaise fortune bon coeur et se contenter de ces 3 niveaux et demis ?

Ajuste le contraste.
Et ne touche pas à GrayAdjust(), ça ne sert pas à grand chose avec les routines de niveaux de gris récentes qui attendent la synchronisation.

Il n'existe donc aucune solution réellement efficace ?

je ne sais pas si c'est dans ma tête ou pas, mais j'ai l'impression que les niveaux de gris du dernier bomber de FlashZ sont particulièrement réussis, et largemebt plus beaux que sur la plupart des autre programmes...enfin c'est peut-être qu'une impression ou un effet, mais tu devrais quand même lui demander

Si, tu as raison.

Il a utilisé je ne sais plus quelle technique qui rend un affichage merveilleux. Tu as remarqué que l'écran ne bave presque pas quand il scroll ?

Les auteurs de TIGCC devraient étudier son astuce et l'impémenter dans gray.s

flashZ a cramé kelkes neurones sur son graphisme pour en arriver a ce nivo la il me senble, et il sme smelbe aussi ke sa methode est surtoo adptée a son jeu, enfin j'en sais rien

Pour l'affichage des sprite il utilise du preshifting. donc c'est tres tres rapide, mais tres tres tres tres gorumant en ram

Sinon pour les niveaux de gris... j'ai pas essayé son jeu

C'est quoi ça le "preshifting" ?

Si je décompose : pre + shift + ing <=> décalage précalculé ?

Tu peux expliquer ?

C'est simple..
tu calcule en ram tout tes decalages (lsr rol et compagine)
et apres tu les affiche qu'avec des and.l or.l eor.l et compagnie..

Inutile de dire que ca demande beaucoup de ram !

Par exemple, pour des sprites de 16x16, il faudrait stocker tous les décalages possibles sur 16 pixels, bref : 16* 65536 (nombres d'images possibles sur 16 pixels) mots, soit 2097152 octets

J'ai pas dû comprendre là

he a mon avis, tous les décalages possibles sur 16 pixels sont au nombre de 16 :-D

ca qui fait deja moins de palce

Pour un XGTW, XGTB XGN ca fait:
16*4*16*2=2048

ca ca serai pour un preshifting de ouf. (on affiche en *.l)

Maintenant tu peux le brider un peu:
16*4*16=1024
ca c'est un preshifting un peu moins bourin, mais plus lent (on affiche en *.w)

Mainteant si tu veux 100 sprites c'est juste...
Sauf avec la 2eme solution.

Mais tu pouras voir ce soir la rapidité d'une telle routine (ou alors essaye Genlib )

On stocke quoi dans cette table de 16*4*16*2 octets ?
Je ne vois pas.

Tu comprendras ce soir.. Xlib est open source..

Sinon on est pas obligé de l'affiché en .w pour la seconde solution, mais secret

Je ne regarderai pas Xlib.

TiMad >> c sur que FZ utilise ça ??

Oui.. enfin dans Fzbomber je sais plus quoi

>Tu as remarqué que l'écran ne bave presque pas quand il scroll ?

oui j'ai remarqué, son jeu est parfait graphiquement je trouve, les gris sont impeccables...ilm e semble aussi qu'il y a une histoire de syncronisation, et il s'était inspiré du bomberman de Blue_Z. (d'ailleru à l'origine il a fait FZbomber pour être au niveau de bigdyna)

Pr en revenir au debut moi ce qui me dérange c pas que les NdG ont pas une belle couleur c qu'ils clignotent ! Et que dans mes progs sous TIGCC !

sur vraie calc ça clignote pas tant que ça , ça se voit presque pas, c'est sur VTI que ça clignote à fond

Sur VTI : l'écran est nickel pour les grays et le scrol, mais ça clignote à fond

Sur vraie calc : ça clignote presque pas à l'oeil nue, mais les grays et les bavures d'écran sont horribles

Mais il y a pourtant des jeux qui apparaissent oncalc avec des beaux grays, d'ou mon topic

peut-être une question de synchronisation entre la mise à jour de l'écran et les grays
(ou la copie du Vscreen vers le LCD des grays)

je crois que sBibi m'avait parlé d'un truc à ce sujet, par rapport à un certain port qui change de valeur à chaque rafraichissement ou un truc dans ce genre

Pim 89: chez moi ca fait ps du tt ca : je dessine un grand rect en gris clair sur VTI ca clignote pas un pet et sur ma calc ca clignote a mort !

tu utilises une version récente de TIGCC ?

94 beta 18 ( et avant ct la 92 ou 93 je sais plus )

pourtant, les grays de la B14-18 sont censés être beau
(et le sont sur mon HW1...)

Ils sont beaux aussi sur ma TI-89 HW1 et sur ma TI-92+ HW2.
J'espère que tu utilises bien les routines de 4 niveaux de gris de TIGCCLIB et pas les routines de 7-8 niveaux de gris que j'ai sorties sur le forum de la TICT et qui clignotent vraiment!

Moi c les routines de TiMad pour gray/sprite/copie_LCD mais sur calc les grays se voient, mais pas tt que ça (gris clair trop clair et gris foncé trop proche du noir, comme avec TIGCC d'ailleurs d'après mes anciens progs).
Par contre l'écran bave, c'est chiant

Bob 64
a écrit : ...Les gris sont bien moins beaux que sur VTI, en effet le gris foncé se distingue très mal du noir, et le gris clair est un poil trop clair.

Oui, même problème que Pim... C'est surtout à cause du gris foncé que ça rend mal.

Les nvg sont -ils fait en 1/3-2/3? peut-être qu'en faisant du 2/5-3/5 le gris clair serait moins clair et le gris foncé moins foncé? (je sais ni si ce serait faisable, ni si ça marcherait: je propose juste).