IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

Ré-écrire « PV2000 » en SDL


Sujet :

C

  1. #1
    Membre actif

    Homme Profil pro
    autre
    Inscrit en
    Juillet 2015
    Messages
    176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Juillet 2015
    Messages : 176
    Points : 202
    Points
    202
    Par défaut Ré-écrire « PV2000 » en SDL
    NdlM : discussion scindée depuis la discussion « Rotation d'ellipses en langage C », à partir du message #24.

    re bonjour.
    Je suis en train de me documenter sur la façon dont fonctionne l'algorithme de scanline fill.
    j'ai acheté le livre "Computer Graphics : Principles and practice", de, entre autre, James D. Foley, en occas sur Amazon.
    A l'intérieur, il parle de "bucket sort" pour les Sorted Edge Table.
    Je n'arrive pas à traduire la signification de "bucket sort". Je vois bien qu'il s'aqit d'un tri, mais lequel?
    Au passage, j'ai vu sur le site wiki que l'invention du scanline fill est revendiquée par un français. Or, aucune documentation n'est disponible en Français. Pourquoi?

  2. #2
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Bonjour,

    Citation Envoyé par piponux Voir le message
    A l'intérieur, il parle de "bucket sort" pour les Sorted Edge Table.
    Je n'arrive pas à traduire la signification de "bucket sort". Je vois bien qu'il s'aqit d'un tri, mais lequel ?
    Le bucket sort, apparemment appelé tri par paquets en français. Je ne le connais pas beaucoup. Apparemment, il ressemble un peu au tri fusion…

    Au passage, j'ai vu sur le site wiki que l'invention du scanline fill est revendiquée par un français. Or, aucune documentation n'est disponible en Français. Pourquoi?
    Parce qu'honnêtement, à mon avis, tout le monde y a plus ou moins pensé tout seul. C'est un peu comme le buffer circulaire ou autres concepts élémentaires. Bien souvent, le problème présenté tel quel paraît ésotérique mais il suffit souvent de se demander comme on s'y prendrait, soi-même, pour le résoudre pour se rendre compte qu'on suivrait le même chemin et aboutirait à la même solution en une vingtaine de minutes.

    C'est un peu comme l'approche pair-impair pour remplir un polygone, fût-il concave par endroits. On comprend que la première chose à faire pour remplir l'intérieur de ce polygone est de définir ce que l'on entend par « intérieur ». Et là, on voit bien que si l'on part des limites de la zone d'affichage, on se trouve bien dans « l'extérieur » par défaut. Puis, à partir du moment où je rencontre une frontière, quelle qu'elle soit, c'est que je passe de l'extérieur à l'intérieur. Si j'en rencontre une nouvelle, c'est que je ressort à l'extérieur. Si j'en rencontre une troisième, je repasse à l'intérieur, et ainsi de suite… et ce, quelle que soit ma trajectoire !

    Il arrive aussi que les gens à qui on accorde la paternité d'un concept l'aient découvert très tôt dans l'histoire, mais c'est bien souvent, là aussi, parce qu'ils s'agissait de personnes qui travaillaient sur le sujet en laboratoire au sein d'un projet plus vaste, qui par conséquent avait accès à des machines qui ne l'étaient pas encore au grand public, et qui ont fait la même démarche à ce moment-là. Et la plupart du temps, ces gens ne revendiquent pas la découverte d'un concept particulièrement révolutionnaire. Celui-ci est simplement consigné parce que c'était normal de le faire à ce moment.

  3. #3
    Membre actif

    Homme Profil pro
    autre
    Inscrit en
    Juillet 2015
    Messages
    176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Juillet 2015
    Messages : 176
    Points : 202
    Points
    202
    Par défaut
    bon, je dois reconnaître que c'est quand même balaise pour mon niveau. Je vais donc utiliser le code qui se trouve dans le livre "Computer Graphics" de Hearn, page 120-124.
    Celà vous paraissait il aussi dur à coder vous même lorsque vous étiez étudiant, disons dans la première / deuxième année?

  4. #4
    Expert éminent sénior
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    Mai 2010
    Messages
    3 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : Mai 2010
    Messages : 3 215
    Points : 10 140
    Points
    10 140
    Par défaut
    Pour ma part le code d'un Scanline fill je l'ai trouvé sur M.A.M.E (un émulateur de borne d'acade et le but n'était pas vraiment de trouver cette fonction , je cherchais par curiosité comment fonctionné certaine machine).

    Voila le code source légèrement modifié par mes soins :

    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
     
     void fill_slope(SDL_Surface* surface,SDL_Surface* texture, int color, int x1, int x2, int sl1, int sl2, int y1, int y2, int *nx1, int *nx2,struct m1_fpoint *tp)
    {
     
    /*
    	if(y2 > view->y2)
    		y2 = view->y2+1;
     
    	if(y1 < view->y1) {
    		int delta = view->y1 - y1;
    		x1 += delta*sl1;
    		x2 += delta*sl2;
    		y1 = view->y1;
    	}
    */
    	int ix,x;
    	if(x1 > x2 || (x1==x2 && sl1 > sl2)) {
    		int t, *tp;
    		t = x1;
    		x1 = x2;
    		x2 = t;
    		t = sl1;
    		sl1 = sl2;
    		sl2 = t;
    		tp = nx1;
    		nx1 = nx2;
    		nx2 = tp;
    	}
     
    	//
     
    	int y = y1;
    	int i, l = 0;
    	//printf("\n----------------------\n");
    	int *tex = texture->pixels;
    	while(y1 < y2) {
    		//if(y1 >= view->y1) {
    			//int xx1 = x1>>FRAC_SHIFT;
    			int xx2 = x2>>FRAC_SHIFT;
    			//if(xx1 <= view->x2 || xx2 >= view->x1) {
    				//if(xx1 < view->x1)
    					//xx1 = view->x1;
    				//if(xx2 > view->x2)
    					//xx2 = view->x2;
     
    					ix = x1>>FRAC_SHIFT;
     
    					int *p = (int*)((char*)surface->pixels + y1 * surface->pitch + ix * 4);
    					int *p2 = (int*)((char*)surface->pixels + y1 * surface->pitch + xx2 * 4);
     
     
     
    					float coef = (float)(y2-y1)/(float)(y2-y);
    					int i = (int)(texture->w*coef)*(texture->h);
    					l += sl1>>FRAC_SHIFT;
     
    					//i = (y2-y1)*(texture->w);
     
    					//printf("(%d %d),",i,(int)(coef*texture->h) );
     
    					while(p <= p2)
    					{
    					//SDL_PutPixel32(surface,ix,y1,color);
     
    					*p = 0x00FF;tex[i];
    					p++;
    					i++;
    					//ix++;
    				}
     
     
    					//draw_hline(surf, xx1, xx2, y1, color);
    			//}
    		//}
     
    		x1 += sl1;
    		x2 += sl2;
    		y1++;
    	}
    	*nx1 = x1;
    	*nx2 = x2;
    }
     
     void fill_tri(SDL_Surface* surf,SDL_Surface* texture,int bitmap, const struct quad_m1 *q)
    {
    	int sl1, sl2, cury, limy, x1 = 0, x2 = 0;
    	int pmin, pmax, i, ps1, ps2;
    	struct m1_spoint p[8];
    	struct m1_fpoint tp[8];
     
    	tp[0].x = 0;
    	tp[0].y = 0;
     
    	tp[1].x = 1;
    	tp[1].y = 0;
     
    	tp[2].x = 0;
    	tp[2].y = 1;
     
    	for(i=0; i<3; i++) {
    		p[i].x = p[i+3].x = q[i].x << FRAC_SHIFT;
    		p[i].y = p[i+3].y = q[i].y;
    	}
     
    	pmin = pmax = 0;
    	for(i=1; i<3; i++)
    	{
    		if(p[i].y < p[pmin].y)
    			pmin = i;
    		if(p[i].y > p[pmax].y)
    			pmax = i;
    	}
     
    	cury = p[pmin].y;
    	limy = p[pmax].y;
     
    	if(cury == limy)
    	{
    		x1 = x2 = p[0].x;
    		for(i=1; i<3; i++) {
    			if(p[i].x < x1)
    				x1 = p[i].x;
    			if(p[i].x > x2)
    				x2 = p[i].x;
    		}
     
    		Line(surf,x1>>FRAC_SHIFT, cury, x2>>FRAC_SHIFT, limy,bitmap);
    		return;
    	}
     
     
     
    	ps1 = pmin+3;
    	ps2 = pmin;
     
    	while(p[ps1-1].y == cury)
    		ps1--;
    	while(p[ps2+1].y == cury)
    		ps2++;
    	x1 = p[ps1].x;
    	x2 = p[ps2].x;
    	sl1 = (x1-p[ps1-1].x)/(cury-p[ps1-1].y);
    	sl2 = (x2-p[ps2+1].x)/(cury-p[ps2+1].y);
     
     
    	if(p[ps1-1].y == p[ps2+1].y)
    	{
    		fill_slope(surf,texture, bitmap, x1, x2, sl1, sl2, cury, p[ps1-1].y, &x1, &x2,tp);
    		return;
    	}
     
     
    	if(p[ps1-1].y < p[ps2+1].y)
    	{
     
    		for(;;)
    		{
    			fill_slope(surf,texture, bitmap, x1, x2, sl1, sl2, cury, p[ps1-1].y, &x1, &x2,tp);
     
    			cury = p[ps1-1].y;
    			if(cury >= limy)
    				break;
    			ps1--;
    			while(p[ps1-1].y == cury)
    				ps1--;
    			x1 = p[ps1].x;
    			sl1 = (x1-p[ps1-1].x)/(cury-p[ps1-1].y);
    		}
    		return;
    	}
    	for(;;)
    	{
    		fill_slope(surf, texture,bitmap, x1, x2, sl1, sl2, cury, p[ps2+1].y, &x1, &x2,tp);
    		cury = p[ps2+1].y;
    		if(cury >= limy)
    			break;
    		ps2++;
    		while(p[ps2+1].y == cury)
    			ps2++;
    		x2 = p[ps2].x;
    		sl2 = (x2-p[ps2+1].x)/(cury-p[ps2+1].y);
    	}
     
    }
    Je trouve pas le code terrible , j'aurais fait très différemment je pense !
    Disons que j'ai aucun intérêt pratique a le refaire (sauf sur un Atari ST et encore je l'aurais codé en assembleur sur cette bécane ).

    Pour ton autre question , je ne pense pas que en 1ere/2eme année j'aurais réussi a refaire ce genre de truc , disons que pour ma part mon but principal les premières années était de maîtrisé le C est de respecté certain paradigme codé sans effet de bord , des fonctions facile a utilisé et utilisable sur n'importe quel programme , j'ai mis quelque année pour réussir ces trois choses correctement , c'est après que je me suis plus concentré sur l'algorithme et le bas niveau.

  5. #5
    Membre actif

    Homme Profil pro
    autre
    Inscrit en
    Juillet 2015
    Messages
    176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Juillet 2015
    Messages : 176
    Points : 202
    Points
    202
    Par défaut
    hello.
    ça me rassure ce que tu dis car je n'aurais vraiment pas été capable de reproduire le code du livre "Computer Graphics" de Hearn. Quand j'aurais le temps je le copierai / collerai ici.
    Pour ma part, je ne "code" en c qu'environ, en moyenne, deux ou trois heures par semaine, depuis deux ans, avec des pauses de plusieurs mois. Ma principale source est l'ensemble de videos publiées par Jacques Olivier Lapeyre, même si je commence à lire des bouquins.
    Je comprends bien l'algorithme des scanline fill, mais l'implémenter correctement, c'est une autre histoire.
    C'est peut être pour celà que la grande majorité des cours internet se basent exactement sur le même exemple, à savoir celui publié dans le livre "Computer Graphics" de Foley.

    J'envisage de me procurer le livre sur Allegro 5 de Frédéric Drouillon, afin de voir comment est fait un squelette de jeu vidéo en c. Que pensez vous de ce choix? sachant que c'est un des rares (le seul?) bouquin en français.

  6. #6
    Expert éminent sénior
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    Mai 2010
    Messages
    3 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : Mai 2010
    Messages : 3 215
    Points : 10 140
    Points
    10 140
    Par défaut
    Je ne suis pas très livre et je te dirai que je te le déconseille ,disons que si tu veux apprendre la prog de jeux vidéo ben.... il faut coder coder et encore coder ! (fait plein de démo )
    Le livre est bien peut être mais je pense qu'il t'apprendra plus la lib Allegro que la prog de jeux vidéo (après je n'en sais rien j'ai pas lu le livre).

    En général je propose de se concentrer sur :
    -La gestion de la fenêtre/contexte
    -Les evenement clavier/souris/joypad
    -Les FPS (frame par seconde)
    -La gestion des sprites (animée ou non)
    -Du Background
    -La Caméra
    -Les Collisions

    Et deja la tu a deja du boulot a faire , et cela te permettra d'apprendre a coder de manière modulaire , chaque partie peut être complètement indépendante.
    Ce que j'ai énumérer suffit pour la plupart des jeux 2D.

  7. #7
    Membre actif

    Homme Profil pro
    autre
    Inscrit en
    Juillet 2015
    Messages
    176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Juillet 2015
    Messages : 176
    Points : 202
    Points
    202
    Par défaut
    en fait, j'aimerais commencer par apprendre la boucle des événements, c'est à dire ce qui fait que, par exemple, plusieurs sprites se déplacent à l'écran, tirent...etc. et que tout celà reste fluide. Quel est, par exemple, le mot clé qui régit tout celà?

  8. #8
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Citation Envoyé par piponux Voir le message
    en fait, j'aimerais commencer par apprendre la boucle des événements, c'est à dire ce qui fait que, par exemple, plusieurs sprites se déplacent à l'écran, tirent...etc. et que tout celà reste fluide. Quel est, par exemple, le mot clé qui régit tout celà?
    Le secret s'appelle VBL (ou VBI).

    L'idée est de synchroniser le tout avec la période de rafraîchissement de l'écran, et idéalement de tout dessiner pendant que le canon à électrons (comprendre : des écrans à tube cathodique) est en train de remonter histoire que cela ne se voit pas. Mais le plus important étant tout de même d'avoir des images à intervalle régulier, d'une part, intervalle correspondant à celui du moniteur d'autre part. Sinon, tu peux te retrouver à avoir une image à moitié dessinée, ou bien avoir deux fois le même frame chaque fois que le « déphasage » redevient nul. C'est ça qui va donner une impression de saccade sur les applications mal réalisées.

    Ça se faisait beaucoup quand on programmait en assembleur sous DOS, et que les registres des cartes VGA étaient encore standardisés. Aujourd'hui, ça se fait toujours mais les bibliothèques le font pour toi et comme on ne manque plus de mémoire vive (ni même de mémoire vidéo en particulier, à dire vrai), les cartes vidéo et les bibliothèques qui les exploitent (OpenGL, SDL…) utilisent souvent des doubles buffers. Ça se faisait aussi à l'époque mais il fallait que le hardware puisse le faire. L'idée est simplement d'orienter l'affichage écran vers un buffer pendant qu'on travaille sur un autre dans l'ombre, puis, une fois terminé, d'inverser les affichages. Là encore, la bascule se fait en principe en attendant le rafraîchissement écran.

    Du coup, c'est ce rafraîchissement période qui sert d'horloge à toute la boucle, un peu comme les rounds des jeux de rôles.

    À noter que le concept de boucle principale est extrêmement répandu dans tout ce qui est multitâche et/ou contrôlé de l'extérieur, même en dehors du monde du graphisme et des jeux vidéos. Tout ce qui est MVC est plus ou moins orienté autour de ce concept mais là encore, c'est quelque chose vers laquelle on s'oriente naturellement quand on essaie d'imaginer comment on résoudrait le problème soi-même. Par exemple, dans les années 1990, j'avais écrit un serveur Minitel à quatre voies en BASIC, d'abord sur mon 8 bit, puis sur un PC avec QBasic pour honorer une commande (le restau du père d'un copain). Il est intéressant de voir qu'en raisonnant de manière algorithmique, on peut résoudre des problèmes en utilisant des systèmes qui ne mettent en œuvre aucune facilité native de multitâche (pas de multicompte, pas de multiprocesseur et bien sûr, pas de threads). Il n'y avait pas non plus de sauvegarde de contexte, ni d'objets, ni de définition de types (uniquement les quatre types natifs : entiers, réels simple précision, réels double, et chaînes de caractères (maximum : 255 caractères)). Et pourtant, cela marchait bien. On peut vraiment faire beaucoup avec très peu.

  9. #9
    Membre actif

    Homme Profil pro
    autre
    Inscrit en
    Juillet 2015
    Messages
    176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Juillet 2015
    Messages : 176
    Points : 202
    Points
    202
    Par défaut
    VBL...ok ok...merci!
    j'aimerais commencer par un remake de PV2000 qui était sorti sur Mo5, quelle éclate ce jeu!
    Mais avant, terminer mon éditeur de sprite / dessins, histoire d'avoir de la suite dans les idées et ne pas sauter les étapes.

  10. #10
    Expert éminent sénior
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    Mai 2010
    Messages
    3 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : Mai 2010
    Messages : 3 215
    Points : 10 140
    Points
    10 140
    Par défaut
    Citation Envoyé par Obsidian Voir le message
    Le secret s'appelle VBL (ou VBI).
    J'aurais seulement dit , que pour gardé une fluidité il faut s'assurer que son programme tourne sur 60 FPS (d’où le conseil de codé une fonction fps avec clock et sleep) par exemple).

    Effectivement le VBlank était assez essentiel dans les vielles machine comme les consoles , par exemple sur la Super Nintendo le VBlank était le seul moment ou en pouvait écrire sur certain I/O (principalement ceux en rapport avec la vidéo).
    Cela est aussi en rapport avec le HBlank (interruption survenant quand le canon a électron revient a la 'ligne') est certaine console pouvait donner des effets sur chaque ligne de l'écran grâce a cette interruption , mais cela reste dans le passé , VBlank/Hblank de nos jours ont y pas trop confronté même sur les consoles récentes.

    j'aimerais commencer par un remake de PV2000 qui était sorti sur Mo5, quelle éclate ce jeu!
    Je trouve cela tres bien , je te conseille que si tu veux le refaire , concentre toi plus sur la qualité du code que sur le résultat ,cela te servira plus tard

  11. #11
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Citation Envoyé par Kannagi Voir le message
    J'aurais seulement dit , que pour gardé une fluidité il faut s'assurer que son programme tourne sur 60 FPS (d’où le conseil de codé une fonction fps avec clock et sleep)
    Tu as certainement plus d'avance aujourd'hui que j'en ai dans le domaine, mais pourquoi avec clock() et sleep() ? Il faut quand même se resynchroniser à intervalles réguliers, sinon les incertitudes finiront par se cumuler et on aura forcément des frames qui sautent à intervalle fixe. C'est vrai que si celui-ci n'est pas trop large, on peut s'en passer pour commencer mais c'est quand même dommage de faire volontairement l'impasse sur ça (surtout qu'à l'époque, c'est un « secret » relativement bien gardé, ou en tout cas pas partagé facilement).

    Effectivement le VBlank était assez essentiel dans les vielles machine comme les consoles , par exemple sur la Super Nintendo le VBlank était le seul moment ou en pouvait écrire sur certain I/O (principalement ceux en rapport avec la vidéo).
    Il auraient pu mettre des latches quand même Mais à part cela, c'est justement le genre de petits détails techniques qu'il fallait prendre en compte et qui « permettait de toucher le hardware du doigt » qui formaient une bonne partie du charme de ces machines. Ça avec le fait qu'elles étaient ENCORE suffisamment rudimentaires pour que l'on puisse les appréhender même à l'adolescence, et suffisamment lentes pour que l'on puisse mesurer les effets de ce que l'on optimisait.

    Cela est aussi en rapport avec le HBlank (interruption survenant quand le canon a électron revient a la 'ligne') est certaine console pouvait donner des effets sur chaque ligne de l'écran grâce a cette interruption , mais cela reste dans le passé , VBlank/Hblank de nos jours ont y pas trop confronté même sur les consoles récentes.
    Ça reste quand même sous-jacent. Comme je le disais au-dessus, même les bibliothèques de haut niveau, dès lors qu'elles proposent un double buffer, se synchronisent dessus pour passer de l'un à l'autre.

    Citation Envoyé par piponux Voir le message
    j'aimerais commencer par un remake de PV2000 qui était sorti sur Mo5, quelle éclate ce jeu !
    PV2000 ! Tu me rajeunis de 35 ans (ce qui ne m'en laisse donc que 6) ! Du coup, je viens de le relancer sur l'émulateur…

    Alors effectivement, j'ai moi-même commencé sur Thomson et c'était tout-à-fait ce genre de logiciel que je m'amusais à concevoir à l'époque. Époque où, justement, ce genre de jeu pouvait avoir de l'intérêt pour le joueur (et donc pour le programmeur) et où, parallèlement, cela ne demandait pas des années de prérequis avant de pouvoir commencer. En plus, PV2000 en lui-même est écrit en BASIC. Il n'y avait donc pas de référence à la VBL (autant que je sache, d'ailleurs, il faudra que je revérifie parce qu'il y a tout de même beaucoup de PEEK et POKE) mais il y a assurément une boucle principale. La limitation de la vitesse était imposée par le langage lui-même !

  12. #12
    Expert éminent sénior
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    Mai 2010
    Messages
    3 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : Mai 2010
    Messages : 3 215
    Points : 10 140
    Points
    10 140
    Par défaut
    Citation Envoyé par Obsidian Voir le message
    Tu as certainement plus d'avance aujourd'hui que j'en ai dans le domaine, mais pourquoi avec clock() et sleep() ? Il faut quand même se resynchroniser à intervalles réguliers, sinon les incertitudes finiront par se cumuler et on aura forcément des frames qui sautent à intervalle fixe. C'est vrai que si celui-ci n'est pas trop large, on peut s'en passer pour commencer mais c'est quand même dommage de faire volontairement l'impasse sur ça (surtout qu'à l'époque, c'est un « secret » relativement bien gardé, ou en tout cas pas partagé facilement).
    Je parle ici sur la programmation sur un PC (donc pas de frame qui saute jsute un fps peut etre moins constant) , il y'a plusieurs façon de faire un FPS mais sans le clock , on fait une boucle qui va lire la fonction clock() tout le temps , c'est la méthode la plus précise , mais ça bouffe quand même 100% du CPU.
    Avec un sleep tu réduira sa consommation mais tu perdra effectivement en précision.

    L'autre point dans les faits , tu risque de perdre avec un clock/sleep quelque milliseconde par frame , donc sur 6 secondes tu peux être en "retard" entre 1 et 12 frame (sur 360 frame) , faut avoir de sacré bon yeux pour quelle soit perceptible , sauf si tu fait un jeux qui a besoin d'absolument d'un 60 FPS (a mes yeux seul les danmaku , shoot them up avec des rideaux de tirs aurait besoin d'un tel cas de figure ! ).
    Ici le mot retard veut dire que par exemple on pourrait se trouvait dans ce cas de figure :
    1 seconde : 59 frame
    2 seconde : 60 frame
    3 seconde : 60 frame
    4 seconde : 61 frame
    etc..
    Bref dans mes tests cela est vraiment pas visible a l'écran (je veux dire que tu fasse 17 ou 18 miliseconde au lieu de 16 miliseconde de temps en temps voila ) , ni dans la réactivité des évents d'ailleurs (je rappelle qu'au cas ou nous européen on jouait a 50 FPS :p ).
    D'ailleurs comme les version américains ou japonaise n'était pas reprogrammé pour les versions pal , la lenteur se faisait sentir (les jeux a était conçu pour du 60 FPS) , sauf certain rare jeux était 'refait' pour les versions PAL.

    Sur les consoles le VBlank étant une interruption IRQ un I/O l'indiquait , donc il n'ya pas forcément de programmation juste une boucle 'infinie' qui attend le VBlank.

    Citation Envoyé par Obsidian
    Il auraient pu mettre des latches quand même Mais à part cela, c'est justement le genre de petits détails techniques qu'il fallait prendre en compte et qui « permettait de toucher le hardware du doigt » qui formaient une bonne partie du charme de ces machines.
    Oui mais peut être que la raison était que la super Nintendo était en retard , la Mega Drive prenait des places du marché et Nintendo a sorti la Super nintendo une console qui n'est pas tout d'a fait fini (par exemple son architecture est pensé pour être compatible avec des jeux Nes mais faute de temps elle ne l'est pas , du coup les I/O ont un drôle de mélange 8/16 bits qui ne les rends pas agréable a manipuler quelque fois , et du coup son architecture proche de la NES est inutile et contraignant ).
    Sinon oui comme d'hab on est bien d'accord que les anciennes machines ont ce charme qu'on maîtrise la bécane de A à Z

  13. #13
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Citation Envoyé par Kannagi Voir le message
    Je parle ici sur la programmation sur un PC (donc pas de frame qui saute jsute un fps peut etre moins constant) , il y'a plusieurs façon de faire un FPS mais sans le clock , on fait une boucle qui va lire la fonction clock() tout le temps , c'est la méthode la plus précise , mais ça bouffe quand même 100% du CPU.
    Avec un sleep tu réduira sa consommation mais tu perdra effectivement en précision.
    Mouais, ça me rassure de constater que l'on voit les choses de la même façon, mais tout de même : si on programme sur PC, alors le/la VBL ou ce qui en tient lieu (je ne sais pas comment c'est pris en charge sur le DVI par exemple, mais apparemment il y a toujours un retour vertical analogique sur la broche 8), alors on devrait toujours avoir cette information. Même cachée derrière les fonctions de commutation de buffer proposées par les bibliothèques de développement. À la limite, de telles fonctions de temporisation devraient être là en fallback pour éviter d'avoir une boucle infinie si jamais l'information en question n'est pas disponible (matériel trop exotique, défectueux, ou compatibilité non assurée).


    L'autre point dans les faits , tu risque de perdre avec un clock/sleep quelque milliseconde par frame , donc sur 6 secondes tu peux être en "retard" entre 1 et 12 frame (sur 360 frame) , faut avoir de sacré bon yeux pour quelle soit perceptible , sauf si tu fait un jeux qui a besoin d'absolument d'un 60 FPS (a mes yeux seul les danmaku , shoot them up avec des rideaux de tirs aurait besoin d'un tel cas de figure ! ).
    Ça dépend. Si tu écris un FPS ou ça tire dans tous les coins, les sauts de frame peuvent se fondre dans l'action, mais si tu fais quelque chose de plus fluide et continu, comme un simulateur de vol, ça risque d'être pénible d'avoir des sauts à intervalle régulier. En plus, il y a toujours la question du rendu : si c'est sur les machines de brutes que l'on a aujourd'hui, il est possible que tout se fasse en quelques lignes écran mais si c'est plus long, on se retrouve avec une ligne horizontale au milieu de l'image, qui est en fait formée par la césure entre l'ancienne et la nouvelle version de l'image à rendre. C'était flagrant sur certains scrolltexts horizontaux aussi bien sur 8 bits que sur PC (et je ne parle pas du marquee de Windows 3.1…).

    Sur les consoles le VBlank étant une interruption IRQ un I/O l'indiquait , donc il n'ya pas forcément de programmation juste une boucle 'infinie' qui attend le VBlank.
    Oui et même quand les interruptions n'étaient pas disponibles, on faisait de toutes façons du polling sur le registre concerné, ce qui revenait un peu au même mais ne posait pas de problème sur les machines de l'époque, essentiellement monotâches. C'était même parfois plus intéressant car en désactivant les interruptions par ailleurs (typiquement dans une démo), ça permettait aussi d'avoir une granularité plus fine. Sur un Thomson, le 6809 fonctionnait à 1 Mhz, soit des cycles d'exactement 1 microseconde, ce qui se traduisait par exactement 8 pixels de long à l'écran, soit un octet, et le format des caractères en 40 colonnes. C'était extrêmement pratique pour calculer la durée d'une ligne mais à raison de deux ou trois cycles par instruction, c'était difficile de se synchroniser proprement au départ. Toutefois, il existe généralement une instruction SYNC ou HLT pour suspendre l'activité du processeur jusqu'à la prochaine interruption. En s'y prenant tôt, on pouvait ainsi approcher une granularité d'un cycle.

    Oui mais peut être que la raison était que la super Nintendo était en retard , la Mega Drive prenait des places du marché et Nintendo a sorti la Super nintendo une console qui n'est pas tout d'a fait fini (par exemple son architecture est pensé pour être compatible avec des jeux Nes mais faute de temps elle ne l'est pas , du coup les I/O ont un drôle de mélange 8/16 bits qui ne les rends pas agréable a manipuler quelque fois , et du coup son architecture proche de la NES est inutile et contraignant ). Sinon oui comme d'hab on est bien d'accord que les anciennes machines ont ce charme qu'on maîtrise la bécane de A à Z
    Ah oui, ça, les machines pas finies pour des raisons commerciales et qui engendrent ensuite des bizarreries historiques, c'est effectivement courant en informatique. L'ironie du sort étant parfaitement incarnée, ensuite, par la Nintendo 64 qui avait l'air assez propre et par la Playstation sortie à la même époque, et qui a eu l'audace d'être la première à utiliser un CD (sacrilège sur console, pour l'époque). On sait de quelle manière l'histoire s'est ensuite écrite…

  14. #14
    Expert éminent sénior
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    Mai 2010
    Messages
    3 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : Mai 2010
    Messages : 3 215
    Points : 10 140
    Points
    10 140
    Par défaut
    Citation Envoyé par Obsidian Voir le message
    Ça dépend. Si tu écris un FPS ou ça tire dans tous les coins, les sauts de frame peuvent se fondre dans l'action, mais si tu fais quelque chose de plus fluide et continu, comme un simulateur de vol, ça risque d'être pénible d'avoir des sauts à intervalle régulier. En plus, il y a toujours la question du rendu : si c'est sur les machines de brutes que l'on a aujourd'hui, il est possible que tout se fasse en quelques lignes écran mais si c'est plus long, on se retrouve avec une ligne horizontale au milieu de l'image, qui est en fait formée par la césure entre l'ancienne et la nouvelle version de l'image à rendre. C'était flagrant sur certains scrolltexts horizontaux aussi bien sur 8 bits que sur PC (et je ne parle pas du marquee de Windows 3.1…).
    Cette sciure viendrai pour ma part que d'un écran cathodique ,et puis l'affichage se fait via un buffer (donc elle ne risque pas d’apparaître).

    Même sur un simulateur de vol , la on parle d'affichage , ça veut dire que 2 frame doit être suffisamment différente pour que cela a un impact , je code souvent des démo /jeux en faite le 60 FPS s'explique plus pour un gameplay solide que pour une animation correct visuellement ( je veux dire ce que tu explique et que on risque d'avoir un 59 au lieu de 60).


    Le code FPS est normalement assez stable , le mien :

    Sur PC :
    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
     
    void LMP3D_Fps(int fps)
    {
    	static LMP3D_FPS time;
     
        int time_dif = 0,slp;
        slp = 1000000/fps;
     
        time.end = clock();
        time_dif = time.end - time.begin;
     
        if(time_dif <= 0) time_dif = 0;
        if(time_dif < slp) usleep(slp - time_dif);
     
        time.begin = clock();
    }
     
    int LMP3D_VBlank()
    {
    	LMP3D_Fps(60);
    	SDL_GL_SwapBuffers();
     
    	return 0;
    }
    Sur Playstation 2 :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    int LMP3D_VBlank()
    {
    	int VBlankCnt = 0;
     
    	//VBlank interrupt enable
    	GS_SET_CSR(0,0,0,1,0,0,0,0,0,0,0,0);
     
    	//wait VBlank
     
    	while( !( ( RW_REGISTER_U32(GS_CSR) ) & 0x08) ) VBlankCnt++;
     
    	return VBlankCnt;
    }
    Juste pour dire que je n'aurais pas conseillé une méthode si elle n'était pas 'fiable' , en tout cas cela est invisible ces détails que tu souligne (sur un PC Moderne j'entends ) .

  15. #15
    Membre actif

    Homme Profil pro
    autre
    Inscrit en
    Juillet 2015
    Messages
    176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Juillet 2015
    Messages : 176
    Points : 202
    Points
    202
    Par défaut
    PV2000 ! Tu me rajeunis de 35 ans
    Et ouais. L'époque où il fallait taper soi même ses jeux en suivant de longues pages de code. A la moindre erreur de frappe, pas de pitié!

  16. #16
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Citation Envoyé par piponux Voir le message
    Et ouais. L'époque où il fallait taper soi même ses jeux en suivant de longues pages de code. A la moindre erreur de frappe, pas de pitié!
    Oui, enfin, c'était surtout vrai quand on saisissait des pages entières de code binaire enregistré dans des datas. Un listing en BASIC, on pouvait quand même le reprendre… En ce qui concerne PV 2000, d'ailleurs, c'est un jeu qui a été édité et vendu. C'était vraiment au tout début de la gamme, d'ailleurs, parce qu'un logiciel comme celui-ci peut s'écrire aujourd'hui en une heure ou deux.

  17. #17
    Membre actif

    Homme Profil pro
    autre
    Inscrit en
    Juillet 2015
    Messages
    176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Juillet 2015
    Messages : 176
    Points : 202
    Points
    202
    Par défaut
    parce qu'un logiciel comme celui-ci peut s'écrire aujourd'hui en une heure ou deux.
    oui, pour quelqu'un pour Obsidian ou Kannagi.
    Pour quelqu'un comme piponux, on peut facilement multiplier par cent!

  18. #18
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Tu exagères.

    Même en apprenant à la volée l'API du framework que tu choisiras d'utiliser, tu pourras facilement implémenter un PV2000 en une dizaine d'heures. Du coup, et pour recentrer un peu la discussion, quelle plateforme souhaites-tu utiliser pour faire ce projet ? La SDL est généralement un bon choix, mais ça dépend aussi des technologies qui t'intéressent (tu dois même pouvoir faire cela en Javascript).

    Il va probablement être temps de scinder le fil, également.

  19. #19
    Membre actif

    Homme Profil pro
    autre
    Inscrit en
    Juillet 2015
    Messages
    176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Juillet 2015
    Messages : 176
    Points : 202
    Points
    202
    Par défaut
    je voudrais faire cela en langage C avec SDL2.

  20. #20
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Bien.

    En SDL1, Il y avait SDL_Flip() pour passer d'un buffer à l'autre et la fonction avait le bon goût d'attendre elle-même le retour vertical, ce qui fait que tes animations étaient automatiquement fluides et intègres sans que tu aies à faire quoi que ce soit. Difficile de faire plus simple… En SDL2, c'est à peine plus dur : il y a simplement un objet Renderer, associée à une fenêtre, qui sert à tout et à qui on peut demander ou non d'attendre ce retour à l'aide d'un flag. Le guide de migration est ici : https://jeux.developpez.com/tutoriel...ide-migration/

    Ce qu'il va falloir faire, surtout, c'est d'abord dessiner les sprites, et généralement ça prend du temps. Sur Thomson (et sur autres 8 bits exploités en Basic), on utilisait en général des caractères graphiques, caractères généralement définis par 8×8 pixels. Ça simplifiait énormément les choses.

    L'autre « difficulté » est que, dans ce même programme, on passait d'une colonne à l'autre, comme si on travaillait en mode texte. Aujourd'hui, tes sprites vont être un peu plus larges et ils vont se déplacer pixels par pixels, ou alors en sautant d'un nombre fixe de pixels à chaque frame (+3 pixels, +4, +5…) mais qui ne sera probablement pas de la largeur d'une colonne, surtout si tu autorises l'utilisateur à agrandir la fenêtre et, donc, à la redimensionner. Il faudra donc décider d'un seuil à partir duquel tu estimes que tu empiètes suffisamment sur la colonne suivante pour « déclencher » le départ de la voiture.

Discussions similaires

  1. [OS] Lire et écrire sur disquette
    Par trax44 dans le forum Programmation d'OS
    Réponses: 17
    Dernier message: 22/02/2004, 21h45
  2. [Debutant] Sdl & OpenGl link ne marche pas
    Par Riko dans le forum OpenGL
    Réponses: 9
    Dernier message: 18/02/2004, 17h13
  3. [opengl et sdl]
    Par Gonath dans le forum OpenGL
    Réponses: 6
    Dernier message: 08/12/2003, 10h49
  4. Autorun comment l'écrire
    Par Speed41 dans le forum Autres Logiciels
    Réponses: 3
    Dernier message: 25/04/2003, 15h55
  5. Un langage pour lire, traiter et écrire de gros fichiers
    Par March' dans le forum Langages de programmation
    Réponses: 19
    Dernier message: 07/04/2003, 16h26

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo