Lua-interface...

Forum où l'on peut discuter de tout à condition de ne pas flooder, sauf dans l'unique sujet dédié "foutoir".
Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Lua-interface...

Message non lu par Pixel »

Bon, il semblerait (au moins 2! whoohoo!) que des gens commencent à se poser la question de comment développer des plugins pour lua-interface. C'est pas forcément une simple affaire, vu que je développe principalement sous linux, mais je vais au moins décrire une façon de faire "windows". Mais je préviens, c'est assez "usine à gaz".


Déjà, il vous faut msys / mingw32, et msysgit. Lors de l'installation de msysgit, spécifiez la troisième option pour les fins de lignes; en clair, vous voulez pas que msysgit touche aux fins de ligne du tout. Il vous faudra aussi gnuwin32, installé dans le path de la machine. En clair:

Image




Ouvrez un shell git dans votre répertoire de travail, (clic droit, hm), et tapez les commandes suivantes:

Code : Tout sélectionner

git clone http://git.grumpycoder.net/Baltisot
git clone http://git.grumpycoder.net/PSX-Bundle
git clone http://git.grumpycoder.net/lua-interface
git clone http://git.grumpycoder.net/lua-modules
git clone http://git.grumpycoder.net/lua-modules-cd-tool
git clone http://git.grumpycoder.net/mogltk
Ensuite, dans un shell msys, allez dans le répertoire de travail, et faites:

Code : Tout sélectionner

wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/bin2c.c
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/Mesa-7.0.3-osmesa-win32-precomp.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/freetype-win32-precomp.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/ftgl-win32-precomp.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/gnuwin32-digested.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/libreadline-static.a.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/mysql-5.0.51b-win32-precomp.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/pthreads-w32-2-8-0-release-win32-precomp.tar.gz
wget http://static.grumpycoder.net/pixel/lua-interface-src-digest/tinyxml-src.tar.gz
gcc -o bin2c.exe bin2c.c
mkdir -p /usr/local/bin
mv bin2c.exe /usr/local/bin
tar xvfz Mesa-7.0.3-osmesa-win32-precomp.tar.gz
tar xvfz freetype-win32-precomp.tar.gz
tar xvfz ftgl-win32-precomp.tar.gz
tar xvfz gnuwin32-digested.tar.gz
gunzip libreadline-static.a.gz
tar xvfz mysql-5.0.51b-win32-precomp.tar.gz
tar xvfz pthreads-w32-2-8-0-release-win32-precomp.tar.gz
tar xvfz tinyxml-src.tar.gz
De là, vous aurez tous les sources nécessaires à la compilation du bouzin.

Donc:

Code : Tout sélectionner

cd Baltisot/lib
./genloadlib.sh > loadlualibs.ii
cd ../../lua-interface
make -f Makefile.mingw32 luac.exe
make -f Makefile.mingw32
cd ../lua-modules
cp ../lua-interface/luac.exe .
make -f Makefile.mingw32
cd ../lua-modules-cd-tool
make -f Makefile.mingw32

*oof*

Logiquement, si tout s'est bien passé, vous avez à peu près lua-interface, et tout ce qu'il faut pour développer des plugins pour lui.

La compilation de http://static.grumpycoder.net/pixel/VP/lua-modules-vp/ est laissée en exercice au lecteur.

--edit--

J'oubliais: ça, c'est pour pouvoir *publier* des dlls compatibles avec ma distribution de lua-interface. Mais la solution visual studio express 2008 qui est présente dans le répertoire lua-interface devrait marcher proprement pour faire du dev. Il faut http://static.grumpycoder.net/pixel/lua ... -win32.zip en plus par contre, et beaucoup de fonctionnalités ne seront pas dispo, mais pour l'usage de base de lua-interface, ça devrait tenir.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Re: Lua-interface...

Message non lu par Pixel »

Et sous la suggestion de Bahabulle, j'ai fait une version "light" du software. Le packaging doit probablement manquer quelques dlls, mais ça a l'air de marcher:

http://static.grumpycoder.net/pixel/lua ... -win32.zip


La plupart des modules sont intégrés directement à la dll principale, et j'ai pas activé les modules graphiques et SQL du tout. Le module "cd" est toujours à part pour des raisons de cohésion du code. Tous les plugins développés pour la version full devraient marcher pour la version light aussi.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Re: Lua-interface...

