bartabasse Posté(e) le 20 juillet 2006 Signaler Posté(e) le 20 juillet 2006 franchement tant que ça descend pas en dessous de 60 je suis content après le coup de chute de fps de 120 à 60 pour moi c'est plus du ramage que du laguage..et encore avec une connection qui tient la route chez moi ça reste bien fluide car bien sur j'y ai le droit aussi...double door middle dust 2 flash + he et quelques gars en embuscade et mes fps descendent en eaux troubles mais tant que ça reste dans les 50 60 ça empèche pas de coller des balles aux ennemis...franchement coller le max fps à 60 alors qu'en intérieur on peut tourner allègrement au dessus 100 fps avec une config potable c'est dommage...
SekYo Posté(e) le 21 juillet 2006 Signaler Posté(e) le 21 juillet 2006 Hum en meme temps c'est logique que les fps limitent le netcode... Une Frame c'est pas que la question de l'affichage de ladite frame, c'est tout ce qui la compose. Tous les jeux étant plus ou moins du tour par tour ( même très rapide, du frame par frame si vous voulez ), entre 1 tour il est logique qu'il ne se passe rien. Même si on dissociait l'affichage du reste des actions avec 2 threads différents ( déjà bonjour le cauchemard pour synchroniser tout ca ), quel est l'intéret d'envoyer plus d'infos que nécessaires ? Tu vas augmenter la conso de bande passante, avec des informations redondantes. Le seul avantage pourrait être avec les procos dual core, avec un thread affichage sur un core et un autre thread pour le reste sur l'autre core... On gagnerait surement en fps ( jusqu'à être GPU limited ).
ChandlerBing82 Posté(e) le 21 juillet 2006 Signaler Posté(e) le 21 juillet 2006 gné? Le processeur va calculer toutes les positions de ce que tu veux et la carte graphique les affichent en gérant les explosions et tout le bordel... Je vois pas spécialement ou il y a calcul redondant et ou il faut obligatoirement que les FPS soit synchro avec le cl_cmdrate dans tout ca... M'enfin bon c'est pas spécialement mon probleme et a vrai dire je m'en fous un peu. Je trouve juste que c'est super mal foutu
SekYo Posté(e) le 21 juillet 2006 Signaler Posté(e) le 21 juillet 2006 lol c'est vrai qu'après coup c'est pas clair. Le principe d'un jeu c'est Tant(Qu'on veut pas quitter) { 1) Récupérer les infos du serveurs 2) Récupérer les actions du joueurs 3) Envoie des actions au serv 4) Rendu sonore 5) Gestion de l'affichage } Je ne pense pas dire une grosse connerie en disant que les fps, c'est tout simplement le nombre de fois que cette boucle est faite par seconde. Donc comment tu veux qu'il passe aux histoires de clients/serveur ( 1 et 3 ) si il n'a pas fini la partie graphique ? Or si le proco/CG est pas assez puissant, le 5) va prendre tellement de temps que mécaniquement ca va diminuer le nombre de fois que la boucle est faite par secondes et donc le nombre dois que 1 et 3 sont effectués par secondes ( et donc ton cmdrate (ou update je sais plus) sera limité ) ( bon c'est un peu plus complexe en réalité, mais c'est pour le principe ^^ ) La seule solution c'est de mettre le 5 dans une boucle à part, mais c'est pas pour rien que peu de jeux supportent le mutlithreading : c'est extrèmement compliqué à faire.
ChandlerBing82 Posté(e) le 21 juillet 2006 Signaler Posté(e) le 21 juillet 2006 nan... L'affichage doit etre gérer indépendemment. Il me parait impensable de mélanger netcode et affichage a l'écran. C'est juste deux concepts qui ne se mélangent pas...
LeSage Posté(e) le 22 juillet 2006 Signaler Posté(e) le 22 juillet 2006 si c'est logique comment dire sur quoi tu tirais entre une image affichée sur ton ecran??? ça me parrais dure le seul moyen de savoir ce que tu as fait c'est de ce fier à une image
WhiteJack Posté(e) le 22 juillet 2006 Signaler Posté(e) le 22 juillet 2006 Quand tu joues en "Mode non connecté" tu as pas plus d'FPS. Donc les FPS n'ont rien à voire avec la connection... J'me trompe ?
inconnu49 Posté(e) le 22 juillet 2006 Signaler Posté(e) le 22 juillet 2006 Et comment etait la façon de gerer tout ceci sous HL1? 1 frame etait egale à 1 tick?
LeSage Posté(e) le 22 juillet 2006 Signaler Posté(e) le 22 juillet 2006 WhiteJack, tu sais au moins ce que veut dire fps, parce que je peux t'aasuré que dès que tu joue a un jeu 3D tu en a fps = frame par seconde = image par seconde pour hl1 j'en sais strictemnt rien
WhiteJack Posté(e) le 22 juillet 2006 Signaler Posté(e) le 22 juillet 2006 WhiteJack, tu sais au moins ce que veut dire fps, parce que je peux t'aasuré que dès que tu joue a un jeu 3D tu en a fps = frame par seconde = image par seconde pour hl1 j'en sais strictemnt rien[/quotemsg] Quand tu joues en "Mode non connecté" tu n'as pas + d'FPS.
LeSage Posté(e) le 22 juillet 2006 Signaler Posté(e) le 22 juillet 2006 ho j'etais completement a coté de la plaque mais mais mais quand tu joues en mode non connecter ton pc crée un serveur sur lequel tu vas et c'est toujours le même principe met ton net graph tu pouras voir que tu est en tickrate 33 bolque tes fps a 10 et tu n'aura pas plus de 10 en cmdrate
SekYo Posté(e) le 22 juillet 2006 Signaler Posté(e) le 22 juillet 2006 Attention, FPS = FRAMES per seconds justement, et la traduction de frame n'est pas tout a fait "image". Mais c'est ce que je disais, en général, comme actuellement c'est la partie graphique qui prend le plus de temps dans une frame, on peut réduire ça à image par secondes. @chandlerbing82 : Je suis d'accord que c'est pas très logique et d'ailleurs dans le monde du developpement la tendance est à dissocier les choses n'ayant rien à voir ( sur le Web le fond - PHP - avec la forme - CSS - et la structure - HTML - par exemple ). C'est pareil pour le dev de logiciels. Ainsi en théorie il est possible de dissocier cette grande boucle pour mettre chaque sous partie dans une boucle toute seule. Chaque boucle tournant dans un thread distinct, l'une est pas bloquée par l'autre. Sauf que 1) Y a que les procos multicores ou les système multi procos qui veraient vraiment une amélioration. 2) C'est extrèmement complexe à developper, à debugger et à maintenir, car ca engendre des problèmes qui n'existent pas dans le cas d'une appli monothread. Les jeux supportant le multithreadings doivent se compter sur les doigts d'une, voir deux mains.
ChandlerBing82 Posté(e) le 22 juillet 2006 Signaler Posté(e) le 22 juillet 2006 nan mais j'ai eu une formation en tant que développeur et on m'a toujours dit de ne pas mélanger l'affichage et le travail réel... Je comprends pas ce principe de tout mélanger pour avoir un jeu bridé par la puissance machine alors qu'on a une connexion de ouf. Et inversement bien sur...
m000t Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 Ca parait pourtant logique. Le client, envoie des infos à chaque frame qu'il calcule. Il ne peut pas en envoyer pour le plaisir. Il y a donc forcément une influence sur l'envoi de paquets, il ne peut pas en être autrement. C'est pas une question de mélanger des choses. Fatalement ce que tu envois au serveur est uniquement ce que ta machine peut calculer (sans même parler d'afficher à la limite). Tu seras donc brider par la machine quoiqu'il se passe. C'est juste pas possible que ça fonctionne autrement. Et c'est pareil si ta connection te bride. Le moteur a besoin d'infos pour ses calculs, il ne peut pas les inventer.
ChandlerBing82 Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 bah justement non. L'affichage n'est pas indispensable dans un logiciel. Ici on parle de jeu donc ca prend une tout autre valeur pour tous mais l'affichage n'est pas prioritaire. Le calcul se fait de toutes manieres en fonction des réglages des rate. Ensuite on décide d'afficher ou pas les frames. Mais ca reste un autre probleme... Enfin ca, c'est si le jeu serait bien foutu. sinon comme je l'ai dit plus haut, ca revient a faire prendre une grosse place a la config au détriment de la qualité de jeu online pour les autres. C'est completement stupide
m000t Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 Mais meme sans penser à l'affichage. Si on prend juste un client de calcul pur qui a besoin d'infos arrivant par le réseau. Si les calculs sont longs et prennent plus de temps que le laps qu'il y a entre 2 arrivées de paquets tu vas te retrouver avec des paquets que tu ne peux pas traiter -> bridage du réseau par ta config. C'est pareil ici. Et c'est pareil à l'inverse, ton client calcul à fond et veut envoyer plus de paquets de résultats que ne peut traiter le réseau -> bridage config par réseau.
ChandlerBing82 Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 c'est de la que provienne le loss et le choke en parti
m000t Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 Oui. Et fatalement je vois pas comment on pourrait avoir la partie moteur complètement indépendant de la partie réseau :/ Ou alors (et c'est fort possible) j'ai pas assez d'expérience dans la programmation client/serveur pour voir comment ça pourrait être possible.
ChandlerBing82 Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 je ne dis pas que j'ai assez d'expérience non plus. Mais le simple fait de faire dépendre le jeu des graphismes va a l'encontre de tout ce qu'on m'a appris :/
m000t Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 Je vois pas pourquoi tu dis que ça dépend des graphismes. Ca dépend de puissance de calcul après tout et du fait que le serveur a besoin de paramètres calculés par le client et inverssement. Je pense que le fait qu'on ai des images nous fait regarder le problème sous un mauvais angle.
ChandlerBing82 Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 c'est exactement ce que je dis en fait pour moi, le jeu s'en contre fous royalement des graphismes. Ce qu'il veut c'est balancer des trames au serveur et que le serveur lui balance des trames. Apres la machine interpretera (ou pas) ces fameuses trames en fonction du nombre de FPS demandé. Enfin c'est comme ca que je vois les choses :x
m000t Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 Bon ben j'ai l'impression qu'on tourne en rond pour dire quasi la même chose en effet ^^ Trop de mal à comprendre avec cette chaleur
ChandlerBing82 Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 la chaleur la fatigue toussa quoi ^^
m000t Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 Exactement, le surmenage, les yeux qui collent xD
SekYo Posté(e) le 25 juillet 2006 Signaler Posté(e) le 25 juillet 2006 Sauf qu'a priro ChandlerBing82, Valve a choisi l'approche opposée. Dans ton post plus haut tu donnes la priorité aux trames réseaux, Valve a simplement choisi de donner la priorité aux frames d'affichages ( parce que nous sommes dans un jeu vidéo ). Parce que attention quand tu dis ca : "Apres la machine interpretera (ou pas) ces fameuses trames en fonction du nombre de FPS demandé." Ca ne représente pas la majorité des cas. Chez la plupart des joueurs la machine n'ARRIVE PAS à fournir un nombre constant de fps égal à fps_max. Donc si en utilisant 100% de ses capacités elle n'y arrive pas, y faut décider ce qui est prioritaire.
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.