Niveaux de gris à 3 plans (7 ou 8 niveaux de gris) pour TIGCC - Page 1

je vais tester mais si ça marche bien
(sur HW2)
#TOP##TOP##TOP#

Si tu lisait bien, il dit que sa rend pas térrible sur HW1 comme sur HW2, comme sa "personne peut se plaindre "

Bon courage Kevin !

Je signale quand-même que ça ne devrait pas être pire que les 7 niveaux de gris de PreOs (que je n'ai pas essayés personnellement) vu que l'algorithme est exactement le même (j'ai jeté un coup d'œil sur l'implémentation de PreOs).

Sauf bien sûr s'il y a un bogue dans ma routine.

LOL avec ca se sera vraiment le top.. car avec la gestion des transparences, ca ne prendra pas plus de place qu'un sprite maské!

hum, j'ai hâte de voir la qualité d'affichage d'un jeu en 7 grays

a quand les 5800 niveaux de gris avec 40plans

en 7 grays, c'est largement possible!!!

si Xlib le fait, je me convertis

bein ca sera toujours plus rapide que Extgraphlib en 4 grays.

Je pense effectivement que ça serait intéressant d'écrire des routines de sprites en 7 niveaux de gris qui permettraient d'utiliser comme couleur transparente un des 2 gris moyens qui sont en double de toute façon.

Bon demain je presenterai si j'ai le temps une routine

Au fait il ne serait pas possible que tu rende directement les routines compatible XLib en mettant tes 3 plans a la suite qqsoit le type de HW? parce que ca permet un gain non negligeable..

D'apres mes petits teste, la couleur blanche comme couleur de transparence serait la methode la plus rapide (cf methode Xlib) et permettrai de faire un shift pour les mask...
alors que le Medium Gray, ce serai plus lent...

Au fait ce n'est pas la peine de faire:
3*Plan+8.. tu gaspilles 2 octets pour rien

TiMad a écrit :
D'apres mes petits teste, la couleur blanche comme couleur de transparence serait la methode la plus rapide (cf methode Xlib) et permettrai de faire un shift pour les mask... alors que le Medium Gray, ce serai plus lent...

Certes, mais ça serait plus intéressant à mon avis. Ceci dit, je peux très bien faire mes propres routines.

Au fait il ne serait pas possible que tu rende directement les routines compatible XLib en mettant tes 3 plans a la suite qqsoit le type de HW? parce que ca permet un gain non negligeable..

Non, parce que ça gaspille 3840 octets sur HW1 et puis parce que ma routine est une adaptation de celle de Thomas, et je n'ai pas envie de changer ce qui n'a pas absolument besoin d'être changé. Plus je change moi-même, plus de travail ça me fera quand Thomas mettra à jour sa routine et que je veux faire les mêmes mises à jour dans la mienne.

Au fait ce n'est pas la peine de faire:
3*Plan+8.. tu gaspilles 2 octets pour rien

Je n'ai qu'adapté la routine de Thomas, je ne l'ai pas optimisée.

Bon j'ai du faire un patch... ca marche nickel.
Demain les routines de XLib seront compatibles.

Je viens de sortir une version 8 gris de TICTEXPV (avec la permission de Thomas Nussbaumer).
Cf. http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=60.topic

Personnellement, les 7 niveaux de gris ne présentent aucun intérêt.
Une photo rend peut-être mieux qu'en 4 niveaux de gris, mais pour le reste, la qualité est même plus mauvaise, du moins sur TI92+ HW1 ! Sans compter :
- sur HW1 : ça clignote trop, ou alors faut un "bon" éclairage.
- sur HW2 : si ça clignote moins, ça prend énormément de CPU...
Et bien évidement : la place supplémentaire et tout le calcul lié au 3è plan.

Faudrait arrêter de toujours refaire le même rêve...
Je ne parle même pas de la tentative des 16 niveaux de gris. Je m'y suis lancé une fois (en adoptant une valeur du contraste pour chaque plan, selon l'idée de NSPIRIT), avec PpHd, et on a fait des suberbes effets, peut-être aussi dangereux que l'écran bleu d'ailleurs (ex : un magnifique ovale qui se déforme, le tout en 256 niveaux de gris...), mais rien à faire.

dsl, mais les 7 niveaux de gris, si on utilises de bonne routine de transparence, ca peut rester encore tres rapide...(j'ai fait qqs teste avec XLib..)

Le pb n'est pas la vitesse mais la qualite.

Tout depend quel type de jeu on fait...

oué mais 7gray c utile pour un jeux qui demande une bonne qualité graphique ... donc contradiction

tout depend si c'est a annimation fixe ou non...c'est sur que le scroll diff est baveux!

PpHd
a écrit : Le pb n'est pas la vitesse mais la qualite.

Si c'est aussi nul comme qualité, on se demande pourquoi tu en as fait toi pour PreOs.
Si c'est juste pour que le mode kernel ait quelque chose que le _nostub n'a pas, alors c'est raté maintenant. Maintenant, tu as les 8 niveaux de gris à rattraper.

Et inutile de passer à 4 plans, si tu le fais, je ferai de même.

Je l'ai fait parce que ca m'a pris 2s pour le faire a partir de mes routines en 4 gray. C tout.

Maintenant que le _nostub a les 7/8 grays, il lui manque encore la compatibilité (en décompression, car en compression il y a beaucoup mieux) avec ziplib.
(Je parie que les mauvaises langues vont encore dire qu'il manque encore beaucoup au _nostub, mais je pense qu'il manque beaucoup au mode kernel).
Nous avons déjà une compression de Huffman à peu près compatible (le header est peut-être un peu différent): c'est KOMP de FL.

Bon je la convertirai au format *.a, c'est pas bien difficile!