Une bibliothèque graphique puissante et pourtant simple d'utilisation - Page 1

Je précise à TiMad et PpHd que je ne prétend pas avoir inventé quoi que ce soit (double buffering, format des sprites, etc...) je sais que vos libs le font déjà... j'espère que vous n'êtes pas fâché de cette modeste "concurrence"


Au menu (pour cette première version, la lib s'améliorera au cours du temps) :


Côté (très grande) vitesse :

- double buffering (pas besoin de recopier les plans vers le LIGHT_PLANE et le DARK_PLANE : l'affichage se fait par un simple échange de pointeurs) : ultra rapide

- fonctions d'affichage de sprites 8x8/16x16/32x32, avec les modes OR/remplacement/masqué, toutes sont "clippées"

- fonction d'affichage de chaînes de caractères, en mode blanc sur noir / noir sur blanc

- scrollings horizontal et vertical, à pas variable : vous pouver scroller de 1 à 32 pixels d'un coup (le temps de scroll n'est pas proportionnel au pas, la courbe f(shift)=temps (assez bizzaroïde) sera dans la doc)

- fonction d'"allumage" de pixels

- fonction de copie de buffers

- fonction d'effaçage de buffers

- fonction _rowread beaucoup plus rapide que celle de TIGCC

Le minimum pour faire un jeu quoi


Côté simplicité :

- vraie bibliothèque statique : s'utilise comme les autres bibliothèques de la TIGCClib : le compilateur s'occupe tout seul d'intégrer à votre programme les fonctions utilisées, et uniquement elles. Il suffit d'écrire #include "GraphX.h" au début de votre source pour pouvoir utiliser la bibliothèque

- identification des buffers par des handles (attention, rien à voir avec ceux du TIOS, question de vitesse)

- grâce à ce système d'identification, l'utilisateur n'a plus à se préocupper des changements d'adresses effectués par la bibliothèque lors de la suppression/création de buffers afin de maximiser la mémoire disponible (défragmentation).

- grâce à ce système d'identification, l'utilisateur n'a plus à se préocupper des changements d'adresses dus au double-buffering : il continue à référencer le buffer de travail sans se soucier qu'il ait changé d'adresse et de contenu




N'hésitez pas à poser des questions ou faire des remarques utiles DANS LE TOPIC Certains sont intéressés ?

Serais-ce trop demander que d'avoir un lien pour d/l cette bibliothèque graphique puissante et pourtant simple d'utilisation ?

Serait-ce trop te demander, que de lire le premier post du topic, au moins la première phrase ???

Je l'ai lue, moi je te parle plutot des dernièes phrases :

N'hésitez pas à poser des questions ou faire des remarques utiles Certains sont déjà intéressés ?

Peut-être interessé, oui, mais comment tu veux qu'on réponde sans pouvoir tester...

Ben si t'as pas de questions pour le moment tu n'en poses pas. Certains peuvent en avoir rien qu'en lisant les fonctionnalités

Merde j'ai oublié de préciser que les fonctions d'affichage de sprites sont clippées

-

Edit : post croisé, je répondais à Thibaut

Erf j'allais poser la question, mais à part ça rien ne me vient à l'esprit.

J'attendrais donc... Vers quelle heure peut-on esperer télécharger cette lib (qui, si elle tient ses promesses, s'avere plus qu'interessante ) ?

Orion : j'ai la flemme. Ceux qui voudront pourront en faire, à condition qu'ils publient leurs sources de test, histoire que les personnes concernées (PpHd, TiMad, Thibaut) puissent voir si les comparaisons sont effectuées en tenant compte des spécificités de chaque lib.

Bob 64 : j'sais pas. A vrai dire, je suis sur le point de la terminer (encore 10 mn de codage), et j'ai encore rien testé si jamais je trouve des bugs durs à comprendre ou à corriger, .... Mais j'ai confiance, je me suis basé sur les sources de la bibliothèque Azur qui fonctionnait sans problème

Je te signale au cas que tu ne serais pas au courant que le double-buffering est déjà implémenté dans TIGCCLIB.

on peux avoir des chiffres genre ton pxl, histoire de pouvoir comparé ...

(20:01) Thibaut - Posté : 16 Juillet 2002
> encore 10 mn de codage

Il est 22:30 snif bouhouhou

Thibaut >> utilises tu un système de "vscreen" ou "Gplan" comme avec Genlib ou Xlib ??? cad un buffer avec une "bordure" comparé à l'écran réel, pour pouvoir afficher en dehors de l'écran sans calculs lourds, et ensuite on ne recopie que la taille du vscreen sans bordures sur le LCD ???

pim89> je pense qu'il utilise ce type de systeme (VScreen, GPLan ) car il parle d'echange de pointeurs.

Pim89> Il dit que les routines de sprites sont clippées, donc je pense que c'est bon de ce côté-là !

Thibaud> Par contre là il est 2h18 et il y a toujours rien !

Il est même 9:19 et maintenant 10:22

-

Il y a au moins Orion de clairvoyant tout fonctionne à merveille sur HW2... mais pas sur HW1 (et donc sur VTI qui est reconnu comme une HW1) : j'ai complètement oublié d'aligner les adresses sur des multiples de 8

Kevin : vos routines de sprites ne sont pas clippées et sont lentes. Mes buffers ont un format spécial qui permet le clipping sans calcul lourd en temps. Et puis tient j'aurais dû rajouter ton nom dans la phrase en gris du premier post je m'attendais à des réflexions du genre...

Pim89 : oui c'est tout à fait ça.

nEUrOne : cf ma réponse à Orion au post #7





Pour les plus curieux, vous pouvez télécharger le .h : http://alineasofts.free.fr/extern/GraphX.h

Il manque les attributs définissant la convention d'appel dans les prototypes. Si tu utilises le passage par pile, mets quelque chose comme ça (tiré de extgraph.h):

//-----------------------------------------------------------------------------
// support for -mregparm switch in TIGCC 0.94
//-----------------------------------------------------------------------------
#include <version.h>

#if (defined(__TIGCC__)&&(__TIGCC__>0))||(defined(__TIGCC_MINOR__)&&(__TIGCC_MINOR__>93))
#define EXTGRAPH_FUNC_ATTRIBUTES  __attribute__((__stkparm__))
#else
#define EXTGRAPH_FUNC_ATTRIBUTES
#endif

et mets EXTGRAPH_FUNC_ATTRIBUTES (ou plutôt GRAPHX_FUNC_ATTRIBUTES ) après chaque prototype.

Tu peux m'expliquer à quoi ça sert ET comment on s'en sert stp ?

Ça sert à pouvoir compiler le programme avec -mregparm sans recompiler GraphX.

Et on s'en sert comme ça:
void fonction(int arg1, int arg2, char *arg3) GRAPHX_FUNC_ATTRIBUTES;

ché pas si on a déjà posé la question mais elle est en Open Source la lib?

Tout est open-source depuis que ttdasm est sorti.

ahahahah ben ça c'est une bonne initiative !!!

lol t'as pas compris, Kevin déconnait les LamerZ ayant un trop bas niveau mais souhaitant se la péter en disant "regardez j'ai codé mes propres fonctions" pourront se démerder pour obtenir le code des routines avec ttdasm.
Les niewbies ne souhaitant que regarder pour apprendre pourront faire de même, mais eux auront du mérite

Les sources ne servent pas qu'aux lamerz qui veulent se la pêter et aux newbies qui veulent apprendre. Elles servent aussi aux programmeurs qui voudraient adapter les routines graphiques à des écrans virtuels de taille différente par exemple. (C'est souvent fait avec les routines de ExtGraph, et Thomas Nussbaumer encourage même ces modifications.) Ou à des programmeurs qui pourraient optimiser quelque chose ou corriger un bogue dans une de tes routines et t'envoyer la correction pour la prochaine version. Ou à des experts comme moi qui sont tout simplement curieux de savoir comment c'est implémenté (mais bon, ttdasm, VTI et/ou DB92 suffisent aussi dans ce cas).

Kevin Kofler a écrit :
Ou à des experts comme moi ...

(même si c vrai)

-

t mal placé pr dire ça

Bob 64 a écrit :
t mal placé pr dire ça

Moi ?? yé comprend pas ton post là ?!

Fais l'innocent
Je suis sur qu'en peu de temps je retrouve au moins une dizaine de posts de toi qui ressemblent bcp à celui de Kevin