> Si tu t´embetes a faire ta compression
> avec tes clés de cryptages, etc
> ben t´es pas pret de le finir ton jeu"

Et pourtant ca fait partie du développement !

J´ai bossé sur 4 jeux pros ( dont un sur PC et 2 qui sont dans le commerce), et 2 jeux amateurs GBA et y a jamais eu de compression de developpé.

Donc n´affirme pas que ca fait partie du developpement. Mes example prouve que ce n´est pas toujours le cas.

Un peu d´humulité diantre. Personne ici ne peux connaitre la verité absolue. Et lorsque qu´on la connait pas, on ne s´avance pas autant.

Donc au lieu d´essayer de me contredire systematiquement, essayer de faire preuve d´un soupson d´intelligence et de pas etaler votre science inutilement et de dire aux noobs que GERER LES BITS CA SERT A RIEN POUR LES PETIT DEV AMATEURS FAIT PAR DES NEWBIES.

peut etre ke ils peuvent l´éviter.
mais si ils veulent apprendre a le faire c´est tres interressant a implémenter je pense au contraire.
ca apprend les operateurs booléens et tout..

lapintade>
ton front montant tu l´aurais eu si tu connaissais la directive:
__assume;

Je pense que les debutant on un million de choses a apprendre avant de faire ca. ( aussi bien au niveau du langage que de la creation de jeu).

Je n´ai rien contre la gestion des bits, j´ai commencé a programmé en assembleur ( a l´epoque c´etait le plus rapide), donc je fu forcé d´en utiliser beaucoup.

ton front montant tu l´aurais eu si tu > connaissais la directive: __assume;

Desolé, je comprends pas.

Lightness1024, c´est toi qui a fait le site de tutos ( et les tutos) que tu donne quelques messages plus bas ?

" J´ai bossé sur 4 jeux pros ( dont un sur PC et 2 qui sont dans le commerce), et 2 jeux amateurs GBA et y a jamais eu de compression de developpé."

Ne pense pas être le seul à bosser ( ou avoir bossé) dans les jeux. Ce qui m´étonne c´est qu´en ayant fait qqchose sur GBA il ne t´est jamais venu à l´idée de compresser un peu tes données!? Remarque tout dépend du jeu évidemment. Ca prouve au moins que les projets sur lesquels tu bossais n´avaient pas besoin de tout cela. Mais pourtant ca existe, plus que tu ne le crois je pense.

" Donc n´affirme pas que ca fait partie du developpement. Mes example prouve que ce n´est pas toujours le cas."

Je n´ai jamais dit que c´était indispensable ni systématique dans un développement. Seulement beaucoup de développements doivent trouver des solutions à ces problèmes ( compression, protection...).

" Un peu d´humulité diantre. Personne ici ne peux connaitre la verité absolue. Et lorsque qu´on la connait pas, on ne s´avance pas autant."

Je ne m´avance pas mais tu semblais prétendre que la question est à la base inutile puisque soit disant posée sur un forum de " noobs" . .. Si le but est seulement d´afficher un sprite ou se servir d´outils de création à la MordMoiLeMaker . . bin c´est un peu triste non ?

Je vais pas debatre avec vous, je vais juste tenter de repondre à la question :

comment créer tableau, 1 case = 1 bit ?

bool tab[n]; / / remplacer n par une valeur constante
ou
bool *tab; / / si tu ne conais pas a l´avance la taille de ton tableau
tab = new tab[n];

C bon, non ?

Zut, tu le fait en C.
tit rectification :
Fait un maloc a la place de faire new.

il le fait en C son tab? un conseil si tu fait de l´allocation de mémoire dynamique passe au C++, le risque en C c´est d´oublier de libérer la mémoire après utilisation et tu plante le programme,en C++ tu crée un constructeur,un destructeur et c´est bon t´à plus à te soucier de libérer ta mémoire après un sous programme

