Release de Flash CPE 2003 - Page 5

TiMad
a écrit : Vertuos: Dsl si Xlib ne correspond pas a tes besoins, mais elle est loin d'etre grosse (faut pas abuser quans meme!).

void _main(void)
{
XOn();
XOff();
}
-> Plus de 3ko. Qui abuse ?

Et pour ce qui est du nombre de fonction a appeler, il faut pas dire n'importe quoi.. a part XOn et XGPlanc et XNewPlan, le reste reste un jeu d'enfant.. et d'ailleur meme avec Extgraphlib, il faudra allouer tes plan, activer tes niveaux de gris etc... qui est beaucoup plus long qu'avec Xlib!

T'as pas comprit. Je veux faire ça MOI MEME ! Parceque par exemple c'est magnifique XOn qui redirige les AUTO_INT et tout le bordel, sauf que moi j'en ai besoin donc je dois les sauver pour les restaurer après le XOn(). Ah oui en effet c'est simple. On ne doit pas avoir la même notion de simplicité.

TiMad
a écrit : NB: tu te plaignais de GX car tu la trouvais pas assez rapide, mais bon perso je suis 80% sur que extgraphlib sera pas plus rapide ( et je ne me base pas sur des benchs a la ***)

GX avait le même systeme de plans "bien à elle", mais Thibaut a mit une fonction genre void *GetActivePlane(void) ce qui évite de passer systematiquement les plans en parametre.

TiMad
a écrit : NB: tu te plaignais de GX car tu la trouvais pas assez rapide, mais bon perso je suis 80% sur que extgraphlib sera pas plus rapide ( et je ne me base pas sur des benchs a la ***)

J'avoue que je ne suis pas sûr qu'ExtGraph soit au niveau de GraphX, vu que je me suis rendu compte à quel point on pouvait l'accélérer...

bon version XLite sera bientot en dl..
apres c'est une question de gout..

TiMad a écrit :
MDR. Kevin, t'as deja vu un jeu sans synchro... ton ignorance me fera de plus en plus rire!

Arrête de me traîter d'ignorant! On peut très bien faire un jeu qui ne se synchronise sur aucune interruption.

ExtendeD a écrit :
La conversion a68k>GNU, je comprends pas vraiment l'interêt...
TIGCC supporte parfaitement a68k, et les fonctionnalités du GNU Asm ne sont pas utilisées, non ? Des % partout c'est pas vraiment marrant à lire.

Toutes les routines de TIGCCLIB sont en assembleur GNU, et toute contribution au format A68k sera convertie pour des raisons d'uniformité. (C'est ce que Sebastian m'a dit quand je lui ai envoyé mes routines d'arithmétique long long en assembleur A68k. Il les a converties. Et maintenant, je ne code mes routines plus qu'en assembleur GNU.) Donc il vaut mieux que jackiechan fasse ce travail tout de suite.

Et il y a un argument technique en faveur de l'assembleur GNU: le format objet AmigaOS utilisé par A68k oblige toute section à faire une taille multiple de 4, donc il y a un nop parasite à la fin une fois sur 2. Pour GNU as, la taille doit être multiple de 2 seulement. Et d'ailleurs, quand j'aurai trouvé où cet alignement est mis, je vais le désactiver, le nouveau linker de TIGCC n'ayant aucun problème avec les sections de taille impaire (il sait lui-même qu'il faut aligner correctement la section d'après s'il y en a une).

Arrête de me traîter d'ignorant! On peut très bien faire un jeu qui ne se synchronise sur aucune interruption.
dans ce cas la c'est de la programmation tres sale, en core avec X GEn ca passe car les routines depende moins de %x, mais avec votre lib c'est du sucide.. sauf pour des petit jeu..
et les truc du genre: for(int i=0;i<2000;i++); c'est du newb'isme rageant!

La synchro directement sur une interruption avec son propre handler d'interruption n'est pas exactement nécessaire. Les routines de gray de TIGCC permettent de le faire sans se synchroniser directement sur une interruption.

TiMad
a écrit : dans ce cas la c'est de la programmation tres sale, en core avec X GEn ca passe car les routines depende moins de %x, mais avec votre lib c'est du sucide.. sauf pour des petit jeu..

Je ne suis pas d'accord, mais bon, personne d'entre-nous n'a des preuves.

et les truc du genre: for(int i=0;i<2000;i++); c'est du newb'isme rageant!

Certes, mais la solution correcte est d'augmenter le nombre de frames calculés jusqu'à ce que la vitesse convienne, pas d'attendre une interruption. Qu'on attende une interruption ou qu'on fasse une boucle d'attente, dans les 2 cas, on jette des cycles par la fenêtre.

Oui mais si tu augmentes le nombre de frames calculées et que justement chaque frame prend un temps de calul différent tu désynchrinise ton jeu.

surtout qu'il est bien connue que toutes les calc tourne a la meme frequence...
pss le nb

Vu que les frames mettent à peu près le même temps (même si pas exactement) à être affichés, ce n'est pas grave.

NON justement!

Selon le %x, il peut y avoir d'énormes variations dans la vtesse d'affichage!
Ca peut varier du simple au double, facilement!
Bon après il y a moyen d'optimiser les routines pour y remédier, mais les différences restent non négligeables!

TiMad a écrit :
surtout qu'il est bien connue que toutes les calc tourne a la meme frequence... pss le nb

Il y a pas mal de jeux qui tournent à une vitesse différente sur HW1 ou sur HW2, et cela dans les 2 sens: certains sont plus lents sur HW2 parce qu'ils utilisent les interruptions, d'autres sont plus rapides sur HW2 parce qu'ils dépendent de la vitesse du processeur directement. Je ne vois pas vraiment où est le problème (à moins que ce ne soit un jeu en "réseau").

Ximoon a écrit :
NON justement!

Selon le %x, il peut y avoir d'énormes variations dans la vtesse d'affichage!
Ca peut varier du simple au double, facilement! Bon après il y a moyen d'optimiser les routines pour y remédier, mais les différences restent non négligeables!

Ben, vu que la coordonnée x va changer assez rapidement (ou alors on est à l'arrêt, mais dans ce cas peu importe la vitesse ), les vitesses différentes devraient quand-même se compenser plus ou moins sans que ça se voie trop.

n'importe quoi.. si t'as un jeu genre zelda.. le gas il peux scroller en montant a ton x defavorable.. faut arreter les conneries!

Bah ça dépend comment c'est géré.
Pour un jeu à défilement horizontal il y a en effet un effet (excusez le style...) de moyenne, mais ça n'est pas le cas général!
La synchronisation sur un int est vraiment utile, même si effectivement ça perd du temps. Au programmeur de gérer ça au mieux.

TiMad
a écrit : n'importe quoi.. si t'as un jeu genre zelda.. le gas il peux scroller en montant a ton x defavorable.. faut arreter les conneries!

Il est vrai que ça dépend un peu du jeu. J'étais plutôt dans la logique d'un jeu 2D x-z de style Mario, Sonic, etc., pas d'un jeu 2D x-y de style Zelda.

pourtant les jeux comme zelda serait plus du niveau de Ext que les sonic etc!