Page 9 sur 14

Publié : mer. 08/mars/2006 18:15
par wolfjeremy
Salut,

J'ai tester ta demo, c'est plutot pas mal :D

Je tourne entre 30 fps minimum (la sale avec les pilier) et l'autre sale je suis a 60 fps. Ma config : amd athlon 2700+, 512 mo de ram pc 3200, geforce fx 5600 xt :wink:

Par contre sa serait mieu avec une petite touche de bump mapping :P

Publié : mer. 08/mars/2006 18:42
par Sehka
Salut à tous...
Je rentre du boulot :)
-> Comtois
Je vois que ça a bien bougé dans la journée :)
Voici les test :
1) avec le bout de code et les dll qui vont bien je tourne à 35 FPS.
2) avec l'exe 35 FPS
J'espère que cela va t'aider :wink:

Publié : mer. 08/mars/2006 18:48
par Sehka
OUPS, j'ai oublié d'indiquer ma résolution : 1280x1024...

Publié : mer. 08/mars/2006 18:50
par Polo
Sehka a écrit :OUPS, j'ai oublié d'indiquer ma résolution : 1280x1024...
Ah oui, moi aussi, p'tete pour ça que ça rame, si comptois ne change pas la résolution pendant le jeu :)

Publié : mer. 08/mars/2006 23:01
par Good07
Idem pour moi qui rentre aussi du boulot.
Le petit bout de code n'accélère pas la chose. Par contre c'est marrant on passe à travers tout et on arrive à avoir le plafont à la place du sol. :D
Par contre, c'est bizarre car on a quand même l'impression que c'est beaucoup plus rapide dans les déplacements mais le FPS affiché ne varie pratiquement pas par rapport à l'autre version.
Bon pour la résolution, je tourne aussi en 1280x1024 et 32 Bits pour les couleurs.

Publié : mer. 08/mars/2006 23:54
par comtois
merci pour les renseignements :)

Donc si le FPS n'est pas meilleur avec le petit code, c'est que mes calculs de collisions ne dégradent pas le FPS et c'est une bonne chose.

Good07, c'est normal que tu passes à travers les murs ,dans le petit code il n'y a pas de collision seulement le déplacement de la caméra :)

Et effectivement le programme utilise la résolution du bureau .

Pour essayer de gagner un peu de FPS vous pouvez remplacer ça

Code : Tout sélectionner

;-Initialisation
If ExamineDesktops()
    ScreenWidth  = DesktopWidth(0)
    ScreenHeight = DesktopHeight(0)
    ScreenDepth  = DesktopDepth(0)
EndIf
Par

Code : Tout sélectionner

    ScreenWidth  = 800
    ScreenHeight = 600
    ScreenDepth  = 32
Et éventuellement réduire la focale, Ogre aura moins de triangles à gérer.

Code : Tout sélectionner

#Focale = 50
Mettre #Focale = 30 par exemple.


Merci à tous pour vos tests.

Je pensais que ma carte 3D était dépassée , finalement , je vais la garder encore longtemps , elle me rend encore de bons services :)

Publié : jeu. 09/mars/2006 17:50
par Good07
Bon j'ai testé avec les nouvelles directives d'affichage:
800x600 et 32

Le FPS affiché reste constant à 75. :D

Mais en 1280x1024 et 32 ça marche aussi nickel. Certe un peu moins rapide mais nickel quand même. :wink:

Publié : ven. 10/mars/2006 0:31
par comtois
je viens d'ajouter la gestion du tir , ça ne va pas arranger le FPS ça :)

Mais j'ai quelques soucis , en fait un gros souci !
Je ne sais pas comment calculer l'angle de la caméra en Y .Sur l'axe des X ça fonctionne bien , le tir est dans la bonne direction, mais en hauteur il n'est pas à la bonne place, il y a un petit décalage , et en plus ça dépend de la distance , je pense qu'il faudrait tenir compte de la distance du point d'intersection , mais euh , comment ?

Pour l'instant je fais comme ça :

Code : Tout sélectionner

Rayon\Direction\x = M3D_Cos(Camera\AngleX) 
Rayon\Direction\y = M3D_Sin(Camera\AngleY)
Rayon\Direction\z = -M3D_Sin(Camera\AngleX)
Pour voir ce que ça donne , les sources et un exe sont dispos .
Je n'ai pas mis les data c'est toujours les mêmes et l'archive fait 213 ko:
http://perso.wanadoo.fr/comtois/sources ... utData.zip

Si quelqu'un a une idée , je suis preneur , parce que je sens que je vais sécher sur ce coup là :?

Si seulement on avait les informations sur les angles de la caméra.Mais est-ce que ça serait suffisant ?

Publié : ven. 10/mars/2006 19:20
par comtois
ok j'ai trouvé mon erreur :oops:

C'était la position d'origine du rayon qui n'était pas correct.

Code : Tout sélectionner

Rayon\Origine\x = CameraX(0)
Rayon\Origine\y = CameraY(0)
Rayon\Origine\z = CameraZ(0)
DivisionVecteur(Rayon\OrigineDansBaseE, Rayon\Origine, InfosNinja\RayonEllipsoide)
Avec ça le tir est près précis , tant qu'on ne vise pas trop haut ni trop bas :?

Pour l'instant c'est bien comme ça :)