Message non lu par Pixel »

Bon... je sais plus trop quelle mouche m'a piqué, c'est parti depuis un délire sur je ne sais plus quoi... bref. Toujours est-il que j'ai rajouté une UI à lua-interface. Enfin, un support pour une UI.

En gros, j'ai joué au boucher avec la librairie IUP (http://www.tecgraf.puc-rio.br/iup/) et j'en ai fait un module pour lua-interface. Les fonctionnalités sont présentes à environ 80%. J'ai giclé tout ce qui prenait de la place, comme le support freefont, jpeg, avi, plot, et la librairie d'icônes built-in.

Bref, c'est compatible Windows, linux, OSX, et c'est présent dans les dernières versions des packages.

Voilà un exemple de ce qu'on peut faire:

http://static.grumpycoder.net/pixel/luapatcher.lua

Ce qui s'affiche comme ceci:
sshot-lua-patcher.png
sshot-lua-patcher.png (25 Kio) Consulté 10452 fois

Le multi-threading est aussi géré proprement, comme le prouve cet exemple: http://static.grumpycoder.net/pixel/test-iup.lua


Bref, voilà voilà.

--edit--

Juste pour le fun, voilà ce que ça donne sous linux:
lua-patcher-linux.png
lua-patcher-linux.png (6.03 Kio) Consulté 10383 fois
Dernière modification par Pixel le 06 nov. 2009, 18:43, modifié 1 fois.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
Ti Dragon
Est devenu grand
Messages : 12441
Inscription : 25 févr. 2002, 18:25
Localisation : Dans mon lit c'est mieux
Contact :
Re: Lua-interface...

Message non lu par Ti Dragon »

Quel homme !

Faut que je pense à inclure tout ça sur la T.R.A.F, moi... Chuis *un peu* à la bourre.

- Edit -
Evidemment, compte tenu de la taille du fichier et des protections, je ne peux pas mettre la version Win sur le site :P Je lie au tiens, du coup ;)
"Heureusement qu'il n'avait que deux mots à nous dire... je plains son auditoire lorsqu'il doit faire un long discours"
(c) Le gardien du square
--
La scène de la traduction francophone : http://traf.romhack.org/

Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Re: Lua-interface...

Message non lu par Pixel »

Bon et vu que je suis dans la série des délires, je suis en train de sortir la version 0.8. La grosse différence c'est que je viens d'inclure LuaJIT 2.0-beta1 dans le bouzin. Ça m'a pris un peu de temps, mais ça semble tourner.

Logiquement, tout devrait fonctionner comme avec les versions précédentes. Maintenant, toute la VM Lua a été changée. C'est censé être 100% identique à l'ancienne, juste en beaucoup plus rapide, mais après...


Donc si Jes et Bahabulle pouvaient tester un peu pendant que je vais prendre quelques heures de sommeil; je sais que Jes a essayé dernièrement le patch MMX4 - le réessayer avec cette nouvelle version pourrait être intéressant, surtout de comparer le temps que ça met (si ça marche). Et pour Baha, pareil: j'aimerais bien savoir ce que ça donne avec ToD.

Cette nouvelle version est située ici: http://static.grumpycoder.net/pixel/lua-jit/ - je la déplacerai à l'endroit habituel dès qu'il y aura eu assez de tests pour confirmer que ça marche bien. De plus ça permet d'avoir toujours l'ancienne version sous la main pour pouvoir comparer les temps d'exécutions. J'ai quelques applis au boulot qui utilisent lua-interface et qui sont assez gourmands en CPU et en features. Je ferai les gros tests d'intégrité cette semaine.

--edit--

Et vu que Baha est encore une fois parti en coup de vent, j'ai trouvé le bug qui l'affectait dans son pcall, et je l'ai corrigé dans la dernière version.


--edit2--

Et concernant les performances, je me suis amusé à relancer le script pour dumper entièrement VP.

Avant:
real 12m29.977s
user 5m19.124s
sys 6m18.820s

Après:
real 10m14.160s
user 3m18.476s
sys 6m11.787s


L'utilisation mémoire était identique. Bon score au final, même si c'est les I/O qui prennent le plus de temps.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6496
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :
Re: Lua-interface...

Message non lu par BahaBulle »

Pixel a écrit :Et vu que Baha est encore une fois parti en coup de vent, j'ai trouvé le bug qui l'affectait dans son pcall, et je l'ai corrigé dans la dernière version.
T'avais qu'à pas me violenter et répondre avant :p

