Discussion :

[yopso]

Bonjour, quelqu'un peut-il me fournir un programme simple pour faire un point graphique plein écran en C avec geany sous raspbian ?
Cordialement

[Jamatronic]

Quelle bibliothèque comptez-vous utiliser pour faire vos affichages ? La réponse en dépend grandement

[yopso]

Quelle bibliothèque comptez-vous utiliser pour faire vos affichages ? La réponse en dépend grandement

Je veux simplement afficher un pixel à l'écran en c avec geany sous raspbian

[Kannagi]

Et google est trop complexe à utiliser ?
Sinon , tu peux utiliser la SDL pour ça (les exemples ne manque pas ).

[Jamatronic]

Je veux simplement afficher un pixel à l'écran en c avec geany sous raspbian

Bon, vu que tu ne sembles pas décidé à répondre à la question simple que je t'avais posée, mettons que tu choisisses SDL 2.0.

Mettons que tu veuilles, dans une SDL_Texture toto créée avec le flag "SDL_TEXTUREACCESS_STREAMING" (ce qui est conseillé dans le
cas où tu veux écrire dans la texture pixel par pixel, selon le wiki de www.libsdl.org), colorier en rouge complètement opaque
(FFFF0000 en hexadécimal, sous réserve que la texture ait bien été créée avec ARGB comme ordre des composantes d'un pixel), le pixel
d'abscisse 30 et d'ordonnée 200.

Ton code peut alors ressembler à :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
void* image_buffer_ptr;
int pitch;
SDL_LockTexture (toto, NULL, &image_buffer_ptr, &pitch);
pitch /= 4;
 
Uint32* pixels_ptr = (Uint32*) image_buffer_ptr;
 
pixels_ptr[30 + pitch * 200] = 0xFFFF0000; /* c'est ici qu'on met du rouge où on voulait */
 
SDL_UnlockTexture (toto);

Mais la texture ainsi modifiée, il faut encore l'afficher sur le SDL_Renderer ren de ton programme
pour que le résultat soit visible à l'écran.
Si le SDL_Renderer a les mêmes dimensions que la texture toto, et si tu veux copier toute
la texture sur le Renderer, tu vas avoir du code comme :

Code :

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

1
2
3
 
SDL_RenderCopy (ren, toto, NULL, NULL); /* copie du contenu de la texture sur le renderer */
SDL_RenderPresent (ren);                        /* mise à jour du résultat à l'écran */

Je te vois tout de suite donner cinq objections à ma réponse :

1- Tu n'as pas dit que tu avais choisi SDL 2.0...
===> Ok mais je t'ai posé une question dans le but de t'aider et tu m'as répondu comme si j'étais un âne qui n'avais pas bien compris ta question.

2- Tu trouves sans doute que c'est compliqué d'écrire tout cela pour afficher un pixel...
===> Ca l'est en effet. Mais en pratique on ne se fait pas ch... à écrire un programme juste pour afficher un pixel.
===> On affiche des sprites, ou encore des images complètes calculées pixel par pixel, ou encore du texte, etc. et là tout de suite
ça devient plus intéressant car le code à écrire ne semble plus du tout énorme par-rapport à ce qu'on arrive à faire avec.

3- Tu constates qu'il manque plein de choses à mon code pour en faire un programme exécutable :
il faut créer la texture, ce qui implique de comprendre ce que c'est et comment SDL 2.0 "implémente" la chose,
il faut créer le renderer, et aussi une window au passage, même si on veut faire un affichage plein écran...
et il faut bien sûr une fonction main pour que le programme soit exécutable, et il faut les bonnes
options de compilation et d'éditions des liens, et il faut en fait avant tout installer SDL 2.0.
===> Ben oui mais est-ce que tu peux imaginer tout le temps qu'il faudrait pour t'expliquer tout cela ?
===> Alors qu'il existe de tonnes de doc déjà existantes sur le sujet ?

4- Tu te demandes à quoi servent les paramètres mis à NULL de certaines fonctions de SDL 2.0...
===> Là encore il existe plein de docs sur le sujet.

5- Finalement tu rages parce que tu te rends compte que tu ne comprends pas un mot au code que
j'ai écrit.
===> Si tu pars de zéro, et c'est visiblement le cas, c'est parfaitement normal.
===> Conclusion j'ai mis quarante minutes à te répondre pour rien alors que TOUT EXISTE
DEJA DANS DES DOCS ET QU'ON A MIEUX A FAIRE QUE DE REECRIRE CES DOCS EN MOINS
BIEN JUSTE POUR TOI.

En résumé :
-- mets-toi au travail ;
-- prend le temps nécessaire ;
-- pose des questions réalistes après avoir vraiment bossé si tu es toujours coincé à un moment...
c'est dans ce genre de cas qu'on sera HEUREUX d'essayer de te répondre.

Et j'ajoute que :
une réponse simple à ta question, du genre :
PUTPIXEL 30, 240, RED.

ça n'existe pas en C. D'où le fait que je classe ta question d'aujourd'hui dans les questions "peu réalistes". Afficher un simple pixel dans un langage "barbare" comme le C, ce n'est pas si horrible en réalité que tu peux le penser en lisant le code ci-dessus avec tes yeux de novice, mais cela nécessite tout de même d'avoir un paquet de pré-requis qui ne s'acquièrent pas en trois jours, ni même trois semaines. (Ni même trois mois si tu as un QI inférieur à 140 )

Donc ne crois pas que tu nous as posé une question super simple et qu'on ne te répond pas parce qu'on
n'a pas compris la question ou parce qu'on est méchant.

[yopso]

Bon, dans ce cas, est-il possible en C d'envoyer 1 octet à l'adresse correspondant au milieu de l'écran de manière à afficher un point ?
En tout cas merci pour ta réponse, effectivement il y a google, et beaucoup de documentation mais c'est moins claire pour moi que vos explications directes.

[Jamatronic]

Bon, dans ce cas, est-il possible en C d'envoyer 1 octet à l'adresse correspondant au milieu de l'écran de manière à afficher un point ?

Je suppose que oui, mais que la manière de faire est différente d'une architecture à l'autre... Nous ne sommes plus dans les années 80 / 90 dans lesquelles il était normal d'adresser directement la mémoire vidéo (qui était souvent de la ram ordinaire en fait) et d'avoir à réinventer la roue dès qu'on devait écrire le même logiciel sur deux machines (même légèrement) différentes.

EDIT : 1 seul octet pour modifier la couleur d'un pixel ? En 2020 ? Pourquoi ? Tu travailles encore avec un PC qui n'affiche des images indexées en 256 couleurs ?

effectivement il y a google, et beaucoup de documentation mais c'est moins claire pour moi que vos explications directes.

Alors concernant SDL 2.0, cela m'étonnerait Le wiki de libsdl.org est irréprochable.

Si ton niveau actuel en C ou en "image" ne te permet pas de te plonger dedans, ce n'est pas avec quelques échange de posts sur un forum qu'on s'en sortira...

Parce que là, au mieux, tu as besoin de quelques tutoriels pour démarrer (et il y en a dans les parages, que nous n'allons tout de même pas paraphraser), et au pire il faut revoir (ou voir) les bases de programmation. Mais des vraies bases, hein, dignes d'un enseignement universitaire ; pas d'un cours style "la programmation pour ceux qui ne veulent pas apprendre à programmer".