Bonne pratique pour coder un Jeux

Version imprimable

26/03/2018, 13h59
greg006

1 pièce(s) jointe(s)

Bonne pratique pour coder un Jeux

Bonjour,
J'ai découvert le monde de l'Arduino et du C il y a un an et demi, je m’éclate.
Je suis partie de 0, je me forme à l'aide des Mooc et des forum, dans un but uniquement plaisir.

J'ai conçu une console de jeux et programmé des jeux comme space invaders et pac-man.
Pièce jointe 364452
J'utilise un écran Oled d'adafruit.

Je souhaite me lancer dans la programmation d'un jeux style Zelda et j'ai besoin de vous !

Le principe du jeu, pour simuler le déplacement du personnage, le personne reste au centre de l’écran et c'est le décors qui bouge.
Je saurais programmer ça, en faisant évoluer les coordonnées des différents éléments du décors à chaque déplacement.

Ma question, n'existe-t-il pas un moyen de déplacer les coordonnées origine de l’écran pour éviter de recalculer tout le décors à chaque déplacement ?

Merci.

J’espère avoir été clair ;)
26/03/2018, 14h12
Médinoc
Généralement, les consoles ont des puces graphiques spécialisées pour ce genre de trucs (tile engine, scrolling, sprites). Sinon, tu constateras que sur les premiers Zelda sur NES et GameBoy, chaque "salle" fait juste la taille de l'écran: Seules les transitions montrent du scrolling.

Et à cette échelle, le scrolling peut être fait avec un memmove() correctement calculé, pour déplacer les données de la mémoire écran d'une certaine quantité par frame:
- 16 pixels vers la gauche,
- 16 pixels vers la droite,
- (taille de ligne)*16 pixels vers la gauche --> 16 pixels vers le haut,
- (taille de ligne)*16 pixels vers la droite--> 16 pixels vers le bas.
26/03/2018, 21h51
greg006

Salut

Merci pour ta réponse, je découvre la fonction scroll.
J'utilise la bibliothèque Adafruit_SSD1306.h.
Et il y a la commande

Code:

display.startscrollright(0x00, 0x0F)

Ça répond "presque a mon problème".

Presque, car quand je scroll une image (de mon cas la map du jeux de taille 256x256, mon écran fait 128x64), des que l image sort du bord supérieur, elle ré-apparait au bord inférieure.

T'aurais un conseil ?
J'en profite tu sais ce que veut dire (0x00, 0x0F), j'imagine que c'est la vitesse du scroll !
26/03/2018, 21h57
Kannagi

Citation:

Envoyé par greg006

Presque, car quand je scroll une image (de mon cas la map du jeux de taille 256x256, mon écran fait 128x64), des que l image sort du bord supérieur, elle ré-apparait au bord inférieure.

T'aurais un conseil ?

C'est un soucis que tu pouvais avoir sur Nes , SNES aussi.
Il faut codé tout simplement la position des sprites sur 2 octet , et n'affichait que si le sprite se trouve dans la caméra.

Mais comme l'a dit Médinoc , les vielles consoles avait quelque accélération hardware pour les Sprites/Background , dans ton cas faudra commencé par recodé certaine chose basique comme a l'époque de l'Atari ST par exemple :p
Je dis cela parce que si ton code pour les sprites/Background est mauvais , tu vas devoir faire une sacré gymnastique pour pouvoir faire des choses basiques !
(je note n’empêche que la Neo Geo ne possède pas de background hardware , les Background sont des sprites géants !).
27/03/2018, 06h30
Médinoc

C'est très simple, tu scrolles puis tu redessines la ligne en question! (et just celle-ci)
27/03/2018, 08h56
greg006

Merci pour votre support

Grasse a vos messages je suis tombé sur Tile Mapping

Ca a l'air de bien correspondre !
27/03/2018, 09h27
Kannagi

Certe mais c'est aussi très orienté PC , et les méthodes de compression ne sont pas expliqué !

Sur le tile , le numéro indique seulement ID du tile.
Moi je te conseille sur Arduino (et donc avec une petite ROM) , d'organiser ton tile de cette façon (en binaire) :
HVII IIII
H : Flip horizontal
V : Flip Vertical
I : pour le ID
(Il est d'ailleurs très facile de faire une compression RLE , mais cela demande d'avoir de la RAM conséquente pour stocker la map).
Si la RAM n'est pas conséquente (ce qui peut arriver) , je me souviens d'avoir mis sur papier une technique de compression et de mettre les tileset par bloc de 4 (en 16x16 pour éviter trop de donné).

