Discussion :

[denzi]

Tu as donc deux mois, jour pour jour, pour rendre ton travail : considère que tu es déjà en retard.

Nulle critique dans cette remarque mais sache qu'un Tétris est relativement difficile à mettre au point et qu'en étant totalement novice en assembleur, c'est un projet que tu pourrais à la limite boucler si tu y travaillais sept heures par jour et que tu n'avais rien d'autre à faire à côté. Or, j'imagine que tu as des partiels à préparer et d'autres cours à réviser (peut-être même un job à côté).

Médite déjà sur les les six étapes de la procrastination. Sache qu'elles restent vrai à toutes les étapes de la vie, y compris lorsque l'on reprend des études étant adulte (c'est d'ailleurs étonnant de s'entendre sortir soi-même des excuses de collégien à ce stade…). Tu n'as pas besoin d'écrire les grandes lignes de ton projet, ou de faire un cahier des charges détaillé dans la mesure où tout le monde sait déjà ce qu'est un Tétris et qu'il y en a pléthore sur le Net. La difficulté est de savoir comment le faire. Si globalement tu as une idée de ce à quoi le tout devrait ressembler mais que tu ne sais pas par quoi commencer, c'est que le plus gros reste à faire.

Ne te fixe pas une grande deadline à deux mois pour le projet complet mais plusieurs échéances à court terme pour les différentes étapes de ton projet : par exemple, essaie d'ici mercredi soir d'initialiser le bon mode graphique et de tracer des pixels à l'écran. Si ça marche et que tu es motivé, essaie d'intégrer une image fixe simple directement au code source de ton programme et de la faire afficher par celui-co dans le mode en question.

Ensuite, essaie pour vendredi soir (ou éventuellement pour le vendredi soir suivant selon ton avancement et ta capacité à t'approprier le langage) de dessiner à l'écran les sept pièces manipulées par un Tétris. Il ne s'agit pas de les intégrer au jeu, ni de dessiner tout le décor (cadre, tableau des scores, etc.) mais juste d'écrire un petit programme initialisant le mode graphique et dessinant les pièces à l'écran (avec une temporisation avant de restaurer le mode initial et de revenir au DOS). Rien d'autre.

Essaie déjà de faire ces deux choses-là d'ici la semaine prochaine car tu en auras de toutes façons besoin pour ton programme final. En fonction du temps que tu vas mettre pour réaliser quelque chose qui marche de ce côté-là, tu vas pouvoir estimer ensuite le temps qu'il te faudra pour réaliser l'application entière.

Merci bcp pour ta longue reponse mais je le sais deja et je vous ai donner la dernier deadline mais je men suis fixé a moi meme et bisarement se sont les meme que les tienne plus dautre. apres jai toujours l'aide des assistant du prof mais bon les connaissant ils ont pas toujours le temps de relire ton code. mais je vous dirai ou jen suis et encore merci je ne pensais aps que jallais avoir autemp de reponse sur ce forum

[BufferBob]

je vous ai donner la dernier deadline mais je men suis fixé a moi meme et bisarement se sont les meme que les tienne plus dautre.

c'est une bonne nouvelle, ça veut dire que tu as une petite idée de comment t'y prendre déjà, de là à parler de cahier des charges il n'y a qu'un pas

je ne pensais aps que jallais avoir autemp de reponse sur ce forum

c'est un projet un peu consistant, des bugs et des questions il va y en avoir à coups sûr, vivement qu'on puisse voir du code

[Forthman]

On n'est pas très nombreux ici, mais je pense que nous pouvons être assez réactif si tu as des problèmes précis
n'hésites pas à poster des bouts de code qui posent problème

[denzi]

dans le lien vous trouverer le code pour dessiner le gui pour les block je fini et je lenvoi apres jai fais ca tres vite donc merci de me dire quoi
http://1drv.ms/1GUBQjk

[denzi]

dans le lien vous trouveré aussi le code pour les blocs jai aps encore réussi a colorier l'interieure jai un peux de mal si vous avez une idée je suis preneur

[Forthman]

Hello,

Alors j'ai survolé ton code, et une question m'interroge : pourquoi ne pas utiliser une méthode type "sprites" pour faire tes carrés ?
Ou alors, si tu as des carrés monochrome, pourquoi vouloir tracer des segments ?

Tracer une boite "pleine" est plus simple.
(je ne mets pas de code mais vu ce que tu arrives à faire, ça ne devrait pas t'être trop compliqué )

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
calculer l'adresse vidéo de départ (comme tu as fait, Y*320+X)
 
Boucle hauteur
  sauvegarder largeur de la boite
  sauvegarder adresse vidéo
  Boucle largeur
    mettre couleur à l'adresse vidéo (voir STOS)
   retour boucle largeur
  restaurer largeur de boite
  restaurer adresse vidéo
  ajouter 320 à adresse vidéo
 retour boucle hauteur

Si tu veux afficher un sprite, c'est pratiquement aussi simple, tu as juste une adresse de plus
à gérer, l'adresse des datas du sprite en question.
Tu pourras utiliser un MOVS au lieu du STOS, et avec l'adresse de départ dans DS:SI et l'adresse vidéo dans ESI

ton sprite pourra être codé sous la forme :

Code :

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

1
2
3
4
5
6
7
 
carre_rouge db 5 , 5 ; 5x5 pixels
db 01,01,01,01,01
db 01,40,40,40,01
db 01,40,01,40,01
db 01,40,40,40,01
db 01,01,01,01,01

Par contre, dans ton code "blocs.asm", il y a quelques trucs que je n'ai pas compris :

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
 
 ; Calculate posX
    mov     eax, 7
    neg     eax
    add     eax, [x]
    shr     eax, 1
    mov     ebx, eax    ; posX is in EBX now
 
    ; Calculate posY
    mov     eax, 7
    neg     eax
    add     eax, [y]
    shr     eax, 1      ; and posY is in EAX
 
    ; Calculate offset of top-left corner
    mov     edx, 320
    mul     edx         ; EAX = posY * SCREENW
    add     eax, ebx    ; EAX now conatins start offset of rectangle
    add     eax, 0a0000h
    push    eax         ; store for left vertical line drawing

Pourquoi ajouter -7 en X et en Y ?
pourquoi mettre 7 dans eax et faire un neg alors que tu pourrais mettre -7 directement ?
je ne suis pas sûr que l'adresse 32 bits soit directement exploitable en mode réel (à vérifier quand-même)
(je viens de jeter un oeil sur empty.asm,)
Ok, donc ton point d'origine lors d'un tracé de rectangle est en bas à droite de ce rectange... queston : pourquoi ?
l'origine de l'écran (adresse A000:0000h) est en haut à gauche, pourquoi ne pas tracer des rectangles dont l'origine est en haut à gauche ?

en tout cas, voici un bout de code qui permet de calculer l'adresse de départ vidéo (origine haut-gauche)
(j'ai gardé les même noms et tailles de variables que les tiennes)

Code :

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

1
2
3
4
5
6
7
 
mov eax, [y]    ; eax = position y
mov edx,320
mul edx    ; eax = y*320
mov ebx, [x]
add ebx,eax    ; ebx = adresse video = y*320+x
add ebx,0A0000h

[denzi]

merci de ta reponse
j'utilise pas sprite car jai demander a mon prof il ma dis que je vais arriver dans la misere quand les block se toucherons enfin apres il a pas toujours raison mais j'y ai penser

apres pour le 7 c'est juste pour la largeur d'un carré voila si ta dautre remarque hesite pas

[Forthman]

Peut-être si tu utilises un sprite pour chaque forme de pièce, mais ça ne changera rien si tu gères ça avec la forme de base.

D'ailleurs, comment comptes-tu gérer la zone de jeu ? un tableau de blocs ou autre chose ?

[Bros]

Salut

Tout d'abord j'ai une question qui n'a rien avoir avec ton projet mais tu es dans quelle école belge pour faire un truc pareil ? (du côté néerlandophone j'imagine vu que tu t'excuse pour ton français dans le premier post)

Drôle d'idée le tetris, j'ai également fait il y a quelques années des projets asm pour les cours (chat, jeux etc ...) et pour le jeu, j'avais choisi le pendu, c'était assez fun et je me suis bien amusé a le faire et a le tester

[denzi]

Peut-être si tu utilises un sprite pour chaque forme de pièce, mais ça ne changera rien si tu gères ça avec la forme de base.

D'ailleurs, comment comptes-tu gérer la zone de jeu ? un tableau de blocs ou autre chose ?

jai pas compris la premier partie genre je fais un sprite pour chaque forme ?
et pour le reste j'y ai pas encore pensé j'ai deja gallerer a fair les blocs et le gui

[denzi]

Salut

Tout d'abord j'ai une question qui n'a rien avoir avec ton projet mais tu es dans quelle école belge pour faire un truc pareil ? (du côté néerlandophone j'imagine vu que tu t'excuse pour ton français dans le premier post)

Drôle d'idée le tetris, j'ai également fait il y a quelques années des projets asm pour les cours (chat, jeux etc ...) et pour le jeu, j'avais choisi le pendu, c'était assez fun et je me suis bien amusé a le faire et a le tester

exactement en neerlandophone et pour tetris je pensais pas que cetais aussi compliqué ahahahah donc je me suis mis dans la merde tous seul

[Forthman]

Oui, la gestion des contacts entre blocs sera plus compliquée si tu utilises des sprites reprenant la forme de chaque tétromino.
Mais ça ne changera rien à la difficulté si tu utilises des sprites de 7x7 pixels assemblés par groupes de 4

Je ne pense pas que ton prof ait mesuré la difficulté d'un tel programme (je doute même qu'il soit capable de le réaliser lui-même)
Donc, ton but n'est pas forcément d'écrire un programme qui fonctionne, (ça serait bien quand-même) mais de bien expliquer ta démarche,
et d'expliquer tes choix dans la conception.

[denzi]

voila le code final pour les blocs a mon avi je toucherai plus trop a ca demain si j'aile temp je m'occupe de la rotation des blocs avec le bouton espace

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
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
;=============================================================================
; 32-bit Assembly LES3
;=============================================================================
IDEAL
P386
MODEL FLAT, C
ASSUME cs:_TEXT,ds:FLAT,es:FLAT,fs:FLAT,gs:FLAT
 
;=============================================================================
; CODE
;=============================================================================
CODESEG
 
PROC setVideoMode
    ARG mode RETURNS eax
    mov     eax, [mode]
    int     10h
 
    ret
ENDP setVideoMode
 
PROC waitKey
    mov     eax, 0
    int     16h
 
    ret
ENDP waitKey
 
; Draw a rectangle at the center of the screen.
; W, H passed on stack.
PROC drawBlock1
    ARG  x:dword, y:dword, co:byte				;dword = 4 bytes , word = 2 bytes, byte = 8 bits
    USES eax, ebx, ecx, edx, esi, edi
 
    ; Calculate posX
    mov     eax, 5
    neg     eax
    add     eax, [x]
    shr     eax, 1		; delen door 2
    mov     ebx, eax    ; posX is in EBX now
 
    ; Calculate posY
    mov     eax, 5
    neg     eax
    add     eax, [y]
    shr     eax, 1      ; and posY is in EAX
 
	;eax positie Y, ebx positie X
 
    ; Calculate offset of top-left corner
    mov     edx, 320
    mul     edx         	; EAX = posY * SCREENW
    add     eax, ebx    	; EAX now contains start offset of rectangle
    add     eax, 0a0000h
	push    eax         	; store for left vertical line drawing
 
    mov 	ecx, 5    		; 7x lijn trekken => vierkant gevuld
	mov     edi, eax		; start of second line
@@FillBlock:
 
    push 	ecx
	push 	edx
 
    mov     ecx, 5    				; rect W
    mov     al, [co]	      		; color
    rep     stosb       			; draw,STOSB stores the byte in AL
 
 
	pop 	edx 
	add 	edi,315
	pop		ecx
    dec     ecx
 
    jnz     @@FillBlock
 
	sub     edi, 320
    ; done
    ret
ENDP drawBlock1
 
 
; ================
; Start of program
; ================
PROC main
    sti                 ; set The Interrupt Flag
    cld                 ; clear The Direction Flag
 
    push    ds
    pop     es
 
    call    setVideoMode, 13h
 
    mov     edi, 0a0000h
 
    ; setup colors
    mov     esi, offset pal     ; set the palette (DAC) address
    mov     ecx, 2 * 3          ; set color 0 and 1 (2 indexes in total, 2 * 3 bytes)
    mov     dx, 03c8h           ; VGA DAC set port
    mov     al, 0               ; set start color index
    out     dx, al
    inc     dx
    rep     outsb
 
    ; draw
    ; add     edi, 320*10 + 160
    ;mov     [byte ptr edi], 1
 
	;*********************************IDEE****************************************
 
	;random blokje oproepen => aan de hand van een random generator. getal kiezen tussen 0-6 ( 7 blokjes in totaal)
	; compare number dan jump to @@DrawXshape
 
	; Speed of game
 
	; spatie => roteren van blok
 
	;*********************************IDEE****************************************
 
;*******************************************0 degrees ********************************************
 
	;I-shape
	;@@DrawIshape
    call    drawBlock1, 320,200,1  	; x,y,color
	call    drawBlock1, 332,200,1  	; x,y,color
	call    drawBlock1, 344,200,1  	; x,y,color
	call    drawBlock1, 356,200,1  	; x,y,color
 
	;j-shape
	;@@DrawJshape
	call    drawBlock1, 200,200,2  	; x,y,color
	call    drawBlock1, 212,200,2  	; x,y,color
	call    drawBlock1, 212,212,2  	; x,y,color
	call    drawBlock1, 212,224,2  	; x,y,color
 
	;l-shape
	;@@DrawLshape
	call    drawBlock1, 100,100,3  	; x,y,color
	call    drawBlock1, 100,112,3  	; x,y,color
	call    drawBlock1, 100,124,3  	; x,y,color
	call    drawBlock1, 112,124,3  	; x,y,color
 
	;box
	;@@DrawOshape
	call    drawBlock1, 150,150,4  	; x,y,color
	call    drawBlock1, 150,162,4  	; x,y,color
	call    drawBlock1, 162,150,4  	; x,y,color
	call    drawBlock1, 162,162,4  	; x,y,color
 
	;z-shape
	;@@DrawZshape
	call    drawBlock1, 80,80,5  	; x,y,color
	call    drawBlock1, 68,80,5  	; x,y,color
	call    drawBlock1, 68,68,5  	; x,y,color
	call    drawBlock1, 56,68,5  	; x,y,color
 
	;t-shape
	;@@DrawTshape
	call    drawBlock1, 40,40,6  	; x,y,color
	call    drawBlock1, 40,28,6  	; x,y,color
	call    drawBlock1, 52,28,6  	; x,y,color
	call    drawBlock1, 28,28,6  	; x,y,color
 
	;s-shape
	;@@DrawSshape
	call    drawBlock1, 80,200,7  	; x,y,color
	call    drawBlock1, 92,200,7  	; x,y,color
	call    drawBlock1, 92,188,7  	; x,y,color
	call    drawBlock1, 104,188,7 	; x,y,color
 
 
 
    ; wait
    call    waitKey
    call    setVideoMode, 3h
 
    mov 	eax, 4c00h      ; AH = 4Ch - Exit To DOS
    int 	21h             ; DOS INT 21h
ENDP main
 
;=============================================================================
; DATA
;=============================================================================
DATASEG
 
pal db 0, 0, 0, 63, 63, 63
 
;=============================================================================
; STACK
;=============================================================================
STACK 10000h
 
END main

[Forthman]

Si j'étais toi je laisserais la rotation pour le moment. c'est un peu compliqué lors du test avec les blocs figés.

Je vais jeter un oeil à ton code.

[Forthman]

Alors... je précise que les critiques qui vont suivre sont tout à fait objectives, et qu'il ne faut pas le prendre mal

Code :

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

; Draw a rectangle at the center of the screen.

non, ça ne dessine pas un rectance au centre de l'écran, mais un carré de 5x5 pixels aux coordonnées x/2,y/2
et décalé de -5 pixels en x et -5 pixels en Y

Il faut vraiment que tu m'expliques pourquoi tu procèdes comme ça, car là je ne comprends pas du tout...

Code :

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

1
2
3
4
5
6
;I-shape
	;@@DrawIshape
    call    drawBlock1, 320,200,1  	; x,y,color
	call    drawBlock1, 332,200,1  	; x,y,color
	call    drawBlock1, 344,200,1  	; x,y,color
	call    drawBlock1, 356,200,1  	; x,y,color

Tu ne devrais pas mettre des coordonnées fixe, ça ne sert à rien, tu ne vas pas indiquer toutes les possibilités
de positions des pièces, ça va être très très très, mais alors très long sinon

1ere Modif :

[code];I-shape
;@@DrawIshape
call drawBlock1, 0,0,1 ; offset x,offset y,color
call drawBlock1, 12,0,1 ; offset x,offset y,color
call drawBlock1, 24,0,1 ; offset x,offset y,color
call drawBlock1, 36,0,1 ; offset x,offset y,color

Le fait que l'affichage se fasse en X/2 et Y/2 t'oblige à multiplier par deux les décalages
d'ailleurs, je note que ton décalage entre chaque bloc va faire 6 pixels et non 5 comme indiqué dans ton (superbe) dessin
ton aire de jeu ne va plus faire 50x150 pixels mais 60x180

La chose qui m'embête le plus (et qui va t'embêter à toi aussi plus tard) c'est que tu code directement les positions.
Ce n'est pas la bonne approche.
Il faut faire en sorte d'utiliser plus efficacement les tableaux.

Voici mon raisonnement concernant le codage des formes
(ce n'est qu'une solution, il y en a plein d'autres ) :
- un tétromino est forcément composé de 4 blocs
- la forme qui prend le plus de place est la barre (4 blocs alignés)
- Elle peut-être verticale ou horizontale.
- Donc toutes les formes peuvent être représentées sur une grille de 4x4
(je vais utiliser les balises "code" pour avoir une tabulation correcte)

Code :

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

1
2
3
4
5
 
00 01 02 03
04 05 06 07
08 09 10 11
12 13 14 15

à partir de là, je peux coder chaque tétromino avec 4 valeurs 8 bits (5 si on veut indiquer la couleur)

Code :

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

1
2
3
4
5
6
7
8
9
10
 
i_shape1 db 00,01,02,03,01 ; bloc1,bloc2,bloc3,bloc4,couleur
i_shape2 db 00,04,08,12,01
i_shape3 db 00,01,02,03,01
i_shape4 db 00,04,08,12,01
 
j_shape1 db 00,01,05,09,02 ; bloc1,bloc2,bloc3,bloc4,couleur
j_shape2 db 04,05,06,02,02
j_shape3 db 00,04,08,09,02
j_shape4 db 04,00,01,02,02

voilà, je viens de définir 2 formes (barre droite + "L" inversé) dans toutes les positions possibles

Astuce supplémentaire :
Si on vire la couleur, on a chaque forme qui tient sur 32 bits, il n'est plus nécessaire de donner un nom à chaque rotation,
il suffit d'un seul nom qui regrouperait toutes les positions, et pour aller de l'une à l'autre un décalage de 4 octets suffirait

Enfin, je reviens sur ce que j'avais écrit plus haut :

Code :

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

1
2
    mov     eax, 5
    neg     eax

peut très bien s'écrire :

Code :

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

    mov     eax, -5

(ou alors j'ai raté quelque chose

[Forthman]

Je crois que les tétrominos sont en vacance...
Il en est où ce projet ?

[Mat.M]

Pour un de mes cours a la fac je dois crée un jeu en assembleur j'ai choissi de crée tetris mais je ne sais pas du tous par quoi commencer ou qu'elle sont les etape que je dois suivre pouriez vous maider?

c'est un bon exercice et je trouve que la vision des intervenants est trop compliquée ( certains nous parlent de procrastination.. ) ça confirme ce que j'ai toujours pensé en France on aime bien faire compliqué quand on peut faire simple...
parenthèse ferméee, ceci dit faire un tetris en assembleur c'est certain c'est pas facile même en C je me suis déjà cassé les dents là-dessus.
Donc comme il a été mentionné avant essayer de trouver un source en langage C et l'adapter en assembleur.
Ensuite tu peux dépasser le VGA en 320*200 en permutant en mode VESA mais je ne sais pas s'il est toujours bien supporté par les cartes récentes..à confirmer
Mais ça c'est en dernier lieu le plus important c'est le coté conception et algorithme.
Sinon une astuce pour calculer l'offset de mémoire écran qui consiste à multiplier par 320 ou bien la résolution en X plus la colonne c'est de faire un décalage à droite avec ROR ou autre instruction de décalage...
sinon oui comme l'écrit Forthman on n'utilise pas de coordonnées en dur...

[Obsidian]

Bonjour,

c'est un bon exercice et je trouve que la vision des intervenants est trop compliquée ( certains nous parlent de procrastination.. ) ça confirme ce que j'ai toujours pensé en France on aime bien faire compliqué quand on peut faire simple...

Je ne vois pas le rapport entre la procrastination (que j'ai évoquée) et la vision « trop compliquée » des intervenants…

parenthèse ferméee, ceci dit faire un tetris en assembleur c'est certain c'est pas facile même en C je me suis déjà cassé les dents là-dessus.

C'est surtout cela qui nous inquiète : un Tétris, ça a l'air facile mais ça ne l'est pas du tout. Ce serait effectivement un bon exercice si le primo-postant souhaitait apprendre seul, sur son temps libre, et qu'il n'avait pas d'échéance pour y parvenir (même partiellement). Mais là, il s'agit d'un projet scolaire à rendre propre du premier coup, entièrement terminé, et sans le moindre retard, faute de quoi il sera lourdement pénalisé même si le travail qu'il a effectué jusqu'alors est de très bonne qualité.

Donc comme il a été mentionné avant essayer de trouver un source en langage C et l'adapter en assembleur.
Ensuite tu peux dépasser le VGA en 320*200 en permutant en mode VESA mais je ne sais pas s'il est toujours bien supporté par les cartes récentes..à confirmer

Il peut mais comme tu le précises, ça n'a aucun avantage immédiat : il va falloir qu'il bataille entre les différents modes pris en charge, alors que le mode 13h est non seulement disponible sur toutes les plateformes type DOS, mais surtout correspond à « 1 octet = 1 pixel », avec une palette de couleur assez riche (256 couleurs à choisir à sa convenance). C'est le mode graphique le plus facile à utiliser qui soit.

Mais ça c'est en dernier lieu le plus important c'est le coté conception et algorithme.
Sinon une astuce pour calculer l'offset de mémoire écran qui consiste à multiplier par 320 ou bien la résolution en X plus la colonne c'est de faire un décalage à droite avec ROR ou autre instruction de décalage...
sinon oui comme l'écrit Forthman on n'utilise pas de coordonnées en dur...

Si tu veux multiplier (par une puissance de 2), il faut décaler vers la gauche et non vers la droite.

À part cela, puisque tu parles de conception et d'algorithme, mettons le doigt sur la fonctionnalité la plus importante et la plus difficile du Tétris : la rotation des pièces.

• Autour de quel centre les pièces doivent-elles pivoter ?
• Dans le cas de la barre verticale ou horizontale, par exemple, serait-ce le centre de la barre elle-même ou une de ses extrémités ?
• Une pièce qui pivote et qui devient plus haute que large doit-elle occuper — ou non — une ou plusieurs lignes de plus vers le bas ?
• Comment faire pivoter une pièce lorsqu'elle se trouve collée au bord gauche ou droite de la scène de jeu ?

Et surtout :

• Quelle politique adopter lorsqu'elle s'approche du bas du jeu, où sont déjà empilées plusieurs pièces et où le terrain est accidenté ? Spécialement quand il s'agit d'aller glisser une pièce « sous » une autre au dernier moment ?

[chrtophe]

Le post d'origine ne parle pas de mode texte ou graphique. Comme c'est un projet qui peut ne pas aboutir par manque de temps, je commencerais par faire une version en mode texte monochrome, qui sera ensuite amélioré en mode graphique, la structure algorithmique étant la même, c'est le "dessin" de cette algorithmie que changera.

Je commencerais par créer un tableau ligne colonnes avec par exemple "." représentant une "case" vide, et "*'" une case occupée. Ensuite je représente chaque pièce par un rectangle virtuel (représenté par un tableau) dans lequel j'utilise le même principe case vide et case occupée pour représenter la forme. Tu dois donc tenir à jour une liste des pièces en mouvement sur "l'échiquier". Une pièce bloquée est sortie de cette liste. La liste doit comporter au moins :

- le type de pièce (pour en déduire sa forme)
- sa position (exemple x,y du rectangle haut gauche occupée par celui-ci, la position de tous les éléments de ce rectangle virtuel en étant donc déductible).

A chaque tour, chaque pièce descend si elle le peut. Après chaque déplacement, il faut vérifier si celui-ci a remplit une ligne et dans ce cas décaler tout le contenu du tableau vers le bas. Ensuite une nouvelle pièce arrive (voir si c'est aléatoire ou prédéfini). Chaque tour est séparé d'une temporisation.

Il te faut ensuite gérer le déplacement latéral manuel des pièces vers la gauche ou la droite, c'est le même principe. Puis enfin le retournement des pièces, encore une fois le même principe. Chaque tour s'effectue après un délai (utiliser les fonctions DOS pour gérer cela).

Ensuite la gestion des niveaux : Le changement de niveau s'effectue après "l'effacement" d'un certain nombre de ligne. Le changement de niveau signifie en général une accélération du tour (changement de temporisation), un nombre accru de ligne à effacer, des pièces plus complexes. Mais a ce stade, si tu as bien géré le truc, c'est pas beaucoup de travail en plus.

Il te suffit d'afficher le tableau pour avoir un résultat visuel. C'est pas optimal mais a ce niveau c'est un prototype fonctionnel.

Le mode graphique :

A ce stade, tu vas générer ton image de la façon suivante :

Tu vas te mettre dans un mode graphique ou 1 pixel=1 octet en mémoire. De la pour l'affichage tu considère qu'un élément de ton tableau prend par exemple 5 pixels tu dessine 5 pixels sur 5 lignes. Le nombre de pixel devant être proportionnel à la résolution et au nombre de lignes colonnes

Ensuite rajoutes de la couleur (dans la liste des pièces il te faut aussi gérer cela).

Si tu as encore du temps, tu peux optimiser le redessin de l'image pour gagner du temps, mais si tu as un processeur rapide, c'est pas forcément utile (mais ça te vaudra des points en plus).


Tu reconstruis l'image après chaque tour et tu l'a ré-affiche. Tu vas utiliser pour cela les fonctions de double-buffering : tu dessines dans la plage mémoire video 2 pendant que la plage video 1 est en cours d'affichage, une fois ton dessin prêt tu dis à la carte video d'afficher la plage video 2, et vice-versa.

Toutes les différentes fonctions devront correspondre a des routines appelées.

[BufferBob]

si on considère que le propos est de faire vite et donc aller au plus simple, on écartera la notion de pixel pour envisager plutôt un rendu en mode texte, avec des couleurs ça dérange pas, ça pourrait ressembler à quelque chose de très épuré dans ce style par exemple :



d'accord avec Obsidian sur l'idée de dire que la partie la plus compliquée concerne la rotation des pièces, peut-être qu'une piste à explorer serait de considérer (toujours en mode texte) qu'on manipule des matrices de 4x4 caractères, le centre de rotation est déterminé à l'avance, arbitrairement, un truc du genre :

Code :

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

1
2
3
4
0,0,0,0      0,0,1,0      0,0,0,0      0,0,0,0
1,1,1,0      0,0,1,0      0,1,0,0      0,1,1,0
0,0,1,0      0,1,1,0      0,1,1,1      0,1,0,0
0,0,0,0      0,0,0,0      0,0,0,0      0,1,0,0

partant de là, il y aurait 2 points importants à gérer

• d'une part les collisions, quand un bout de la pièce se retrouve dans un bout de mur, mais c'est assez simple à gérer, il suffit de décaler la pièce à gauche ou à droite selon le cas, et si la collision arrive par en dessous, ben on la stoppe et une nouvelle pièce apparait par le haut
• l'organisation en mémoire de ces matrices/leur référencement, qui aura tout intérêt à être un peu intelligente de manière à gagner à la fois en lisibilité ET en efficacité (des branchements du style mov ax, word ptr [si + cx * 4] avec SI qui désigne l'adresse de base de la pièce et CX son orientation par exemple)