OPENGL RECODÉ: MGRAPHICS (OPENGL-LIKE)

Commentaire de Arnaud16022 le 04/05/2005 19:25:32

pourquoi pas
ou sur coder-studio, aussi, n'est-ce pas funto mdr
merci pour la note, ca fait tjs plaisir
++

Commentaire de MoDDiB le 04/05/2005 20:28:02

Oups pardon c'est aussi pour ton autre source quadtree pour celui ci l'un rame énormément et l'autre est en fil de fer coloré ?

Commentaire de Funto66 le 04/05/2005 20:38:27

Wa chuis....ben hautement admiratif, c'est le genre de projet que j'avais éfleuré de l'esprit avant de me raviser et de me dire que c'était trop dur/trop long/trop balèze/inutile (lol)...

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 ;)

Commentaire de MoDDiB le 04/05/2005 21:04:47

"Moddib, tas rien compris a son source alors!!!!"
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

Commentaire de Arnaud16022 le 04/05/2005 21:25:28

Bon je vais passer aux aveux ;)
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

Commentaire de Arnaud16022 le 04/05/2005 22:26:56

tout bidon pour une implémentation simple (MG_NEAREST)
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

Commentaire de Arnaud16022 le 05/05/2005 11:12:58

ah OK je vois
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

Commentaire de Cyberboy2054 le 05/05/2005 11:52:05

Utilise tinyptc :)
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 ...

Commentaire de Arnaud16022 le 05/05/2005 15:12:44

moué TinyPTC c'est pas beten j'y avais pas pensé mais c'est rapide ce machin la (plus que SetPixel, déja...)
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
++

Commentaire de Arnaud16022 le 05/05/2005 18:14:00

mouais on voit bien lesgros fanas qui font de la pub pour leur site mdr
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

Commentaire de basted le 06/05/2005 11:07:24

Si ca t'interesse, j'ai deja fait une ptite lib pour acces direct a la memoire video (un SetPixel ca ramme ++ comme convenu)

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 !

Commentaire de LiBe444 le 06/05/2005 14:02:48

Bonjour,
ça existe 11/10 ? non ? vraiment pas ?

Bon tant pis, alors seulement 10.

Lionel.

Commentaire de Arnaud16022 le 06/05/2005 19:41:25

a wé , basted C tro cool, j'avais déja vu cette source et je la recherchais sans succes depuis quelques temps pour une raison toute autre
merci je vais aller y faire un tour

Commentaire de darkpoulpo le 26/06/2005 10:46:11

std::vector/list

Commentaire de Arnaud16022 le 26/06/2005 12:16:47

sinon j'avais pensé a autre chose:
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 ^^
++

Commentaire de Kirua le 26/06/2005 15:56:09

euh, petite erreur dans mon message précédent: les heaps ce sont les structures "arboricoles" utilisées pour les "priority queues", donc dans ton cas c'est bien un AVL dont tu as besoin, je les ai confondus un instant.

plenty of docs sur google ;) n'empêche que tu devrais utiliser les librairies standards pour ce genre de choses ...

Commentaire de Kirua le 26/06/2005 18:48:53

bah sinon plus simplement un tableay dynamique trié avec un binary search dessus, ce qui revient, conceptuellement, presque au même mais en plus simple ^^.

Commentaire de Kirua le 26/06/2005 21:21:58

algorithmiQUE -_-
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.

Commentaire de Kirua le 26/06/2005 21:40:09

Disons qu'à la base je comprends pas pourquoi tu te prives de ce qui existe déjà, qui est standard, bien fait et que tout le monde connaît (oui, je parle de la STL).

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.

Commentaire de Kirua le 26/06/2005 23:00:29

- code tes conteneurs
- 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 ;).

Commentaire de Arnaud16022 le 27/06/2005 14:39:14

ah ouais pas bete

Commentaire de Arnaud16022 le 27/06/2005 19:10:56

merci bien mais c'est inutile.
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
++

Commentaire de SAKingdom le 13/12/2005 22:20:38

Salut Arnaud16022. J'ai fait une petite DLL semblable à la tienne. La seule grosse différence c'est qui gère des graphiques 2D. Je me suis gradement inspiré de ton code. Le seul problème c'est que comme toi, le programme utilisant la DLL rame beaucoup quand il y a beaucoup de pixel à gérer. J'ai trouver une petite solution pour accéléré le tout. Tu peut controler une camera dans mon DLL donc quand les pixels ne son pas dans le champ de la camera ils ne sont pas créé. Mais bon ma question revien à: connait tu une solution qui pourais faire rouler les programmes rapidement? Sur le forum Graphique on ma dit que le problème était SetPixel. C'est vraiment ça le problème?

Commentaire de Arnaud16022 le 13/12/2005 23:33:59

" Tu peut controler une camera dans mon DLL donc quand les pixels ne son pas dans le champ de la camera ils ne sont pas créé."
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

Commentaire de Arnaud16022 le 15/12/2005 10:56:02

ouaip
ca a meme été déja dit sur ce forum ^^
je crois meme que c'était toi qui l'avait dit ...
:p
++
ad

Commentaire de SAKingdom le 13/02/2006 18:50:11

Ouais mais connaisez vous une méthode autre que SetPixel qui reste dans les fonctions Windows (Jveux pas le rendre dépendent à d'autre moteur tel OpenGL ou TinyPTC même si je sais même pas ce que c'est). On m'a suggéré SetDIBitsToDevice mais je ne comprend pas sont fonctionnement même après avoir été sur MSDN.

Commentaire de SAKingdom le 22/04/2006 15:04:08

A non plus besoin maitenant. Je vien enfin de comprendre SetDIBitsToDevice et WOUAW.... ça roule. Mais la jai un autre problème d'ordre mathématique cette fois. Je cherche à dessiner une ligne droite entre 2 points. Ok ça va ten que x1y1 est plus petit que x2y2 mais sinon.... ça donne un resultat asser désastreux. Bon alors j'explique mon procédé:

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

Commentaire de SAKingdom le 22/04/2006 21:00:09

Hein??? Je reconvertie pas en radian.

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?

Commentaire de SAKingdom le 22/04/2006 21:46:49

En effet. J'avais pas vue ça comme ça mais c'étais sourtout pour que ma fonction x2dDrawLineagl comprenne car elle ne prend que des degrée. Mais ça regle pas le probleme. Les angles ne sont pas encore bon. Mais connaissez vous une formule qui justement répondrais à ma question?