[Cobain]

punaise, le code qui s'occupe de ça est minimaliste au possible 
excellent

Ouais, c'est le but Si tu as une idée pour le réduire encore, tu me fais signe, ça m'intéresse

moi je claque des doigts

c'est pas le curseur de la SDL?

[Mollusk]

moi je claque des doigts

c'est pas le curseur de la SDL?

Si Pour des questions de simplicité/portabilité la version PC utilise SDL pour le buffer principal et les touches (mais le plot se fait à la main pour des questions pratiques, j'aime pas la SDL ). Sur PocketPC on fait tout à la main avec du 100% WinAPI derrière, par contre.

Je sais pas si c'est intéressant, mais une fonction genre split qui retournerait un tableau d'objets à partir d'un PSD ça pourrait être pas mal. Remarque faudrait bien différencier les BGs des sprites  Quoiqu'avec un poil de polymorphisme 

J'avoue que là j'ai pas tout compris sur ce que tu veux
1. Quid du tableau ?
2. Différencier Bg et Sprite ? En fait dans tous les cas ce sont des images
3. Polymorphisme ? Quel rapport ?

[Campanile]

Ah oui pareil c'est pas intéressant, ça m'est venu sur le moment 

En gros l'idée c'est d'au lieu de créer les sprites dans une boucle à partir des layers, ils sont créés par un split qui retourne un tableau avec les numéros de sprites, les tailles, le nombre de couleur, etc, etc.
C'est une économie de bout de chandelle, je te l'accorde

Le coup du polymorphisme c'est d'avoir une classe image, et 2 classes sprite et bg qui héritentde image, du coup tu peux avoir dans un tableau d'images des sprites et des bgs (avec surcharge des méthodes et appels de la "bonne" méthode en fonction du type d'objet).
Bien sur, dans la mesure ou tu gères déjà tout en temps qu'image, toute mon idée n'a plus acune utilité 

En gros, avec du pseudo code, juste pour montrer que je suis pas complètement malade :

Code

 (cpp):
objArray= PSD_split(PSD_file); // récupères dans le PSD l'image et les infos genre coordonnées et tout ça
for each obj in objArray
  obj.display(obj.x, obj.y, prio); // Appelle la méthode d'affichage d'un sprite ou d'un bg en fonction de l'objet
 

Voilà, c'est plus court en code, aprés, est-ce que ça peut exister ? Je n'en suis pas si sur 

[Mollusk]

