[Minishlink]

Et tu n'aurais pas un build récent ou même ancien que je puisse coder stp car je n'ai rien de ta MLlib pour l'instant ?

EDIT : en fait le principe de ta lib ne me va pas du tout ! Tout simplement car c'est la merde de chez merde d'afficher une bête map (comme dans PAlib quoi). je préfère une lib qui me permet en chargeant une seule image de l'afficher plusieurs fois à l'écran (sans la charger plusieurs fois en mémoire quoi) style SDL, µLibrary ou même grrlib.

Heu, tu parles sans savoir là
C'est exactement le schéma que tu viens de donner...
Le "clonage" de sprite sert juste à faire un alias du premier sprite, mais on ne recharge pas le sprite ! >_<

[Risike]

Oui mais c'est ingérable ! Je veux dessiner une grosse maps de 200x200 tiles je vis devoir gérer 40 000 sprites !!! Les afficher un par un dans une boucle de 40 000 "tours".

En gros si on veut faire un jeu de baston, un pong...etc c'est parfait mais dès qu'on veut faire des niveau dans un jeu c'est l'enfer.

A moins que tu me dise que tu as implémenté un truc plus sympa pour ça 

[Risike]

Le "clonage" de sprite sert juste à faire un alias du premier sprite, mais on ne recharge pas le sprite ! >_<

Tu devrai éviter d'appeler cette fonction "clone" alors, car par définition un clone en programmation est une copie en mémoire d'un objet. Ce qui te permet de modifier le clone sans modifier l'original.

[Pyroh]

Perso si j'ai bien compris et si ce que j'ai fait avec SDL sous PSP fonctionne aussi sur Wii alors tu as deux partie dans un sprite :

 - l'image en elle même qu'on appellera la texture elle est chargée une fois en mémoire et est accessible autant de fois qu'il ne l'est requis.
 - le cadre qui est un espace qui affiche une image. On appellera ca le sprite, géré en hardware sur DS notamment, il n'est pas duplicable. Il agit comme un pochoir en gros, on le pose à un endroit dans le framebuffer, on récupère les données de la texture et on les retranscrit au travers du pochoir pour le mettre dans le framebuffer.

A partir de ça tu comprends qu'un sprite n'est pas réellement duplicable dans la mesure ou c'est une fonction hard sur bien des machines (sur WII aucune idée). Tu peux en revanche n'avoir qu'une seule texture que tu feras afficher par des sprites.

En ce qui concerne les map de 200*200, par exemple, tu divise le tout en briques dans ces briques certaines seront identiques (si tu mappes pas comme un cochon) et donc prendront moins de place en mémoire. Ces briques seront donc autant de petites textures mais on n'utilisera pas de sprite pour tout ca. Pourquoi ? Tu l'as dit 40000 sprites c'est pas gérable. Alors au lieu de gérer plusieurs petits cadres ont va en gérer que un et copier peu à peu dans le frame buffer les infos de nos textures pour reconstituer la map.

Voilà en gros comment ca marche.

Pour ta méthode du :

Code:

monSprite = Charger("monsprite.png")

Boucle

   monSprite.dessiner(x, y)
   raffraichirEcran()

Fin

C'est pas vraiment viable quand t'en a plein. Tu rends le codage objet plus difficile et tu ne sais pas réellement quel sprite est lequel et tu devras updater tout le temps même si ca ne bouge pas c'est pas vraiment le top. La méthode image/cadre me parait beaucoup plus pratique et rapide à mettre en pratique.

[Mollusk]

Tu ne peux pas afficher 2 fois le même sprite.

Tu charge un sprite qui a des coordonnées précises ! Sur DS tu as 125 (?) sprites par écran et tu ne peux pas afficher 10 fois le sprite numéro 0 d'un écran. C'est une fois et c'est tout. Dans sa MLlib c'est pareil.

Non, c'est très différent

