Posté le 30/06/2012 00:09
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 103 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 02/07/2012 00:02 | #
Moi aussi j'ai eu pas mal de problème, j'ai planché pendant 2h sur un "not enough memory" avant de changer littéralement de methode, mais bon t'inquiette pas tu va gagner, j'ai fait qu'un petit démineur
Citer : Posté le 02/07/2012 00:04 | #
N'empêche je suis fier de mon jeu. J'ai commencé hier, j'y ai passé toute la nuit et mon dimanche, et je pourrais presque l'inscrire dans la catégorie 3d du concours UCF.
Escape prison
Bloxorz
Free wheel
QR code
Nombre en or
RayCasting Engine
Mario Party
Zelda
et Planète Casio
Citer : Posté le 02/07/2012 00:13 | #
O_o j'avoue qu'il est bien, en 2 jour j'aurais pas pus faire ca
Perso j'était en weekend familliale, heureusement qu'on peut programmer OnCalc un peu ca aide quand on passe 4h a table
Citer : Posté le 02/07/2012 01:37 | #
En tout cas, bravo à vous deux !
Citer : Posté le 02/07/2012 09:49 | #
Le luafx sur g85 est assez limité en mémoire.
Le problème de programmer on-calc est que l'on est obligé de passer par le format .lua (et non .lc). Or pour lire le .lua, l’interpréteur a besoin de beaucoup de mémoire pour précompiler et aussi il ne supprimer pas les informations débug: pour les gros programmes on est obligé d'utiliser le format .lc sans les info debug.
Bravo pour votre participation.
Citer : Posté le 02/07/2012 13:02 | #
Je sais, au moment ou j'ai eu mon problème de mémoire, je programmais plus OnCalc(parce que edit limite la taille) donc j'ai tester en compilant, et j'ai eu le même problème (il métait juste un tout petit peu plus longtemps a arriver).
Citer : Posté le 02/07/2012 13:35 | #
Tu utilises deux tableaux de 188 cases: status et nbrBombe.
Les tableaux en lua prennent beaucoup de mémoire. Sur g100, j'avais pu estimer qu'une case d'un tableau prenait environ 20 octet. C'est surement plus sur g85 (les pointeurs prennent plus de place). or 2 * 20 *188 = 7520 octets, ça n'explique pas la problème de mémoire, mais libérer cette place peut résoudre le problème.
As tu bien enlevé les info débug lors de la précompilation ('-s')? ça peut enlever un tiers de la place prise par le programme lors de l'exécution.
Pour gagner de la place en n'utilisant pas de tableaux pour status et nbrBombe, utilises le système des fichiers: Les nombres contenus dans tes tableaux sont très petits, ils tiennent donc dans un char (1 octet ). Tu peut donc stocker ces tableaux dans des fichiers de 200 octets environ.
Citer : Posté le 02/07/2012 13:56 | #
Ah ouais j'avais pas regardé les fichier, mais ca prendra plus de temps a lire non ?
En fait le problème est survenu quand j'ai voulu faire la partie qui fait que lorsqu'on clique sur une case sans numéro ca découvre toutes les cases voisines, et j'avais fait une espèce de liste d'attente des cases a analyser (parce que ca part dans tous les sens) et bien evidement c'était dans un tableau.
Ca explique pourquoi ce problème de mémoire
Et non je n'avais enlever les info de débug. Merci pour cette info
Citer : Posté le 02/07/2012 15:54 | #
Oui, ce sera un peu plus lent d'utiliser les fichiers, et tu ne pourra pas utiliser la case 0: c'est indexé à partir de 1.
Sinon, pour résoudre ton problème de manière linéaire, on peut utiliser tes tableaux (ou des fichiers) et une fonction récursive (qui s'appelle elle même avec un nouvel argument tant que son rôle n'est pas fini).
Le lua n'est pas bien adapté à la programmation récursive, et il y aura une légère perte de mémoire à chaque appel (libérée après).
Voici en pseudo code ce que tu peux faire:
découvre_blanc ( case , dejatraité):
si dejatraité[case] == true alors ne rien faire
sinon
dejatraité[case] = true
si il n'y a pas de bombes autour,
dans status, indiquer que case est blanc
appeler decouvre_blanc sur la case à gauche
appeler decouvre_blanc sur la case à droite
... de même pour haut et bas...
sinon (il y a des bombes)
ne rien faire
Citer : Posté le 02/07/2012 16:08 | #
J'avais pas dutout pensé a faire comme ca pourtant c'est simple
Sinon les fichiers vu qu'ils sont dans la ram sont supprimés a la fin du programme, non ? Y'a moyen de sauvegarder quelquechose qui ne se supprime pas a l'extinction ?
Et j'ai pas vu de fonction qui m'aurait permis de chronomettrer le temps que met l'utilisateur a resoudre le démineur, on peut pas le faire ?
Citer : Posté le 02/07/2012 16:20 | #
Les fichiers ne sont pas supprimés à la fin si il n'y a pas de reset.
On ne peut pas chronometrer le temps, mais tu peut quand même avoir une variable qui s'incrémente petit à petit, mais tu ne pourras pas en déduire le temps (pas même vitesse d'exécution sur g100 et g85 et g85 avec overclocking)
Edit: Je ne sais pas si la méthode récursive ne risque pas de causer des 'not enough memory'. Le Lua n'étant pas adapté au récursif, chaque appel prend une place non négligeable dans la mémoire. Pour s'en rendre compte, j'ai utilisé le programme suivant:
local function rec (i)
i=i+1
print (i,"\n\r")
rec(i)
end
rec(0)
Le programme n'avait plus de mémoire à partir de 390 appels sur l'émulateur g85 et à partir de 510 sur g100
Les programmeurs du Lua ont connaissance de cette faiblesse et ils ont programmé un remède qui ne marche totalement que pour la récurrence simple (ce qui n'est pas ton cas puisque tu as une récurrence quadruple): si l'on met return fonction() alors fonction réutilise la mémoire de la fonction appelante, c'est à dire que le code suivant ne s'arrète jamais:
local function rec (i)
i=i+1
print (i,"\n\r")
return rec(i)
end
rec(0)