il le fait en C son tab? un conseil si tu fait de l´allocation de mémoire dynamique passe au C++, le risque en C c´est d´oublier de libérer la mémoire après utilisation et tu plante le programme,en C++ tu crée un constructeur,un destructeur et c´est bon t´à plus à te soucier de libérer ta mémoire après un sous programme

il le fait en C son tab? un conseil si tu fait de l´allocation de mémoire dynamique passe au C++, le risque en C c´est d´oublier de libérer la mémoire après utilisation et tu plante le programme,en C++ tu crée un constructeur,un destructeur et c´est bon t´à plus à te soucier de libérer ta mémoire après un sous programme

Altonfrere, je me doute que suis pas le seul pro ici, mais j´aimerais simplement que les discussions ne tourne justement pas dans des debats de pros. Y a d´autres forums pour ca.

Sur GBA, j´aurais peut etre besoin de compresser mes données, mais ce jour la j´utiliserai surement le compresseur du bios ou une lib deja faite. Donc meme en faisant de l´amateur avancé ( c´est quand meme avancé sur GBA de remplir toute la ROM ) , ben toujours pas besoin de coder mes algos de compression et gerer mes bits dans les clés de cryptage.

Love and peace et essayons de conseiller au mieux les debutants.

Si le but est seulement d´afficher un
sprite ou se servir d´outils de création
à la MordMoiLeMaker
. . bin c´est un peu triste non ?

Non ce qui est un peu triste est de denigrer des outils simples qui permettent de faire des jeux.

" kookii, tu ose me dire que j´etale mon ignorance ( tu me donnais meme pas) ben toi tu te caches pas pour etaler ta connerie. Le jour ou tu aura un jeu qui aura 100 millions d´objets, tu m´appellera. "

Ce n´est pas parce que ca ne t´es jamais arrive d´avoir affaire a des données qui ne tiennent pas en memoire que ca n´existe pas.
Un petit exemple, un terrain sous forme de heightmap 10000*10000 quads et hop 100M de Triangles... Si tu veux gerer plusieurs textures, plutot que de mettre un char, tu stockes ca sous forme de bits pour savoir laquelle afficher et tu réduis la taille par ex par 2 ou 3 en memoire.

C´est un exemple, c´est excessif 100M de T pour un terrain, mais on n´est plus y´a 10ans ou il n´y avait que 10000T a faire tenir en mémoire.

De même, pour les applications industrielles ( et je sais de quoi je parle) les modeles ne tiennent pas en mémoire. Il faut les compresser et les decompresser a la volee. Quand tu utilises des scanners a resolution de 0.25*0.25*0.75µm pour scanner un objet ne serait-ce que de 1m^3 je te laisse imaginer le nombre de triangles a gerer... Si tu arrives a me faire tenir ca en memoire sans compresser, depose un brevet

Kookie, je ne dis pas que tout ce que tu me dis est faux, mais c´est relativement hors sujet . .. ( tu cites les applis industielles, on en est loin quand meme ici).

Pour les terrains, il existe des millions de methodes qui ne font pas forcement appelle a de la compression ( patchs, streaming, etc . ..).

Je suis le premier a utiliser les bit nu mais c´est assez hardcore et inutile pour les newbies. Si tu message est de dire " oui mais ca existe" alors je ne le conteste pas. OUI CA EXISTE. Heureux ?

bon g pas lu le débat, je répond juste a lapintade>

oui c moi ki ai fait le site des tutos

et aussi, __assume; c la directive de certains compilateurs pour qu´ils n´optimise pas les lignes de codes qui sont dans une portée.

Si tu me le permets j´ajouterai le lien de ta page tutos dans ma page resumé.

Pour le __assume, je pense que tu doit confondre, j´ai jamais posé de questions de ce genre Ca doit etre quelqu´un d´autre.

Pour répondre à la question.

Je pense qu´il vaut mieux utilisé des champs de bits. Le tout bien ordoné en structure et unions.

Bien sûr, des masques sont utilisé, mais comme c´est en natif, c´est beaucoup plus rapide que si on développait une classe.

