nGc

[pierrotdu18]

Pour la transparence, si il faut demander à toi, alors je demande à toi
Nan sérieusement, c'est quand même bizarre... La couche alpha serait pas au bon endroit?...

Sinon pour le trackpad, ok je vais aller voir, mais je vais me perdre, je suis débutant....

EDIT : Dsl, je comprends vraiment rien au code... J'ai vu qu'il y avait une sorte d'algo pour détecter si c'est genre 8, 4, 6 ou 2 par exemple, mais sinon je n'ai rien compris

[pierrotdu18]

J'arrête pas d'overflower la stack...
Si je fais avec des malloc, ça peut aller?

EDIT : Non ça marche toujours pas... J'aurais en fait voulu afficher une image de 320*240, et du coup le code TI.image est incroyablement long...
Du coup, j'ai compté le nombre de virgules dans mon code, et j'ai fait la commande suivante pour créer dynamiquement mon tableau, mais que nenni...

Code: Tout sélectionner

char *background = malloc(230421 * sizeof("0xff"));

C'est beaucoup trop grand comme variable, mais ça ne veut quand même pas dire qu'il est impossible d'afficher une image de 320*240 ?

[Levak]

J'arrête pas d'overflower la stack...

Non, tant que tu n'as pas fait de variable locale à une fonction on ne parle pas de stack mais de heap.
Ne mélange pas les termes.

Code: Tout sélectionner

char *background = malloc(230421 * sizeof("0xff"));

2 erreurs :

• Pour pouvoir stocker 320*240 pixels en 2bpp, ça te donnera au moins 153600. Seulement, je ne comprends pas pourquoi tu ferais un malloc alors que tu disposes déjà du buffer de pixels de l'image. Tu essaierais pas d'allouer 2 fois l'image ?
• sizeof ("0xFF") est équivalent à sizeof (char *) donc à 4 (la taille d'un pointeur) et non 1 comme tu sembles l'avoir pensé.

Malgré nos problèmes d'alpha chelous je n'ai pas de problèmes à charger une image 320*240px via notre méthode.

[pierrotdu18]

Pardon excuse, je ne les connais pas les termes.

Non, en fait, lorsque je crée ma grande variable (enfin mon tableau) et que je la mets en paramètre dans mon drawImage(), l'ému affiche une espèce d'image noire et redémarre immédiatement...
(et sinon, sizeof("0xff") = 5.......)

[Adriweb]

et sinon, sizeof("0xff") = 5....

"0xff" est une chaîne, et ici, donné en tableau de char statique, donc sizeof te donnera la taille, donc 5 (0 x f f \0).
Pour une allocation dynamique, char* est un pointeur, et donc sur un système 32bit, 32/8 = 4 octets.

Cf. ici pour un exemple : http://codepad.org/AF7eYIZM


Bref, sinon, oui, il aurait fallu, pour une alloc dynamique de ton tableau de char, juste malloc(taille * sizeof(char)).
Mais en pratique, pas besoin, comme déjà dit, un tableau statique (non local à la fonction) suffit.

[pierrotdu18]

D'accord... Mais... Je viens de lire vite fait un paragraphe sur la nSDL : gère les images externes avec un format BMP, la transparence, les polices autres que serif et sansserif...

Je crois que je vais voir comment ça marche, parce que ça serait super quand même...

[Levak]

Tu fais comme tu veux.
Je ne peux pas t'empêcher de t'orienter vers une technologie beaucoup plus stable et répandue aujourd'hui.

nGC n'est pas voué à être intégré dans de gros projets, son origine vient de nFrame (que je n'ai pas pris le temps de publier car incomplet + passage en 3.6) où il est possible de définir des "CustomButton" dont il est possible d'implémenter le callback on.paint où on nous passe un gc déjà configuré.

Des exemples d'utilisation : nCapture et Theme Editor.

[pierrotdu18]

Bon, c'est décidé, je me mets à la SDL!
Je vais enfin commencer mon projet

Petite question : en Lua, pour gérer les screens, je mettais les bouts de code dans des listes, mais bon... Déjà en C ce n'est pas possible, puis je n'ai jamais trouvé ça très beau...
En C, si je veux gérer plusieurs screens, comment puis-je faire? J'aurais tendance à penser aux goto et lbl, mais je sais qu'il faut faire gaffe à leur utilisation...

[Adriweb]

Je me permets de citer Levak :

(19:51:45) Levak: pierrotdu18 : je crois avoir élucidé le mystère complet à propos de drawImage
(19:52:47) Levak: en 3.1, le drawImage du Lua n'appelle pas l'API ngc mais dessine chaque pixel avec des rectangles de couleurs, c'est d'ialleurs pour ça qu'on a toujours dit que la 3.1 était lente avec les images
(19:53:49) Levak: en 3.6, la fonction drawImage de l'API ngc s'est vue rajoutée un argument, indiquant si on doit gérer ou non la transparence. Cet argument n'existant pas dans la dfinition du syscall dans Ndless, on ne peut pas le mettre à 1 pour le moment
(19:54:38) Levak: L'origine des résultats étranges vis à vis de la transparence vient du fait de l'utilisation différente de "RasterOp", une opération définissant comment mélanger les pixels d'avant avec les nouveau
(19:57:19) Levak: en 3.1, la fonction drawImage de l'API utilise RasterOp(zANDz). En 3.6, sans l'argument de transparence, il utilise RasterOp(zREPz), avec transparence, il utilise RasterOp(xNANDNx)

[Levak]

Bon, c'est décidé, je me mets à la SDL!
Je vais enfin commencer mon projet

Petite question : en Lua, pour gérer les screens, je mettais les bouts de code dans des listes, mais bon... Déjà en C ce n'est pas possible, puis je n'ai jamais trouvé ça très beau...

Pas des listes, ici, des tables. En l'occurrence, outre le fait que l'on utilisait le nom de la fonction comme indexation, c'est ce que fait le C++ avec les vtables. Donc ce n'est peut être pas très "beau" pour toi, mais c'est un principe très répandu. Dommage que tu ne l'ai pas compris et/ou aimé.

En C, si je veux gérer plusieurs screens, comment puis-je faire? J'aurais tendance à penser aux goto et lbl, mais je sais qu'il faut faire gaffe à leur utilisation...

Les goto et lbl sont à proscrire sauf en cas d’extrême malice/contrainte (temps réel). Ce sont deux mots clé qui foutent en l'air toute l'organisation du code et le rend illisible pour n'importe qui.
Dans ton cas, tu peux t'inspirer de nClock, toujours avec le même principe d'écrans et de callbacks à définir.