Avec PAlib tu fais par exemple (tu as le choix, ça c'est important) u16 mon_gfx = PA_CreateGfx(tonimage, etc...), et au final c'est ça que tu affiches. Tu peux avoir 15 sprites qui appellent cette unique image si tu veux

Je suis plus partisan du :

monSprite = Charger("monsprite.png")

Boucle

   monSprite.dessiner(x, y)
   raffraichirEcran()

Fin

Ca je suis d'accord, c'est sympa Mais pas toujours adapté à une plateforme donnée.

EDIT : résultat tu passe par des BG hardware dans PAlib ce qui gène a mort pour dessiner des maps. En gro je veux faire une map de tiles de 25x25 et de 200 sur 200 j'en chie comme un pape. Tandis qu'avec une SDL ou un µLibrary c'est plus facile.

Sauf que techniquement les BG hardware de PAlib sont... des bgs hardware... tandis qu'avec une SDL ou une µLibrary, non Tu peux aussi utiliser la 3D (comme µLibrary) pour faire des maps si tu veux (je le fais dans Little Soldiers, c'est bien pratique, avec des blocs de 24x24 qui zooment à volonté).

(Je ne dénigre pas PAlib au profit des autres ne t'inquiète pas, PAlib a beaucoup d'avantages sur elles mais pour ce qui est de la simplicité et de la lisibilité je préfère ça)

Pour ce qui est de l'efficacité par rapport aux ressources, il faut voir Parfois, il vaut mieux s'en tenir à du 24x24 pour des tiles que du chercher à tout prix à faire du 25x25, sachant que ça tiendra dans du 32x32 de toute façon.
Ensuite, en SDL je crois que t'es en pixel plot, on a vu mieux sur DS :s

Et pour µLibrary, qui est super (bravo Brunni ), il faut pas oublier que si tu veux de la 3D bi-écran tu divises ton framerate par 2 et tu perds la moitié de la vram, donc c'est pas tout rose non plus. Il n'y a pas, et il n'y aura jamais (!!) de solution "parfaite" sur DS, à partir du moment où tu dois t'en tenir à un hardware limité

Je veux dessiner une grosse maps de 200x200 tiles je vis devoir gérer 40 000 sprites !!! Les afficher un par un dans une boucle de 40 000 "tours".

Bah non, si tu fais ta boucle intelligemment tu fais une boucle que sur la partie de l'écran

En gros si on veut faire un jeu de baston, un pong...etc c'est parfait mais dès qu'on veut faire des niveau dans un jeu c'est l'enfer.

* Mollusk va regarder comment sont faites les maps de mario et sonic...

edit : oh, un pyroh

[Risike]

Sur DS ok vu que le hardware de la DS est fait comme ça. Si on veut des performance optimales c'est sur qu'il fait jouer avec ce système de sprite et BG hardware.

Mais ça nous limite a des tiles de 8x8 et des maps de je ne sais plus combien de max.

Maintenant sur Wii (qui est beaucoup plus puissante) je pense que l'on peut s'approcher d'une syntaxe SDL qui est selon moi la mieux adaptée aux jeux vidéos (c'est pas pour rien que c'est LA lib de référence dans le dev amateur de jeux vidéos, et que ces dérivés sont extrèmement appréciés (pygame, SDL PSP et sur d'autres machines...etc))

Si vous voulez un exemple de ce qui se fait sur console et que je trouve parfait niveau syntaxe il y a le LUAPlayer PSP.
Avec ça : aucune limitation a part la taille de la ram, tout le monde peut coder sans avoir beaucoup de notion de programmation.

[Risike]

Bon en tout cas j'attends la MLlib pour voir ce que je peux faire pour rendre mon lua le plus simple et ergonomique possible.

[Pyroh]

Blablabla...

* Mollusk va regarder comment sont faites les maps de mario et sonic...

edit : oh, un pyroh

Comment qui vient et qu'il nique toute mon explication de merde lui 
Mais les maps de sonic je veux bien savoir

[Minishlink]

Le "clonage" de sprite sert juste à faire un alias du premier sprite, mais on ne recharge pas le sprite ! >_<

Tu devrai éviter d'appeler cette fonction "clone" alors, car par définition un clone en programmation est une copie en mémoire d'un objet. Ce qui te permet de modifier le clone sans modifier l'original.

Certes.

Oui mais c'est ingérable ! Je veux dessiner une grosse maps de 200x200 tiles je vis devoir gérer 40 000 sprites !!! Les afficher un par un dans une boucle de 40 000 "tours".

En gros si on veut faire un jeu de baston, un pong...etc c'est parfait mais dès qu'on veut faire des niveau dans un jeu c'est l'enfer.

A moins que tu me dise que tu as implémenté un truc plus sympa pour ça 

J'ai pas compris le blem là
Une map ne peut être qu'un alignement d'images lors du cas d'une map avec tiles, sinon c'est une image toute faite...
Il n'y a aucun problème de charger une image de 1000*5000 dans la Wii :\
Mais si tu veux je pourrai ptet adapter un éditeur de map pour pouvoir importer les fichiers générés par cet éditeur !
Il faudrait que je lance un sondage un des ces 4 concernant lequel des éditeurs seraient le mieux