Bien, je ne veux pas trop m´interposer dans la luttle générale, même si je suis à 100% avec Aitonfrere.

Quant à la question originelle...

" Je vais pas debatre avec vous, je vais juste tenter de repondre à la question :

comment créer tableau, 1 case = 1 bit ?

bool tab[n]; / / remplacer n par une valeur constante
ou
bool *tab; / / si tu ne conais pas a l´avance la taille de ton tableau
tab = new tab[n];

C bon, non ? "
Non, c´est dommage, mais un bool ne vaut pas un bit, mais un octet entier. Ça fait gaspillage, mais c´est comme ça, c,est un byte entier pour un seul bit...

Aitonfrere propose un bonne solution avec sa classe, quoique il en existe une autre.

C´est un truc dont je pense qu´il n´est pas très connu, mais je peut me tromper... M´enfin, peut importe. Il s´agit des champs de bits. Ça vient du C, c´est une fonctionalité très utile en prog système, où des flags par bits sont très utilisés.

La syntaxe est la suivante:
struct nomDeStructure
{
unsigned int/int NomDuChamp:NombreDeBits;
/ * Autant que nécessaire */
};

La taille des structures est arrondi vers le haut de un byte. Cela signifie que la taille en bits sera un multiple de 8, garatissant une structure d´un nombre entier de bytes. Dans le cas où l´arrondisement est nécessaire, des bits, non accessibles, seront laissés vacants.

ex:
typedef struct Champ
{
int a : 2;
int b : 3;
int c : 6;
};

La taille de la structure sera 2 bytes. La disposition des bits n´est pas définie, et est libre au compilateur.

ex: aabbbccc ccc00000, bbb000aa cccccc00, 000ccccc caa00bbb, ect.

Cepandant, la taille totale d´un champ ne doit pas dépasser celle d´un entier.
int machin : 455 est illégal, par exemple.

Notez cepandant que la norme spécifie bel et bien un entier, mais que il est généralement accepté, aussi, des short et des char... Dans ce cas, la taille en bits du champ ne doit pas dépasser celle de son type.

Considérant ceci, donc, il est très possible de créer autant de bits que nous voulons. Ça serait un peut l´équivalent d´un tableau statique. Par exemeple, un " tableau" de 7 bits:

typepdef struct _Tableau7
{
int b1:1;
int b2:1;
int b3:1;
int b4:1;
int b5:1;
int b6:1;
int b7:1;
} Tableau7;

tableau7 Tableau;

On accède alors à un bit par:

Tableau.b5=0;
Tableau.b3=1;
Tableau.b2=2;/* Illégal! */

Voilà. C´est plus pratique pour des petits tableaux, mais pour des gros, c´est impensable: vous imaginez, 256 champs de bits?
Notez aussi que il n´est pas possible de pointer sur un champ ( ainsi que plein d´autres restrictions), interdisant la possibilité d´effectuer de l´allocation dynamique ( tout à fait sensé, d´ailleurs).
Dans ces cas, une grosse classe de dingue, dite méthode Aitonfrere, serait le plus bienvenue.

D´ailleurs que ceci ne sert à rien:

struct _Bit
{
int b:1;
} BitTableau[256];

BitTableau[45].b=1;

En effet, la structure étant arrondi au byte près, _Bit serait alors un tableau de 256 bytes. C´est 8 fois plus gros que nécessaire. malgré tout, c´est possible, mais alors, il vaudrait mieux utiliser des bool, à mon avis...

Kelios
---------

" la structure étant arrondi au byte près, _Bit serait alors un tableau de 256 bytes."

Euh, je voulais bien sur dire que BitTableau serait un tableau de 256 bytes. Mon erreur

Kelios
---------

Pfff, je me rends compte que j´ai écrit tout ça pour rien...

" Sans utiliser les champs de bit avec la commande struct."

Résolution 2004: lire TOUT avant de répondre

Kelios
---------

c koi ce programme? il m´a l´air interressant...