[Index Software] Coin des développeurs :]

[Bubu]

Ça y est c'est réglé ....
Via des comptes gmail à qui j'envois une url de validation, n'importe qui peut-être testeur.
Lors de la fenêtre d'achat de Google, c'est précisé que ce n'est qu'un test, et qu'il n'y a bien sûr rien à la charge du testeur. (Heureusement ! )

Bon, je fignole le système de paiements, j'ai un bug à corriger, et des couleurs à remplacer dans le magasin.
Après, je posterai une première version de test exploitable.
Il suffira de me donner son adresse gmail, je la rentre dans la console Google et envois le lien pour activer son statut de testeur.
Après on la télécharge depuis googlePlay. (Le lien est directement proposé).

A suivre sur le sujet dédié. (Sqwap !)

[Tugdual]

Trois jours que je me prends la tête dans tous les sens sur
un bug très aléatoire dans une application multi-threads !

J'ai repéré une situation qui peut expliquer le bug, et quand
je fais des modifications pour éviter cette situation, cela
semble bien ne plus bugger, même en chargeant l'appilcation.

Mais je n'arrive pas à repérer le contexte qui amène à cette
situation, ce qui me rend suspicieux quant à ma correction ...

Je déteste ce genre de cas de figure ...

[Bubu]

Trois jours que je me prends la tête dans tous les sens sur
un bug très aléatoire dans une application multi-threads !

J'ai repéré une situation qui peut expliquer le bug, et quand
je fais des modifications pour éviter cette situation, cela
semble bien ne plus bugger, même en chargeant l'appilcation.

Mais je n'arrive pas à repérer le contexte qui amène à cette
situation, ce qui me rend suspicieux quant à ma correction ...

Je déteste ce genre de cas de figure ...

Je te plains. C'est une horreur ces trucs là.
Ça plante aléatoirement, et impossible de créer les conditions du bug ou d'en trouver ses raisons.

Il faut s'assurer que toutes les variables et méthodes utilisées par plusieurs threads sont bien thread-safe.
En C++, des sections critiques (mutexes ...) partout autour de ces variables et méthodes partagées entre plusieurs threads.

Après je sais bien que c'est très facile à dire.
Bon courage !

Par exemple :

class Choucroute {
private :
bool avecDesSaucisses;
Mutex avecDesSaucissesMutex;


public:
bool getAvecDesSaucisses {
bool result;
avecDesSaucissesMutex.lock();
result = avecDesSaucisses;
avecDesSaucissesMutex.unlock();
return result;
}

void setAvecDesSaucisses(bool avecDesSaucisses) {
avecDesSaucissesMutex.lock();
this->avecDesSaucisses = avecDesSaucisses;
avecDesSaucissesMutex.unlock();
}
};

Là, la variable avecDesSaucisses est thread-safe.

[Tugdual]

En fait le contexte est une variable globale, indirectement
partagée par des threads via un système de référencement.

C'est la seule ressource non thread-safe du projet, mais à
l'analyse du source je ne vois rien qui puisse partir en vrille.

Accessoirement, le code est à la fois trop complexe pour
utiliser des sections critiques de bas niveaux, et trop bas
niveau pour utiliser des mutex/sémaphores sans provoquer
une baisse de performance critique pour le projet ...

D'un côté j'ai résolu le problème, en supprimant cette
variable globale, dont la présence devait apporter une
optimisation des performances, finalement très modeste.

Au moins, le bug est résolu.

Reste que j'aimerais comprendre exactement à quel endroit
du source l'interruption d'un thread par un autre provoque
le plantage que je constate occasionnellement ...

Pour l'instant, je sèche ...

[Tugdual]

Je pense avoir trouvé !

À priori, c'est une erreur de "vieux" programmeur ...



Contrairement aux microprocesseurs du passé, ceux actuels
ne garantissent plus l'atomicité de l'incrémentation ou de la
décrémentation d'un entier en mémoire (probablement à cause
de leurs saloperies de micro-codes internes à outrance).

Il faut passer désormais par des fonctions systèmes :

• "InterlockedIncrement" et "InterlockedDecrement" pour Windows ;
• "__sync_fetch_and_add" et "__sync_fetch_and_sub" pour Linux.

Tests encourageant en cours ...

[Bubu]

Tu ne peux pas créer dans le même contexte que ton entier, une variable globale section critique ou mutex ?
Si tu es sous Linux, je ne connais pas l'API posix , mais sous Windows, créer une section critique est très facile.

Code : Tout sélectionner

#pragma once
#include <windows.h>

class CriticalSection
{
protected:
	CRITICAL_SECTION cs;
public:

	CriticalSection(void)
	{
		InitializeCriticalSection(&cs);
	}

	void lock()
	{
		EnterCriticalSection(&cs);
	}

	void unlock()
	{
		LeaveCriticalSection(&cs);
	}

	~CriticalSection(void)
	{
		DeleteCriticalSection(&cs);
	}
};

Après tu crées une section critique indépendante pour chaque variable. Pour des raisons de performance (on ne bloque que ce qui est nécessaire), et pour éviter le risque de dead-locks inutilement.

C'est un peu vache, mais ton problème, en Java, aurait été simplement résolu en mettant l'attribut volatile devant ton entier.
En C++, c'est juste plus verbeux, il faut créer une section critique sur ta variable et l'utiliser dès que tu la manipules.

Ça peut peut-être t’intéresser :
http://en.cppreference.com/w/cpp/atomic/atomic
(std::atomic_int std::atomic<int>)

[Tugdual]

Merci Bubu pour les infos ...

Mais là, mes fonctions système font le job correctement,
et je multiplie les tests, qui se déroulent sans soucis ...

Accessoirement, c'est un source qui compile et fonctionne
à la fois sous le système Windows aussi bien que Linux ...

