Citer : Posté le 31/01/2016 18:52 | #

---

Super !

Bonne chance pour générer de manière procédurale !

Je test ça

Une boucle for ?

Mais de rien je suis content que ça avance si bien (mario, tuyaux, je l'ai )


edit : "now compilig" ?

Sinon c'est bien fait et fluide de ce que j'ai pu voir
La compilation est longue mais ça va.


edit 2 : Je n'arrive pas à placer de blocs

---

Citer : Posté le 31/01/2016 20:15 | # | Fichier joint

---

C'est bon ! Première version jouable \o/ Y'a juste besoin d'avoir le programme PLATFORM et INIT~W1 pour que ça fonctionne ! (Inutile de tout initialiser manuellement, il suffit de passer par le programme PLATFORM dont sa première tâche sera de loader le niveau.)
Par contre, je ne sais toujours pas comment je vais simuler un bloc qui se casse, ça c'est moyen vu que les textures sont déjà calculées... Bref, je pense que j'ai ma dose pour aujourd'hui, je vais build le monde 1 dans la semaine et voir ce que ça donne

Ajouté le 31/01/2016 à 20:25 :
Alors, en tant que bon triso, j'avais pas vu la deuxième page, donc je vais t'expliquer pourquoi j'ai rajouté du return de partout dans Bin2Str. L'idée, c'est de gagner un max de temps lors de la compilation, or il s'avère que cette dernière est environ 20% plus rapide lorsque je lui demande immédiatement de revenir. En fait, je pars du principe que dès lors qu'il a trouvé ce qu'il devait faire, il n'a pas besoin de lire la suite et de perdre du temps : donc retour au prog de base (du coup adieu la flèche inutile c'est pour ça)

La boucle for, j'y ai pensé, mais du coup faut repenser entièrement la manière de générer la matrice, il est là le vrai problème mais bien tenté xD

Alors, pour ce qu'il est de placer des blocs, je vais t'expliquer la manière foireuse dont ça fonctionne. Dans la caméra normale, tu peux techniquement placer des blocs, mais tu n'en vois pas la répercussion immédiatement (il faut compiler avec F<->D sur la ligne que tu veux actualiser). C'est pour cela que j'ai ajouté ce mode au fonctionnement dynamique en appuyant sur ALPHA : la caméra est fixe, mais tu vois ce que tu fais. Si tu veux être sûr que tu es en train de placer le bon bloc dans ce mode, il faut appuyer sur SHIFT (c'est une petite flemmardise de ma part que je ne vais pas tarder à corriger) et là, tu vois en haut à droite le bloc que tu t'apprêtes à poser. Ensuite, EXE pour placer un bloc ou le retirer si y'en a déjà un.

---

Citer : Posté le 31/01/2016 22:00 | #

---

Salut !

Tu as l'air de bien avancer et de savoir où tu vas, ça fait plaisir à voir !

Au sujet de la compilation, tu as bien sûr raison, Arkenstone est simpliste de ce côté là, c'était plutôt l'idée en elle-même que je pensais que tu pouvais exploiter.

Tu m'excuseras de ne pas avoir regardé en détail tes programmes mais disons que tes maps comportent 8 éléments différents (7 "briques" + l'élément vide). Tu peux donc considérer chaque "case" de ta map comme étant en base 8. Ensuite tu peux convertir en base 2 (sur 4 bits donc). Là où ça devient intéressant c'est que tu peux "agglomérer" les cases deux par deux pour obtenir des octets (2 fois 4 bits = 8 bits = 1 octet).

Et c'est là qu'intervient l'astuce : tu peux créer un "dictionnaire" comportant 255 caractères différents (c'est important, tu peux les trouver dans le menu caractère spéciaux). Ainsi à un caractère donné correspondra un index unique, et inversement.

Du coup tu peux convertir l'octet binaire de tout à l'heure en base 10, pour obtenir un nombre décimal entre 0 et 255 et venir chercher le caractère d'index cet entier décimal dans ton catalogue.

Si tu m'as bien suivi : 2 cases = 1 seul caractère.

Puisque que tu peux mettre 255 caractères dans une Str, ça veut dire que tu peux faire des niveaux de 510 cases de long ! Et pour la hauteur il suffit de mettre autant de Str que tu le souhaites.

J'ai fait la démonstration pour des cases octales mais si tu fonctionnes sur une autre base c'est le même principe ! Il faut juste que ton programme soit capable de toujours agglomérer les cases en binaire puis de découper en octets, et bien sur de savoir faire l’inverse sans perdre d'info.

J'espère que c'est clair, sinon n'hésite pas à me faire signe.

---

Citer : Posté le 01/02/2016 13:18 | #

---

Ahah non ce n'est pas compliqué en fait, c'est juste que j'ai voulu aller trop vite sans écrire d'exemple. Ca ne touche en rien la façon dont la calculatrice encode les informations, ça n'utilise que des fonctions que tu maîtrises visiblement déjà.