J'ai pas chronométré de façon aussi précise que toi mais avec mon script actuel et l'insertion de 174 fichiers, j'ai gagné environ 2 minutes.

Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Re: Lua-interface...

Message non lu par Pixel »

Okay. Dans tous les cas, c'est vraiment les I/O qui tuent les scripts de manipulation d'iso. D'ailleurs, dans ton cas, je me demande si la compression est bien utile. Est-ce qu'elle sert vraiment ? Je veux dire, le lzss a vraiment des taux de compression pourris. Est-ce qu'il ne serait peut-être pas plus sage de la laisser tomber, et de court-circuiter le code de décompression pour le transformer en memcpy ? Quelle taille ferait l'iso si tes modifs n'étaient pas compressées ?

Ou au pire, je peux te mettre en place le code qui va compresser en UCL, comme ce que j'ai fait avec VP. C'est carrément plus rapide que tout ce que tu peux faire en compression de ton coté :)

Dans tous les cas, j'en conclue que la version JIT ne t'a pas explosée à la figure ?



Sur un autre sujet, j'ai rajouté du code dans lua-interface-light: maintenant quand on le lance via double-clic, il affiche cette fenêtre:
lua-interface-light.png
lua-interface-light.png (14.2 Kio) Consulté 10294 fois
Si on clique sur "Command Line", ça donne directement un prompt, l'équivalent de l'option -i. Si on sélectionne un fichier .paq à lancer et qu'on clique sur Ok, il va chercher dans ce .paq le fichier "archive_main.lua", et va tenter d'exécuter la fonction "archive_main" sans aucun argument. Le compresseur de .paq est gracieusement fourni par Jes. :P
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
Jes
Pom pom pom
Messages : 5822
Inscription : 24 févr. 2002, 14:05
Localisation : Siège social de BessaB
Contact :
Re: Lua-interface...

Message non lu par Jes »

Pixel a écrit :D'ailleurs, dans ton cas, je me demande si la compression est bien utile. Est-ce qu'elle sert vraiment ? Je veux dire, le lzss a vraiment des taux de compression pourris. Est-ce qu'il ne serait peut-être pas plus sage de la laisser tomber, et de court-circuiter le code de décompression pour le transformer en memcpy ? Quelle taille ferait l'iso si tes modifs n'étaient pas compressées ?
LZ, un taux de compression pourri o_O Mais bien sûr :p T'as une idée de la place qu'occuperait les fichiers de VP si on supprimait juste la couche LZ, en laissant le RLE? Plus d'un giga :p Comme n'importe quelle autre méthode de compression, le LZ est très efficace sur des données hautement redondantes comme les graphismes ou les textes de script. A moins qu'il ne reste plusieurs centaines de mos libres sur le CD, je vois mal comment il pourrait s'en passer :p

Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Re: Lua-interface...

Message non lu par Pixel »

Sauf que je parle de ne pas compresser que les fichiers qui sont modifiés par le patch. Et ça, ça augmente le tout que de très peu.

Et, oui, LZSS a un taux de compression pourri pour des performances assez horribles, ou en tout cas, les 95% des implémentations faites par les game programmers. La seule implémentation de compression type LZSS qui est valable que je connaisse est UCL, justement.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
Jes
Pom pom pom
Messages : 5822
Inscription : 24 févr. 2002, 14:05
Localisation : Siège social de BessaB
Contact :
Re: Lua-interface...

Message non lu par Jes »

Pixel a écrit :Sauf que je parle de ne pas compresser que les fichiers qui sont modifiés par le patch. Et ça, ça augmente le tout que de très peu.

Et, oui, LZSS a un taux de compression pourri pour des performances assez horribles, ou en tout cas, les 95% des implémentations faites par les game programmers. La seule implémentation de compression type LZSS qui est valable que je connaisse est UCL, justement.
Tu mélanges un peu tout là. Au départ, tu compares un fichier pas compressé du tout avec son équivalent compressé en LZ: dans ce cas, il est parfaitement faux de dire que le taux de compression est, en moyenne, négligeable. Après, on peut comparer le taux de compression du LZ avec d'autres algorithmes, mais là encore, la supposée infériorité du LZ reste à démontrer. Celle-ci ne dépend pas seulement de l'implémentation (je parle ici de la variante et du schéma exact retenu) mais aussi de la méthode de parsing du fichier d'entrée. Et en la matière il y a un éventail de possibilités. Au final, je ne pas sûr du tout que le LZ fasse si pâle figure face à d'autres algorithmes sensé être optimaux, comme Huffman ou le codage arithmétique :p