Le système de lancer de rayon fonctionne , il peut servir pour le tir et simuler la vision , je vais essayer d'ajouter un robot qui tire quand le perso passe dans son champ de vision.

Publié : sam. 11/mars/2006 12:33
par comtois
J'ai ajouté un robot avec vision , c'est sommaire , mais ça fonctionne.
On peut se cacher derrière un pilier , le robot ne nous voit pas :)

Cette fois ci le tir fonctionne , bref que du bonheur.
Par contre c'est le bordel dans mon code, va falloir que je l'organise avant d'aller plus loin :?

Comme d'hab je mets tout à disposition des fois que ça intéresse quelqu'un.
Il y a les sources et un exécutable pour tester,et je n'ai pas mis le répertoire DATA, c'est toujours le même.

Download (408 ko)

Bien sûr , s'il y a des suggestions pour améliorer le code, l'optimiser , l'organiser ,etc , je suis preneur .

Publié : sam. 11/mars/2006 12:39
par Polo
comtois a écrit :Par contre c'est le bordel dans mon code, va falloir que je l'organise avant d'aller plus loin :?
Oui, c'est vrai, j'ai encore essayé de porter ton code de collisions sur mon moteur 3d, et j'ai encore renoncé :D

Publié : sam. 11/mars/2006 12:49
par comtois
Polo a écrit :
comtois a écrit :Par contre c'est le bordel dans mon code, va falloir que je l'organise avant d'aller plus loin :?
Oui, c'est vrai, j'ai encore essayé de porter ton code de collisions sur mon moteur 3d, et j'ai encore renoncé :D
tssss , tsss , c'est la partie du code la mieux structurée :)

Publié : sam. 11/mars/2006 12:53
par Polo
:)
Faut dire, c'est toujours plus dur de lire le code des autres, tu lirais les miens, tu dirais probablement la même chose :D
Mais par contre, ce dont j'essaye de faire attention, c'est, quand j'écris des petites routines, c'est de ne produire qu'une seule fonction, ne pas utiliser de structure, pour que n'importe qui puisse l'utiliser et l'adapter sans problèmes ;)
En fait, je crois que tu as écrit ta routine de collision trop, disons, en fonction de la librairie ogre et de ton code :)

Publié : sam. 11/mars/2006 14:19
par Coolman
comtois a écrit :J'ai ajouté un robot avec vision , c'est sommaire , mais ça fonctionne.
On peut se cacher derrière un pilier , le robot ne nous voit pas :)

Cette fois ci le tir fonctionne , bref que du bonheur.
Par contre c'est le bordel dans mon code, va falloir que je l'organise avant d'aller plus loin :?

Comme d'hab je mets tout à disposition des fois que ça intéresse quelqu'un.
Il y a les sources et un exécutable pour tester,et je n'ai pas mis le répertoire DATA, c'est toujours le même.

Download (408 ko)

Bien sûr , s'il y a des suggestions pour améliorer le code, l'optimiser , l'organiser ,etc , je suis preneur .

D'apres mes tests, voici les fps :

config p4 2.6 cg nvidia gt6600 256 mo : 80-84 peut descendre ramer a 45 fps (voir mon precedent post)

config p4 3 ghz cg nvidia fx5200 : lamentable, environ 18-20 fps, bizarre, avec cette carte, beaucoup de demo de jeux fonctionnent correctement...

config celeron 2.5 radeon 9600 128 mo : environ 40 fps et plus apparement, le processeur n'influe pas directement, c'est la carte graphique qui compte...

Test effectué avec la beta 4 de purebasic 4...

Pour Sehka, un fps de 35 avec une gt6600 est anormale, cette carte est superieure aux nvidia fx et ati radeon 9600 et meme 9800 pro a moins que le processeur utilisé n'arrive pas a suivre la cadence (peut etre un 1500 ghz) sinon tu devrais mettre a jour les drivers...

la seul facon d'avoir quelque chose de fluide, c'est de descendre la resolution a 640x480, bon ce qui m'etonne c'est le post de certains qui affirment que c'est fluide, desolé mais en appuyant sur les touches de deplacements et en meme temps en effectuant des deplacements lateraux, ca rame, et la c'est seulement une exploration d'une petite map, j'ai du mal a imaginer l'implentation d'une ia ou de sprites
animés dans une map conscequente...

Il me semble que le moteur 3d ogre est allergique aux hautes resolutions et n'est probablement pas utilisable dans l'etat dans un projet d'envergure, je crois qu'il excelle plutot dans des demos graphiques et il est vrai que le rendu est vraiment bon...

Note : le robot est blanc, je dis ca car j'ai vu que tu as inclu les textures et il n'y a pas de rendu a ce niveau...

En tous cas c'est du beau boulot, bravo :)

Polo, tu parle souvent de ton moteur 3d, serait il possible de voir ne serait ce qu'un prototype :)

Publié : sam. 11/mars/2006 14:51
par Polo
Pour mon moteur 3d, il manque dès choses essentielles, du coup, pour le moment, je préfère ne rien montrer plutôt que de montrer un truc pas fini :)
Mon but étant d'avoir l'équivalent du moteur de Blitz3d ;)
Il me manque l'animation, les terrains, les collisions, de la 2d basique, et des petits machins ici et là ;)