Grib - Page 1

Voilà une première version de ma librairie de niveaux de gris.

C'est une librairie statique _nostub (en kernel il y a déjà genlib ) qui permet d'allouer les buffers soi-même (ou bien de demander à la lib de le faire elle-même, comme le GrayOn de TIGCCLIB), et on peut régler les temps d'exposition (par défaut c'est 1/3 - 2/3, comme TIGCCLIB). En outre l'utilisation de cette librairie semble prendre un poil moins de place que les fonctions de TIGCCLIB (environ 200 octets), et le code de l'interruption doit être un peu plus léger si mes souvenirs sont bons (mais ça fait vraiment longtemps que je n'ai pas regardé le code de TIGCCLIB).

Un screenshot pas très intéressant puisque la lib s'occupe seulement de gérer les niveaux de gris :


Et puis la librairie (on ne sait jamais, si jamais quelqu'un veut l'utiliser...) : grib.zip

[edit] : Je viens de regarder le code de TIGCCLIB et il est assez différent du mien (que j'ai repompé de graphlib en fait), donc je ne peux pas trop dire lequel est le plus léger. Je testerai sûrement ça un jour...
Et sinon, je voudrais rajouter qu'avec Grib on peut faire facilement du double buffering, cf les démos fournies avec la lib

Cool. En gros il n'y a que des avantages par rapport aux fonctions de niveaux de gris de tigcclib ?
Edit: je viens de réfléchir, et ça va m'économiser 2 FastCopyScreen par frame... Mais il faudrait que tu renommes "Gray4Planes", parceque c'est trompeur.

La lib n'exporte pas de variable pour la synchro, comme genlib ? (utile pour le double buffering ...)

question stupide, mais bon : quel est l'intéret par rapport a un fork de tigcclib ?

Ah, ça me fait plaisir de voir des réponses

./2> Le nom Gray4Planes est trompeur ? Parce qu'il y a un 4 devant planes alors qu'en réalité la structure ne contient que 2 planes ? C'est vrai Je ne m'en étais pas rendu compte en l'écrivant parce que dans ma tête, je lisais Gray4 Planes... J'ai toujours eu du mal avec les nommages ; et encore plus quand c'est en anglais.

./3> Merci pour la correction dans la doc. Non, je ne développerai pas de lib par-dessus ça. Cette lib s'occupe seulement des niveaux de gris. ExtGraph est très bien pour le reste.

./4> Non. Je n'y avais pas pensé. Il me semble que TIGCCLIB fait ça aussi (par contre pour genlib je ne vois pas trop). Si ça ne pose pas de problème avec mon système actuel je le ferai, mais en fait je ne vois pas trop ce que je pourrais exporter qui pourrait aider à synchroniser. Tu peux m'éclairer ?

./5> Je ne sais pas. Mais quel aurait été l'intérêt d'un fork ? Peut-être la recompilation de sources existantes avec une lib plus puissante ?
C'est vrai qu'il y a quelque temps j'avais l'intention de forker TIGCCLIB parce que Kevin ne voulait pas ajouter mes idées.
A la limite ça peut toujours se faire. En fait, j'avais commencé à regarder le fichier gray.s, mais j'ai toujours du mal à repartir d'une source existante, je préfère réécrire moi-même, donc j'ai écrit Grib. Cela dit, on peut très facilement réaliser un fork de TIGCCLIB avec ce que j'ai fait (mais bon, je préfèrerais attendre d'avoir corrigé les bugs s'ils y en a), car leurs API sont très proches.

Mais il n'est pas banni lui ?

même si les propos sont de lui, je crois qu'il s'agit d'un clone (underscore)

#7 > si si, c'est liquid là...

si le _vrai_ Kevin est banni...
quand à cet "usurpateur", je sens qu'il va pas tarder à le rejoindre...

[edit] Ban posé.

./4> Non. Je n'y avais pas pensé. Il me semble que TIGCCLIB fait ça aussi (par contre pour genlib je ne vois pas trop). Si ça ne pose pas de problème avec mon système actuel je le ferai, mais en fait je ne vois pas trop ce que je pourrais exporter qui pourrait aider à synchroniser. Tu peux m'éclairer ?

Genlib::timer et genlib::frame_timer qui s'incrémentent à chaque fois qu'un plane (ou que la totalité des planes) ont été recopiés par l'interruption. Ainsi, en faisant (par exemple) du polling sur ces variables ça permet de faire l'échange de buffers quand l'interruption a fini de recopier les buffers, et donc d'éviter des scintillements.

Autre question: c'est compatible hw1/hw2/hw3 ?

OK, en fait je pensais qu'il s'était créé un nouveau compte juste pour répondre...
D'ailleurs comment fonctionne le ban, puisque je suppose qu'il n'a pas une IP fixe ?

boah, une petite boutade...

(en plus les routines de 7/8 niveaux de gris de kk s'appellent Gray3P.)

(j'ai pas été tres clair la-dessus, mais je parlais pas forcément d'un fork complet de TIGCCLIB, juste la routine de gris ^^)

Sasume :
./5> Je ne sais pas. Mais quel aurait été l'intérêt d'un fork ?

Bah éviter d'avoir a tout refaire, de risquer d'introduire des bugs, d'avoir une API différente [et aussi des variables internes non documentées différentes... c'est incroyable le nb de programmes qui utilisent des __gray_machintruc__ ] donc des difficultés pour porter un programme existant... Mais bon si tu fais ca juste pour le fun c'est intéressant aussi de refaire un truc a partir de zéro et ca peut permettre de comparer les deux apres...

liquid :
boah, une petite boutade...

han le méchant il poste dans le topic sous un autre pseudo pour contourner son ban de yn, c'est contraire a la charte ca

c'est de TIGCC qu'il faisait allusion

edit : double cross

Sasume :
Voilà une première version de ma librairie de niveaux de gris.

C'est une librairie statique _nostub (en kernel il y a déjà genlib )

Statique ok, mais rien n'empecherait de l'utiliser en kernel non ?

./12> OK, effectivement ce n'est pas inutile et ça ne coûte pratiquement rien dans mon code... Je ferai sûrement ça plus tard.
En fait, pour l'instant je pensais simplement à inciter à avoir une boucle principale du même style que celle dans demo2.c, à savoir :
1. Calculer ce qu'il y a à calculer dans le jeu (gestion des personnages, des objets, etc...)
2. Les afficher sur un buffer "de dessin"
3. Echanger le buffer de dessin avec le buffer d'affichage (donc le buffer de dessin devient celui affiché)
4. Effectuer une attente qui permet d'avoir un fps constant

Je pense qu'avec ce genre de boucle, le dessin sur un buffer se fait bien après qu'il soit devenu "buffer de dessin", donc il aura eu le temps de n'être plus affiché par le controleur LCD HW1 donc ça ne créera pas de dessin parasite (par exemple, si juste après avoir échangé les buffers on dessine sur le nouveau buffer de dessin qui en fait est encore en train d'être affiché, on verra les changements à l'écran).

Mais en fait, c'est vrai que ça ne protège pas du tout l'échange de buffer de se produire alors que les buffers n'ont pas été affichés en entier, donc ça pourrait peut-être poser des petits problèmes graphiques. Je pense que j'implémenterai l'équivalent de genlib::frame_timer

Et sinon, oui c'est compatible HW1/HW2 (enfin, ce n'est pas le même handler pour HW1 et HW2, mais les programmes tournent sur tous les HW).

./16> OK. Bah comme je te l'ai dit, j'avais commencé, mais je trouvais ça assez désagréable de modifier de l'existant pour l'adapter à une nouvelle architecture pour pouvoir offrir une nouvelle API. J'ai préféré tout réécrire (même si je me suis basé sur le code de graphlib).

./19> Non, à part le bon sens peut-être, puisque genlib et graphlib sont déjà là.

Oui mais je parle de l'utiliser comme une lib static, on a pas forcement besoin de Genlib ou meme graphlib juste pour avoir des nvg. Bon ok au moins graphlib est tjrs installé avec un kernel, mais bon.

Je sais pas ou en est graphlib actuellement, mais je suis pas sur qu'elle soit tres recommandé, et genlib juste pour avoir du nvg je trouve ça un peu (tres) lourd

Mais bon ct une idée comme ça hein ^^

(d'ailleur faudra que je regarde ça pourrait m'interesser ton truc si ça marche mieux que celle de tigcclib ^^)

Bah pour l'instant apparemment ce n'est pas le cas (pour le double buffering au moins). Mais j'espère bien réussir à faire une lib intéressante.
Je trouve intéressant le fait qu'on puisse spécifier soi-même la fréquence d'exposition des planes (par exemple, toutes les libs actuellement font du 1/3 - 2/3 mais on peut choisir 2/5 - 3/5, qui donne des gris plus proches), mais en fait ça se met à clignoter assez facilement

En fait, pour la synchro, je ne sais pas trop comment faire pour HW1. Il faut attendre que le controleur LCD ait fini de recopier entièrement l'écran ?

les HW1 sont obsolètes.
voilà c'est réglé.

Hé ma 89 est une HW1 alors respet

itou ^^ (par contre ca me dérangerait pas de perdre 3ko de ram pour faire chier kevin )

lol

Mais ya un truc que je pige pas..

Ct pas sur les HW1 jsutement que l'allocation des plans colé etait interessant ?

euh, non, pas particulierement... le controleur LCD marche aussi bien avec les deux ^^

Bon, c'est bon la librairie exporte une variable grib_frame_counter, qui s'incrémente chaque fois qu'une frame complète été affichée. Par frame complète, j'entends que les planes ont été affichés selon un cycle complet
Le surcoût doit être d'une dizaine d'octets.