Je suis actuellement, en recherche sur mon projet de codage numérique, qui vise à reproduire l'image d'une météorite, à l'aide d'un tableau bidimensionnels de pixels. Le corps du programme a déjà été réalisé pour ma part, puisque la méthode doit être universel, et reste utilisé pour tous les autres exercices dans la même Matière. Ainsi, n'ayant pas réussi à déterminer comment débuter mon programme, je venais vers vous, pour savoir si vous pouviez m'apporter des explications sur la méthode pour que je puisse commencer mon programme et savoir dans quelle direction aller.
Nous utilisons cette formulation en C++ pour combiner des images en une :
unsigned long alphaBlending(const unsigned long p, const unsigned long s);
Nous utilisons également cette formulation quant aux dégardés de couleur nécéssaire à la réalisation du bandeau lumineux de la trainé de la météorite :
unsigned long monBlend(double a, unsigned long c1, unsigned long c2);
Voici L'image géométrique de la conception de la météorite :
On nous indique aussi :
Fonction
Teta --> r(Teta) est une fonction affine, c’est-à-dire de la forme Teta --> a X Teta + b où a et b sont des coefficients à déterminer sachant que r(0) = rMétéorite et que r(Teta Max) = 0 .
Voici l'image souhaiter à la fin :
Mon programme actuelle ressemble à cela (PS : Je n'ai toujours rien mis dans la structure car c'est principalement le but de ma question) :
#include <iostream>
#include <string>
#include "OutilsCreationImage.h"
using namespace std;
int main()
{
cout <<"création d'une image représentant un damier" << endl;
string chemin = "images_creees"; // chemin relatif : c'est-à-dire à partir du répertoire courant
string nomFichierImage = chemin + "\\" + "TestDamier_LosangeVFinal.bmp";
const uint32_t LONGUEUR = 400;
const uint32_t LARGEUR = 320;
uint32_t m = LARGEUR-1;
uint32_t n = LONGUEUR-1;
const uint32_t couleur1 = 0x40e5e5FF; // cyan opaque
const uint32_t couleur2 = 0xFFFF00FF; // jaune opaque
const unsigned couleurs[] = {couleur1,couleur2};
uint32_t matricePixels[LARGEUR][LONGUEUR];
... (parti à compléter)
OutilsCreationImage::creeImage( nomFichierImage, matricePixels, LARGEUR); // sauve l'image sur le fichier nomFichierImage
cout << "image créée" << endl;
return 0;
}
Merci encore de vos réponse, j'espère que vous saurez m'aiguiller dans le projet et m'indiquer s'il existe des erreurs (PS : Je précise, using namespace stp, ainsi que les UINT_32 sont obligatoire dans cette matière, car je ne suis encore actuellement qu'en niveau de Licence 1. Je n'ai donc pas les bases suffisantes pour utiliser les autres méthodes biens plus poussées et largement plus professionnel)
- Edité par JulienLORSCHEIDER1 15 novembre 2021 à 18:54:31
>Je n'ai donc pas les bases suffisantes pour utiliser les autres méthodes biens plus poussées et largement plus professionnel
C'est pas vous qui n'avez pas les bases, mais c'est vos prof. qui sont encore dans le millénaire passé.
La minière de faire la plus simple est largement fonction de vos background et des outils dont vous disposez.
Montrez ce que vous avez fait et qu'est qui coince concrètement pour faire la suite.
Ce qui coince réellement n'est pas forcément dans la programmation, c'est l'idée de définir la trajectoire de la météorite en C++, j'ai du mal à me l'imaginer, à me représenter en C++, je vois bien le schéma avec les points et valeurs, mais je ne comprend pas comment passer du schéma à une mise en place en C++
En vrai, c'est pas trop un exo C++. En termes d'apprentissage de la syntaxe du C++, c'est un exo très limité. Le but de cet exo (et le précédent dans le link rouloude), c'est plutôt d'apprendre à traduire en termes de code (peu importe le langage) un problème math.
Donc ça ne sert à rien de critiquer le code C++, ca sera de toute façon bof.
Tu as une fonction math à implémenter, de la forme :
Couleur calculerCouleur(x, y, paramètres de ta fonction...);
avec les paramètres qui sont le centre c, la theta max, etc.
Tu dois trouver sur papier quelle est la formule math a implémenter. C'est a priori un simple calcul de fonction affine avec un transformation en coordonnées polaire. L'écriture du code C++ sera trivial quand tu auras la fonction math.
Et ensuite, tu as juste a boucler sur x et y :
for (int x = 0...) {
for (int y = 0...) {
couleurs[x][y] = calculerCouleur(x, y, ....);
}
}
Comment détermines-tu ton shéma ou ta trajectoire? Tu l'imagines ou tu as des équations? Il y a les lois de Keppler et les lois de Newton. As-tu besoin d'équations différentielles? etc.
Le Tout est souvent plus grand que la somme de ses parties.
Vu la partie "On nous indique aussi" de son message, je pense qu'on lui donne les valeurs de r_meteorite, le centre c, theta_max, etc. Et c'est a lui d'écrire l'équation de la couleur en fonction de ces paramètres et de (x,y).
"Les coordonnées de C et M sont définies par rapport au repère de l’image (O,i,j) où O est le coin en haut à gauche de l’image. Les valeurs du rayon rMétéorite et des coordonnées de C et de M peuvent être définies en fonction des dimensions de l’image (hauteur et largeur).
L’angle Teta Max est orienté et défini en radians. Dans l’image ci-dessus, il vaut pi/8.
Les valeurs intéressantes pour rMétéorite et pour les coordonnées de C et de M peuvent être déterminées expérimentalement."
C'est l'équation mathématique, parce que, le professeur m'a mis le doute, il m'a indiquer que l'équation devait prendre en compte l'angle Teta en fonction de rayon. Il m'a dis que l'équation devait être défini avec cela, et puis il m'a préciser qu'il avait 4 zone à réaliser, je ne comprend pas pourquoi 4 zones ?
Aucune idee des 4 zones. Sur le dessin, tu n'as a priori rien a faire pour les zones 2 et 4 (si les numéros correspondent bien aux zones).
Et pour la formule math, tu as a priori toutes les infos :
- pour la zone 1, c'est juste un disque centré autour de M et de rayon r_meteorite
- pour la zone 3, c'est un triangle (en fait, 2 triangles rectangles) en coordonnées polaires, l'hypoténuse étant défini par la fonction affine donnée (tu as la taille d'un des bord, puisque c'est le r_meteorite, et l'autre bord qui correspond à la longueur de l'arc theta).
Mais c'est juste des maths, pas de la programmation.
D'accord j'ai bien visualiser pendent tous ce temps le problème j'ai compris l'idée de l'équation, mais je vois pas comment l'intégrer en C++. Mathématiquement cela ne me pose aucun soucis, mais il faut que l'intègre en C++ pour que je puisse à l'aide de ma boucle pour et de ma MatricePixels, créer l'image de Pixels que je souhaite avoir.
J'ai penser à attribuer des coordonnées au centre M de la météorite mais je n'ai pas su ou compris comment à l'aide ma boucle pour j'allais créer le cercle.
Si on reprend la fonction "calculerCouleur" du post de @gbdivers du 15 novembre 2021 à 23:47:48, vous devez déterminez, dans cette fonction, dans quelle zone (1 à 4) se situe le point aux coordonnées (x,y) passées en paramètre de la fonction.
En fonction de la zone, le mode de calcul de la couleur retourné par la méthode sera différent. Vous aurez donc un gros "if" dans le corps de "calculerCouleur" qui aiguillera les différents modes de calcul de la couleur résultante.
Pour que la fonction "calculerCouleur" puisse faire son oeuvre, il lui faudra plus que juste la paire (x,y) mais toutes les informations pour déterminer la zone de cette paire, d'où les "paramètres de ta fonction..." dans le post de @gbdivers.
>J'ai penser à attribuer des coordonnées ... l'aide ma boucle pour j'allais créer le cercle.
Il faut comprendre que votre "matricePixels" n'est qu'un échantillonnage "du réel" et n'est composé que de LARGEUR*LONGUEUR pixels (même si uint32_t est un nombre en principe et pas un pixel), chaque pixel contenant les composants R (pour rouge), G (pour vert), B (pour bleu) et A (pour la transparence/opacité). Chaque composant de RGBA tient sur 1 octet de 8 bits, donc 4*8=32, donc ça tient dans un "uint32_t".
La méthode "calculerCouleur" ne fait échantillonner "le réel" à un pas constant et y extraire une valeur 'RGBA" à chaque pas.
Vous construisez une "image matricielle" et pas une "image vectorielle" (qui décrit un "monde" et qui doit encore être échantillonnée pour être affichée sur nos moniteurs matriciels modernes, les affichages vectoriels n'existant plus depuis des décennies).
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Ah oui, quand à la fonction mon blend, qui permet effectivement d'avoir les couleur en dégrader je l'ai effectuer, mais dans un cas générale, si l'on souhaite un dégradé à la verticale sur toute une image, que le dégradé soit l'image en claire.
Voici la fonction monblend qui me permet d'avoir la couleur du milieu à partir de deux autres couleurs
Je pense qu'il faudrais donc simplement que je l'adapte pour qu'elle donne se rendu la, en fonction d'un "t" qui serais la variable que ferais varié les couleurs
- Edité par JulienLORSCHEIDER1 26 novembre 2021 à 10:55:02
Primo, on dégage ces "printf" qui sont du C, pas du C++.
Secondo, on dégage tous ces "print coucou" à la con, un débogueur, c'est pas fait pour les chiens.
Tertio, ligne 4, 5 etc..., ne pré-déclarez pas vos variables, on est plus dans du C des années 70.
Quarto, pourquoi récupérer a1 et a2, vu que vous ne vous en servez pas ? (à bin si, mais ça sent l'erreur à la con)
Quinto, la ligne 50 fait mal aux yeux.
Voilà pour les remarques de casse-couilles, mais en les suivant, votre code fera ~4/5 lignes, pas plus.
>Ah oui, quand à la fonction mon blend, qui permet effectivement d'avoir les couleur en dégrader
Et ne fantasmez pas, votre fonction ne fait que ce qui est écrit dedans, calculer une nouvelle couleur qui est une interpolation à partir de 2 couleurs "de base" et un coefficient d'interpolation. Et la ligne 47 montre que votre interpolation est "chelou".
>mais dans un cas générale, si l'on souhaite un dégradé à la verticale sur toute une image,
Quel rapport avec la question initiale ?
Pour faire un gradient de couleur, vous fixez les 2 couleurs extrêmes, le nombre de niveau du gradient (identifié par n par la suite), vous passez à la fonction "monblend" (corrigez ligne 47 SVP), les couleurs de départ et de fin ainsi que le nombre 1/(n+1) pour avoir la première couleur du dégradé, puis 2/(n+1) pour la seconde couleur, etc...
Pour avoir un dégradé de ce gradient de couleur verticalement, il suffit de mettre la même couleur sur l'ensemble des uint32_t de "matricePixels" qui sont dans la même colonne de ce tableau à 2 dimensions (ce qui est une connerie, mais bon).
EDIT :
Dans votre image d'exemple, il y a 4 gradients de couleurs qui s’enchaînent. Vous devez appliquer le résonnement ci-avant 4 fois, une fois par quart d'image.
- Edité par bacelar 26 novembre 2021 à 11:34:44
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Actuellement pour prendre le moins de place dans mon programme j'ai créer une second fonction suite à ma première fonction. Celle-ci me permet d'utiliser "monblend" mais d'utiliser aussi les paramètre t, qui serait en réalité les coordonnée sur un axe t qui serait vers la droite. t = 0 correspondrait à la première couleur et t = 2 à la dernière. Tout comme mon prof l'a suggérer.
Voici les paramètre que je pense intégrer à la fonction :
unsigned long melange(double t, double tDebut, double tFin, unsigned long couleurs [], int m);
Mais je ne sais pas quoi placer dans le corps de ma fonction.
Préalablement, j'ai tenté une autre solution, qui n'est pas concluante puisque le résultats n'est pas celui attendu pour seulement 3 couleurs à dégradés :
Je ne comprend absolument pas comment aboutir à un dégrader avec trois couleurs, dans le cas de deux couleurs j'ai très bien réussi et cela à fonctionner. Mais pour 3 couleurs voici le rendu...
Le professeur nous précise aussi cela quant à l'exercice : Je ne comprend ici pas ce qu'est le paramètre "m" ?
- Edité par JulienLORSCHEIDER1 28 novembre 2021 à 19:59:38
Votre prof. vous mâche le travail, comme un prof. de math qui connait plus le C que le C++, mais bon, c'est quand même une aide.
(en C++, on n'airait pas un tableau à la C et un paramètre "m" qui se baladent ; et un informatique (std::array et std::vector sont nos amis.), "t" aurait varié entre 0 et 1 ou entre 0 et "unParametreVector.size()", pas entre 0 et 2 et on ne se serait pas embarrassé tDebut et tFin (et on utiliserait pas cet horrible franglais.).)
Vous devriez donc commencez par implémenter la fonction "melange" (même si 2 paramètres : t et un std::vecteur/std::array serait mieux que ces 5 paramètres dont cet horrible tableau de "long", même pas d'uint32_t, putain de matheux même pas assez rigoureux (comment ça, je me venge sur les profs de math, mais pas du tout )).
Implémentez-la plus comme une fonction mathématique "toute bête" et ayant dans le paramètre "couleurs" des points du tableau de variation d'une fonction comme ceux dont on vous a goinfrer au lycée.
>Actuellement pour prendre le moins de place dans mon programme j'ai créer une second fonction suite à ma première fonction.
C'est quoi cette connerie de "place" ???
Votre truc, c'est plus un exo de math qu'un exo d'informatique. Les premières questions sont là pour constituer les briques de la question d'après. Donc, vous devez utiliser les questions d'avant pour construire les réponses d'après. Ne les mettez pas de côté, servez-vous en !
>j'ai tenté une autre solution, qui n'est pas concluante
Il y a pas mal d'erreurs "évidentes" dans le code que vous postez (outre le fait que c'est largement plus du C que du C++, encore un prof de math à qui on donne les cours d'info; et qui soit ne sait pas mis à jour, soit n'a pas compris la différence entre le C et le C++)
- Déjà, indentez correctement votre code (votre IDE est votre ami), cela permet de voir bien plus facilement les erreurs "à la con".
Exemple : que les bornes de la boucle ligne 84 ne correspondent pas avec celle ligne 95.
- 2 boucles quasi-identiques, ça sent pas bon, le principe DRY devrait vous guidez, et donc vous dire que la fonction "melange" proposée par votre prof (qui n'est pas un Léonard de Vinci du nommage de méthode, je vous l'accord), serait bien pratique pour n'avoir qu'une boucle imbriquée "bien propre".
- dégagez-moi fissa ces cast C ((double)), ça n'a rien à faire dans du code C++ et en plus vous castez un truc qui à déjà perdu l'information "importante".
((double)n)/2 != (double)(n/2)
Dans la partie droite, vous castez en double le résultat de la division entière, vous avez donc déjà "perdue" la partie fractionnaire.
coeff = j/(n/2.0)
C'est bien plus simple, et en plus, ça donne bien un double qui n'a pas perdu la partie fractionnaire.
Donc, si vous implémentez correctement la fonction "melange" votre code devrait ressembler à :
#define NELEMS(x) (sizeof(x) / sizeof((x)[0]))
...
int main()
{
...
for (j = 0 ; j <= n ; ++j)
{
uint32_t couleur = melange((j*2.0)/n,0,2,couleurs,NELEMS(couleurs))
for (i = 0 ; i <= m ; ++i)
{
matricePixels[i][j] = couleur;
}
}
...
}
>Je ne comprend ici pas ce qu'est le paramètre "m"
C'est juste la taille du tableau passé en paramètre "couleurs", donc un paramètre totalement "à la con" quand on sait que cette information est un champ intrinsèque aux instances de std::array ou std::vector du C++.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Il y a pas mal d'erreurs "évidentes" dans le code que vous postez (outre le fait que c'est largement plus du C que du C++, encore un prof de math à qui on donne les cours d'info; et qui soit ne sait pas mis à jour, soit n'a pas compris la différence entre le C et le C++)
Je suis complètement d'accord que le C et le C++ n'ont pas la même philosophie et qu'il y a vraiment des choses à comprendre qui ne se limitent pas à faire du "C with classes" MAIS est-ce que ça veut dire que le C est fondamentalement mauvais ? Si le prof avait appelé ça du C, vous auriez trouvé que c'est mieux ?
Et par rapport au C-style cast, est-ce que vous trouvez sincèrement que le static cast apporte quelque chose pour des conversions arithmétiques ? Etes vous sûr que ce n'est pas de la b******* intellectuelle ? Combien de temps et de bugs un static_cast va-t'il faire économiser à une équipe de dév ? Si la réponse est "beaucoup" alors utilisez-le et grand bien vous en fasse, mais si c'est juste parce que "le C++ commitee a décidé que, donc c'est comme ça", alors ce n'est pas une raison convenable, il faut tester et mesurer l'apport des "bonnes pratiques" puisque ce qu'on veut au final c'est mener à bien le projet, qu'il soit maintenable, etc.
Pour donner un exemple de cast où le "static_cast" se justifie :
enum class Foo {
A, B, C, D
};
class Bar {
public:
int faireQuelqueChose(Foo foo) const {
// On exploite notre cache pour éviter une pile de if
return cache_[static_cast<std::underlying_type_t<Foo>>(foo)];
}
private:
std::array<int, 4> cache_{8, 2, 9, 4};
};
Par contre pour de simples conversion int -> double ou autre, le code est quand même plus lisible avec des C-style cast, et de toute façon, j'ai envie de vous dire "kestuvafèr?", il est normal d'avoir ce genre de conversion à faire, c'est une fonctionnalité basique du CPU, ce n'est pas error-prone et l'atrocité illisible de static_cast ne se justifie pas dans ce genre de cas, contrairement au underlying cast de mon exemple, qui a potentiellement un côté "dangereux", et qu'il est donc bien de rendre visible et facilement greppable, "au cas où". Barney Starsoup le dit-lui même que c'est illisible (en parlant d'une conversion entre pointeurs) : "This form of explicit type conversion is inherently unsafe and ugly. Consequently, the notation used, static_cast (§11.5.2), was designed to be ugly and easy to find in code"
JadeSalina, toujours à se croire plus malin que tous les autres, c'est touchant, cette naïveté.
Les cast, c'est de la merde, en C ou en C++, c'est pareil. Et si c'est "illisible", ça rend conscient qu'on fait de la merde.
Si un cast est justifié, qu'il soit "illisible" ou pas, on sent cogne, s'il est là, c'est que la personne a dû mûrement y réfléchir.
Un cast à la C est intrinsèquement une débilité, car le programmeur ne contrôle plus rien, c'est de la merde, dans un beau papier d'alu.
Faire du C, why not, mais plus de "string", et de "cout", etc... alors. On ne peut pas avoir le beurre, l'argent du beurre, ....
Et quand on se prend des méga-lourdeurs totalement injustifiées (cf. le "m" imbittable, et c'est pas moi qui le dit mais le PO), parce que le prof. n'a pas revu son code qu'il à pomper sur le NET de sources datant du K&R(1978), ça me gonfle.
Tu peux mesurer autant que tu veux dans tes projets JadeSalina, ma "psycho-rigidité" sur le sujet du "cast à la C c'est nimp" m'a déjà fait gagné bien plus que mon ancienne psycho-rigidité que le C++ "ça sert à rien" que j'ai eu bien avant toi (mais il y a près de 30 ans).
>c'est une fonctionnalité basique du CPU
Ce qu'il faut pas entendre comme connerie, c'est quoi l'opcode de la conversion sur un CPU X86, STP ?
Et mattes un peu quelle version du CPU l'implémente.
Excuses-moi d'avoir connu les co-processeurs x87.
N'hésites pas à montrer ta supériorité en nous donnant le schéma des portes logiques qui fait la conversion des registres à 80bits de la FPU des x86 dans les registres "généraux" de l'ACU de ces mêmes x86.
>le C++ commitee a décidé que
Et généralement, c'est bien plus étayé comme argumentaire que tes appels à l'ignorance.
On peut être d'accord ou pas avec leur argumentaire, mais ça sent bien plus la réflexion que tes envolées sur "le C c'est mieux, la preuve, je comprends pas à quoi ça sert ce truc en C++".
Si le cast en C++ est si peu "naturel", c'est justement pour que le programmeur prenne la peine de sous-peser le bidule.
Et dans le code du PO, il n'y a absolument pas besoin de cast, à la C ou à la C++, dont le sous-pesage il aurait été utile, non ? (question rhétorique)
>j'ai envie de vous dire "kestuvafèr?"
Me marrer des inepties que tu sors pour justifier "tes positions".
(Joli extrait de Bjarne Stroustrup pour essayer de lui faire dire l'inverse du message du texte, que moi, pauvre crédule est gobé dans son entièreté, et Barney Starsoup, c'est qui, à oui, ton idole à qui tu fais dire n'importe quoi quand ça t'arrange, merci pour lui.)
A oui, c'est tellement "basique" que c'était même pas normalisé, mais c'était encore à une époque où le Cray du coin t'envoyait bouler quand les octets d'un int n'était aligné sur une frontière de mots.
C'est tellement "basique", bin, peux-tu nous donner où, dans les spécifications du C, les mécanismes de conversion vers et depuis les formats IEEE des virgules flottantes sont spécifiés ?
Une remarque quand même sur le code : c'est ton prof qui impose le uint32_t pour la couleur ? (Dans tes screenshots, c'est même "unsigned long", c'est encore pire). Parce c'est horriblement lourd et inutile tous tes calculs pour extraire chaque canal d'une couleur.
Perso, je m'attend a voir un code comme celui la pour ton problème :
En fait, cela montre justement le problème dont je parlais plus tôt (et Bacelar aussi) : dans cet exo, la problématique principale est de trouver cette fonction math à écrire. Et c'est pour ca qu'on se retrouve avec un code de très mauvaise qualité (d'un point de vue qualité logicielle).
Un exo qui se concentrerait sur l'apprentissage de la programmation et pas les maths se focaliserait justement sur ces aspects découpage du code en classes et fonctions, pour rendre le code de qualité (plus simple, moins de risque d'erreur, plus performant). C'est particulièrement flagrant dans ton code, quand on voit que tu as juste 1 seule fonction monblend.
Hors sujet : ca sert a rien de pré déclarer tes variables. Et utilise const si tu peux.
Je ne comprend absolument pas comment aboutir à un dégrader avec trois couleurs, dans le cas de deux couleurs j'ai très bien réussi et cela à fonctionner. Mais pour 3 couleurs voici le rendu...
Le rendu de 3 couleurs (ou plus, peu importe), c'est identique à mélanger 2 couleurs : tu mélanges la première couleurs avec la seconde, et la seconde avec la troisième, etc.
La formulation de l'exo est lourde, on sent le prof de math inutilement rigoureux. Mais pour autant, les infos sont présente. Par exemple, il est écrit que les couleurs s'expriment par c_0, c_1,..., c_m. Si tu as posé la question de à quoi correspond "m", c'est que tu as mal lu l'énoncé de l'exo.
On insiste, mais comme c'est un exo de math principalement, il faut que tu lises beaucoup mieux l'énoncé. C'est pas du tout des problématiques de programmation.
Un cas d'application pour voir si tu as compris les maths :
- si tu as t compris entre 2 et 9 et si tu as 5 couleurs, quelle est la couleur pour t=7.3 ?
(tu dois pouvoir répondre, sans code, et en expliquant ton raisonnement math)
comment vous faites pour avoir des variables entières (par exemple un int i) et l’utiliser dans des opérations flottantes ? Un cast est nécessaire, du moins pour éviter la division entière, si les autres variables ne sont pas flottantes. Et cast ou pas, la conversion devra se faire sur le CPU, autant le rendre explicit un glissant un petit (float ou autre. Etes vous en train de dire qu’il vaut mieux se reposer sur les conversions implicites plutôt de dire explicitement que la variable doit être castée ? c’est dans ces cas là que le c-style cast est intéressant, il est concis et permet de voir explicitement qu’une conversion arithmétique est nécessaire, puisqu’elle EST nécessaire de toute façon, même si c’est pas écrit explicitement.
et vous dites "plus de cout" ?? Mais j’ai envie de vous dire tant mieux ! En C++20 arrive std::format et print en C++23, qui sont beaucoup mieux que ces horreurs de streams (peut être que pour l’instant vous trouvez que c’est bien mais attendez que ça sorte et qu’ils vous disent que c’est la nouvelle manière de faire, et je suis sure que vous allez changer).
"le prof. n'a pas revu son code qu'il à pomper sur le NET de sources datant du K&R(1978), ça me gonfle."
ca cest aussi quelquechose que je déteste, mais il y a une différence entre quelqu’un qui reste bloqué en C parce qu’il a l’habitude et flemme d’évoluer et ce que je suis en train de dire. petite question, est-ce que vous allez toujours faire du C++ de manière "religieuse" ou bien est-ce que si de nouveaux langages sortent vous pourriez y passer ? Si vous comptez toujours faire du C++ parce que "olol c’est cool on est des programmeurs Hardcore" ce n’est pas une bonne raison, la bonne raison est qu’il faut faire les choses qui permettent vraiment d’atteindre de meilleurs résultats et d’evoluer etc
@gbdivers La fonction `mix_canaux` est pas tiptop, déjà le calcul se fait en double, il faudrait au minimum arrondir avant de renvoyer un uint8_t (ça je pense que le compilateur prévient de toute façon), et ensuite, les uint8_t sont bien pour le stockage mais pas forcément pour manipuler l'image, les floats seraient mieux. Et pourquoi il vaut mieux mettre const sur des variables locales ? Je me suis déjà fritée sur le forum C à ce sujet. Quand on écrit l'algorithme, on fait en sorte que ça marche, donc si il faut modifier une variable bah c'est comme ça et quand on lit l'algorithme, de toute façon on le voit bien si la variable est modifiée ou pas, c'est redondant de le marquer dans la déclaration je trouve.
Après vous parlez de qualité logicielle, mais il n'y a pas que la lisibilité, il faut aussi prendre en compte le résultat final, si le logiciel est lent comme pas possible c'est pas cool. Si le logiciel est aussi mal fait que l'éditeur de message OC, ce n'est pas la peine d'avoir du code lisible (je suis à 2 doigts de balancer la tablette par la fenêtre tellement c'est lourd à utiliser)
- Edité par JadeSalina 29 novembre 2021 à 18:10:06
JadeSalina, c'est bien beau tes discours, mais faudrait quand même regarder un peu le code qui est posté, par le PO et par moi, de temps en temps.
>comment vous faites pour avoir des variables entières (par exemple un int i) et l’utiliser dans des opérations flottantes ?
Et la ligne 9 du dernier code que j'ai posté, c'est du poulet ? bordel !!!
(j*2.0)/n
C'est pas plus explicite qu'un cast à la con (C ou C++) ?
Le cast C est tellement génial que le pauvre PO c'est fait avoir par le parenthésage totalement abusé de la merveilleuse syntaxe C. LOL
>Un cast est nécessaire,
Oui, un cast est nécessaire, quand il est, ce qui n'est vraiment pas le cas dans le code du PO. On atterrit quand votre sainteté des cieux immaculés ?
>la conversion devra se faire sur le CPU
Toi, t'as toujours pas compris ce qu'est un x87 (co-processeur).
>autant le rendre explicit
Oui, aussi explicite que le permet le C++, qui permet, lui, de contrôle quel type de cast on veut et pas juste dire aux compilateurs : "fermez vos gueules, je gère (la fougère)".
>qu’il vaut mieux se reposer sur les conversions implicites plutôt de dire explicitement que la variable doit être castée ?
Bon, y en a marre, t'as technique à 2 balles de l'homme de paille, on la connait depuis des lustres, "Dont food the troll".
>et vous dites "plus de cout" ?? Mais j’ai envie de vous dire tant mieux !
GG, t'as enfin compris, il faut réfléchir, on voit la lumière, enfin !!!
J'ai jamais aimé les streams moins non plus, c'est trop chouppy, on va être copain pour la vie.
Les "cout", comme les string, c'est dans le code du PO. Moi, je parts du code du PO (je fais peut-être 2/3 remarques désobligeantes sur le niveau du prof. de math hybernatus c/C++), mais j'ai la décence de partir d'un code du PO et pas de sortir des codes complètement claqués au sol qui n'ont rien à voir avec la choucroute.
>peut être que pour l’instant vous trouvez que c’est bien mais attendez que ça sorte et qu’ils vous disent que c’est la nouvelle manière de faire
Non mais, coco, tu nous prends vraiment pour des lapereaux de 6 semaines ?
La majorité des personnes que tu rabroues, ils ont connus une époque où le C++ n'existait, puis où il n'était même pas standardisé, etc...
Notre manière de coder, elle a bien changée en plus de 30 ans, crois-moi ; et clairement, elle continuera de changer, fort heureusement.
>Si vous comptez toujours faire du C++ parce que "olol c’est cool on est des programmeurs Hardcore"
Toi, ça fait longtemps que t'as pas eu un entretien d'embauche dans une SSII, ou t'en a jamais eu. Sinon, ton cliché de codeur C++ barbu au fond d'un bureau, ça serait du second degré et comme disait Desproges : "on peut rire de tout mais pas avec n'importe qui".
Désolé JulienLORSCHEIDER1 pour cette interférence avec tes demandes, et aussi à JadeSalina pour mes moqueries, mais faut pas pousser mémé dans les orties.
Revenons à nos moutons et la dernière intervention de gbdivers et plein de bon sens. ;-)
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Tu parles de syntaxe sur un code où j'ai écrit explicitement "(code pas testé)" et qui sert plus à montrer le problème d'approche dans son code (non utilisation de classes et mauvais découpage du code) ?
Ma réponse : je m'en tape.
JadeSalina a écrit:
déjà le calcul se fait en double
Relis l'exo, t est un double.
JadeSalina a écrit:
sont bien pour le stockage mais pas forcément pour manipuler l'image, les floats seraient mieux.
Relis l'exo, il est explicitement dit que chaque composant est un octet.
JadeSalina a écrit:
Et pourquoi il vaut mieux mettre const sur des variables locales ?
de toute façon on le voit bien si la variable est modifiée ou pas, c'est redondant de le marquer dans la déclaration je trouve.
C'est redondant par rapport à quoi ? Ecrire explicitement "const" pour dire qu'une variable est constante est redondant par rapport au fait de lire le code et d'en déduire que la variable n'est pas redondante ?
C'est idiot, écrire explicitement un truc, ce n'est pas redondant avec déduire un truc implicite.
On veut exprimer qu'une variable ne change pas, on écrit "const".
JadeSalina a écrit:
Après vous parlez de qualité logicielle, mais il n'y a pas que la lisibilité
Super. Vu que c'est exactement ce que j'ai écrit aussi.
JadeSalina a écrit:
il faut aussi prendre en compte le résultat final, si le logiciel est lent comme pas possible c'est pas cool.
Argument qui ne repose sur rien de concret. Aucune raison de penser que découper en structure et fonctions comme je l'ai fait a un impact sur les performances.
C'est même le contraire, vu que cela évite tous les bit shift pour extraire les composants rgb.
---------------------------------------------
Tu es lourd avec tes interventions. On s'en tape du C versus C++. Et tes arguments sont moisis en général. Tu fais perdre du temps au PO et a nous aussi.
J'ai pu évoluer sur le projet, en effet j'ai terminé et déterminer la fonction mélange qui se sert de la fonction monBlend, et qui me permet d'avoir le dégradé de couleurs de la météorite.
Voici la fonction mélange dans le programme de réalisation de la matrice pixel :
#include <iostream>
#include <string>
#include "OutilsCreationImage.h"
#include "Prog_Dégradé.h"
using namespace std;
uint32_t melange1(double t, double tDebut, double tFin, uint32_t couleurs [], int m){
double x;
x = m*(t-tDebut)/(tFin-tDebut);
int i;
i = (int)x;
double a = x - i;
return monblend(couleurs[i], couleurs[i+1], a);
}
int main()
{
cout <<"création d'une image représentant un dégradé de couleur" << endl;
string chemin = "images_creees"; // chemin relatif : c'est-à-dire à partir du répertoire courant
string nomFichierImage = chemin + "\\" + "TestDégradéMultiCouleurs.bmp";
const uint32_t LONGUEUR = 400;
const uint32_t LARGEUR = 320;
uint32_t m = LARGEUR-1;
uint32_t n = LONGUEUR-1;
const uint32_t couleur1 = 0x000000FF; // Noir opaque
const uint32_t couleur2 = 0xFFAC1CFF; // Orange opaque
const uint32_t couleur3 = 0xFFFFFFFF; // Blanc opaque
const uint32_t couleur4 = 0xFFAC1CFF; // Orange opaque
const uint32_t couleur5 = 0x000000FF; // Noir opaque
uint32_t couleurs[] = {couleur1,couleur2,couleur3,couleur4,couleur5};
uint32_t matricePixels[LARGEUR][LONGUEUR];
uint32_t i,j;
for (i = 0 ; i <= m ; ++i) // remplissage de la matrice de pixels
for (j = 0 ; j <= n ; ++j)
{
double coeff;
coeff = j/(double)n;
uint32_t couleur;
couleur = melange1((double)j, 0.0, (double)LONGUEUR, couleurs, 4);
matricePixels[i][j] = couleur;
}
OutilsCreationImage::creeImage( nomFichierImage, matricePixels, LARGEUR); // sauve l'image sur le fichier nomFichierImage
cout << "image créée" << endl;
return 0;
} //main
Voici ci-joint le fichier .h qui recense la fonction monBlend :
Ayant fais tourner le programme, l'image finale ressemble à cela :
Je cherche maintenant à appliquer cette méthode mais sur l'équation de la météorite que je peine à déterminer. C'est vraiment le plus gros de mon soucis, je me demande comment la réaliser parce que je ne sais pas par quel bout prendre la chose. J'ai bien constater un cercle qui réalise le bout de la météorite, mais je peine à savoir comment assembler le tout et insérer chaque paramètre...
- Edité par JulienLORSCHEIDER1 7 décembre 2021 à 12:07:10
Tu as une méthode qui te donne le secteur de l'image en fonction de (x,y).
Tu as une méthode qui donne la distance de (x,y) au(x) point(s) remarquable(s) du secteur.
En fonction de la distance, tu appliques un mélange entre la couleur "primaire" et la couleur du fond (l'image avec les étoiles au fond de ta deuxième illustration).
=> tu auras une image proche de ta 2ème illustration.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Le fond de l'image avec des étoiles n'est lui pas à réaliser en c++, il est à juxtaposer à la météorite créer par le programme à l'aide de Gimp, qui est un outils de dessin. C'est pourquoi, je pense qu'il est simplement nécéssaire alors je suppose de déterminer les méthodes que tu m'a conseillé
"j" est un double, "n" est un uint32_t, le cast ne sert à rien puisque le "n" sera automatiquement converti en double. MAIS l'avantage de le mettre c'est qu'on voit directement qu'il y a une conversion à faire (elle se fera dans tous les cas, elle est nécessaire). En voyant explicitement la conversion, on peut par exemple réorganiser le code et directement déclarer le "n" en double pour éviter de le convertir à chaque opération, ou des trucs comme ça. En omettant le cast, on passe à côté de cette conversion qui peut être couteuse (int -> double c'est pas la même chose que int -> unsigned, qui ne coute rien).
On en vient au vif du sujet, vous êtes donc en train de suggérer de soit mettre un static_cast qui rend le code illisible (et c'est son but), soit ne pas mettre de cast, ce qui cache la conversion. De toutes les fois ou j'ai parlé du cast à la C, c'est précisément et uniquement dans ce contexte que je trouve qu'il est plus intéressant que de mettre un static cast illisible voire pire rien du tout.
En gros si on devait classifier ce cast, ça serait "pour les conversions anodines qui sont de toute façon nécessaire et qui se feront dans tous les cas quoi qu'il arrive". C'est le seul usage intéressant du cast à la C. Si on suit cette convention, alors toute le monde comprend en voyant ce type de cast qu'il s'agit d'une conversion numérique anodine. Le static cast est fait pour les conversion "douteuses" qui peuvent mettre en évidence un problème de design, mais ce n'est pas le cas ici.
Voilà c'est tout pour moi n'oubliez pas de vous abonner et laisser un like
>je trouve qu'il est plus intéressant que de mettre un static cast illisible voire pire rien du tout
GG, tout faux, c'est bien mieux de ne pas polluer le code avec des considérations d'optimisation totalement mal venues à ce niveau du projet.
Si vous voulez vraiment des performances, c'est pas avec un cast tout merdeux que vous allez en avoir des "plus intéressantes".
Donc oui, faire simplement de "n" un double ne pollue pas le code et permettra d'utiliser plus tard des bibliothèques mathématiques qui feront bien mieux qu'un cast foireux (utilisations d'extension du code set comme MMX, etc...).
>alors toute le monde comprend en voyant ce type de cast qu'il s'agit d'une conversion numérique anodine
C'est surtout la trace d'une mauvaise analyse du domaine numérique du "problème".
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Voici ce que nous venons de recevoir de la part du professeur, un fichier .h qui retrace un grand nombre de fonction de distance, etc... Je vouals savoir comment les utilisés dans mon programme...
Le fichier OutilGeometrie.h :
/*
* OutilsGeometrie.h
*
* Created on: 6 déc. 2020
* Author: Dom
*/
#ifndef OUTILSGEOMETRIE_H_
#define OUTILSGEOMETRIE_H_
#include <cmath>
#include <sstream>
#include <string>
#include <iostream>
using namespace std;
#define PI 3.1415926
/**
* Représente un nombre complexe sous forme cartésienne
*
* Rappel : un nombre complexe z, dans la représentation cartésienne s'écrit sous la forme :
*
* z = x + i*y avec x et y nombres réels
*
* */
class Complexe
{
public:
double x,y;
/** construit le nombre complexe x + i y */
explicit Complexe ( const double & x = 0, const double & y = 0) : x(x),y(y){}
operator string() const { ostringstream o; o << "( " << x << ", " << y <<")"; return o.str(); }
friend ostream & operator << ( ostream & o, const Complexe & z) { return o << (string) z; }
/** opposé d'un nombre complexe */
const Complexe operator -() const { return Complexe ( -x, -y); }
/** somme de 2 nombres complexes */
const Complexe operator + ( const Complexe & z) const { return Complexe ( x+z.x, y+z.y); }
/** différence de 2 nombres complexes */
const Complexe operator - ( const Complexe & z) const { return *this + -z; }
/** produit de 2 nombres complexes */
const Complexe operator * ( const Complexe & z) const { return Complexe ( x*z.x - y*z.y, y*z.x + x*z.y); }
/** produit d'un nombre complexe par un nombre réel à droite */
const Complexe operator * ( const double & a) const { return Complexe ( x*a,y*a); }
/** produit d'un nombre complexe par un nombre réel */
const Complexe operator / ( const double & a) const { return (*this)*(1/a); }
static double produitScalaire( const Complexe & z1, const Complexe & z2) { return z1.x*z2.x + z1.y*z2.y; }
/**
* déterminant de 2 nombres complexes
* */
static double det( const Complexe & z1, const Complexe & z2) { return z1.x*z2.y - z1.y*z2.x; }
/** calcule le carré de la norme euclidienne de z (ou le carré du module si on préfère )*/
static double norme2( const Complexe & z) { return produitScalaire(z,z); }
/** calcule la norme euclidienne de z (ou le module si on préfère )*/
static double norme( const Complexe & z) { return sqrt(norme2(z)); }
/** calcule l'angle orienté de z1 vers z2, ce qui revient à calculer l'argument de z2/z1
* l'angle calculé est en radian et appartient à l'intervalle [-PI,+PI]
* */
static double angleOriente(const Complexe & z1, const Complexe & z2)
{
double n12 = norme2(z1);
if (n12 == 0) throw invalid_argument("Complexe::angleOriente(z1,z2) : z1 est nul");
double n22 = norme2(z2);
if (n22 == 0) throw invalid_argument("Complexe::angleOriente(z1,z2) : z2 est nul");
double n1 = sqrt(n12);
double n2 = sqrt(n22);
Complexe u1,u2;
u1 = z1/n1;
u2 = z2/n2;
double cosu1u2 = produitScalaire(u1,u2);
double sinu1u2 = det(u1,u2);
return atan2(sinu1u2,cosu1u2);
}
}; // fin de la classe Complexe
/** produit d'un nombre complexe par un nombre réel à gauche */
inline const Complexe operator * ( const double & a, const Complexe & z) { return z*a; }
//------------------------------------ distance entre 2 points ------------------------------------------------------------
/** calcule la distance entre le point (x1,y1) et le point (x2,y2) */
inline double distance( double x1, double y1, double x2, double y2)
{
Complexe z1(x1,y1), z2(x2,y2);
return Complexe::norme(z1-z2);
}
//------------------------------------ distance au carré entre 2 points ------------------------------------------------------------
/** calcule le carré de la distance entre le point (x1,y1) et le point (x2,y2) */
inline double distance2( double x1, double y1, double x2, double y2)
{
Complexe z1(x1,y1), z2(x2,y2);
return Complexe::norme2(z1-z2);
}
//------------------------------------ angle orienté dans un triangle ------------------------------------------------------------
/** calcule l'angle orienté dans le triangle formé des 3 sommets [(x1,y1),(xCentre,yCentre),(x2,y2)]
*
* Dans cet ordre-là. (xCentre,yCentre) est le centre de la rotation qui transforme la droite ((xCentre,yCentre),(x1,y1))
*
* vers la droite ((xCentre,yCentre),(x2,y2))
*
* le calcul est possible seulement si les 3 points sont distincts
*
* l'angle calculé est en radian et appartient à l'intervalle [-PI,+PI]
* */
inline double angleOriente(double x1, double y1, double xCentre, double yCentre, double x2, double y2)
{
Complexe z1(x1,y1), c(xCentre,yCentre), z2(x2,y2);
return Complexe::angleOriente(z1-c,z2-c);
}
#endif /* OUTILSGEOMETRIE_H_ */
Manifestement, c'est une lib assez généraliste, c'est a toi de choisir ce que tu veux utiliser ou pas. Je pense pas que tu dois tout utiliser.
(Par contre, écrire une classe Complexe alors qu'il existe déjà std::complex... Et vraiment, il y a des choses qui ne vont pas dans ce code Mais bon, ce n'est pas le sujet)
Par contre, je me permet de te poser une question : je pensais initialement que tu étais en étude post bac. C'est le cas où tu es au lycée ? (Pour avoir une idée de ton niveau en math).
Je continue d'insister sur un point : c'est avant tout un problème de math, pas d'info. Tu dois faire 80% du boulot sur un feuille de papier avec un crayon, pour poser le problème math et le résoudre. Tu ne dois pas t'attendre a avoir une piste de solution simplement avec du code que le prof t'envoie.
Et donc, comme tout problème de math, il faut que tu réussisse à décomposer un problème complexe en petits problèmes plus simple à résoudre. C'est ce que tu as fait par exemple avec la problématique du blend, qui est isolable et plus simple que le problème général.
(Par exemple, j'aurais fait un changement de repère, de façon à ce que cM soit unitaire et correspond à l'abscisse, que Theta correspond a 90 degrees (Pi/4). C"est une approche ultra classique en programmation graphique 2D/3D).
En fait, c'est probablement ce que tu devrais faire : ne plus poster de code, mais montrer les démos math que tu as fait sur papier.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Le Tout est souvent plus grand que la somme de ses parties.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.