Néanmoins si tu affiche des couleurs sur ta console , alors il faut oublier le RGB et passer sur du 4bpp (4 bits per pixel).
Et donc indiquer sur chaque tile la palette (sauf si tout tes tiles sont sur une même palette).

Pour le scrolling , a l'époque pour qu'il soit optimisé , on ne changeait que celui en bordure comme le dit Médinoc soit tu modifie que la ligne ou la colonne (alors que je vois sur les codes exemple montré une modification de l'ensemble) de plus son code utilise pas mal de division , division qui un n'existait pas a l'époque (sauf sur Mega drive et éventuellement sur SNES mais en tant qu'accélération matériel) mais son taux de cycle étant tellement énorme qu'il était plus judicieux d'utiliser un décalage binaire , et donc de ne faire que des maps ayant une puissance de 2. ;)
27/03/2018, 09h47
Médinoc

De nos jours, si on utilise des variables non-signées, un compilo optimisera tout seul les divisions en décalages de bits.

Citation:

c'est aussi très orienté PC

D'un autre côté, si la "console" de greg006 fait tout logiciellement, ça vaut peut-être mieux ainsi: Pas de considérations du genre "X sprites à 3/15/255 couleurs + transparence", etc.
27/03/2018, 10h03
Kannagi

Citation:

Envoyé par Médinoc

D'un autre côté, si la "console" de greg006 fait tout logiciellement, ça vaut peut-être mieux ainsi: Pas de considérations du genre "X sprites à 3/15/255 couleurs + transparence", etc.

Je parle dans le sens qu'il ne se base pas sur une quelconque contrainte technique (principalement celle de la ROM , RAM et du CPU).
Atmega c'est assez puissant certes , mais quand on fait tout en sotftware , il est bon de ne pas trop fatiguer le CPU sur tout cela !

D'ailleurs on peut faire des sprites software sur les vielles machines ,tu imagine que le souci était juste le CPU.
Par contre "Pas de considérations du genre "3/15/255 couleurs " pour les 15/255 couleurs c'est une contrainte technique qui a existé pour les textures jusqu'a la PS2 !
Donc si Square Enix faisait leur jeux avec une contrainte de palette , pour Final Fantasy X , Kingdom Hearts , Dragon Quest etc , sur une machine possédant 1 processeur principal et 2 coprocesseur avec une puissance de 6 GFLOPS , je doute que ce pauvre Atmega avec moins peut se passer de ce genre d'astuce ;)
(La PS2 permettait de faire du RGB 32 bits , oui 32 bits vu que c'était pour l'alignement ! ).

On gros je ne prendrai pas l’exemple de ce tuto si je devais tout faire en software (comme sur Atari St par exemple ).

Pour la division je suis d'accord , mais faudrait juste éviter des écritures de ce type c = a/b; (dans ce cas là le compilo n'est pas devin et ne sait pas forcément ce qui se trouve dans b) , comme si on écrirait c =a/3 par exemple , bref avoir une map par puissance de deux me semble complètement nécessaire :)

Merci a tous

Désolé, mais je suis vraiment debutant, j'ai du mal a suivre vos explications sur :

Citation:

Certe mais c'est aussi très orienté PC , et les méthodes de compression ne sont pas expliqué !

Sur le tile , le numéro indique seulement ID du tile.
Moi je te conseille sur Arduino (et donc avec une petite ROM) , d'organiser ton tile de cette façon (en binaire) :
HVII IIII
H : Flip horizontal
V : Flip Vertical
I : pour le ID
(Il est d'ailleurs très facile de faire une compression RLE , mais cela demande d'avoir de la RAM conséquente pour stocker la map).
Si la RAM n'est pas conséquente (ce qui peut arriver) , je me souviens d'avoir mis sur papier une technique de compression et de mettre les tileset par bloc de 4 (en 16x16 pour éviter trop de donné).
....

T'aurais pas un exemple, ou un lien, pour que je puisse comprendre de quoi vous parlé.

