Dräc a écrit :Il est vrai que tout étant "fenêtre" sous Windows, on peut certainement décliner les exemples à outrance.
C'est plutôt un bon point!
Un bémol cependant sur la méthode OpenWindowedScreen().
Cela n'a pas bcp d'interet à mes yeux car alors on crée un double Buffer dont on ne se servira pas.
Je ne comprend pas, là on a bien un double buffer qu'on utilise et aussi des gadgets, et ca sans scintillement chez moi
ça servirai pas simplement à tester si l'appli peut lancer la fenêtre tout simplement ?
On utilise souvent des tas de verif pour tester tout et n'importe quoi pour empêcher tout eventuel plantage ici ou la... c'est peut être un residu de ces test justement
à prioris en tout cas, si c'est le cas, y a pas de raison que ça planté, et par consequent, avec ou sans, ça marche quand même. Donc, c'est juste en cas de debug, ça permet d'isoler la ligne qui coince rapidement, plutôt que de trifouiller tout le code en long en large et en travers pour pas grand chose
Les lignes commantées sont en fait des vairiable globale qui sont habituellement
initialisées dans la procedure DM_Graphics3D() du fichier Dreamotion3D.pbi, et
je les est mise pour garder la compatibilité avec le moteur, mais effectivement
ne servent a rien dans le code present...
Et oui, dans le cas présent, OpenWindowedScreen() ne sert a rien
(heu, Boby tu plonge toi aussi dans le monde de PB ?)
tmyke a écrit :
(heu, Boby tu plonge toi aussi dans le monde de PB ?)
J'attend de voir ce que donnera la 3D... je suis pas encore fixé pour la releve de Blitz3D. Comme on atten la 3D de bmax on attend aussi celle de Purebasic. donc, je prefere jeter un oeil ici et là histoire de pas m'investir bêtement dans un truc qui tiendra pas la route.
En attendant, PB ou BMx, les deux auront la chance de voir la 3D de dreamOtion, c'est déjà ça
je me suis amusé a faire un terrain avec 500 mesh de 400 vertices chacunes.
et là paf, chute du fps
je faisait la même chose avec Dbpro, sans que ca rame trop
la fonction DM_renderWorld() doit être optimiser je pense.
j'ai remarquer une chose, lorsque mon terrain est nu (sans objet) et que je regarde ailleurs que sur le terrain, le fps monte en flêche
En revanche , j'essaye de faire pareil lorsque il y a des objet, j'ai beau regarder dans le vide, le fps est bas. meme en changeant le range de la camera.
Le terrain engine n'est que partiellement finalisé.
La représentation du terrain lui-meme est optimisé (plus de 500fps en triple texturing / quad sur 200.000 polygones avec ma 6800GT)
Par contre il ne tient pas encore compte des objets que l'on place dans son environement.
Donc meme quand tu leurs tourne le dos, il sont calculé et envoyé vers le pipeline
de rendu de la carte, d'ou
ce probleme de fps dès que tu place pas mal d'objets, pour peut qu'il comportent
pas mal de polygone.
L'extension du Quad détection sera bientot intégre, de quoi faire sérieusement remonter ton fps...
ok, mais si je n'utilise pas de terrain, mais que des meshs, le quad detection ne servira pas. c'est possible de ne pas envoyer un mesh en natif vers le pipeline lors que qu'il n'est plus dans le frustum ?
For i = 0 To 500
If DM_EntityInView(Palm(i), *Camera)=1
DM_EntityVisible(Palm(i),1)
Else
DM_EntityVisible(Palm(i),0)
EndIf
Next i
ca marche , sauf que c'est l'origine de l'objet qui est pris en compte, du coup, si c'est un grand mesh, il disparait meme si il doit être encore visible.
les objets qui se trouvent derriere un mouvement de terrain sont pris en compte aussi. donc au final , le fps monte que si il n'y a pas d'objet