[Bubu]

Je crains concernant la portabilité de ton code...

Si c'est l'atomicite de l'entier qui pose problème, mieux vaut utiliser std::atomic sur ton entier.
En plus c'est indépendant de la plateforme.

Le micro code est différent pour chaque processeur, il vaut mieux utiliser les objets tout faits C++ qui sont faits pour ça, qui garantissent l'atomicite des objets.

[Tugdual]

Je crains concernant la portabilité de ton code...

Et pourtant ça marche d'enfer ...



Ce n'est pas une création de code, mais une évolution
d'un très ancien code, donc on reste assez "bridé" ...

Mais ce qui est dépendant à l'OS est concentré dans un
seul module, ce qui facilite la gestion de la compatibilité.

[Bubu]

Et pourtant ça marche d'enfer ...

Tant mieux pour toi, ça fait plaisir.

Le multi-threading c'est un pain-in-the-ass en général quand ça ne marche pas. Les fameuses race conditions.
Le bug est très difficile à reproduire souvent.

Te voilà débarrassé !

[Bubu]

De nos jours, même pour faire des graphismes 2D, il vaut mieux utiliser OpenGL ou DirectX.
Des API initialement conçues pour la 3D.

Pourquoi ?

Parce que vous pourrez lisser vos sprites, faire des rotations de sprites, des scaling, et des effets codés dans vos shaders.
Grâce aux shaders, vous pourrez faire des effets de lumière, ou plus simplement coloriser un sprite initialement en niveau de gris selon la couleur voulue.
Vous pourrez faire du normal mapping, et donc appliquer les éclairages de Blinn-Phong par exemple.
Multiplier les effets d'alpha-blending, gérer l'émissif, etc ...

Tout en jouissant de l'accélération matérielle des GPU.

Il faut pour cela désactiver le z-buffer, et utiliser une matrice de projection orthographique.

En général on utilise les Sprite Batches :
On crée à chaque frame des meshes dynamiques où chaque élément est un quad (2 triangles têtes-bêches) avec les bonnes coordonnées uv, qui se référent à la texture atlas. (Qui contient tous les sprites).
Après il suffit de transformer le quad pour faire des rotations et scalings. La coordonnée z (la profondeur) est ignorée.
Et on trace tous ces sprites dans un seul draw-call. Donc on comprend que niveau performance, c'est une tuerie.

Je vous laisse consulter les nombreux tutos sur la question sur le net, et si besoin, demandez moi.

Bonne programmation !

[Bubu]

Suite à ça : l'effet Chamallow :
C'est un scaling non homogène.
Selon une coordonnée du scaling vous appliquez un sinus selon le temps écoulé.
Selon l'autre coordonnée du scaling, vous appliquez ce sinus opposé selon le temps écoulé.
Le sprite garde la même aire tout en se tortillant dans tous les sens !
Et on se retrouve avec un sprite qui gigote tout en gardant la même aire. C'est un effet amusant.
On l'utilise dans notre jeu, pour les pièces dans la grille, mais en hyper discret.
C'est pour ça que ça ne se voit pas dans les screenshots.


Pour être plus rigoureux :

Code : Tout sélectionner

Pseudo code :

Soit le réel : interpolationFactor = 0.5 * (sinus (timeFactor * elapsedTime) + 1) (Donc interpolationFactor varie entre 0 et 1 en suivant une sinusoïde)

scalingX = scalingMin * interpolationFactor  + scalingMax * (1 - interpolationFactor ) 
scalingY = scalingMin  * (1 - interpolationFactor ) + scalingMax * interpolationFactor 

Donc quand scalingX vaut scalingMin, scalingY vaut scalingMax et inversement.
Le sprite s'étire en hauteur en se contractant en largeur, puis s'étire en largeur en se contractant en hauteur.
C'est rigolo.

[Bubu]

Dû au fait qu'il y a 648 niveaux dans notre jeu Sqwap, et que l'erreur est humaine,
Nous avons décidé qu'il nous fallait un logiciel (sur ordi) de test des niveaux.
Je m'y suis mis, j'ai toute la logique du jeu à reproduire (sans les animations, juste des manipulations dans des tableaux). Et c'est fait.
Ah ça me manquait, je m'éclate !
C'est purement algorithmique, pas de graphismes, d'animations, de layout graphiques... Ce qui est hyper répétitif. (Et hyper chiant)
Je vais utiliser le backtracking pour tester toutes les possibilités. En chaînes.
C'est un algorithme récursif assez amusant et simple, et extrêmement puissant.

J'en ai pour quelques jours tout au plus. Le jeu (Android) est en Java, le logiciel (PC) est en Java. Donc il y a pas mal de copier-coller.

Le but :
On charge le fichier de niveaux.
Puis on lance le test.
Le logiciel crée un rapport, où il mentionne les erreurs éventuelles et ses corrections pour chaque niveau, seulement quand il faut.
J'aime bien faire ça.

[Tugdual]

Sur le Club des développeurs :

• Les développeurs nés dans les années 70 auraient commencé à écrire
  leurs premières lignes de code plus tôt que les générations suivantes ...

[Bubu]

En fait c'est pas si simple ....
C'est même sans aucun doute la fonction récursive la plus complexe que j'ai eu à programmer ....
Les fonctions de base du jeu sont faites, et fonctionnent :
Détecter que les pièces de même type se touchent toutes (c'est aussi récursif), faire tomber les pièces quand il y a du vide en dessous d'elles, tourner à droit ou à gauche.... c'est fait, et c'est du gâteau.
Mais alors la fonction qui analyse les possibilités, c'est autre chose.
Dans un niveau, il peut y avoir plusieurs possibilités, de plusieurs coups chacune.
J'avoue j'ai du mal.