Probleme de place (et autre) - Page 2

Pfff... Dis-moi où j'ai dit qu'elle est plus simple que Xlib

Non graphx et Xlib on un fonctionnement assez similaire, sauf au niveau de la gestion des evenement de GX et la gestion de la ram de XLib...

Edit : Oops pas vu la 2e page :]

P.S : Thibaut ton post #26 visait à me corriger non ? Mais je faisais une comparaison Ext / Xlib et non pas Ext / GraphX

Thibaut
a écrit : ExtGraph n'est pas la plus simple à utiliser si on fait du double-buffering.

Si, le double-buffering intégré à TIGCCLIB est très simple à utiliser.

lol, Thibaut
g pas dit que ct DUR, pas que ct PLUS dur.
nuance

nEUrOne> n'ayant jamais utilisé GraphX, je n'argumenterai pas...
mais Xlib n'est pas diffificile d'emploi pr ki veut s'en servir
mais elle est d'approche moins simple que Extgraph, pr un débuttant

Je signale à ceux qui ne le sauraient pas (presque tous, en fait), que beaucoup de routines d'ExtGraph seront réécrites (en ASM, bien sûr) dans une des prochaines versions... De plus, il y aura deux versions de ces routines: une __attribute__((__stkparm__)), une __attribute__((__regparm__(n))), dans la même librairie.
Les gains de vitesses seront non négligeables pour certaines routines... Des tests m'ont donné 30% pour les Sprite32_XXX, 20% pour les Sprite8_XXX, 10% ou un peu moins moins pour les Sprite16_XXX; il y a même SpriteX8_MIRROR_H dont la vitesse a été plus que doublée.

Je remercie en particulier jackiechan, qui m'a envoyé une routine de dessin de ligne horizontale sensiblement plus rapide que celle d'ExtGraph (même que la v
version ASM que j'avais faite moi-même), et cela même si on transforme sa routine __attribute__((__regparm__(5))) en __attribute__((__stkparm__)).

XDanger
a écrit : De plus, il y aura deux versions de ces routines: une __attribute__((__stkparm__)), une __attribute__((__regparm__(n))), dans la même librairie.

Pourquoi ?

Je te passerais peut-être ma routine de tracé de ligne quelconque si tu veux, sinon elle restera à dormir chez moi...

ExtendeD
a écrit : Pourquoi ?

Compatibilité avec les versions préhistoriques de TIGCC, probablement.

Si vous pouviez faire aussi des versions en regparm(2,1) ce serait pas mal

Résigne-toi à devoir rajouter le support pour le vrai passage par registres, pas seulement d0-d2/a0-a1, à GTC.
Et pourquoi 2,1 et pas 3,2?

Et de toute façon, on va bientôt convertir les fonctions assembleur de TIGCCLIB en regparm(4), et tu ne pourras plus utiliser les mises à jour de TIGCCLIB tant que tu ne résous pas ce problème.

Parce que c'est souvent plus efficace.

Et je ne prévois pas de supporter le regparm complet dans GTC, puisque soit la qualité du code généré serait horrible, soit il faudrait une allocation de registres différente qui ralentirait significativement la compilation. Et comme le gain en qualité de code est vraiment minime...

Ben tant pis pour toi. Tu ne pourras pas utiliser les version récentes de TIGCCLIB sans convertir toutes les fonctions assembleur à la main à chaque fois qu'elles changent.

Euh...Desole de vous interompres, mais G un autre probleme
Voila, G reussi a mettre une animation dans la boucle principale (de deplacement du curseur) et voia, a cause de la boucle de ralentissement, le deplacement du curseur est ...comment dire...ralenti kwa, et si je baisse la valeur de la boucle, l'animation est invisible
que faire ???

Ce que tu peux faire, si j'ai bien compris, c'est attendre quelques frames avant de passer à l'image suivante dans l'anim de ton curseur.

C pas tout a fait ca, en fait sur un des lieux, il y a une animation de chat, et cette animation est dans la boucle où ce deplace le curseur,mais a cause de la boucle de ralentissement de l'animation du chat, le curseur est ralenti
voila le truc

Ne fais pas une boucle d'animation à l'intérieur de la boucle du curseur, mais intègre l'animation à la boucle du curseur. Donc au lieu d'avoir:

for (...) { // curseur
  // traîtement de la touche
  for (...) { // animation
    // image suivante
    for(...); // ralentissement
  }
}

tu auras:

for (...) { // curseur
  // traîtement de la touche
  // image suivante
}

ou, si c'est toujours trop rapide:

int counter=0;
for (...) { // curseur
  // traîtement de la touche
  counter++;
  if (counter==...) {
    counter=0;
    // image suivante
  }
}

> Je te passerais peut-être ma routine de tracé de ligne quelconque si tu veux, sinon elle restera à dormir chez moi...
Je veux bien. Elle aussi sera sensiblement meilleure que la routine actuelle. Bien entendu, jackiechan et toi serez dans les credits.
Par contre, il existe une routine de dessin de ligne verticale, et là, il n'est pas possible de faire beaucoup plus rapide.

>>ExtGraph n'est pas la plus simple à utiliser si on fait du double-buffering.
> Si, le double-buffering intégré à TIGCCLIB est très simple à utiliser.
En effet, le doublebuffering n'est pas dans ExtGraph mais dans TIGCCLIB. Thibaut, apprends ce que font les autres, avant de les critiquer lourdement et parfois pour rien...