Tu crée un vecteur avec un rayon qui ne bougera pas, puis tu augmente l'angle par pallier et à chaque fois tu relie le point obtenu au bout du vecteur.
Plus tu auras de palliers et plus ton cercle paraîtra rond.
Oui, tu es obligé de discrétiser le cercle (l'approximer si tu veux) en polyline. A toi de calculer un palier correct qui te permettra d'avoir un beau cercle, sans avoir un million de segments. la trigo est ton amie
J'ai compris les coordonnées polaires, l'addition de vecteurs mais j'ai pas compris comment créer des vecteurs !!
Quelqu'un pourrai me faire un petit code d'exemple siouplait :).
- la fonction glClearColor() attend des flottants, situés entre 0 et 1 inclus, pas des valeurs entre 0 et 255 inclus ;
- c'est pas très beau de séparer le glEnd() de ta fonction dessiner.
Citation : titouille56
Quelqu'un pourrai me faire un petit code d'exemple siouplait :).
float vecteur[3];
Et en C++, il existe le type std::vector je crois...
Secret (cliquez pour afficher)
Pour créer un cercle plein :
/* PI */ #ifndef M_PI #define M_PI 3.14159265358979323846 #endif
void drawFillCircle(int faces) { int i; float angle;
Et en C++, il existe le type std::vector je crois...
Houla attention.
Oui ça existe mais ça na rien à voir avec des vecteurs.
C'est un conteneur, en gros une classe permettant de créer et manipuler des tableaux plus facilement.
OpenGL est fait pour le rendu, on n'affiche pas un vecteur !
A toi d'utiliser l'arithmétique des vecteurs, de te faire des classes si tu veux, de calculer les points dont tu auras besoin, a coup d'opérations mathématiques, et des les déclarer a OpenGL avec glVertex
Il demandait la façon de créer un vecteur, pas de le manipuler. Je pense que std::vector est utilisé en C++ tout comme les tableaux sont utilisés en C... ?
Je pense que std::vector est utilisé en C++ tout comme les tableaux sont utilisés en C... ?
Ca dépend des personnes j'imagine.
Personnelement je n'utilise un std::vector que si j'en ai vraiment besoin (augmentation de la taille dynamiquement, allocation manuelle de la mémoire etc...)
Sinon je fais un bon vieux tableau classique, qui est plus léger au niveau de la syntaxe.
Sinon pour les vecteurs on peut faire pleins de choses différentes en C++.
Une simple structure ou une super classe avec toutes les opérations pouvant être utiles inside.
c'est vrai que tu peux ranger un vecteur dans un std::vector<float> mais bon... c'est se casser la tete pour rien.
En C++, on n'utilise pas non plus systématiquement std::vector, on utilise encore des tableaux "normaux" : ça reste plus rapide que std::vector.
pour stocker un vecteur FIXE de degré 2 ou 3, je ne suis pas sur qu'il faille s'enquiquiner avec un std::vector...
Tiens justement, je regardais à l'instant une discussion à ce sujet ; il semblerait qu'une bonne utilisation de std::vector n'est pas moins rapide (à partir du 3eme post) :
"C'est pas très portable "
--> C'est pour un Benchmark. Je pars toujours du principe que le gars capable de détecter la portabilité est également assez intelligent pour adapter l'algo sur le systeme qui lui convient
La chose pas portable ici, c'est la mesure du temps, en effet.
Non, dans cet exemple, je n'ai pas utilisé d'iterateurs (j'utilise davantage les itérateurs surs les map, list, set, et autres conteneurs), mais la, c'est du random-access iterator, donc j'utilise pas. Peut etre devrais-je
Quoiqu'il en soit, je suis surpris par les bonnes perfs de std::vector en release ici ! Je m'attendais a largement pire
(j'utilise davantage les itérateurs surs les map, list, set, et autres conteneurs)
Remarque tout à fait à part, les maps ne sont pas du tout faites pour être itérées. En effet, comme il s'agit d'une table associative, l'acces associé aux données associée à une clé est en O(log(n)), avec n le nombre d'entrées dans la map. C'est a dire que le temps d'acces "direct" est proportionnelle au nombre d'entrées dans la map. De plus, pour pouvoir être utilisées comme clé dans une map, un type doit avoir une sémantique de comparaison (si ça se dit comme ca.): les clé doivent pouvoir etre comparées, et donc pouvoir être ordonnées. Tous ces indices mènent a croire que le stockage des données dans une map se fait grace a un arbre dichotomique. On en déduit que les performances d'une iteration a travers un map sont catastrophique.
Ceci est un avis tout à fait personnel, et uniquement basé sur la doc de la stl, et une expérience personnelle. Je n'ai pas été verifier dans le code source...
Oui, dans l'utilisation standard des maps, tu n'utilises pas d'itérateurs (je te confirme d'ailleurs qu'en interne, on a affaire a un arbre binaire de recherche)
Si tu veux dumper une map par contre, tu es obligé d'y aller avec un itérateur D'ou mon utilisation d'itérateurs pour les maps, mais dans ce cas la uniquement bien sur !
hey, moi j'ai jamais appris le c++, je connais que le C, si je poste ce topic là c'est parce que dans le tuto de kayl, il code en c++ donc moi, std::vector, connais pas . Mais merci à Yno de m'avoir donné la réponse.
Pour mon bug, j'ai tout réécris et ça a bien compilé.
Pour le cercle, j'ai mis toutes les variables, j'ai inclu math.h mais quand je compile, ma fenêtre est vide.
Voila le code que j'ai mis:
la différence entre debug et release ?
-->
En debug, il y a du code de rajouté : des tests de debuggage, du control d'exeption, des données initialisées pour le debug, des tests supplémentaires, plein de truc dont le but est de faire en sorte que si ça plante, le programme t'arrete la ou ça a planté : que tu puisses consulter les variables, remonter la pile, bref, débugguer (d'ailleurs, si tu n'utilises pas le debuggueur, je te le conseille vivement !)
En release, le programme est fait pour tourner : pas d'infos de debuggage, pas d'initialisations si tu ne les a pas faite, pas de tests que tu n'as pas demandé : un programme qui va donc carrément plus vite !!
En général, ce qu'on fait, c'est qu'on travaille en débug (comme ça, le debuggueur nous aide a corriger nos coquilles), et quand ça marche bien, on passe en release -> et la on y gagne monstrueusement
En général, ce qu'on fait, c'est qu'on travaille en débug (comme ça, le debuggueur nous aide a corriger nos coquilles), et quand ça marche bien, on passe en release -> et la on y gagne monstrueusement
J'avais déjà prise cette habitude et en regardant mes programmes récemment terminés, je constate que la taille de mes éxécutables varient nettement.
C'est que le vector est plus rapide qu'un tableau dynamique !!!
Pourquoi ?
Le compilo doit faire des optimisations dessus lors de la compilation. Chez moi en C et avec un tableau statique ([]), j'ai beau faire autant d'opérations que je veux (genre 1000 boucles de 100000000 tours), ça s'exécute toujours en 0 millisecondes Par contre la compilation est vachement longue (logique).
Je pense que pour les sdt::vector il doit y avoir un truc similaire...
Au fait, là je parle de millisecondes, mais que renvoie exactement timeGetTime() ? À comparer avec mes temps, ça doit aussi être des millisecondes.
Seconde question : quels sont vos processeurs réspectifs ?
Seconde question : quels sont vos processeurs réspectifs ?
Je possède un processeur Intel Dual Core 2 E4300
[OpenGL] Cercle + un problème
× 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.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html