Avant tout je vais repréciser le but de la manip' car ça ne semble pas être limpide. Le but ici est de "compresser" les niveaux en mémoire pour que ton programme pèse moins lourd et donc que tu puisses potentiellement mettre plus de maps. Il faut bien comprendre que l'on ne peut pas jouer en direct un niveau "compressé" car la calculatrice n'a pas assez de ressources pour le permettre. En revanche, au début d'un niveau ou d'un monde comportant plusieurs niveaux, on peut imaginer un temps de chargement qui va venir décompresser les maps.

Bien. Maintenant place à la technique.

Prenons le cas où tu as 15 blocs différents possibles, plus le bloc vide. C'est à dire que dans tes matrices actuelles tu as des valeurs comprises entre 0 et 15. Alors tu peux les convertir en binaire sur 4 bits. Par exemple la case 13 deviendra le mot binaire 1101. Jusqu'ici ça va ? Si tu transformes toutes tes cases de cette façon tu obtiendras une matrice remplie de mots binaires de 4 bits. Imaginons qu'à droite de la case comportant la valeur 13 nous avons une case de valeur 5. Le mot correspondant à cette case est 0101. Si je récapitule jusqu'à présent, [13][5] devient [1101][0101]. Ensuite vient l'agglomération : deux cases successives peuvent être agglomérées en un seul mot binaire sur 8 bits, soit 1 octet : ici 11010101. Tu me suis toujours ?

Si à présent on transforme cet octet en base 10, on obtient par définition un nombre décimal compris entre 0 et 255. Dans notre exemple on obtient 213. Si on reprend l'idée du dictionnaire comportant 256 caractères différents, ça veut dire que tu peux remplacer tes deux cases par le caractère unique d'index 213.

Tout ce que je viens de décrire est le processus de compression, c'est à dire qu'après ça tu peux écrire en dur dans tes programmes des chaines de caractères qui sont beaucoup plus compactes et légères que tes matrices. Au moment de jouer, il suffit de faire exactement le script inverse, qui va reconstruire à partir d'une série de caractères un matrice complète.

Est-ce que c'est plus clair ?

EDIT :

Au sujet du dictionnaire, je l'ai mis entre guillemet car ce n'en est pas vraiment un. En fait il s'agit juste de remplir une Str avec 256 caractères différents. En compression il faudra simplement utiliser la fonction qui permet d'extraire le caractère d'index i (cet index est connu, c'est le nombre décimal obtenu à la fin), et en décompression c'est l'inverse : on connait le caractère, et grâce à la fonction de recherche dans une Str on récupère l'index puis on le trifouille jusqu'à récupérer les valeurs des 2 cases.

EDIT 2 :

J'ai pensé à une autre technique qui pourrait te rapporter très gros en terme d'économie d'espace. J'avais fait un programme qui faisait rentrer 30 matrices en une, la seule contrainte étant que les valeurs des cases soient comprises entre 0 et 9. Bien sûr on peut adapter le petit algo pour qu'il fasse rentrer 15 matrices en une seul, avec des valeurs comportant 2 digits (entre 0 et 99).

En fait l'astuce est toute bête. Voici un exemple hyper simple pour lequel je fais rentrer 4 matrices de valeurs à 1 digit dans une seule.

matrice 1 :
1 7
3 4

matrice 2 :
2 5
6 3

matrice 3 :
7 9
5 6

matrice 4 :
9 7
1 2

matrice "optimisée" :
1279 7597
3652 4362

L'avantage c'est que ça prend exactement le même espace en mémoire, mais que ça comporte les informations de plusieurs matrices, et que les calculs à effectuer sont très simples et donc rapide en terme de temps d'execution.

Tu peux utiliser ça de deux façons :

T'en servir pour la dimension "verticale" de tes matrices. De cette façon tu n'auras plus une matrice de 7 par 155 mais de 1 par 155, tu divises par 7 quasiment le poids.

