OPENGL RECODÉ: MGRAPHICS (OPENGL-LIKE)
darkpoulpo
Messages postés
76
Date d'inscription
lundi 21 mars 2005
Statut
Membre
Dernière intervention
29 novembre 2009
-
4 mai 2005 à 19:06
SAKingdom Messages postés 3212 Date d'inscription lundi 7 novembre 2005 Statut Membre Dernière intervention 16 février 2009 - 23 avril 2006 à 03:51
SAKingdom Messages postés 3212 Date d'inscription lundi 7 novembre 2005 Statut Membre Dernière intervention 16 février 2009 - 23 avril 2006 à 03:51
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/31207-opengl-recode-mgraphics-opengl-like
https://codes-sources.commentcamarche.net/source/31207-opengl-recode-mgraphics-opengl-like
23 avril 2006 à 03:51
22 avril 2006 à 23:13
donc t'as 2 choix, soit google soit cette même source, qqpart dans mg_dll.cpp.
Attention ma version tient compte de tous les cas possibles, c'est à dire x1>?x2 et y1>?y2 ( 4 cas possibles; on pourrait réduire ça en échangeant 2 points mais je sais pas si ça serait beaucoup plus performant)
22 avril 2006 à 21:46
22 avril 2006 à 21:41
22 avril 2006 à 21:00
angle = asinf(result);
angle = ((angle*180)/PI);
Convertion de l'angle en degréé
xadd = sinf((angle*PI)/180);
yadd = cosf((angle*PI)/180);
Convertion du resultat de sin et cos en degree car a moin que je me trompe, leur valeur de retour est en radian.
len++ c'est tout simplement pour savoir quand quitter avec la boucle.
Mais peut tu me corriger un peu mon codage?
22 avril 2006 à 20:29
sinon ya plusieurs trucs inutiles dans ton code, ex :
float xadd 0, yadd 0;
xadd = sinf((angle*PI)/180);
yadd = cosf((angle*PI)/180);
( en outre, tu convertis en degrés pour 2 lignes plus loin reconvertir en radians )
22 avril 2006 à 15:04
En premier je calcule l'opposer(y2-y1) et l'adjacent(x2-x1) de l'angle.
Ensuite je calcule l'hypothénuse avec pythagore(racine de Adj à la 2 + Opp à la 2)
Puis je récupère le sinus de l'angle(Opposer / Hypothénuse)
Je fais sin-1 pour avoir l'angle en radian
Je convertie en degrée(angle = ((angle*180)/PI))
Puis j'utilise un fonction que j'ai créé qui créé une ligne avec un point de départ, une distance et un angle donc comme ceci: x1, y1, angle, Hypothénuse
Et cette fonction soccupe de trouver le sin et le cos de l'angle pour dessiner une ligne.
Voici les 2 fonctions
void x2dDrawLine2p (float x1, float y1, float x2, float y2)
{
float Adj 0, Opp 0, Hypo = 0, angle = 0, result = 0;
Opp = (float)y2 - (float)y1;
Adj = (float)x2 - (float)x1;
Hypo = (float)sqrtf((float)((Adj*Adj)+(Opp*Opp)));
if(Hypo == 0)
return;
result = ((float)Opp / (float)Hypo);
angle = asinf(result);
angle = ((angle*180)/PI);
x2dDrawLineagl(x1, y1, angle, Hypo);
}
void x2dDrawLineagl (float x, float y, float angle, float Lenght)
{
float xadd 0, yadd 0;
float len = 0;
xadd = sinf((angle*PI)/180);
yadd = cosf((angle*PI)/180);
while(len < Lenght)
{
SETPIXEL(arrondi(x), arrondi(y), RGB(SetColor.Red*255, SetColor.Green*255, SetColor.Blue*255));
x += xadd;
y += yadd;
len++;
}
}
Je comprend pas pourquoi ça marche pas
13 févr. 2006 à 21:58
13 févr. 2006 à 18:50
15 déc. 2005 à 14:19
Cyberboy2054 le 05/05/2005 11:52:05
Utilise tinyptc :)
Désolé -_- en plus c'est parce que lui en a parlé que j'ai commencé à l'utiliser :p (et à l'aimer ^^)
15 déc. 2005 à 10:56
ca a meme été déja dit sur ce forum ^^
je crois meme que c'était toi qui l'avait dit ...
:p
++
ad
15 déc. 2005 à 00:14
13 déc. 2005 à 23:33
Je n'affiche aucun pixel qui n'est pas dans le frustum. c'est a ca que sert le frustum culling, tu désoupes tes polygones pour transformer un poly qui coupe les plans de clipping en plusieurs polys qui sont dans le champ de vision
Pour setPixel beini sur que c'est ca qui fait ralentir, je crois meme l'avoir dit dans la présentation de la source, mais le bur n'était de toute facon pas la performance mais les maths qui se cachent derriere une telle lib
++
ad
13 déc. 2005 à 22:39
13 déc. 2005 à 22:20
28 juin 2005 à 10:17
Ce qui est intéressant aussi, c'est que tu peux avoir des données centrales accessibles depuis plusieurs sortes de conteneurs, potentiellement triés différemment etc: possibilités infinies pour un petit surcoût en mémoire. Bien sûr, faut faire gaffe quand on ajoute / enlève des données, mais pour pouvoir chercher un élément selon différents critères, c'est du tout bon :).
27 juin 2005 à 19:10
comme je l'ai dit plus haut, le truc important ds ce prog est l'affichage, le rendu; pas la gestion de la mémoire, pour ca je vais me débrouiller a l'arrache quitte a faire un truc [encore plus ] lent
merci qd meme
++
27 juin 2005 à 16:01
la class s'appel CMyList, elle est pas top (pas de gestion de garbage collector ni d'allocation par bloque) mais ca peut donnéer des idées (et ca fait reviser les template). Dispo sur mon site:
help: http://mignonsoft.free.fr/logiciel/SFC/doc/classMyList.html
source: http://mignonsoft.free.fr/logiciel/SFC/
Sinon bonne continuation
27 juin 2005 à 14:39
27 juin 2005 à 00:03
26 juin 2005 à 23:00
- apprends la STL
- benchmark
- utilise la STL en ayant la satisfaction d'avoir aussi fait l'effort de coder qq conteneurs ;)
on s'est mal compris pour l'histoire des ID / tableaux, c'est pas grave.
Il se passe rien dans le cas que tu évoques: imaginons que tu aies 300 textures pour un total de 33 Mo (ça fait bcp ^^). Ton tableau fera 512 entrées = 512 * 4 octets (512 pointeurs quoi): tu perds que dalle. Sans compter que c'est pas en mémoire vidéo ;).
26 juin 2005 à 22:51
pour la STL je ne veux pas pour 2 raisons:
- je ne connais pas ^^
- c'est de la triche, je préfere , quitte a galérer, m'occuper de tout tout seul, au maximum (maximum signifie que je ne gere pas moi meme le son, l'affichage, etc, trop dur pour moi, je laisse ca a fmod ou openGL... ou à MG lol )
pour le tri: ben ca ferait tout planter...
dans openGL qd tu charges une texture, il te renvoie un numéro, le numéro de la texture. un index quoi. si le tableau vers lequel ces numéros "pointent" , "indexent", ben si ce tableau change en cours de route, l'utilisateur va binder une texture de mur et va se retrtouver avec une texture de vitre....bref pas possible sauf si j'ai mal compris
"il réalloue en doublant la mémoire" ouais j'avais lu ca. 'parrait que si on fait pas ca de temps a autre ya des pbs. n'empeche que c'est honteux, vraiement.si j'ai 33Mo de textures et une carte graphique avec seulement 64 Mo, il se passe quoi?
voilavoila
oh, et inutile de m'emvoyer de la doc sur la STL pour m'y convertir, j'en ai déja ^^
arno
26 juin 2005 à 21:40
La proposition de tri, c'était pour permettre de trouver un élément quelconque dans le tableau très très vite (en log n opérations plutôt que n/2 opérations en moyenne pour un tableau de n éléments), mais c'est parce que je suis parti du principe que tu aurais plus souvent besoin d'accéder aux éléments que d'en ajouter (car ajouter un élément dans un tableau en conservant le tri, coûte log n pour trouver l'emplacement ... mais bcp trop cher pour réallouer un tableau de la bonne taille et y insérer le nouvel élément -_-). Mais comme je disais, une tableau de hashage ou un AVL ...
Sinon, bien entendu, le plus simple est tout de même de référencer les textures par leur ID dans le tableau, mais j'ai cru comprendre que ça t'embêtait. j'ai pu me tromper. Auquel cas, les vector font très bien l'affaire: chaque fois que tu dépasses la capacité, il réalloue en doublant la mémoire, du coup si tu fais n ajouts, il ne fait que log n redimensionnements et tu n'utilises jamais plus de 2x la place nécessaire.
26 juin 2005 à 21:32
pourquoi un tri? surtout pas! enfin a priori kwa, t'en connais plus que moi sur ce rayon :$
26 juin 2005 à 21:21
désolé Funto :D
à ce propos d'ailleurs, ça vaut franchement le coup de bien choisir ses structures de données quand on fait un algo, ça change les perf du simple au huit renversé quand c'est très mal / bien fait.
26 juin 2005 à 20:50
26 juin 2005 à 18:48
26 juin 2005 à 18:16
je vais commencer par un bete _Texture * tex pour l'instant ca ira bien :$ de toute facon ca n'a pas la volonté d'avoir les perfs d'openGL (mdr les bones excuses :D )
bon je vais voir
26 juin 2005 à 15:56
plenty of docs sur google ;) n'empêche que tu devrais utiliser les librairies standards pour ce genre de choses ...
26 juin 2005 à 15:53
en gros, tu veux un conteneur dynamique (qui peut facilement grandir) et avec lequel on puisse accéder rapidement aux différents éléments.
tu as plusieurs choix: les arbres "heap" ou AVL et les tables de hashage.
ça te permet dans les deux cas de faire une récupération en log n je pense, ce qui est assez négligeable (pour 1024 textures ça fait 10 comparaisons d'index, ça ira je pense ;)).
26 juin 2005 à 12:16
avec les listes liées (moi j'appelle ca comme ca):
j'ai un tableau de 10 pointeurs pointant chacun vers une texture; et dans la classe _Texture je mets un pointeur vers la texture suivante.
comme ca au lieu d'avoir 1 big liste j'en ai 10 plus petites, et ca a l'avantage de simplifier a mort tout les malloc pour l'OS , tout en gardant unne vitesse correcte, puisqu'au maximum il faut parcourir 100 _Textures (au lieu de 1000)
dites moi ce que vous en pensez...
pdt ce temps je vais essayez de refaire MG avec tout ce que vous m'aviez dit....
a vrai dire j'y avais plus retouché :$ , BAC + plein d'autres projets en cours. je vais m'y remettre promis ^^
++
26 juin 2005 à 11:44
Et pour les listes chaînées je ne pense pas que ce soit l'idéal, étant donné qu'il doit pouvoir accéder à une élément particulier n'importe quand.
A mon avis, OpenGL ne se pose pas trop de questions : le nombre de ses textures est limité par la mémoire de la carte graphique, ce qui n'est pas le cas de MG, mais bon ça ne doit pas tout expliquer...
D'un autre côté, quand est-ce que tu vas utiliser tes 100 textures ? A moins de créer plusieurs polices de caractères et d'associer chaque lettre à une texture, mais bon jtrouve ça bourrin (oui je l'ai déjà fait mais c'était y'a longtemps :p).
Sinon bah ta méthode de tableaux dans des tableaux a l'air correcte, et j'en vois pas d'autre...
26 juin 2005 à 10:46
26 juin 2005 à 00:00
on était en train de parler des textures, remember ?
ben je galere pour le chargement.
en fait je me dedmande comment openGL fait pour pouvoir enregistrer une quasi infinité de textures.
en fait ce qui m'embete c'est l'index: par exemple, dans un prog normal, je sais qu'il va y avoir 40 texture, alors je fais soit textures[40] soit UINT textures=(UINT*)malloc(40*sizeof(UINT));
mais la, le '40' peut augmenter en permanence et a n'importe quel moment.
bon alors admettons qu'une texture, sous MG, soit enregistrée dans une classe.au départ je crée un pointeur:
UINT*tex; int NofTex=0;
et puis qd l'utilisateur ajoute une texture, j'incrémente NofTex.
bon. mais est-ce que je suis obligé de réallouer la mémoire pour "tex" avec un realloc, ou il existe d'autres solutions plus rapides? je ne veux pas utiliser de vecteurs.
j'avais pensé a un truc je ne sais pas si c'est plus rapide ou meme réalisable (pour moi):
au lieu de créer un tableau de 1000 pointeurs (en admettant qu'il y ait 1000 textures),avec 1000*4octets a réallouer chaque fois qu'on rajoute une image, pk ne pas créer un tableau de 10 pointeurs, pointant chacun sur un tableau de 100 pointeurs, poitant chacun vers une image? comme ca qd on rajoute une texture, on ne réalloue que 100 poiteurs...
je sais pas si je me suis bien fait comprendre... ?
en tout cas voila mon pb, merci de vos idées.
++
ad
6 mai 2005 à 19:41
merci je vais aller y faire un tour
6 mai 2005 à 16:06
6 mai 2005 à 14:02
ça existe 11/10 ? non ? vraiment pas ?
Bon tant pis, alors seulement 10.
Lionel.
6 mai 2005 à 12:08
si c'est le cas, il faudrais que lon parle dun truc tout les deux en pv
6 mai 2005 à 11:07
C'est les fichier: MyScreen.{h|cpp}
dispo sur: http://mignonsoft.free.fr/logiciel/MyGlSaver/
Si ca peut t'aider, bon continuation en tout cas !
5 mai 2005 à 18:18
Bravo pour le code au fait! Pour tout te dire, je me bas avec les bases des vecteurs là, ça situe le niveau :p
5 mai 2005 à 18:14
boaf ya ptet moyen mais, encore une fois, pas tt de suite, surtout si il faut faire un tuton j'ai pas fini moi, avec toutes les trucs auquel ca touche ce prog...
enfin je verrai bien
5 mai 2005 à 18:08
:D
feel free to post ;)
5 mai 2005 à 15:12
sinon, je n'utilise pas SDL (pour une fois) c'est 100% API winnt
pour le double buffer je suis bien conscient qu'il n'est pas au point, pour l'instant ce n'est qu'une solution pour éviter le scintillement (elevez-le et vous verrez ... plus rien, d'ailleurs, tellement ca scintille)
pour le fonctionnement "normal" d'un double buffer je suis au courant, merci ;)
et non, ce n'est pas ce que je fais
et maintenant, une page de pub:
si vous voulez plus de FPS facilement, s'embeter avec la carte graphique, z'avez qu'a aller voir sur ma source de quadtree :D (encore sur le sommaire) lol
++
5 mai 2005 à 14:13
pour lhistoire du double buffer, je me demande si tu ty prend comme il faut, normalment tu devrais prevoir avant dafficher, mais plutot a linitialisation , 2 buffers dan sla memoire d etaille identique represantant ta zone memoire dans lequl tu dessines, les 2 qui sont pour le double buffering, et donc en plus un pointeur vers ca, et toi tu travaille qu'avec le pointeur,que tu swap dun buffer a lautre , ca tevite des copies en plus.
je sais pas si tu as saisi? (c'est peut etre ce que tu fais deja, mais du source que jai vu hier, me semble que non)
5 mai 2005 à 11:52
t'auras un projet portable et ca te permet de facilement tester quelle librairie te donne les meilleurs résulats !
Suffit juste de changer un #define et tu passe de la SDL au GDI ...
5 mai 2005 à 11:30
Si tu veux des FPS correctes, il va te falloir te passer du GDI et coder (en dur) les accés CG, etc...
5 mai 2005 à 11:12
en fait c'est une sorte de double buffering, pasque sans ca, l'écran scintille a mort
cette partie du code est en gde partie tirée de la source 'yeux' déposée ya bien 1 an sur ce site
pour le hdc j'ai tout (presque) essayé
pour l'exploitation de la C ca serait le top mais je sais pas comment faire... je vais voir
5 mai 2005 à 00:15
void mgFlush(void){
BitBlt(gmhdc, 0, 0, cxClient, cyClient, gmMemhdc, 0, 0, SRCCOPY);
DeleteObject(hBmp);
DeleteDC(gmMemhdc);
}
et
void mgClear(int buffer){
gmMemhdc CreateCompatibleDC(gmhdc);hBmp CreateCompatibleBitmap(gmhdc, cxClient, cyClient);
SelectObject(gmMemhdc, hBmp);
SelectObject(gmMemhdc, CouleurBackground);Rectangle(gmMemhdc,0,0, cxClient, cyClient);
for (int a=0;a<cyClient*cxClient;a++)depthbuffer[a]=-1.0f;
for ( a=0;a!= cyClient;a++){startx[a]=-1;endx[a]=-1;}
}
peut etre que le hdc, ne bouge pas dune frame a lautre, donc ca te permetrais de virer tout ce qui concerne cela pour le foutre dans wm_create.
sinon les boucles pour clearer le memcpy() n'est pas plus rapide?
ce quil faudrait (si lidee d'orienter ton travail sur le raytracing te plait pas) ce serait de trover comment exploiter la carte video pour gagner des frames. si tu trouves, tu gagnes.
4 mai 2005 à 22:26
apres on a de quoi s'amuser:
interpolation linéaire, bicubique meme , mipmaps, de dimension puissance de 2 ou non (voir nvidia.com, sommaire)
, filatrage bi/trilinéaire et j'en passe et des meilleures.
d'autant + que ces nom +/- barbares cachent d'autres techniques beaucoup plus compliquées, implémentées dans openGL et DX
si vous avec Flight Simulator, vous pouvez essayer de voir la différence point de vue texture entre les versions avec et sans accélération matérielle
en gros, sans, c'est tout en logiciel, c'est ce que je fais, et c'est horible et lent
avec , c'est codé en dur dans le GPU (voui funto, j'ai lu de la doc depuis une certaine conversation sur msn o:) ), super rapide, super beau et 'lisse'
vous attendez pas a un truc superbe, je serai déja content avec un MG_NEAREST
4 mai 2005 à 21:58
Je pensais par contre que l'application sur une surface l'était...
Faudra qu'on en parle sur MSN ;)
4 mai 2005 à 21:25
En fait j'étais pas trop motivé pourles textures, mais le 10/10 répété ( 1ere fois!! ca se fete, j'ai fait un screenshot MDR) m'a étrangement motivé...
bon faut pas vous attendre a le voir débarquer demain, ya le bac + des concours en rafale, va falloir bosser un peu bouh :'( )
mais ca viendra, aucun doute (presque) a ce sujet
comme je l'ai dit plus haut, je n'ai pas commencé a le faire mais une fois que j'aurais fait ma routine de chargement des textures ca sera du gateau, en 15 minutes ac peut etre réglé
bon voila pour les breakin'news, ++ @ ts
ad
4 mai 2005 à 21:15
Funto-> tu vois chte l'ais dit que je le ferais:) mais ca m'étones que tu aies renoncé, toi les gros projets ca te connais, vive le FuntoBasic :)
le screenshot est inutile, c'est surement aussi moche chez moi que chez vous:)
le pb est multiple:
-le z-buffer et pas au top, ce qui donne des pbs du style le triangle qui est tout devant n'est pas affiché en entier :(
- la routine pour tracer des lignes, qui est a la base de celle pour afficher les triangles (voir le code, C long a explisquer ici)
n'est pas parfaite, cad que qd on fait un LINE_STIP (l'équivalent en openGL), il y a parfois un pixel non affiché a l'intersection des 2 droites et ca crée des parasites... je sais pas si vous m'aveez bien compris lol
Pour le LoadIdentity, non, openGL le fait toujours en chargeant une nouvelle matrice. tu dois confondre avec l'utilisation de la modelview_matix
3eme chose:
"tes obligé de de creer et detruire lobjet a chaque fois" ??? je comprends pas, quel objet? l'étoile? nan, je la crée une fois dans case:CREATE et c'est tout. pour les HDC, effectivement , je suis obligé, a chaque frame, de le repasser a MG, je n'ai pas trouvé comment faire pour éviter ca, mais je crois que c'est dû au basecode, je naurais pas du faire un timer mais un time-based-movement a la digiben, a mon avis là yaurait moyen. A voir.
++
ad
4 mai 2005 à 21:04
Désolé je parlais pour l'autre source par contre pour le ramage de cette source ci je viens de relire j'avais pas bien vu (39 de fievre ca aide pas :/) sry
4 mai 2005 à 20:40
sinon, essayes aussi de supprimer le loadidentity dans mgpopmatrix() vu que tu linitialises dans mlpushmatrix().
en fait, tu devrais plutot laisser le codeur faire le loadidentity, ce que fait opengl il me semble, jai un trou de memoire la!!!!
sinon, bon courrage pour la suite.
4 mai 2005 à 20:38
Que dire, là ton 10/10 tu le mérites largement....bravo :)
Je veux bien voir ce que donnent les textures :)
Par contre c'est clair que niveau FPS c'est pas ça mais bon c'est normal aussi ;)
Ce qui serait cool aussi, puisque tout ne s'appuie que sur une seule fonction, ce serait de voir si ce ne serait pas possible d'implémenter ta lib par d'autres moyens...
Genre avec la Xlib sous Linux, ou même avec OpenGL, SDL ou TinyPTC...
'fin y'a tellement de trucs possibles lol, la différence c'est que toi tu les réalises ;)
Encore bravo ;)
4 mai 2005 à 20:30
preuve en est tu specifies ta carte video.
Arnaud, tu devras le continuer et t'orienter sur le raytracing
4 mai 2005 à 20:28
4 mai 2005 à 20:27
4 mai 2005 à 19:25
ou sur coder-studio, aussi, n'est-ce pas funto mdr
merci pour la note, ca fait tjs plaisir
++
4 mai 2005 à 19:06