Page 21 sur 62
Publié : mar. 14/nov./2006 16:15
par Dr. Dri
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
Dri
Publié : mar. 14/nov./2006 23:38
par Dräc
L'exemple de tmyke marche tout aussi bien en commentant les ligne suivantes:
Code : Tout sélectionner
; If OpenWindowedScreen(GadgetID(1), 0, 0, 160, 160, 0, 0, 0)
DM_hwnd = GadgetID(1)
DM_InitGraphics(DM_hwnd, 32, 0 ,1)
*DM_d3d9 = DM_GetD3D9()
*DM_d3dDev9 = DM_GetDevice9()
DM_WIDTH = 160
DM_HEIGHT = 160
; Else
; MessageRequester("Error", "Can't open windowed screen!", 0)
; End
; EndIf
OpenWindowedScreen() ne sert à rien en fait!
Publié : jeu. 16/nov./2006 0:48
par Anonyme
j'ai regarder, il serait bien de pouvoir choisir manuellement la frame d'un model animé, notament pour un .x
@++
Publié : jeu. 16/nov./2006 7:14
par bobysait
ç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
Publié : ven. 17/nov./2006 17:14
par tmyke
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 ?)
Publié : ven. 17/nov./2006 18:01
par tmyke
Cpl.Bator a écrit :j'ai regarder, il serait bien de pouvoir choisir manuellement la frame d'un model animé, notament pour un .x
@++
j'te fais un topo demain des possiblité des anim en l'etat actuel des choses...
Publié : dim. 19/nov./2006 21:02
par bobysait
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
Publié : lun. 20/nov./2006 19:42
par Anonyme
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.
Publié : lun. 20/nov./2006 19:49
par tmyke
Un terrain avec le terrain engine ou en manuel avec des fonctions généraliste ?
Publié : lun. 20/nov./2006 19:58
par Anonyme
avec le terrain engine.
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.
Publié : lun. 20/nov./2006 20:03
par tmyke
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...
Publié : lun. 20/nov./2006 20:07
par Anonyme
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 ?
@++
Publié : lun. 20/nov./2006 20:13
par tmyke
Oui, il y a une fonction qui est
DM_EntityInView.l(*entity.CEntity, *camera.CEntity)
Je ne l'ai pas tester rééllement, et donc je ne connais pas sa précision réélle.
par exemple si tu ecris
res = DM_EntityInView(*mesh, *camera)
=1 si c'est visible, sinon 0
Publié : lun. 20/nov./2006 20:23
par Anonyme
j'ai fait ca :
Code : Tout sélectionner
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
Publié : lun. 20/nov./2006 20:29
par Anonyme