T'en servir pour compacter plusieurs niveaux dans une seule matrice. Moins tu as d'éléments différents sur ta map, plus tu vas pouvoir mettre de niveaux en une seule matrice (jusqu'à 30 disais-je, si tu n'as pas plus de 9 éléments différents, plus l'élément vide).

Combiner les deux possibilités précédentes...

---

Citer : Posté le 01/02/2016 13:34 | #

---

Un topic fort intéressant avec beaucoup d'informations très utiles et en plus, un très bon jeu en perspective, j'ai hâte de voir ça sortir parce que là, ça tient du niveau de Ne0' / Rémiweb

---

Citer : Posté le 01/02/2016 19:36 | #

---

Très intéressant ce que tu racontes Ne0tux.
Par contre attention, une matrice avec un complexe dedans double sa taille. Donc pas d'optimisation de mémoire à ce niveau là

Personnellement, je déconseille les matrices pour stocker des données. C'est lourd avec tous les crochets et les virgules. Ecrire une matrice en brut dans le code prend une place folle :
[[X,X,X...]...[X,X,X...]] les crochets et et les virgules prennent trop de place.
Pour une List c'est pas beaucoup mieux, il y a toujours ces virgules qui prennent de la place pour rien.
Ce que je conseille, c'est d'utiliser les Str pour stocker en dur les infos.

Je vais donner un exemple :
Imaginons que tu ais un monde comme cela :
Dans une Str tu pourras le stocker comme ça :
"400009"->Str 1
"100103"->Str 2
"101111"->Str 3
36 octets au lieu de 44 avec les matrices (C'est pas énorme comme différence, mais l'écart se creuse d'autant que le monde est grand !!)
A première vue, on ne peut stocker que des nombres en 0 et 9. Mais l'astuce consiste à utiliser les lettres alphabétiques.
Pour enregistrer un bloc d'id 12, on utilise la lettre "C".
En effet quand tu vas décompresser ta Str pour la transformer en Matrice, tu vas faire un Exp(...)->Mat A[J] pour chaque caractère.
Si au préalable, on a fait 10->A:11->B:12->C ... alors on récupère la bonne valeur si le programme Exp(...) un "C"
Ce qui peut donner "1000CAA"->Str 1 pour enregistrer les blocs 1, 0, 0, 0, 12, 10, 10

Un autre avantage c'est de pourvoir éviter les redondances. Par exemple une ligne qui comporte 9 fois des 0 d'affillé, on pourrait le coder :
"...Z09..."->Str 1
Le Z caractère spécial qui signifie : attention redondance de 9 fois le bloc 0

Et là je peux te dire tes niveaux vont pas prendre beaucoup de place en mémoire

Citer : Posté le 01/02/2016 20:39 | #

---

C'est incroyable le nombre de techniques efficaces et possibles pour optimiser de la mémoire que vous arrivez à trouver même tant de temps après la sortie de ce langage Ce serait bien si d'autres anciens revenaient un peu sur le site pour en débattre, ça fait un sujet de conversation sympathique et utile

---

Citer : Posté le 01/02/2016 21:23 | #

---

Tiens je viens de penser à une autre technique , prenons comme exemple

1 2 2 1 3 1 1 2
2 4 3 3 3 3 1 1
2 2 2 1 1 3 1 1

Et bien là, on peux compresser chaque ID séparément en binaire de cette manière
ID 1 : 10010110, 00000011, 00011011
ID 2 : 01100001, 10000000, 11100000
ID 3 : 00001000, 00111100, 00000100
ID 4 : 00000000, 01000000, 00000000

Ce qui nous donne reconverti en décimal :
ID 1 : 150, 3, 27
ID 2 : 97, 128, 224
ID 3 : 8, 60, 4
ID 4 : 0, 64, 0

Ensuite, on passe par le "dictionnaire" des 256 valeurs et obtiendrais seulement un caractère par ligne de cette manière, et on pourra ensuite tout coller dans une Str, ce qui nous ramènera à :
Une Matrice 4*8 -> Str de 12 caractères ! (Contre 24 avec l'autre technique)

Bien sur il faut couper les lignes si elles dépassent 8 cases car sinon ça pourra dépasser une valeurs de 256 lors de la compression binaire, mais si la largeur et la hauteur sont connues, ça passe .
Bon après je sais pas trop ce que ça donnerais pour plus d'ID ou plus de lignes/colonnes ...

---

Citer : Posté le 01/02/2016 22:17 | #

---

9*, à propos de la diagonalisation, ça marche pas vu que tes 3 vecteurs propres comportent chacun 3 coordonnée

Assez intéressant comme topic, je peux le renommer et le mettre en post-it ?

---

Citer : Posté le 01/02/2016 22:40 | #

---

Après, la solution par string est beaucoup plus intéressante lorsqu'il s'agit de les coller dans un programme pour personnaliser les niveaux (comme dans Arkenstone), puisque ne perdant pas de place à cause des crochets et virgules.

Après (je retrouve plus la quote, passons…) au niveau de la vitesse, les fonctions sur les strings sont bien plus rapides que celles sur les matrices en lecture, et en écriture tout dépend de ce que l'on écrit. J'estime la différence de rapidité à un facteur 3 à 5 sur la lecture. Après, tout va se jouer au niveau des opérations. Écrire une valeur dans une matrice est bien plus rapide que d'écraser un caractère, mais compresser avec la méthode de 9* (10000000001 > "1Z091") reste vachement intéressante, surtout si en plus on optimise au niveau du dictionnaire.

Idée surgie comme ça justement pour améliorer cette méthode : si une map fait 21 caractères de long par ligne, on peut attribuer 19 caractères spéciaux qui serviront à compresser encore plus, indiquant à la suite d'un bloc le nombre de répétition. Exemple avec A = 3, B = 4, etc., mais faut adapter aux blocs déjà existants dans le dico



C'est pas grand chose, mais on gagne 1 octet à chaque répétition. Donc très efficace sur des répétitions rapides de motifs qui vont de longueur 3 à 5-6.

Ajouté le 01/02/2016 à 22:41 :
Bien entendu, c'est juste pour le stockage des données, ces méthodes sont bien trop lentes pour le jeu en temps réèl.
Après, soit on utilise les strings (comme dans Calcraft), soit les matrices, au choix et selon les besoins du jeu.

---