Et concernant les performances en terme de temps d'exécution, il n'y a strictement rien à redire :p La décompression est *naturellement* très rapide. Le temps de compression quant à lui dépend entièrement de la façon dont est implémentée la recherche de chaînes dans la fenêtre glissante, de nouveau c'est une pure question d'implémentation. Mais intrinsèquement, il est clair que le LZ n'est *pas* lent. On ne pourrait expliquer la popularité de DEFLATE dans le cas contraire :-P

PS: Quoiqu'il en soit, je comprends pas bien pourquoi tu conseilles à Baha de ne pas recompresser ses fichiers alors-même que le goulot d'étranglement - et c'est pas la première fois qu'on en parle - se situe au niveau des accès au disque dur. Il va gagner quoi, 10% de temps d'exécution? :p

Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Re: Lua-interface...

Message non lu par Pixel »

Jes a écrit :Tu mélanges un peu tout là. Au départ, tu compares un fichier pas compressé du tout avec son équivalent compressé en LZ: dans ce cas, il est parfaitement faux de dire que le taux de compression est, en moyenne, négligeable. Après, on peut comparer le taux de compression du LZ avec d'autres algorithmes, mais là encore, la supposée infériorité du LZ reste à démontrer.
Ceci est discuté en long en large et en travers par les travaux de Jean Loup Gailli et Markus Oberhumer. Je te laisse lire leurs papiers.
Jes a écrit :Celle-ci ne dépend pas seulement de l'implémentation (je parle ici de la variante et du schéma exact retenu) mais aussi de la méthode de parsing du fichier d'entrée. Et en la matière il y a un éventail de possibilités. Au final, je ne pas sûr du tout que le LZ fasse si pâle figure face à d'autres algorithmes sensé être optimaux, comme Huffman ou le codage arithmétique :p
Le schéma a une énorme importance sur le taux de compression. Et sur un texte de 2 ou 3 Ko, un schéma comme celui de ToD ne fera pas vraiment d'effet, surtout que ledit schéma est destiné à du graphisme.
Jes a écrit :Et concernant les performances en terme de temps d'exécution, il n'y a strictement rien à redire :p La décompression est *naturellement* très rapide. Le temps de compression quant à lui dépend entièrement de la façon dont est implémentée la recherche de chaînes dans la fenêtre glissante, de nouveau c'est une pure question d'implémentation. Mais intrinsèquement, il est clair que le LZ n'est *pas* lent. On ne pourrait expliquer la popularité de DEFLATE dans le cas contraire :-P
La décompression, oui. La compression, non. Tu as regardé le code de Baha à ce sujet ? Et je parle bien de LZSS, pas des variantes genre LZW qui ont une optimisation naturelle due à leur nature de dictionnaire.
Jes a écrit :PS: Quoiqu'il en soit, je comprends pas bien pourquoi tu conseilles à Baha de ne pas recompresser ses fichiers alors-même que le goulot d'étranglement - et c'est pas la première fois qu'on en parle - se situe au niveau des accès au disque dur. Il va gagner quoi, 10% de temps d'exécution? :p
Qu'est-ce que tu en sais ? Son code de compression est une implémentation naïve de LZSS. Au final, on ne sait pas combien il gagnerait en sucrant ce code-là et en faisant juste un memcpy des textes.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
Jes
Pom pom pom
Messages : 5822
Inscription : 24 févr. 2002, 14:05
Localisation : Siège social de BessaB
Contact :
Re: Lua-interface...

Message non lu par Jes »

