Discussion :

[hbx360]

Bonsoir, j'ai récupéré les sources du jeu Arkanoïd fait par C1702 : Clément CORDE (merci a lui pour avoir partagé sont travail) sur son site.
Dans les sources du jeu il y a une feuille de sprite et je me suis basé sur cette feuille de sprite pour en créer une. Voici celle de C1702 (je ne sais pas si j'ai le droit de mettre sa feuille de sprite à l'écran si c'était le cas j'en suis désolé je l'enlèverais ) :



et voici la mienne :





Mon problème c'est que je n'ai pas bien compris la façon don il récupère les coordonnées de chaque image j'ai bien regarder le fichier sprites.c et sprites.h mais je n'arrive pas à comprendre comment il arrive a récupérer les position x, y w, et h de l'image apparemment il fait une boucle sur le sprite puis puis quand il trouve une image il met les coordonnées de celle-ci dans un tableau.
C'est la détection de l'image dans le sprite qui me pose problème comment fait-il ?

Voici le code de C1702 que je ne comprends pas bien (idem je ne sais pas si j'ai le droit de mettre une partie de son code à l'écran si c'était le cas j'en suis désolé je l'enlèverais) :

Source sur son site : http://oldschoolprg.x10.mx/projets.php
Le sprites.c

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
 
 
#define	SPR_MAX_NB	2048
struct SSprite	pSpr[SPR_MAX_NB];
u32	gnSprNbSprites;		// Nb de sprites capturés.
 
 
// Pour tri des sprites à chaque frame.
struct SSprStockage
{
	u32 nSprNo;
	s32 nPosX, nPosY;
	u32 nPrio;
 
};
#define	SPR_STO_MAX	512
struct SSprStockage	gpSprSto[SPR_STO_MAX];
struct SSprStockage	*gpSprSort[SPR_STO_MAX];	// Pour tri.
u32	gnSprSto;			// Nb de sprites stockés pour affichage.
 
 
// Initialisation du moteur.
void SprInitEngine(void)
{
	gnSprNbSprites = 0;	// Nb de sprites capturés.
	gnSprSto = 0;		// Nb de sprites stockés pour affichage.
 
}
 
// Nettoyage.
void SprRelease(void)
{
	u32	i;
 
	for (i = 0; i < gnSprNbSprites; i++)
	{
		free(pSpr[i].pGfx);
	}
}
 
// Récupération des sprites d'une planche.
// In: pSprPal == NULL, on ne sauvegarde pas la palette.
//     pSprPal != NULL, on sauvegarde la palette de nPalIdx à 256.
void SprLoadBMP(char *pFilename, SDL_Color *pSprPal, u32 nPalIdx)
{
	SDL_Surface	*pPlanche;
	u32	nNbSprPlanche = 0;
 
	// Lecture du BMP.
	pPlanche = SDL_LoadBMP(pFilename);
	if (pPlanche == NULL) {
		fprintf(stderr, "Couldn't load picture: %s\n", SDL_GetError());
		exit(1);
	}
 
	// Sauvegarde la palette ?
	if (pSprPal != NULL)
	{
		SDL_Color	*pSrcPal = pPlanche->format->palette->colors;
		u32	i;
 
		for (i = nPalIdx; i < 256; i++)
		{
			pSprPal[i - nPalIdx] = pSrcPal[i];
		}
	}
 
	// On parcourt la planche pour en extraire les sprites.
	u32	ix, iy;
	u8	*pPix = (u8 *)pPlanche->pixels;
#ifdef	DISPLAY_INFO
printf("w = %d / h = %d\n", pPlanche->w, pPlanche->h);
#endif
	for (iy = 0; iy < (u32)pPlanche->h; iy++)
	{
		for (ix = 0; ix < (u32)pPlanche->w; ix++)
		{
			// On tombe sur un sprite ?
			if (*(pPix + (iy * pPlanche->pitch) + ix) == 0)
			{
				// On a encore de la place ?
				if (gnSprNbSprites >= SPR_MAX_NB)
				{
					printf("Spr: No more sprites slots available.\n");
					SprRelease();
					exit(1);
					// Fainéantise, on peut faire un système de realloc tous les x sprites.
				}
#ifdef	DISPLAY_INFO
printf("sprite at (%d, %d)\n", (int)ix, (int)iy);
#endif
				u32	LgExt, HtExt;
				u32	PtRefX, PtRefY;		// Pts de ref.
				u32	ii, ij, ik;
 
				// Recherche des largeurs extérieures (cadre de 1 pixel). + Pts de ref.
				PtRefX = 0;
				LgExt = 1;
				ii = ix + 1;
				while(*(pPix + (iy * pPlanche->pitch) + ii) == 0 || *(pPix + (iy * pPlanche->pitch) + ii + 1) == 0)
				{
					if (*(pPix + (iy * pPlanche->pitch) + ii) != 0) PtRefX = LgExt - 1;
					ii++;
					LgExt++;
				}
 
				PtRefY = 0;
				HtExt = 1;
				ii = iy + 1;
				while(*(pPix + (ii * pPlanche->pitch) + ix) == 0 || *(pPix + ((ii + 1) * pPlanche->pitch) + ix) == 0)
				{
					if (*(pPix + (ii * pPlanche->pitch) + ix) != 0) PtRefY = HtExt - 1;
					ii++;
					HtExt++;
				}
#ifdef	DISPLAY_INFO
printf("lg ext = %d / ht ext = %d / ref (%d, %d)\n", (int)LgExt, (int)HtExt, (int)PtRefX, (int)PtRefY);
#endif
				// Stockage des valeurs.
				pSpr[gnSprNbSprites].nPtRefX = PtRefX;
				pSpr[gnSprNbSprites].nPtRefY = PtRefY;
				pSpr[gnSprNbSprites].nLg = LgExt - 2;
				pSpr[gnSprNbSprites].nHt = HtExt - 2;
				// Avec un seul malloc (taille gfx + taille masque).
				pSpr[gnSprNbSprites].pGfx = (u8 *)malloc(pSpr[gnSprNbSprites].nLg * pSpr[gnSprNbSprites].nHt * 2);
				if (pSpr[gnSprNbSprites].pGfx == NULL)
				{
					printf("Spr: malloc failed.\n");
					SprRelease();
					exit(1);
				}
				pSpr[gnSprNbSprites].pMask = pSpr[gnSprNbSprites].pGfx + (pSpr[gnSprNbSprites].nLg * pSpr[gnSprNbSprites].nHt);
 
				// Récupération du sprite + génération du masque.
				ik = 0;
				for (ij = 0; ij < HtExt - 2; ij++)
				{
					for (ii = 0; ii < LgExt - 2; ii++)
					{
						pSpr[gnSprNbSprites].pGfx[ik] = *(pPix + ((iy + ij + 1) * pPlanche->pitch) + (ix + ii + 1));
						pSpr[gnSprNbSprites].pMask[ik] = (pSpr[gnSprNbSprites].pGfx[ik] ? 0 : 255);
						ik++;
					}
				}
 
				// Effacement du sprite dans la planche originale.
				for (ij = 0; ij < HtExt; ij++)
				{
					for (ii = 0; ii < LgExt; ii++)
					{
						*(pPix + ((iy + ij) * pPlanche->pitch) + (ix + ii)) = 255;
					}
				}
 
				// Terminé.
				nNbSprPlanche++;
				gnSprNbSprites++;
 
			}
 
		}
	}

et une partie du sprites.h :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
 
 
#define	SPR_Flag_Shadow		(1 << 31)
 
 
// Structures.
struct SSprite
{
	u32	nPtRefX, nPtRefY;	// Points de ref.
	u32	nLg, nHt;			// Largeur et hauteur du sprite.
	u8	*pGfx;
	u8	*pMask;
 
};

Je souhaitais aussi savoir si il y avait d'autres façon de récupérer les coordonnées des images d'un sprite par exemple en mettant directement les coordonnées des images a la main dans le programme ou bien en utilisant une fonction qui récupère automatiquement toutes les coordonnées.

Merci par avance.

[Kannagi]

Que cela devient pas une habitude de nous filer du code pour nous dire ce qu'il fait...
Grosso modo son code fait qu'il lit chaque pixel (j'imagine non bleu/alpha) et puis il regarde a droite et a gauche les pixels et ensuite il efface et il enregistre dans un tableau.
ça marcherai pas avec n'importe quel feuille de spirit , si la feuille de sprite ne possède pas de 'rectangle' les délimitants , cette technique ne fonctionne pas.

Je souhaitais aussi savoir si il y avait d'autres façon de récupérer les coordonnées des images d'un sprite par exemple en mettant directement les coordonnées des images a la main dans le programme ou bien en utilisant une fonction qui récupère automatiquement toutes les coordonnées.

Tu n'as qu'a la coder
Plus sérieusement ton souci n'a rien a voir avec la SDL , en gros t'es en train de nous dire que t'es fainéant et que tu veux un truc tout fait pour ta feuille de spirit , si un logiciel peut s’amuser a séparer chaque sprite (et tu peux le coder) , cette technique aura ces limites si ton sprite et en deux ou plusieurs parties.

[hbx360]

Merci Kannagi pour ta réponse qui ma éclairé.

J'ai du mal a comprendre cette ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (*(pPix + (iy * pPlanche->pitch) + ix) == 0)

La couleur de fond du sprite est bleu donc : 0 0 255 le cadre en rose fait 255 0 255.
Dans le code ci-dessus ce que je ne comprends pas c'est comment la condition va faire la différence entre le 0 de la couleur bleu et celle du 0 du rose, puisque cette ligne de code lit octet par octet donc si on est sur un pixel bleu la condition lit le premier octet du pixel bleu et il tombe effectivement sur un octet de valeur 0 non ? Donc la condition est rempli alors que c'est faux puisque c'est un pixel bleu je pige pas ?

Est-ce que ce n'est pas trop lourdingue de récupérer toutes les coordonnées de toutes les images de cette façon ?
Y a t-il d'autres technique pour récupérer les coordonnées d'une image dans un sprite ?
Quel technique emploi les professionnelles ?

Kannagi sache que, en aucun cas je suis un fainéant je voulais simplement demander de l'aide car j'avais du mal a comprendre son code et que je ne connaissais pas cette technique pour récupérer les coordonnées d'une image et ce n'est pas du tout dans ma mentalité de demander un code tous fait ; je préfère le coder moi même ce qui est plus passionnant et instructif.

Tu as très mal interprétez mes propos c'est dommage mais merci pour ta réponse car tu confirme ce que je pensais.

Que cela devient pas une habitude de nous filer du code pour nous dire ce qu'il fait...

Si ma manière d'avoir présenté la chose ta blesser en tous cas ce n 'était pas dans mon intention ; il est souvent difficile je trouve, de savoir comment aborder les questions ou le sujet à poster.

PS. : si je suis dans la mauvaise section désolé.

[Kannagi]

Merci Kannagi pour ta réponse qui ma éclairé.

J'ai du mal a comprendre cette ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (*(pPix + (iy * pPlanche->pitch) + ix) == 0)

La couleur de fond du sprite est bleu donc : 0 0 255 le cadre en rose fait 255 0 255.
Dans le code ci-dessus ce que je ne comprends pas c'est comment la condition va faire la différence entre le 0 de la couleur bleu et celle du 0 du rose, puisque cette ligne de code lit octet par octet donc si on est sur un pixel bleu la condition lit le premier octet du pixel bleu et il tombe effectivement sur un octet de valeur 0 non ? Donc la condition est rempli alors que c'est faux puisque c'est un pixel bleu je pige pas ?

Parce qu'il lit pixel par pixel et non octet par octet , pPlanche->pitch c'est la largeur de l'image en octet donc on faisant pPlanche->pitch tu tombe sur le pixel en bas

Est-ce que ce n'est pas trop lourdingue de récupérer toutes les coordonnées de toutes les images de cette façon ?
Y a t-il d'autres technique pour récupérer les coordonnées d'une image dans un sprite ?
Quel technique emploi les professionnelles ?

Sur un PC pendant le chargement c'est pas un souci.
En pro sache que en 2D( je parle pour les plateforme android/IOS) on lisait un fichier XML qui posséder tout les rectangles + info sur la vitesse d'anim , le fichier xml ne se faisait pas a la main par contre je me souviens plus du nom du logiciel mais je sais qu'il était payant.
si tu parle des jeux 8/16 bits (nes , Super nintendo , Master system/mega drive ect) la question ne se pose plus et je t'ai deja répondu comment il faisait , des anim tout en 16x16 ou 32x32.
un exemple d'un sprite Super Nes :

Je me répète mais de plus l'avantage de cette technique c'est que tu n'as pas besoin d’éditeur , ou de faire un code en surplus pour le gerer.

Sur la génération PS1 les texture sont limité a 128x128 et/ou PS2 les texture sont limité a 256x256.
Donc sur ces console une feuille de spirit de cette taille est pas possible sauf si on la mettait en RAM mais cela prendrai trop de place , d'ou une compression (pas en RVB ou RVBA mais avec palette) comme je te l'ai deja dite (tout en bloc) était souvent de mise.
Je pense même que certain jeu PS1 en 2D utilise une compression du type 4bpp (4 bit par pixel) , vu que j'avais remarqué que certain sprite était limité en 16 couleurs ( ce qui semble assez étrange sur PS1 avec ces 16M de couleurs disponible).

Kannagi sache que, en aucun cas je suis un fainéant je voulais simplement demander de l'aide car j'avais du mal a comprendre son code et que je ne connaissais pas cette technique pour récupérer les coordonnées d'une image et ce n'est pas du tout dans ma mentalité de demander un code tous fait ; je préfère le coder moi même ce qui est plus passionnant et instructif.

Tu as très mal interprétez mes propos c'est dommage mais merci pour ta réponse car tu confirme ce que je pensais.

Si ma manière d'avoir présenté la chose ta blesser en tous cas ce n 'était pas dans mon intention ; il est souvent difficile je trouve, de savoir comment aborder les questions ou le sujet à poster.

PS. : si je suis dans la mauvaise section désolé.

Je t'ai mis tout de même +1 pour avoir bien répondu et avec calme , mais sache que je ne prend pas trop de gant en général.
Et je vais être plus honnête , j'ai jamais vu un débutant sur cette section revenir en nous montrons ce qu'il a appris ici , en général je pense qu'il abandonne le C et la SDL après quelque essaie infructueux
De plus on avait répondu a ta question sur gérer les feuille de spirit et il y a en général pas de méthode miracle donc je trouvait ton post un peu redondant.

[hbx360]

Merci beaucoup kannagi d'avoir pris le temps de me répondre c'est bien sympa.

Désolé mais j'ai pas compris cette phrase :

Et je vais être plus honnête , j'ai jamais vu un débutant sur cette section revenir en nous montrons ce qu'il a appris ici

Je ne vois pas ou je reviens en montrant ce que j'ai appris ici ???
C'est pas dans mon habitude de fanfaronner et je vois pas l'interet de faire ça.

en général je pense qu'il abandonne le C et la SDL après quelque essaie infructueux

Non j'abandonnerais pas le C et je vois pas pourquoi je le ferai, je ne suis pas à l'université et je pense que chercher a comprendre et a savoir comment faire les choses c'est plutôt bien et surtout que internet c'est pas l'université sinon quel intéret y aurait-il a aller a l'université ? Donc internet ne vaudra jamais l'université pour apprendre sa c'est sûr !

De plus chacun a ces propre capacité de compréhension et si on doit arrêté de faire quelque chose sous prétexte que l'on comprends pas bien et que l'on redemande alors on ne ferai plus rien être persévérant et ne pas se décourager c'est très important.

Ce que je reproche souvent a internet dans l'apprentissage amateur de la programmation c'est le manque de clarté dans les tuto cherche un tuto claire bien expliquer tu n'en trouve pas comme ça c'est d'ailleurs assez rare.

Désolé mais je pense que ta phrase est complétement idiote.
Après tous je suis amateur je ne cherche pas a en faire mon métier.

[Kannagi]

Je ne vois pas ou je reviens en montrant ce que j'ai appris ici ???
C'est pas dans mon habitude de fanfaronner et je vois pas l'interet de faire ça.

Peut être que la phrase est mal tourné mais j'imagine que si quelqu'un fait un jeu , il voudra le présenter et il y a une section projet ici

[CodeurPlusPlus]

(...)

Ce que je reproche souvent a internet dans l'apprentissage amateur de la programmation c'est le manque de clarté dans les tuto cherche un tuto claire bien expliquer tu n'en trouve pas comme ça c'est d'ailleurs assez rare.
(...)

Tu as tort. Si tu suivais un enseignement à l'Université, tu penserais la même chose au centuple, et tu aurais tort au centuple.

C'est bien ton erreur de penser de la sorte, et cela explique pourquoi tu n'avances pas malgré tout le temps que tu as déjà consacré à la programmation.

Quand tu ne comprends pas quelque chose, tu as le réflexe de dire "je ne comprends pas donc c'est mal expliqué".

C'est comme si je disais "j'ai bien compris donc c'est bien expliqué". Ces deux affirmations ne sont ni toujours vraies ni toujours fausses.

La vérité c'est qu'on ne peut mesurer objectivement la clarté et l'intérêt d'une pédagogie que lorsqu'on maîtrise déjà ce dont elle traite. Quand tu seras un bon programmeur, tu pourras aller relire et / ou réécouter tous les tutoriels que tu auras essayé de comprendre auparavant... et tu pourras déterminer lesquels sont clairs et lesquels ne le sont pas.

Mais tant que tu ne comprends pas suffisamment ce que tu lis / écoutes, tu ne pourras pas juger. Si tu ne comprends pas tel tutoriel, comment savoir dans quelle mesure est-ce de la faute de son auteur et / ou de la tienne ? Tant que tu es encore en position d'apprenti, tu ne peux pas en juger.

Moi qui suis souvent en position de juger, voire de juge (dans mon métier), je trouve que le manque de clarté est le défaut qu'on trouve le moins souvent dans les tutoriels...

Je me souviens d'une question que tu avais posée sur ces mêmes forums... un des premiers intervenants qui t'avait répondu avait pris le temps d'écrire une super réponse : il te donnait vraiment toutes les clés mais aucunement la façon de les comprendre ou de les faire fonctionner ensemble pour arriver au résultat... bref, il t'apportait une véritable aide mais sans te prendre pour un neuneu à qui il faut tout expliquer.

Tu lui avais répondu d'un lapidaire : "Désolé mais je ne comprends pas."

L'auteur de la réponse avait dû mettre une bonne heure à la rédiger.

Si j'avais été à sa place, à "Désolé mais je ne comprends pas", j'aurais répondu : "C'est ton problème."