Edit: grillé de 5 messages ><

[Risike]

Je viens de tester un truc en LUA combiné avec des fonctions C 

En gros j'ai trouvé comment faire ce que je veux avec la MLlib.

En gros la syntaxe :

img = Image.new("monimage.png")

while true do

   screen.drawImage(img, 100, 100)
   screen.render()

end

L'astuce et que je code la classe Image en LUA !
Les méthodes de cette classe appellent des fonctions statiques qui sont les version lua de celles de la MLlib.

Bref me manque plus que la lib pour tester !

[Mollusk]

Sur DS ok vu que le hardware de la DS est fait comme ça. Si on veut des performance optimales c'est sur qu'il fait jouer avec ce système de sprite et BG hardware.

Mais ça nous limite a des tiles de 8x8 et des maps de je ne sais plus combien de max.

Ca te limite aux multiples de 8, pas que à 8x8 Si tu veux faire des tiles de 32x8, libre à toi
Quant à la taille, niveau hardware c'est 512x512, mais comme c'est plus grand que l'écran tu peux (et c'est automatique avec PAlib ou plein d'autres libs, genre Ham/Hel sur GBA, etc...) faire changer dynamiquement les tiles. Donc tu peux te faire une map de 4096x4096 (ou plus, pas de limite), et ça se charge de foutre les tiles qui vont bien pour toi

Maintenant sur Wii (qui est beaucoup plus puissante) je pense que l'on peut s'approcher d'une syntaxe SDL qui est selon moi la mieux adaptée aux jeux vidéos (c'est pas pour rien que c'est LA lib de référence dans le dev amateur de jeux vidéos, et que ces dérivés sont extrèmement appréciés (pygame, SDL PSP et sur d'autres machines...etc))

Ou alors ce qui est apprécié est justement son ubiquité   J'ai taté de la SDL, et je trouve que niveau productivité on fait mieux. Mais ça, ça viendra en temps et en heure.

Si vous voulez un exemple de ce qui se fait sur console et que je trouve parfait niveau syntaxe il y a le LUAPlayer PSP.
Avec ça : aucune limitation a part la taille de la ram, tout le monde peut coder sans avoir beaucoup de notion de programmation.

Le parfait exemple Bah oui, quand j'ai un gars qui explique que sur PSP on peut pas faire énormément avec du LUA parce que la limite de 32Mo est trop rapidement atteinte, je rigole doucement Quand je vois le nombre de jeux GBA/DS (commerciaux) qui sont bien plus petits que ça, pour une qualité supérieure (ok, pas tous par contre :s), avec un contenu plus vaste...

[Risike]

Quand on sait pas gérer sa mémoire...

Le gros problème du LUA PSP c'est que si tu fais un bon programme qui tourne à 60 ftps avec pleins d'objets a l'écran faut pas espérer mettre du son, il sera inaudible... Chose que je vais essayer de faire tourner parfaitement sur Wii.

Bon actuellement voilà ce que j'ai fait :

- Support de toutes les fonctions du luaplayer 5.1.3, ce qui inclue les simple print dans la console et le système de fichier (libfat)
- Gestions des erreurs de syntaxe a l'exécution d'un script avec message d'erreur et stacktrace.
- Gestion partielle de la Wiimote, nunchuk, manette classique, GH3 (pas encore la manette gamecube)

Donc pour l'instant aucun graphisme, j'attends de réussir à faire marcher la MLlib.

[Risike]

Si quelqu'un veut voir ce que ça donne mettez le boot.elf là ou il faut et tous les fichiers .lua a la racine de votre SD.

Ne touchez pas a global.lua et image.lua.

Ecrivez vos scripts dans test.lua.

controls.read() pour lire les touches
controls.held(code de la touche) pour tester si une touche est appuyée. (liste des codes a ne pas modifier dans global.lua)
print("blabla") pour écrire dans la console

[Cid2Mizard]

bon sa fonctionne j'ai le text en print, mais j'ai "lua can't open file because FAT couldn't initialize SD to the slot 7" et le retour à la chaine homebrew se passe bien 

[Risike]

j'ai deja eu ce message je ne sais pas ce que c'est. Ton code s'execute sans probleme non ? Je virerais ce message.