Pixel a écrit :
Jes a écrit :Tu mélanges un peu tout là. Au départ, tu compares un fichier pas compressé du tout avec son équivalent compressé en LZ: dans ce cas, il est parfaitement faux de dire que le taux de compression est, en moyenne, négligeable. Après, on peut comparer le taux de compression du LZ avec d'autres algorithmes, mais là encore, la supposée infériorité du LZ reste à démontrer.
Ceci est discuté en long en large et en travers par les travaux de Jean Loup Gailli et Markus Oberhumer. Je te laisse lire leurs papiers.
Bizarrement, ces deux-là ont choisi d'incorporer une variante du LZ dans leurs algorithmes de compression :D
Pixel a écrit :Le schéma a une énorme importance sur le taux de compression.
Jamais dit le contraire. Mais le schéma a lui seul ne détermine pas complètement le taux de compression atteignable. Le parsing du fichier à compresser introduit un autre degré de liberté. Au final le taux de compression est donc fortement dépendant de l'implémentation. Ces problèmes d'implémentations mis à part, je maintiens que le LZSS est un "bon" algorithme, à tout pointe de vue. Et affirmer le contraire, c'est du troll :p
Pixel a écrit :Et sur un texte de 2 ou 3 Ko, un schéma comme celui de ToD ne fera pas vraiment d'effet, surtout que ledit schéma est destiné à du graphisme.
Mais si, bien sûr qu'il y aura un effet. Au grand minimum, le fichier compressé obtenu devrait être 30% moins gros (et c'est bien le minimum). Un texte, français ou anglais, est naturellement fortement redondant. N'importe quel schéma utilisé *doit* réaliser une compression substantielle. Par ailleurs je suis curieux de savoir ce qui te fait dire que le schéma choisi convient mieux aux propriétés statistiques des images que des textes :p
Pixel a écrit :
Jes a écrit :Et concernant les performances en terme de temps d'exécution, il n'y a strictement rien à redire :p La décompression est *naturellement* très rapide. Le temps de compression quant à lui dépend entièrement de la façon dont est implémentée la recherche de chaînes dans la fenêtre glissante, de nouveau c'est une pure question d'implémentation. Mais intrinsèquement, il est clair que le LZ n'est *pas* lent. On ne pourrait expliquer la popularité de DEFLATE dans le cas contraire :-P
La décompression, oui. La compression, non. Tu as regardé le code de Baha à ce sujet ? Et je parle bien de LZSS, pas des variantes genre LZW qui ont une optimisation naturelle due à leur nature de dictionnaire.
Ah mais, on ne parle pas du code de Baha là, je t'ai bien entendu dire "le LZSS a des performances horribles" non? :p Alors, mettons de côté le LZW qui descend du LZ78 et qui n'a que peu de rapport avec le LZ77 (LZ77 dont le LZSS n'est qu'une infime variation). Il y a, dans la littérature, tout un tas d'articles discutant du meilleur moyen pour accélérer la recherche de chaînes adéquates dans la fenêtre glissante. En fait, tu as un éventail de solutions possibles pour résoudre le problème: table de hachage, arbre binaire de recherche, arbre suffixe, tableau suffixe... Au final, il a été démontré qu'on peut construire un algorithme de compression LZ77/LZSS de complexité temporelle linéaire (en moyenne) avec la taille du fichier à compresser. Et ce n'est pas que de la théorie. Je reviens sur DEFLATE. Est-ce que tu as à te plaindre du temps d'archivage d'un zip? Ou du temps d'enregistrement d'une image PNG?
Pixel a écrit :
Jes a écrit :PS: Quoiqu'il en soit, je comprends pas bien pourquoi tu conseilles à Baha de ne pas recompresser ses fichiers alors-même que le goulot d'étranglement - et c'est pas la première fois qu'on en parle - se situe au niveau des accès au disque dur. Il va gagner quoi, 10% de temps d'exécution? :p
Qu'est-ce que tu en sais ? Son code de compression est une implémentation naïve de LZSS. Au final, on ne sait pas combien il gagnerait en sucrant ce code-là et en faisant juste un memcpy des textes.
J'en sais qu'il nous a déjà donné il y a peu le temps de reconstruction de l'ISO sans rien recompresser, et que ça ne laissait pas beaucoup de doutes sur la question :p

Avatar de l’utilisateur
BahaBulle
Bub'n'Bob Pawa!
Messages : 6496
Inscription : 06 août 2002, 09:34
Localisation : Sur une bulle
Contact :
Re: Lua-interface...

Message non lu par BahaBulle »

Pixel a écrit :Et sous la suggestion de Bahabulle, j'ai fait une version "light" du software. Le packaging doit probablement manquer quelques dlls, mais ça a l'air de marcher:

http://static.grumpycoder.net/pixel/lua ... -win32.zip
Juste pour dire que ce lien ne fonctionne plus car le nom du zip à changé.