Du coup j'ai essayé la version Tile Mapping.
J'ai pris pour exemple une carte de jeux de 128x128, pour un écran qui fait 128x64, avec des tiles de 16x16.
Je pars du bas de la carte et je remonte.

Ça donne un truc comme ça :

Code:

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
#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>
#include "tile.h"
#define OLED_MOSI  5
#define OLED_CLK   6
#define OLED_DC    7
#define OLED_CS    9
#define OLED_RESET 8
Adafruit_SSD1306 display(OLED_MOSI, OLED_CLK, OLED_DC, OLED_RESET, OLED_CS);
 
const byte rowNumber (8);
const byte columnNumber (8);
const byte tileSize (16);
boolean oneTime (true);
 
//1=T  -  2=O  -  3=G
byte tileMapping[rowNumber][columnNumber] = {
  1, 1, 1, 1, 1, 1, 1, 1,
  1, 1, 1, 1, 1, 1, 1, 1,
  1, 1, 1, 1, 1, 1, 1, 1,
  2, 2, 2, 2, 2, 2, 2, 2,
  2, 2, 2, 2, 2, 2, 2, 2,
  3, 3, 3, 3, 3, 3, 3, 3,
  3, 3, 3, 3, 3, 3, 3, 3,
  3, 3, 3, 3, 3, 3, 3, 3,
};
 
//*********************************** SETUP
void setup() {
  display.begin(SSD1306_SWITCHCAPVCC);
}
 
//************************************ LOOP
void loop() {
 
  if (oneTime == true) {
    oneTime = false;
 
    //Scroll up
    for (int scrollUp = 4; scrollUp > -1; scrollUp--) {
      mapDisplay(scrollUp);
      delay(2000);
    }
  }
}
 
//***************************** MAP DISPLAY
void mapDisplay(byte scrollUp) {
  display.clearDisplay();
  display.display();
 
  byte tileSelection (0);
  byte tileCoord_X (0);
  byte tileCoord_Y (0);
  byte screenVerticalSize = scrollUp + 4;
 
  for (int ii = scrollUp; ii < screenVerticalSize; ii++) { //Raw
 
    for (byte i = 0; i < columnNumber; i++) { //Column
      tileSelection = tileMapping[ii][i];
      tileDisplay(tileCoord_X, tileCoord_Y, tileSelection);
      display.display();
      tileCoord_X += tileSize;
    }
 
    tileCoord_Y += tileSize;
    tileCoord_X = 0;
  }
}
 
//**************************** TILE DISPLAY
void tileDisplay(byte tileCoord_X, byte tileCoord_Y, byte tileSelection) {
 
  switch (tileSelection) {
    case 1:
      display.drawBitmap(tileCoord_X, tileCoord_Y, T, tileSize, tileSize, 1);
      break;
    case 2:
      display.drawBitmap(tileCoord_X, tileCoord_Y, O, tileSize, tileSize, 1);
      break;
    case 3:
      display.drawBitmap(tileCoord_X, tileCoord_Y, G, tileSize, tileSize, 1);
  }
}

tile.h

Code:

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
static const unsigned char PROGMEM T[] =
{
  B00000000, B00000000,
  B01111111, B11111110,
  B01111111, B11111110,
  B01111111, B11111110,
  B00000011, B11000000,
  B00000011, B11000000,
  B00000011, B11000000,
  B00000011, B11000000,
  B00000011, B11000000,
  B00000011, B11000000,
  B00000011, B11000000,
  B00000011, B11000000,
  B00000011, B11000000,
  B00000011, B11000000,
  B00000000, B00000000,
};
 
static const unsigned char PROGMEM O[] =
{
  B00000000, B00000000,
  B01111111, B11111110,
  B01111111, B11111110,
  B01111111, B11111110,
  B01110000, B00001110,
  B01110000, B00001110,
  B01110000, B00001110,
  B01110000, B00001110,
  B01110000, B00001110,
  B01110000, B00001110,
  B01110000, B00001110,
  B01111111, B11111110,
  B01111111, B11111110,
  B01111111, B11111110,
  B00000000, B00000000,
};
 
