Config à peu pres stable meme en Stress Day

Par Saledan le 15/6/2001 à 19:34:00 (#444187)

j'ai un AMD 400, VOODOO 3, SB 128, 3 Disque IDE Standard et 128 Mo de ram

Windows :
Mémoire virtuelle 3x la taille de la RAM (moi 400 Mo) en FIXE ! mini 400, Maxi 400
et le disque de swap est sur un AUTRE Bus IDE (donc autre disque) que le JEU.

AO :
800x600
PAS DE MUSIQUE (surtout en Stress Day)
Resolution texture Moyenne (Sol et autres)
Texture 16 bit (Pas en High)

Distance de vue 25% en ville et Plus en dehors

avec ça, je marche bien.. je subi uniquement les lags serveur, donc delog parfois.. mais tres tres rarement Crash windows .. voire jamais.. je joue meme parfois en fenetre et je garde mes preformances.

j'espere que ça aidera certains...
plus on est de fous.. moins ya d'Omnis :D

Bonne Beta

Saledan

Par Groo le 15/6/2001 à 19:45:00 (#444188)

Pour le stress day, le but est de STRESSER le serveur. Donc si tu te configures spécialement pour jouer avec le moins de lag possible (800 x 600, je rêve !), t'as rien compris au film. Tu t'amuseras un autre jour, demain c'est du boulot. Il s'agit de reproduire à quelques dizaines de milliers la charge induite par 100 ou 150 000 utilisateurs.

Par mutonz le 15/6/2001 à 19:49:00 (#444189)

Euh, c'est un stress test de LEUR serveur, pas de notre machine :)

Donc je conseille aussi de régler les paramêtres de visu et de ZAPPER LA ZIK!!!

Par Saledan le 15/6/2001 à 19:50:00 (#444190)

Stress Day client ?
je pensais que c'etait serveur... moi je stress pas..

mais bon.. fais comme tu veux.. si t'as besoin de tester ta machine .. vas y !

Saledan

Par Groo le 15/6/2001 à 20:03:00 (#444191)

Euuuhhh... z'avez pas tout compris, là. S'il y a moins de lag quand tu baisses les options graphiques, c'est bêtement parce que tu échanges moins de données avec le serveur. Donc tu plus tu montes les options, plus tu stresses le serveur.

Le client, lui, il aurait pas de mal à afficher du 1280 x 1024 toutes textures à donf en 80 FPS, s'il n'avait pas à attendre la réponse du serveur. Du moins pas avec le genre de bécanes qu'on a tous. Arf !

Par mutonz le 15/6/2001 à 20:14:00 (#444192)

ROFL, désolé ringo mais tu n'y est pas du tout :)

Ta config graphique client ne change RIEN au lag.
Faut pas confondre 2 choses, le lag graphique(dépendant de ta machine, carte vidéo etc) et le lag internet (latency, qui dépend uniquement de ton modem, du lag général sur internet et du serveur).

Si tu joues en 640x480x16bit, avec TOUTES tes options à 0, tu transfères exactement les meme données que si tu joues en supra haute résolution avec toutes les options à fond.
En gros, c'est pas parceque tu vois pas le mec qui vient de sortir d'un shop que ton client sait pas qu'il est là, juste qu'il ne l'affiche pas, mais il sait quel nom il a, qu'elle texture il porte, etc, et meme son déplacement (et ce meme si tu le vois pas).

Par Saledan le 15/6/2001 à 20:18:00 (#444193)

Qu'est ce qu'on rigole au moins :) :)

bon allez.. j'abandonne..

mais restez pareil :p

Saledan

Par Alex1979 le 15/6/2001 à 20:19:00 (#444194)

Ah bon la résolution à laquelle tu joues à une influence sur le serveur??!! C'est nouveau ça !! En principe tout ce qui est graphisme est géré par le client et pas par le serveur, non ?

Par Groo le 15/6/2001 à 20:39:00 (#444195)

Kemor, une GeForce DDR 64 Mo couplée à un 700 Mz et 200 Mo de RAM est capable d'afficher un jeu comme AO en 1024 les doigts dans le slot :D .

Quand tu baisses la distance de vue dans une ville, par exemple, ça va plus vite parce que le serveur n'est pas obligé de renvoyer au client la position de chaque polygone de chaque bâtiment à chaque centième de seconde. Et évidemment la texture associée à chacun de ces polygones, la manière dont elle est éclairé etc... Que la carte de la ville et l'ensemble des textures soit stocké sur ton dur et chargé dans la RAM de ta carte vidéo ne change rien au problème. Seul le serveur peut indiquer au client ce qu'il doit afficher.

Test si tu joues à EQ : regarde ton upload à l'heure dans le "vieux monde", puis compare avec l'upload à l'heure dans Kunark. Tu verras la différence. Plus de polygones = plus de positions de polygones à communiquer au client. Etant cablé Noos (avec upload limité, donc), je peux te dire que c'est un souci technique que je maîtrise bien ;)

Par Saledan le 15/6/2001 à 21:08:00 (#444196)

Bha allez pourquoi pas ...

moi je rend mon tablier d'admin reseau demain ...

vous etes des pros ...

Bonne Beta quand meme !

Saledan

Par mutonz le 15/6/2001 à 21:10:00 (#444197)

Restons calme et zen :)
Oublie totale, ta configuration client NE CHANGE RIEN à ton upload, nada, niet, RIEN.
La différence d'upload de Velious/kunark et le vieux monde c'est tout simplement que les ZONES sont plus grande, donc plus de monstres, et comme EQ raffraichit la loc de TOUS les monstres dans une meme zone (contrairement à AC ou AO qui gère ca en sorte de bulle autour de toi), tu as plus d'upload (plus d'upload car plus de données envoyées juste pour dire ok j'ai bien recu ton paquet de données principalement).

Reprenons. Dans AO, le serveur raffraichit les données de ton environnement dans la petite bulle ou tu es. C'est pas le serveur qui te dit, ok affiche ce building énorme avec whatmillard de polygons, c'est ton client qui récoit ta position du serveur(juste une coordonnées à la con) et qui, en fonction des fichiers de carte que tu as sur ton disque durs, affiche les polygons.
Donc, que tu ais besoin d'afficher 2000000 batiments de whatmillards de polygon ou juste 1, le serveur lui il s'en fout, il a envoyé les coords x,y,z au client et voilà. C'est le client qui gère le reste.

Enfin bon, pense ce que tu veux, mais tu es dans l'erreur :)

Par Alex1979 le 15/6/2001 à 21:20:00 (#444198)

La théorie de Kemor me parait plus juste ... :D

Ringo : si le serveur s'amuse a communiquer le nombre de polygones ou les millions de couleurs à afficher aux clients, crois tu alors qu'un type avec un modem RTC arriverait à jouer ??
Si tu prends juste la ville d'Omni qui est déjà immense, c'est impensable que le serveur gère la partie graphique pour les clients.
Comme le dit Kemor, il balance une vulgaire les coordonnées des bâtiments et après c'est à nos machines de se débrouiller pour l'affichage...

Par Saledan le 15/6/2001 à 21:39:00 (#444199)

Yen a qui reinvente le monde,
yen a d'autres qui le vivent c'est la la différence.

ok, si vous voulez lancer vos config a fond pour faire votre stress day allez y :)

moi je ne me pose meme pas la question.. contrairement a certains.. m'enfin bon..

Saledan

Par Diacre le 15/6/2001 à 21:43:00 (#444200)

si tu augmentes la distance de vision a 100m, il y aura forcement des moments ou ton perso verra plus de monde que si la vision etait limité a 25m.

Et donc plus d upload de ta part.

Par Diacre le 15/6/2001 à 21:54:00 (#444201)

si tu augmentes la distance de vision a 100m, il y aura forcement des moments ou ton perso verra plus de monde que si la vision etait limité a 25m.

Et donc plus d upload de ta part.

Par mutonz le 15/6/2001 à 21:56:00 (#444202)

Diacre -
Seulement dans cette "bulle" dont je parlais.
Si tu met ton clipping a fond, tu verras pas d'objet dynamique (genre perso, NPC, monstres) au dela te ta bulle, meme si tu vois à 20 kilometres d'horizon.

Cependant, il est évident que les gars de funcom ont fait en sorte que la "bulle" en question soit assez grande, comme ca tu peux voire assez loin les monstres si tu es en clipping plane a fond.

Par Groo le 15/6/2001 à 22:08:00 (#444203)

Ben oui, forcément. Bon, je reprends à mon tour, dans le calme :

1 - On est le matin, ta connexion est super-bonne. Tu joues en 1024x768 à 40 fps. Donc tu a déterminé que la puissance de ta bécane permet au client de te laisser jouer à cette résolution et à ce framerate sans souci. OK ?

2 - Maintenant, on est le soir. Ca lagge pas mal. En 1024x768, tu es tombé à 12 fps. Tu en as marre, donc tu passes en 800x600. Si la quantité de paquets transférés entre le client et le serveur restait la même quelles que soient les options graphiques, tu ne verrais aucune amélioration dans ton framerate, OK ? Pourtant ça s'améliore et tu montes, disons à 30 fps au lieu de 12. Pourquoi ? Tout simplement parce que le client passe moins de temps à attendre les infos du serveur, car il en a moins à recevoir, et donc saute moins de frames. Le client et ta bécane, eux, ils n'ont pas changé depuis le matin, quand ils étaient capables d'afficher du 1024 à 40 fps ;)

Après ça, il faut voir option par option, lesquelles sont les plus stressantes pour la connexion (dans les 2 sens, donc). Certaines ont peu d'influence, d'autres beaucoup.

Par Groo le 15/6/2001 à 22:17:00 (#444204)

Moloch : je ne dis pas que le serveur gère les couleurs, la partie graphique, etc... Bien sûr qu'il se contente d'envoyer des coordonnées. mais c'est justement la quantité de coordonnées qui influe sur les transferts. Pour que le client sache comment il doit éclairer une texture en plein air, par exemple, le serveur doit évidemment lui envoyer en permanence la position du soleil. Puisque dans AO ou EQ, le soleil se déplace. Si tu rajoutes une 2ème source de lumière, ça fait 2 fois plus de coordonnées à transférer. Après, évidemment, c'est le client qui se démerde.

Par mutonz le 15/6/2001 à 22:49:00 (#444205)

Mais non euhhhh!!!!


1) entre le matin et le soir, dans la campagne, AUCUNE différence, pas de lag, etc (sauf crash divers mais rien a voir avec le lag).
2) dans les villes, EVIDEMENT que ca lag plus le soir, il y a plus de monde!
- Tu lag plus coté internet : parske le serveur gère plus de monde dans la zone, qu'il t'envoi plus de détails car plus de joueurs et plus de déplacements.
- Tu lag plus coté graphisme : parske afficher 30 mecs avec différentes textures ca rame plus qu'en afficher 10 :)

Donc en gros, évidement que tu lag le soir, mais ce sont 2 lags complètement différents, le lag serveur car il y a plus de données a envoyer à CHAQUE client! et le lag graphique (seulement en ville ou il y a du monde), tout simplement parcequ'il y a plus de monde a afficher :)

Voilo, probleme (kel problème?) résolu.

Par zarkof le 15/6/2001 à 23:18:00 (#444206)

C'est marrant ce qu'on lit comme conneries.. =)..

L'option "view distance" ne change pas la distance des positions des personnages mais uniquement des objets fixes tels que batiments, arbres, rocs. Le personnages disparaissent toujours à la meme distance, l'option view distance n'est qu'un paramètre graphique.

Diminuer sa config pour le stresstest est très important. A la base, ils vont tester la charge du serveur. Le seul intérêt à ce moment est d'aller dans une zone où il y a beaucoup d'autres personnages vu que, pour chaque client, le serveur devra envoyer la position de tous les personnages visibles par le client. A ce moment, chaque client devra afficher beaucoup plus de polygones/textures que la norme. (imaginons une zone de 200-300 personnes)

Par contre, le traffic montant (upload) ne sera pas augmenté pour autant. Le client envoit uniquement ses données (positions, commandes,..) et pas celles des autres. En l'occurence, qu'il y ait 2000 personnes ou que tu sois tout seul, tu upload-eras la meme chose.. Par contre, tu download-eras beaucoup plus.

Au passage, si on a 30fps en extérieur c'est qu'apparament il y a pas moyen d'avoir + que 30fps en extérieur. Par contre, si on tombe souvent en dessous de 30fps, c'est bien souvent lié aux textures, plus qu'aux polygones. (AGP texturing c'est bien mais c'est lent...)

En conclusion, baissez les textures en stresstest n'est pas une mauvaise idée.. le but est de pas dépasser la mémoire de la carte vidéo.

Sinon il y a aussi les ralentissements liés au swap file et à la mémoire, mais là vous pouvez pas faire grand chose à moins d'avoir 512+ mb de ram et de virer le swap file..

Zarkof

Par mutonz le 15/6/2001 à 23:30:00 (#444207)

Juste une chti truc pour finir :)

L'upload est LEGEREMENT plus grande dans les zones avec plus de monde car a chaque paquet recu, le client envoi une confirmation. Bien sure, c'est microscopique, mais multiplier par 1 million disont, ca monte :)
et 1 million de paquet cest keud :)

Par Dreadskulo le 15/6/2001 à 23:38:00 (#444208)

hahaha ringo elle est bien bonne .....le serveur qui envoie tous les parametres des polygones de la zone ou t es ....trop fort :D
Et pourquoi pas carrement les calculer sur le serveur et puis les envoyer a la carte graphique comme ca ca ferait moins de boulot pour notre PC .....c est pas con comme principe ca .....enfin bon meme avec une connection reseau je suis pas sur que ca serait rapide ..... :D
Ah lala qu est ce qu on se marre quand meme des fois :)

Par Groo le 15/6/2001 à 23:39:00 (#444209)

kermor, je ne te parle pas des raisons pour lesquelles ça lagge plus le soir que le matin ! Je te parle des raisons pour lesquelles baisser le réalisme du rendu fait que ça lagge moins ! Et cette raison tient uniquement au nombre moindre de paquets transférés, ce qui fait que le client passe moins de temps à les attendre et donc t'affiche un meilleur framerate. Arrrgh :D

Bon, je reprends en le formulant autrement :

1 - Tu tournes à 60 Ko/s. Ton framerate est de 50 fps en 1024x768.

2 - Ca se met à lagger à cause de TA connexion qui vient de s'effondrer à 20 Ko/s pour une raison x ou y. La scène est exactement la même, il n'y a pas plus de mobs ou de joueurs, OK ? Du coup, ton framerate s'effondre aussi et tombe, mettons, à 20 fps. Normal, le client ne reçoit plus les infos du serveur assez vite et il est obligé de sauter des frames (les infos étant des coordonnées, on est bien d'accord là-dessus).

3 - Tu descends quelques options graphiques et ça te permet de remonter à 35 fps. OK ? C'est parce que le serveur a moins d'infos à envoyer au client, et que celui-ci, du coup, les reçoit plus vite et peut sauter moins de frames. C'est pas ta bécane, qui fait ramer le client : tu pouvais afficher à 50 fps 1 minute avant.

La seule différence entre 2) et 3), c'est que si par exemple, tu as désactivé les nuages, le serveur n'a plus a envoyer les coordonnées des nuages au client. Moins de paquets, donc. Plus tu montes les options graphiques, plus tu stresses :

1 : la connexion du serveur vers le client (donc le download, de ton point de vue).

2 - dans une (très) moindre mesure, la connexion du client vers le serveur (l'upload).

3 : le serveur lui-même, à qui le client demande plus de renseignements ("dis-moi à quelle position se trouve chaque pixel des nuages, afin que je puisse les afficher").

Ah allez, on va bien finir par se mettre d'accord :D

[ 15 juin 2001: Message édité par : Ringo ]

Par Foneus le 15/6/2001 à 23:47:00 (#444210)

Euh...............
ON S'EN FOUT! :D :D :D
Nan, je deconne :rolleyes: Pq ca lag? C'est une Beta, les serveurs de Funcom avec leurs debug qui tourne en fond -----> Caca! ;)
Comment on peut diminuer le LAG? On peut pas!
Comment je fais, c'est injouable là! Tu joues pas! :D

Eh avec de la chance tu as Win2k, alors ca t'evitera un Crash du susdit Windaube2k

Par Groo le 16/6/2001 à 0:06:00 (#444211)

Zarkov : si les paramètres graphiques n'ont rien à voir avec le nombre de paquets transférés, pourquoi peux-tu gagner 10 fps, par exemple, en les baissant ? Sachant que même avec ces 10 fps supplémentaires, tu es encore très en-dessous de ce que ta bécane peut afficher ?

Moi, je veux bien admettre que je dis des conneries, tout le monde peut se tromper, mais j'aimerais bien que quelqu'un se décide à répondre à cette 'tite question.

Pour ce qui est de l'upload, il est proportionnel au download. De 5/6% dans le meilleur des cas à 10 ou 12% s'il y a beaucoup de perte de paquets. Que tu télécharges un truc en ftp, que tu affiches une page web ou que tu joues à AO avec une option ou une autre, tu auras toujours ce pourcentage minimum. Plus le serveur t'envoie d'infos, plus tu uploades. C'est comme ça. Passe 2 ans chez Noos, avec un oeil sur Stat & Perf pour être sûr de ne pas dépasser tes 125 Mo d'upload/mois autorisés, et crois-moi que ça te sensibilisera au problème ;) (maintenant, on est passé à 250 Mo/mois, on respire un peu plus).

Par mutonz le 16/6/2001 à 1:21:00 (#444212)

ok hehe, on reprend point par point :)

1 - Tu tournes à 60 Ko/s. Ton framerate est de 50 fps en 1024x768.
-----> jusque là ok, simple postula de base

2 - Ca se met à lagger à cause de TA connexion qui vient de s'effondrer à 20 Ko/s pour une raison x ou y. La scène est exactement la même, il n'y a pas plus de mobs ou de joueurs, OK ? Du coup, ton framerate s'effondre aussi et tombe, mettons, à 20 fps. Normal, le client ne reçoit plus les infos du serveur assez vite et il est obligé de sauter des frames (les infos étant des coordonnées, on est bien d'accord là-dessus).
----> Non, pas du tout. si ta connection tombe à 20ko/s, ton client et ta carte graphique n'en ont rien a foutre et ils ne sautent aucune frame. Simplement, ils sont pas au courant qu'il y a un gus qui passe devant toi et donc il l'affiche pas. En général, le problème c'est que avec internet, quand ca lag, tu reçois tous tes paquets d'un bloc, pis pu rien, pis un autre gros bloc. Ca donne que un coup ya rien de spécial, pis poof, 20 mecs à charger d'un coup (alors qu'il sont surement loin déjà).

3 - Tu descends quelques options graphiques et ça te permet de remonter à 35 fps. OK ? C'est parce que le serveur a moins d'infos à envoyer au client, et que celui-ci, du coup, les reçoit plus vite et peut sauter moins de frames. C'est pas ta bécane, qui fait ramer le client : tu pouvais afficher à 50 fps 1 minute avant.
----> Je doute REELEMENT que le serveur ait quelques choses a foutre de ta configuration et qu'il envoi ses paquets et ses infos de toutes facon. en gros, imaginons un paquet pour un personnage envoyer par le serveur (just pour exemple):
- NOM (ton client créé un ID qui identifiera le perso)
- DETAIL DE PERSO (classe, niveau, etc)
- LOOK (armure,arme,etc)
- PROGRAMS (les nano qu'il utilise, ce qui créé ou non des effets spéciaux et gère un paramêtre de luminosité)
- COORDONNEES (pos x,y,z du mec)

Ensuite, a chaque 'tic' (rafraichissement de client/serveur), tu recois un truc du genre :
- Pour tel NOM, updater LOOK,PROGRAMS,COORDONNEES.

C'est paquet se succède pour chaque personne/monstre/objet dynamique ton ta 'bulle' de rafraichissement.
Disons maintenant que tu joues en 32bits couleur avec super option a fond et tout, ton client affichera un LOOK clean, en couleur 32bits, avec des éclairages pour les nanos lancées. Si tu joues en 16 bits, tout à zéro, le client affichera un look pourave sans aucun éclairage. Dans les DEUX cas, le serveur enverra le même paquet exactement.

La seule différence entre 2) et 3), c'est que si par exemple, tu as désactivé les nuages, le serveur n'a plus a envoyer les coordonnées des nuages au client. Moins de paquets, donc. Plus tu montes les options graphiques, plus tu stresses :

1 : la connexion du serveur vers le client (donc le download, de ton point de vue).

2 - dans une (très) moindre mesure, la connexion du client vers le serveur (l'upload).

3 : le serveur lui-même, à qui le client demande plus de renseignements ("dis-moi à quelle position se trouve chaque pixel des nuages, afin que je puisse les afficher").
---> ok, pour les nuages, si tu imagines que c'est ce qui se passe, restons amis et passons à autre choses hehe :)


Un dernier exemple pour la forme:
CLIENT A à toutes les options à fond.
CLIENT B à toutes les options à zéro.
CLIENT A ET B ont EXACTEMENT le meme débit et la meme machine (juste pour l'exemple).
CLIENT A utilise une nano avec super effet lumineux et tout. CLIENT A est content, il voit plein de truc coloré. CLIENT B voit CLIENT A faire des gestes, il est moins content, ya pas de truc coloré.
SERVEUR est content, il a envoyé un paquet à CLIENT A et CLIENT B. Le même paquet en fait, juste envoyé à tous les CLIENT X autour de CLIENT A. Ce paquet disait (au figuré):
["CLIENT A utilise NANO X"]

Maintenant la meme chose si SERVEUR gérait les graphiques de chacun :
CLIENT A à toutes les options à fond.
CLIENT B à toutes les options à zéro.
CLIENT A ET B ont EXACTEMENT le meme débit et la meme machine (juste pour l'exemple).
CLIENT A utilise une nano avec super effet lumineux et tout. CLIENT A est content, il voit plein de truc coloré mais il lag a mort. CLIENT B voit CLIENT A faire des gestes, il est moins content, ya pas de truc coloré et en plus il lag!.
SERVEUR est PAS CONTENT!!, il a envoyé 2 paquets à CLIENT A et CLIENT B. Ces paquet disait (au figuré):
Pour CLIENT A ["CLIENT A utilise NANO X AVEC OPTION A FOND"].
Pour CLIENT B ["CLIENT A utilise NANO X avec OPTION A ZERO"].

voilà, SERVEUR est pas jouasse en fait, parcqu'il a vachement ramé pour envoyé tous les paquets différents.


Voilo, juste pour montrer que la théorie du serveur prenant en compte les options graphique est totalement impensable :)

[ 16 juin 2001: Message édité par : Kemor Defender ]

Par Groo le 16/6/2001 à 2:02:00 (#444213)

Pfiou ! Chapeau ! Je suis pas encore bien sûr que tu aies raison, mais si c'est le cas, on peut dire que tu te seras donné du mal pour m'expliquer ;)

Cela dit (t'énerves pas, hein ? ;) ) je vois toujours pas pourquoi tu gagnerais des fps en baissant tes options graphiques (et c'est pourtant le cas !) si cela ne modifiait pas la quantité d'infos réclamées par le client et donc le nombre de paquets que le serveur doit t'envoyer. Dans la mesure, bien sûr, où tu n'avais pas dépassé les capacités de proc/vidéo/RAM de ta bécane.

Pour mon exemple des nuages, j'ai l'impression de m'exprimer comme un pied dès que j'essaye d'être précis, donc je vais essayer de rester plus général et je dirai moins de conneries ;)

Le ciel se modifie en fonction de l'heure et d'événements aléatoires (pluie/orage etc...). Il peut même être modifié ponctuellement pour les besoins d'un évenement. J'ai souvenir à EQ d'un des rares évenements auquel j'ai pu participer. Je rentrais à Qeynos de je ne sais plus où et il s'est mis à faire nuit brusquement tandis que de giant skeletons faisaient la foire dans tous les coins.

Donc, bon : le serveur communique quand même bien des infos sur le ciel au client pour lui dire ce qu'il doit afficher ? S'il le fait, c'est forcément à chaque instant, non ?

Bon, 1h50, je crois qu'il vaudrait mieux que je me couche ;) Finalement, le meilleur moyen d'en avoir le coeur net serait que je réinstalle Stat&Perf (désinstallé depuis qu'on est passé à 250 Mo d'upload chez Noos) puis que je mesure mon upload/download pendant 5 minutes alternativement avec les options graphiques à 0 puis à 100%. parce que là, plus j'en cause et plus j'ai plus l'impression de m'embrouiller...

Par zarkof le 16/6/2001 à 2:47:00 (#444214)

Jpense qu'il y a quelquechose que vous comprennez mal..

Le netcode de 99% des jeux ne transmet *jamais* du graphisme ou des informations statiques liés à ce graphisme.. Ce qu'il envoit ce sont surtout des positions, des actions, ou des noms de textures (pour les jeux de role) J'insiste sur le 'nom' car dans le meilleur des cas, il s'agira de noms ou de codes, rien de plus. Tout le reste est sur le client (en local), tous les graphismes, la musique, le son, la partie 3D, etc..

D'autant plus que 99% des jeux transmettent en UDP, donc le netcode et le moteur graphique sont complétement indépendents, il n'y a pas de synchronisation.

D'autant plus que techniquement, le FPS désigne une vitesse d'affichage et non une synchronisation réseau/image.

Si on parlais de snaps ou de maxpackets, je veux bien, mais l'fps ca n'a vraiment rien à voir avec le réseau..

Zarkof

Par Alex1979 le 16/6/2001 à 3:20:00 (#444215)

Ringo : pour ton exemple des nuages, tu crois que le serveur va s'amuser à envoyer à chaque client l'état du ciel toutes les secondes ??? A mon avis le serveur désigne ça de manière aléatoire (pour les intempéries) pis quand il a envie (façon de parler) qu'il pleuve ben il transmet l'info aux clients qui eux, chargent et exécutent la routine ad hoc.

Ensuite tu dis que ton upload varie en fonction de ton fps : là j'arrive pas à voir le lien de causalité.
Pour AO j'ai descendu les paramètres graphiques et je n'ai pas constaté d'amélioration notables au niveau de la jouabilité : ça lag toujours.
C'est pareil pour Tribes 2 : je suis en 1280*920 32 bits avec toutes les options et le jeu bronche pas ni au niveau des graphismes ni au niveau du lag...

Par Dreadskulo le 16/6/2001 à 12:43:00 (#444216)

Heu ringo .....je peut te dire par experience ( bosse dans une boite de jeu ) que Kemor a Totalement raison .........
Si le serveur devait envoyer des conneries du genre la position des nuages du soleil etc .....et carrement la position des immeubles et obstacles selon que tu ais regle tel ou tel parametre graphiques ca serait carrement pas malin et super lourd a gerer.......
Solution plus simple ........faire des NIVEAUX et les faire faire installer par l utilisateur ( tiens c est bizzarre on se demande pourquoi la beta fait 600 Mo )
comme ca la seule position a renvoyer c est celle des autres joueurs par rapport a toi ( comme tout quake like d ailleurs )
Et pour les nuages soleil et savoir la position de la lune suffit juste de rajouter 2 variables ( que dalle koi ) representant le temps ( meteo et heure de la journee )et de l envoyer au client comme ca apres c est TON PC qui genere toutes les positions des elements meteo.