Le nouveau nom : http://static.grumpycoder.net/pixel/lua ... -light.zip

Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Re: Lua-interface...

Message non lu par Pixel »

Ah mais il avait répondu le Jes, j'avais pas vu.


Le schéma de ToD inclue une pré-initialisation du backbuffer avec des data qui sont typiques d'images, comme des rampes et autres répétitions, afin de mieux compresser les images justement. Donc c'est en effet prévu pour les propriétés statistiques des images.


Et pourquoi tu parles de DEFLATE ? Tu es en train de parler d'un algo qui utilise de la *mémoire* pour fonctionner! C'est pas un LZSS! Il y a du huffman dedans, ainsi qu'un dictionnaire dynamique. Ca n'a rien à voir comme méthode. Enfin, au mieux, on peut parler de "lz77 improved". C'est un lz78 en fait à la base. Mais les "lzss" tels qu'on peut les voir dans les jeux sont juste des batards qui ont été grossièrement assemblé à partir de l'idée de "ce que c'est qu'une compression type lz77".

De manière générale, je parle du "LZSS barbare utilisé par les codeurs de jeu vidéo qui veulent pas mettre de la zlib ou acheter une license lzo". La plupart du temps, ils vont se foutre dedans, et provoquer des algos qui sont peu efficaces ou qui ne correspondent pas à leurs besoins.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
Jes
Pom pom pom
Messages : 5822
Inscription : 24 févr. 2002, 14:05
Localisation : Siège social de BessaB
Contact :
Re: Lua-interface...

Message non lu par Jes »

Pixel a écrit :Le schéma de ToD inclue une pré-initialisation du backbuffer avec des data qui sont typiques d'images, comme des rampes et autres répétitions, afin de mieux compresser les images justement. Donc c'est en effet prévu pour les propriétés statistiques des images.
L'initialisation du buffer ne fait pas partie de ce que j'appelle le schéma. Et si ce n'est que ça ça n'empêche pas une compression substantielle du texte.
Pixel a écrit :Et pourquoi tu parles de DEFLATE ? Tu es en train de parler d'un algo qui utilise de la *mémoire* pour fonctionner! C'est pas un LZSS! Il y a du huffman dedans, ainsi qu'un dictionnaire dynamique. Ca n'a rien à voir comme méthode. Enfin, au mieux, on peut parler de "lz77 improved". C'est un lz78 en fait à la base. Mais les "lzss" tels qu'on peut les voir dans les jeux sont juste des batards qui ont été grossièrement assemblé à partir de l'idée de "ce que c'est qu'une compression type lz77".
DEFLATE c'est LZ77 + Huffman (aucune trace du LZ78 qui comme je le disais plus haut, n'a rien de comparable au LZSS). Et je te parle de DEFLATE pour sa vitesse d'exécution lors de la compression (ça me paraissait pourtant clair). DEFLATE est rapide, alors même qu'il se paie le luxe de rajouter une couche de compression supplémentaire par rapport au LZ77 pur. C'est bien la preuve que le LZSS n'est pas un algorithme de compression fondamentalement lent.

Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Re: Lua-interface...

Message non lu par Pixel »

Je vais formuler autrement: aide Bahabulle dans ce cas à améliorer son algo de compression pour ToD en y mettant les algos de création de dictionnaire de deflate, afin d'améliorer sa vitesse de réinsertion. Ensuite on en reparlera.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
Jes
Pom pom pom
Messages : 5822
Inscription : 24 févr. 2002, 14:05
Localisation : Siège social de BessaB
Contact :
Re: Lua-interface...

Message non lu par Jes »

Ca c'est ce qui s'appelle botter en touche :D Mais tu sais, comme le temps d'exécution reste largement impacté par les I/O... :D

Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Re: Lua-interface...

Message non lu par Pixel »

Voilà voilà voilà voilà.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
Jes
Pom pom pom
Messages : 5822
Inscription : 24 févr. 2002, 14:05
Localisation : Siège social de BessaB
Contact :
Re: Lua-interface...

Message non lu par Jes »

Ah? T'as changé d'avis alors? Je croyais que la compression LZSS était fondamentalement ultra-lente et plombait tout le temps d'exécution du script de Baha :D

Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Re: Lua-interface...

Message non lu par Pixel »

