mais qu'est-ce que vous nous préparez?? - Page 4

>Ximoon:
>Kevin Kofler> pour porter un jeu, il n'y a pas que les sprites qui posent problème...
>même en réduisant les spritres à 24*25 comme tu le disait, on perd les avantages des sprites [32]*32 à l'affichage,

Je ne vois pas pourquoi on ne pourrait pas utiliser une routine 32×32 pour afficher un sprite 24×25.

>et pour peu qu'on ait fait une routine qui les affichent tous d'un coup à l'écran il faut tout réécrire pour ces nouveaux formats.

On remplace tous les 32 par CALCULATOR?32:24 ou CALCULATOR?32:25 et TIGCC s'occupe du reste. (Si on compile pour une seule calculatrice, ça sera calculé en temps de compilation.)

>Après, si ils sont compressés et que l'on gère directement la taille des archives il faut tout reconsidérer.

Non, on enregistre les sprites au format 32×32 en laissant les pixels de trop vides.

>Sans parler du mouvement du prerso qui est à refaire.

Là aussi, il suffit de remplacer les constantes par des CALCULATOR?x:y.

En fait il suffit simplement d'utiliser la routine de pen² avant l'affichage, pas besoin de se casser le c*l à tout corriger

>Kevin:

>Je ne vois pas pourquoi on ne pourrait pas utiliser une routine 32×32 pour afficher un sprite 24×25.

je n'ai pas dis celà, je trouve juste que ce serait dommage du point de vue optimisation.
Tu afficherais autant de sprites sur un écran plus petit.
Perso je préfère laisser les sprites comme ils sont et réduire la zone de jeu.

>[...]et TIGCC s'occupe du reste.

ben voyons, où avais-je la tête?
j'avais oublié que je suis la seule personne au monde à ne pas utiliser le fameux TIGCC.

>Là aussi, il suffit de remplacer les constantes par des CALCULATOR?x:y.

Qui a parlé de constantes?

Je continue à penser qu'un programme est développé pour une platte-forme spécifique: 92 ou 89. Si l'auteur a la bonne idée de faire les deux, tant mieux. Mais chercher à le porter façon Mc Giver avec une alumette et un trombone, je trouve ça courageux, mais quand au résultat, j'attend de voir.

Après chacun fait ce qu'il veut.

Adapter un jeu à la barbare avec une fonction de rezoom, ça ne coute rien.
=> C'est à essayer, je ne sais pas ce que ça va donner mais de toute façon faut tenter.

Hum

Je suis d'accord avec toi sur le principe, c sur que si l'auteur veut utiliser une méthode un peu artisannale de ce genre il peut.

Mais moi, ce qui me génait, c'était plutot la façon de le demander, voir même de le réclamer. Un auteur reste libre de sortir ses progs pour la plateforme qu'il estime nécessaire.

Ce n'est certainement pas "réclamer", par contre oui c'est une demande, et c'est plutot à prendre comme un compliment je pense...

C'est dommage qu'un jeu qui pourrait (parceque pour l'instant personne ne peut prédire) être bien soit réservé à un petit nombre de calc, alors que c'est plutot simple de l'adapter pour les 89, même si ça devient moche.

perso, si je fais un jeu bo sur le plan graphismes sur 92+, je me vois pas le laisser en moche sur 89 : soit il sera porté sur 89 à 100% (et si possible en compatibilité ON-calc !), soit il ne sera pas porté...

perso...
bah oui effectivement c assez perso comme résonnement... Il y en a qui aimeraient sans doute avoir le jeu moche pluttot que rien du tout...

Kevin Kofler : Mieux vaut faire au début d'une source calc = CALCULATOR; , et après utiliser la variable calc, on y gagnera beaucoup de place si il y a beaucoup de tests dans la source.
[edit]Edité par ExtendeD le 22-02-2002 à 10:55:08[/edit]

>Ximoon:
>>[...]et TIGCC s'occupe du reste.
>ben voyons, où avais-je la tête?
>j'avais oublié que je suis la seule personne au monde à ne pas utiliser le fameux TIGCC.

Avec A68k, tu fais:

 ifnd VERSION89
 lsl.w #4,d0
 endc
 ifd VERSION89
 mulu.w #24,d0
 endc

Ce n'est pas plus compliqué que ça.

>Extended: Kevin Kofler : Mieux vaut faire au début d'une source calc = CALCULATOR; , et après utiliser la variable calc, on y gagnera beaucoup de place si il y a beaucoup de tests dans la source.

Ça dépend. Si on compile pour un seul modèle à la fois (et quand on utilise des sprites redimensionnés à l'avance, c'est ce qu'on fait probablement), CALCULATOR est une constante et donc c'est plus optimisé d'utiliser CALCULATOR directement que de l'enregistrer en une variable. Si au contraire on compile pour plusieurs modèles à la fois (pour être compatible on-calc), alors oui, il vaut mieux utiliser une variable auxiliaire.

Kevin: oui merci je sais, seulement je ne savais pas que ce que tu avais mis correspondait à celà. Je m'attendait à un truc super magic, en fait non.

Pourquoi ne pas faire une routine de gray4 centré sur 89
je m'explique:
(sauf si je n'ai rien compris) pour faire du gray4 sur hw2, on recopie en permanence l'écran. j'imagine que celà peut être optimisé sur 89 en ne recopiant que l'écran utile (coin supérieur gauche par rapport à la 92/92+). Pourquoi ne pas recopier juste le centre de l'écran? Cela permettrait de jouer à quelques jeux non portés sans massacrer les graphiques.
Est-ce faisable?

Je ne sais pas si voir uniquement le centre est plus avantageux que voir uniquement la partie haut-gauche

Dans pas mal de jeux, par ex les rpg, les jeux de platte forme, etc... le centre est plus intéressant: les persos/équivalents sont centrés. Je propose juste...