><lib :: version 2.0 - Page 1

bon voilà, neurone a pas mal traviller pour la prochaine version de Xlib en ce qui conscerne X2D (sous entendu fonction dedroite triangle fonte etc..). Moi j'ai rien fait


Bon alors c'est maintenant ou jamais pour faire vos propositions:
A noter que les fonctions de transparence vont etre verifiées (il parait qu'elles sont buguées ).
XFree etc.. sera mieux implenter, mais une doc supplémentaire permettra au succidaire de ne pas l'utiliser
XError utilisera un pointeur de focniton comme l'a proposer Godzil.
reprogrammation totale de toutes les apps pc en C / C++, compatible nux et windows open source.
programme permettant de faire ses fichiers perso on pc.
Ajout d'une fonction permettant de gerer le halo en 2 temps ( c'ad creation du halo en ram => affichage maské), permettant ainsi de gagner de l'archive et de la vitesse ( mask > hallo).
peut etre gestion du swap buffering a la graphX

voilà les grandes lignes.
Je pose neanmoins 2 vetos:
pas de fonction 8x8 (lente et en plus prendra de la place pour rien)
pas de transparence gris (trop lente!).

voilà pour ma part, neuro fera ptetre parvenir ses nouveautés

ca serait possible une routine de sprites en 16*h ou alors 16*24 ? (sprite+small)

et ca sera en dll (mixte) ou en archive statique uniquement ?

*.a uniquement.

pour le 16*24 c'est en effet possible il faut juste que je reprenne toutes les fonctions

ca serait cool en effet
mais en fait, à y re-réfléchir, si je dois utiliser une fonction differente pour les 16*16 et le 16*24, ca ne m'arrangera pas des masses (autant faire un 16*16+un16*8 eventuellement :/ (mais ca aurait surement été plus rapide))

(mes sprites peuvent avoir des hauteurs variables (et les largeurs aussi, arg^beaucoup))

donc, ne te prend pas la tete pour moi ^^

non ce serra toujours la meme fonction.
Xlib utilise la meme fonction pour le XSmall le XSprite et ton format.

mouais, alors pkoi pas
ca peremettrai d'utiliser un tableau de pointeurs vers chacune des 3 fonctions en fct de la taille du sprite

Je pensais faire ca ùais tu vas peut-être pouvoir les faire
- fonction de recopie de buffer avec un SCR_RECT perso (ie: un cadre)
- la mm mais recopie directement sur le LCD
- pseudo fonction de sprite x8 (ca sert a rien, mais tout le monde gueulle là)

moi je suis contre la fonction 8x8 ! je la programmerais pas

Je la ferais pke tout le monde gueulle ..
pis tu utilises en interne les fonction de small mais faut qu'un sprite 8x8 puisse se rentrer en paramètre

oui, mais ca a la limite une fonction qui transforme en ram un 8² en small ok mais le reste no

JackosKing :
XFree etc.. sera mieux implenter, mais une doc supplémentaire permettra au succidaire de ne pas l'utiliser

Cool
(sachant qu'un des suicidaire obtient de bien meilleurs résultats sans utiliser tout ce bordel, c'est très bien que ça soit prévu now )

pas de fonction 8x8 (lente et en plus prendra de la place pour rien)

nEUrOO a tout comprit

pas de transparence gris (trop lente!).

Plus lente qu'un masque ? (seule autre alternative)

Bon, pour ce qui est de V2, ce qu'il y aura en plus et deja programmé:
- XFont (utilisation des fontes standardes de TiOS / avec ou sans préchargement suivant la rapidité que vous voulez)
- XDialog (bah c pour les dialogues...)

J'avais commencé a faire des algos pour les tracés de ligne etc. en assembleur mais ca m'a vite fait chié et je dois avoir qu'un tracé de ligne et ligne verticale qui doit bien marcher ...

Je pense faire XFile, mais je ne sais pas trop quoi mettre dedans:
- certaines fonctions pour lire directement des niveaux/sprites compressés ?

J'ai pensé a une fonction générant des sprites ayant subit une rotation, histoire d'avoir des rotation tres rapides...

Cool (sachant qu'un des suicidaire obtient de bien meilleurs résultats sans utiliser tout ce bordel, c'est très bien que ça soit prévu now )

Heu ca m'etonnerai
ton fonctionnement est obligé de prendre plus de place et au mieux aussi stable

Plus lente qu'un masque ? (seule autre alternative)

oui, ou alors presque pareil (j'ai pas fait le calcul des cycle mais bon ..

pour le 8x8 je suis 200% contre et pour le moment personne m'a donner un seul argument valable pour que je l'implante, sachent que le 8x8 est plus lent, et que en plus ca vas rajouter des fonctions assez consequentes..

ué mon fonctionnement prend plus de place c'est le seul problème, mais si je vire XLib ça sera reglé. Par contre moins stable surement pas, et au moins en cas de manque de RAM je peux couper certains trucs sans quitter le jeu à la barbare

Sinon je serais interessé par la différence de cycle entre masque et trans gray. Parcequ'avec X 1.5 je suis obligé d'utiliser des masque sur des sprites de Game Boy qui sont en noir / gris foncé / blanc, qui étaient affichés en transparence gris clair à l'origine.

bein si tu vires XLib t'as plus de fonctions
puis si t'as pas assez de ram, t'es bien obligé de couper le jeu

pour la diff de cycle je peux pas te dire, ca fait longtemps que j'ai plus touché aux routines;(

Non non, pas assez de ram pour loader une map par exemple -> J'affiche un message d'erreur mais pas besoin de quitter le jeu, une autre peut très bien fonctionner.

bein sous win quand t'as pas assez de ram ca plante c'est pas mieux

Win n'est pas forcément un exemple

jackos: le 8x8, on s'en fout qu'il y ait de avanatages ou non .. faut le faire. Tout le monde le veut, on le fait, ca prendra pas plus de place et ca doit pas être bien dur a faire ...

si ca prend de la place.; parce qu'il faut gerer toutes les possibilitées de clipping etc..

mé on s'en fou, c en archive ...
le gars fait ce qu'il veut et faut qu'on le fasse ...

faudrait aussi penser a faire un format PIC x8 et non pas x16 mm si c moins rapide ...

bon a la limite je suis ok pour tout reprogrammer les fonctions de transparence (gray..), mais la format x8 non

je le ferais alors

de tte qu'on le fasse ou non sachant qu'on utilise la GPL (ou la LGPL au fait ?) si ya un ptit malin qui veux mettre du 8x8 il le pourra

heu si je fait XGTL XGTD le programme va devnir assez gros, il faudrait alors reflechier a une solution mistub

Ils le veulent ...

On pourra penser a une version kernel

heu certaines personne utilise les ancienne fonte de X, ce serait cool de les repredre quand meme par compatibilité

faut mettre la compatibilité dans : compat.h

si godzil tu veux t'ocupé du format de la lib du loader etc c'est comme tu veux mais bon je pense que t'es meilleur que moi sur ce point la

c un non