Tu viens juste de prouver que j'ai raison. Dans le cas de ToD, le ratio "temps passé" / "gain de place" est tellement élevé que c'est une perte de temps plus qu'autre chose. Baha peut donc largement éviter de recompresser ses textes. Ou bien recoder l'algo complètement pour être efficace, ce qui, avec ton aide étant donné ta large connaissance de deflate, devrait être chose aisée.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
Jes
Pom pom pom
Messages : 5822
Inscription : 24 févr. 2002, 14:05
Localisation : Siège social de BessaB
Contact :
Re: Lua-interface...

Message non lu par Jes »

Pixel a écrit :Tu viens juste de prouver que j'ai raison.
:D Alors que depuis le départ je me tue à te dire que tes considérations sur le LZSS sont fausses :D
Pixel a écrit :Dans le cas de ToD, le ratio "temps passé" / "gain de place" est tellement élevé que c'est une perte de temps plus qu'autre chose. Baha peut donc largement éviter de recompresser ses textes.
Même si c'était vrai, comme c'est pas la compression qui plombe tout le process, à quoi bon vouloir l'éviter? Surtout qu'au final ça implique de court-circuiter la routine de décompression dans le binaire. Berk, berk, berk :p
Pixel a écrit :Ou bien recoder l'algo complètement pour être efficace, ce qui, avec ton aide étant donné ta large connaissance de deflate, devrait être chose aisée.
Ou toi avec ta large connaissance du n2e :D Remarque, là ce serait vraiment une perte de temps inutile, dans les deux cas :p

Avatar de l’utilisateur
Pixel
Codeur à l'irc dormant
Messages : 1946
Inscription : 17 avr. 2002, 17:30
Localisation : San Jose
Contact :
Re: Lua-interface...

Message non lu par Pixel »

Et moi je te dis que tu as tort: la compression dans le cas de la reconstruction de l'iso pour Baha prend obligatoirement un temps non négligeable, au vu de l'algo qu'il utilise. Je ne serais pas surpris du tout d'un boost du temps de reconstruction en virant la compression. Je pense donc sincèrement que c'est à considérer.

Le n2e est une toute autre affaire. Déjà, le temps de compression de l'algo ucl est inférieur aux algos que l'on peut produire, donc de toute façon, rajouter du n2e dans le paté serait un plus au niveau du temps de reconstruction de l'iso. Ensuite, l'algo de décompression existe déjà pour MIPS, et l'inclure serait trivial. Le temps de travail pour effectuer cette modif est lui négligeable comparé au temps de travail pour améliorer l'algo de compression original. Donc, pourquoi pas aussi, si la compression est absolument nécessaire; ce qui, je le répète, ne me semble pas être le cas du tout.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department.

Avatar de l’utilisateur
Happexamendios
Adepte !
Messages : 6750
Inscription : 22 févr. 2002, 12:01
Localisation : Royaume d'Imajica
Contact :
Re: Lua-interface...

Message non lu par Happexamendios »

fiouuu !

c'est raide à suivre les débats d'experts...
Complètement lourdé, moi! :(

on peut pas causer voiture, filles ou picole ? :D
Je pionce donc je suis

Avatar de l’utilisateur
Jes
Pom pom pom
Messages : 5822
Inscription : 24 févr. 2002, 14:05
Localisation : Siège social de BessaB
Contact :
Re: Lua-interface...

Message non lu par Jes »

Et c'est tout ce que tu trouves à dire toi? :D

Avatar de l’utilisateur
Jes
Pom pom pom
Messages : 5822
Inscription : 24 févr. 2002, 14:05
Localisation : Siège social de BessaB
Contact :
Re: Lua-interface...

Message non lu par Jes »

Bon, et sinon, puisqu'on me l'a demandé, je mets en ligne mon soft gérant les PAQ:

http://www.bessab.net/jes/paq/paq-1.0-win32.zip

Code : Tout sélectionner

PAQ archiving utility, version 1.0 (Nov 22 2009)
Copyright (C) 2009 Jes, http://www.bessab.com

Usage: paq [action] [paq file] {in/out directory}

  The following actions are supported:

  -l list files in a PAQ archive
  -x extract PAQ archive to the specified directory
  -c create PAQ archive of an entire directory (including its sub-directories)
Toutes les dépendances ont été statiquement liées, ça devrait donc tourner n'importe où sans problème de dll :p

En espérant que ça serve :)


Répondre