Alors Pour le coup de l'héritage, c'est bien ce que je pensais Oui, ça aurait pu être sympa mais on est en full C (en tout cas pour l'instant), donc ça existe pas

Pour ce qui est du split, en fait là je récupère avec une boucle for, mais j'ai un gros tableau dans mon filesystem avec pour chaque IMAGE (et pas chaque fichier psd, chaque image/layer du psd) le point de référence, la taille, le nombre de couleurs, tout ça   Quand on utilise IMG_TRUC, ça va récupérer les données de l'image, mais ça va utiliser les autres données qu'on a en mémoire pour placer le tout. On peut faire un Img_GetWidth(IMG_TRUC) pour avoir la taille, par exemple. Là c'est un exemple de truc statique, donc effectivement une bête boucle for était plus appropriée

[Campanile]

Ok,  en fait t'as déjà un tableau d'image avec toutes les infos dans un coin caché 
Je suppose que le data_converter machin splitte les layers du PSD et te fournit tout le nécessaire ?
Mon idée était de faciliter la création sprites/bgs depuis ce tableau d'image, mais on risque d'y perdre en souplesse...
Bref, tu as déjà bien réfléchi le truc, pour qui je me prenais 

[Mollusk]

Je suppose que le data_converter machin splitte les layers du PSD et te fournit tout le nécessaire ?

Ouep Tu peux y accéder à ces données, mais en règle général tu ne fais que donner l'image, x, y, prio, et c'est la lib qui y accède en interne (taille, type d'image, hotspot) pour toi. Migal est une lib faite par des fénéants pour des fénéants.

[Campanile]

Migal est une lib faite par des fénéants pour des fénéants.

J'en suis 
Par contre une question bête, tu vas gèrer comment le multiplateforme DS par rapport aux 2 écrans ? 

[Mollusk]

Bonne question C'est une des choses qui fait que c'est pas implementé. Mon idée de base était de fournir 2 fonctions particulières, du coup :

Sys_SetScreen => tous les appels d'affichage qui suivent vont pour un écran donné
Spr_CreateDS => prendrait en plus un paramètre screen

Sys_SetScreen permettrait de rendre le code (en gros) compatible si t'as bien pensé le jeu à la base Spr_CreateDS, à faire une partie plus spécifique.

[Campanile]

Le coup du Sys_SetScreen c'est la seule solution que je pouvais imaginer, pareil je m'étais dit que t'avais trouvé une autre
Comme tu dis, avec un code un peu propre ça passe presque tout seul...

A la place de la fonction Spr_CreateDS, on pourrait avoir des paramètres optionnels dans une seule fonction ?  Je suppose que t'as déjà réfléchi au truc et que t'as déjà une liste de pour et de contre longue comme le bras 

Une autre question (désolé si je te saoule w00t ), au niveau des images, tu peux en faire n'importe quoi ? Je m'explique, à partir d'une de tes image IMG_TRUC, il est possible de créer un sprite, un bg ou une texture ? Si non, peux-tu nous donner un plan de charge pour l'implémentation d'une telle fonction ?

EDIT : c'est vraiment la loose de pas avoir accés à l'irc depuis le bureau 

[Mollusk]

Marrant, je lance dev-fr, je vois que tu as répondu, et je me dis "bizarre, j'ai pas reçu le mail d'avertissement !". Et là je vois l'heure et je reçois ce mail

Bref, pour le coup des paramètres optionnels, je crois qu'on ne peut pas en C pure :/ J'avais pensé sinon à faire genre Spr_CreateEx qui prendrait des flags (pour foutre les flips et tout à la volée) et qu'on pourrait donc utiliser pour les écrans sur DS. A voir

Concernant les images, sur PC/PPC on n'a pas de vraie limitation, donc oui, une image peut devenir ce que tu veux, de toute façon c'est la même routine d'affichage Je vais rajouter un support de tilemap, mais qui sera très différent de ce qu'on fait avec libnds/PAlib.
En fait, une tilemap ne sera pas comme on le fait souvent un couple tileset/map, mais juste une map avec une référence vers chaque image. Donc en gros, pour afficher les tiles, ça ira piocher dans la "bibliothèque"/banque d'images, sachant que pour DS il faudra forcément que ce soit en multiple de 8
L'avantage est que ça permettra de streamer les tiles quoi qu'on fasse, pendant le scroll, etc... On ne sera donc pas réellement limité à 1024 tiles par map, puisque de toute façon tu pourras faire genre Map_SetTile(x, y, IMG_DUCON), ça ira chercher un emplacement libre dans le tileset en mémoire pour copier cette dedans

Concernant les sprites, on aura une petite subtilité, par contre. Autant une texture sur DS on peut utiliser des images comme ça (en ajustant à la bonne taille), autant pour les sprites faut découper à la fois en petites images de la taille qui va bien (8x8, 16x32, etc...) et à la fois chacune de ces images doit être sous-découpée en tiles de 8x8. Ca serait trop lourd à gérer en temps réel sur DS je pense, donc on aura forcément à rajouter des flags dans dataconv.txt (le truc qui est l'équivalent de PAGfx.ini).
Ca sera probablement du style
PLATFORM=NDS, et ensuite des flags /spr et/ou /tile pour les lignes à foutre en 8x8. Mais quand on convertira pour une autre plateforme, il suffira de ne pas mettre le PLATFORM=NDS, et les flags seront ignorés.

Donc on pourra avoir des sprites de n'importe quelle taille, c'est le convertisseur qui sera chargé de découper ça en plein de blocs en interne

[Campanile]

Bref, pour le coup des paramètres optionnels, je crois qu'on ne peut pas en C pure :/ J'avais pensé sinon à faire genre Spr_CreateEx qui prendrait des flags (pour foutre les flips et tout à la volée) et qu'on pourrait donc utiliser pour les écrans sur DS. A voir

Effectivement, on peut pas faire de paramètres optionnels en C  En revanche on peut toujours se rabattre sur du va_list...

Concernant les images, sur PC/PPC on n'a pas de vraie limitation, donc oui, une image peut devenir ce que tu veux, de toute façon c'est la même routine d'affichage Azn Je vais rajouter un support de tilemap, mais qui sera très différent de ce qu'on fait avec libnds/PAlib.
En fait, une tilemap ne sera pas comme on le fait souvent un couple tileset/map, mais juste une map avec une référence vers chaque image. Donc en gros, pour afficher les tiles, ça ira piocher dans la "bibliothèque"/banque d'images, sachant que pour DS il faudra forcément que ce soit en multiple de 8
L'avantage est que ça permettra de streamer les tiles quoi qu'on fasse, pendant le scroll, etc... On ne sera donc pas réellement limité à 1024 tiles par map, puisque de toute façon tu pourras faire genre Map_SetTile(x, y, IMG_DUCON), ça ira chercher un emplacement libre dans le tileset en mémoire pour copier cette dedans

OK, et ça coute combien un un PPC ?  Blague à part je vois le système, c'est complètement rationnel...

Concernant les sprites, on aura une petite subtilité, par contre. Autant une texture sur DS on peut utiliser des images comme ça (en ajustant à la bonne taille), autant pour les sprites faut découper à la fois en petites images de la taille qui va bien (8x8, 16x32, etc...) et à la fois chacune de ces images doit être sous-découpée en tiles de 8x8. Ca serait trop lourd à gérer en temps réel sur DS je pense, donc on aura forcément à rajouter des flags dans dataconv.txt (le truc qui est l'équivalent de PAGfx.ini).
Ca sera probablement du style
PLATFORM=NDS, et ensuite des flags /spr et/ou /tile pour les lignes à foutre en 8x8. Mais quand on convertira pour une autre plateforme, il suffira de ne pas mettre le PLATFORM=NDS, et les flags seront ignorés.

Décidément tu as répose à tout w00t
Du coup tu aurais 2 types possibles pour les images sur DS contre 1 pour les autres... C'est dommage de pas trouver un truc transparent... Ca impose un choix de plateforme dans le code aussi....

Mince, je vais manger, je reprends plus tard, je trouve ça passionnant 

Bon appétit !

[Mollusk]

Du coup tu aurais 2 types possibles pour les images sur DS contre 1 pour les autres... C'est dommage de pas trouver un truc transparent... Ca impose un choix de plateforme dans le code aussi....

Non Le code ne change pas, c'est juste au moment de la conversion, dans le petit .txt, qui te précisera ça. Donc dans le code, ça sera toujours du IMG_BIDULE, quoi que tu fasses.

[Campanile]

Non Le code ne change pas, c'est juste au moment de la conversion, dans le petit .txt, qui te précisera ça. Donc dans le code, ça sera toujours du IMG_BIDULE, quoi que tu fasses.

Ah ouais, j'suis con... Juste dans le code l'image en question sera moins polyvalente à priori, sauf retraitement...

[Doud]

EDIT : c'est vraiment la loose de pas avoir accés à l'irc depuis le bureau 

Essaie Mibbit ? A moins que tu ais déjà testé...

[Campanile]

Merci Doud, mais ce site est classé en "Messagerie instantanée" par cette m**** de smartfilter 
ICi on est des malades de al sécurité... On a les mots de passe root de tout les serveurs, mais on a pas accés aux sites sur les jeux vidéo et messagerie instantanées