static const unsigned char PROGMEM G[] =
{
  B00000000, B00000000,
  B01111111, B11111110,
  B01111111, B11111110,
  B01111111, B11111110,
  B01110000, B00000000,
  B01110000, B00000000,
  B01110000, B11111110,
  B01110000, B11111110,
  B01110000, B00001110,
  B01110000, B00001110,
  B01110000, B00001110,
  B01111111, B11111110,
  B01111111, B11111110,
  B01111111, B11111110,
  B00000000, B00000000,
};

28/03/2018, 08h36
Kannagi

Alors je n'ai aucun exemple (si tu parle de code , la seule fois ou j'ai codé des truc dans le genre c'était en assembleur ).
Et encore moins de lien , faut savoir que ce sont des techniques du millénaire passé :mrgreen: , et avec la venu des moteur de jeux moderne je ne me suis jamais senti motivé d'expliqué toutes les techniques du passé dans un article ou un tuto , alors qu'on peut afficher des millions de polygone par frame avec du photo-réalisme dessus avec quelque ligne de code , cela demande un certain bagage technique pour faire un Mario/Zelda avec quelque ko et quelque mhz de puissance me semble un peu dérisoire à coté :aie:

Bref si tu est débutant le mieux dans tout les cas c'est d'apprendre pas à pas ,et quand tu maîtrisera les bases tu reviendra ici si tu veux peaufiner /optimiser ce que tu as deja fait !
28/03/2018, 21h29
greg006

Ok
Merci
29/03/2018, 12h24
greg006

Je me lance avec les tiles et on verra ce que ça donne.

Quelques questions :
1/ C'est plus rapide d'afficher 32 tuiles 16x16 ou 128 tuiles 8x8.

2/Es ce qu'il y a une différence, en terme de vitesse d'affichage, entre une tuile 16x16 qui affiche un seul pixel et une tuile qui affiche 256 pixels.

3/Toujours en vitesse d'affichage, il vaut mieux un écran blanc avec des tuiles qui affiche des pixels noirs ou l'inverse.

J'ai fais quelques tests, les différences ne me saute pas au yeux.

Merci
29/03/2018, 14h20
Kannagi

Alors :
1) 32 tuiles de 16x16 sera plus rapide (principalement a cause des boucles) et prendra moins de mémoire pour les tileset (et donc plus rapide pour le scrolling et ta fonction d'affichage de map ).
2) gné :koi: ? ça affiche dans les deux cas 256 pixel...
3) Aucune différence par contre pour la consommation électrique un écran noir ça consomme sûrement moins !

Pourquoi ces questions ? Tu as des soucis de performance ?
29/03/2018, 14h57
greg006

Encore merci pour tes réponses.

J'ai effectivement un léger soucis, ça lag un peu (une fraction de seconde) quand scrolling.

Citation:

2) gné ? ça affiche dans les deux cas 256 pixel...

J'ai donc pas été claire ... :oops:
Es qu'il y a une différence entre entre un pixel allumé ou un pixel éteint, entre B00000000 et B11111111.
Suis je plus claire :D

Mais je pense que tu as répondu avec la question 3.
29/03/2018, 15h40
Kannagi

Donc oui B00000000 et B11111111 c'est pareil en terme de calcul.

Pour le ralentissement , moi je trouvais deja ta fonction un peu longue en terme de calcul, je connais pas la puissance de ton Atmega (normalement 20 MIPS donc assez proche d'une Playstation 1 ).
Les fonctions de rendu doivent toujours être optimisé , je déconseillerait de faire un appel de fonction pour le tilemapping en interne (il existe les fonctions inline en C).
Si c'est du monochrome comme rendu alors normalement le rendu doit être super rapide (1 octet pour 8 pixel) , Si tu es sur 60 FPS tu as donc 333 333 instruction par frame si ton truc est bien optimisé on peut esperer 2048 cycles (Load/Store ) pour l'affichage de la map entière de ton écran :mrgreen:
29/03/2018, 16h17
greg006

J'ai essayé de faire une console compacte et j'avais besoin de SRAM, j'ai donc choisi la carte Arduino Micro, qui est a 16 MIPS.

Je suis en monochrome.

Citation:

je trouvais déjà ta fonction un peu longue en terme de calcul

tu parles de cette fonction :

Code:

void mapDisplay(byte scrollUp) {

Ouhaou ! je la trouve super vide ! il y a juste le minimum. Je regarde tout ça de plus prés.

Citation:

(il existe les fonctions inline en C).

Je vais regarder également.