Dans le meilleur des cas, ont compte 1 octets par carré de la carte, donc ont fait: 512*512 = 262144 carré(pixels )

donc 262144 octets = 256Ko de RAM utilisé.

pour donc du 2048*2048 = 4Mo de RAM utilisé, ce qui fait une sacré différance.
Ensuite, il faut coder en mémoire les arbres présents, les industries, les compagnies avec véhicules etc...
Tous cela ca fait lourd dans la balance.

Et encore, pour la carte je n'ai compté que 1 octet pour chaque pixel donc utilisation d'un type char.

Comme en général ont utilise le type int(integer), cela fait non pas 1 octets par pixels mais 4.

donc 512*512 = 262144 pixels = 1048576 octets = 1024Ko = 1Mo.
C'est déja plus pareil

pour 2048*2048cela nous fait 16Mo de RAM juste pour charger la carte.
Faut ensuite afficher arbres etc...
Faut aussi gérer les autres joueurs, donc ca prend de la RAM en plus car si ont considère que la case herbe par exemple est remplacé par la case rail vertical par exemple, dans ce cas là oui niveau de la RAM ont touche pas(ont fait juste le changement c'est tous).
Mais oublions pas qu'il faut charger en mémoire les GRF, gérer le déplacement des véhicules, gérer celui de la souris quand ont bouge la carte.

Avec du 512*512 je penses que l'ont doit sur une partie sur le serveur, déja utilisé pas loin de 16Mo de RAM si ont est 2 ou 3 pas plus sur le serveur.

Imaginez si ont était 10 sur le serveur et en 2048*2048
1 - Faut que la RAM suive
2 - Faut que le CPU suive, sachant que celui-ci va tourner a plein régime
3 - Faut que la connexion suive
Car si ont est bcp, il y a bcp plus d'infos qui doivent etre reçus par le client et le serveur lui doit en recevoir et en envoyer bcp.

2048*2048 avec 10 joueurs assez actifs sur le serveurn là je peux vous garentir que en dessous des 2432Kbps vous tenez pas pour le client, et le serveur oui il lui faut bien 5Mbps en réception et si possible en envoie au moins 512Kbps autrement une configuration de base en free haut débit non dégroupé comme ce que j'avais avant(a cause du bug ECI de FT, j'ai du repassé en 2432Kbps chez free en attendant que je sois dégroupé).


Donc éffectivement, il faut pas trop poussé au niveau de la taille de la map.
De plus, il y a un facteur don j'ai pas parlé: la RAM vidéo.
Les jeux utilisent toujours la RAM vidéo plutôt que le CPU pour faire certains calcules, afin d'en augmenter la vitesse et diminuer la charge CPU.
Si ont prend un utilisateur ayant une CG de 8Mo RAM vidéo, le CPU va avoir énormément de boulot si cette mémoire est déja entièrement utilisé.
Un utilisateur qui a pas contre une 256Mo RAM vidéo DDR2, il aura aucun problème.



Il faut toujours prendre en compte tous ses facteurs là contrairement à ce certaine personne disent que sur le site la seule chose qui importe est la connexion.
Car la connexion est importante oui, plus la connexion est haute, plus le ping sera bas je dit pas le contraire.

Maintenant si niveau RAM tu as pas assez, que le CPU est surchargé, ou que la RAM vidéo sature, les données seront reçus toujours aussi vite mais seront analysé plus lentement, et le ping va quand même monté.

Oublions pas une chose, je vais prendre l'exemple de Windows(vous êtes 85% a l'utiliser plutôt que utiliser Linux ):
Ont nous envoie des données, windows va mettre en sommeil une tache pour recevoir les données envoyé(la connexion a toujours une priorité assez haute par rapport aux autres applicatios), il faut ensuite qu'il analyse les données en question pour savoir a qui il doit les redistribuer.
Il analyse donc, il voit que c'est pour OpenTTD, il lui transmet.
OpenTTD va analyser, comprendre les données et réagir en conséquence, puis il va donner les nouvelles infos à windows qui va les transmettres, et ainsi de suite.


Jusque là tous va bien.
Mais imaginons que la RAM vidéo est saturé
Dans ce cas là, OpenTTD dit à windows: la RAM vidéo est pleine, demande au CPU de faire telles calcules.
Le CPU va donc prendre plus en charge(au lieu de 85% par exemple il va prendre 95% ce qui va commencé à créer quelques lags ).
Puis ont reçoit du serveur des données.
Windows va les reçevoirs, puis va attendre que le CPU est fini les calcules actuelles qui l'oblige a être utilisé à 95% au lieu de 85%.
Une fois que le CPU a un peu de temps devant lui, windows peut analyser les infos puisqu'il va faire des calcules donc il va utiliser le CPU.
Ses analyses une fois faite, il va transmettre à OpenTTD.
Mais le jeu lui a déja acumulé un peu de retard car les données qui sont envoyé à windows pendant qu'il faisait les analyses ne sont pas arrivé au but, donc ils sont perdu(d'où l'utilité de l'UDP, mais je vais expliqué un peu ce protocol ).
Donc OpenTTD a eu juste une partie des données, ce qu'il va afficher a l'écran sera juste le résultat des données reçus.
Il va s'en dire que l'ont va voir un décalage que l'ont nome un lag.

Donc, de quoi est venu ce lag dans mon exemple ?
A une surcharge du CPU.
Pourquoi  cela ?
La RAM vidéo étant insuffisante/pleine, le jeu à du relégué certaines taches directement au CPU de l'ordi plutôt que au CPU de la Carte Graphique(oui les CG ont un processeur interne, c'est pour cela qu'elles ont une mémoire vidéo ).



Un peu plus haut, dans mon exemple j'ai parlé de l'UDP, vous allez me dire: "Mais c'est quoi l'UDP ?"
Ont reconnais 2 types de protocoles de communication dans un jeu:
- UDP
- TCP

Les 2 protocoles sont utiles suivant ce don ont à besoin.

Le protocole UDP envoie des données dans n'importe quel ordre.
Le TCP lui envoie toujours dans un ordre précis.

Avantage de l'UDP:
- Il n'a pas besoin d'attendre, il envoie les infos c'est tous.
- Il n'y a pas d'ordre.

Désavantage de l'UDP:
- Celui-ci ne sais jamais si l'info est arrivé à destination ou non, l'information peut donc être perdu.


Le TCP lui:
- Attend toujours une réponse du client.
- Il n'envoie d'autres infos que après avoir reçus une réponse.

avec le TCP les infos ne peuvent donc pas être perdu, car il attendra soit jusqu'a ce que l'ont ai reçus l'info et renvoyé une réponse, soit jusqu'au TimeOut.
Le problème c'est que dans un jeu comme OpenTTD, cela provoquerais donc un blocage sur l'écran, plus rien ne bougerais si l'info met du temps à arriver.

L'UDP ne demandant pas coonfirmation de réception et envoyant dans n'importe quel ordre, ce genre de problème est donc inéxistant.

Les 2 protocoles sont utiles, dans le cadre d'un jeu l'UDP est plutôt utilisé.
Dans le cadre d'un chat comme MSN Messenger(windows Live Messenger) par exemple,  c'est plutôt le TCP qui est utilisé.
Pour un logiciel d'assistance à distance comme VNC, c'est le TCP.

Pour un logiciel de VOIP comme Skype, c'est plutôt de l'UDP.

Plus haut, je vous ai aussi parlé de TimeOut, vous allez dire: "Oui, tu nous en a parlé mais c'est quoi ce machin là encore ?"

Le TimeOut c'est un certains temps autorisé pour une chose, dans mon exemple le protocole TCP dispose d'un TimeOut, c'est à dire qu'il va attendre un certain temps la réponse, si celle-ci n'est pas reçus avant la fin du TimeOut, le client est considéré comme déconnecté ou mort, la connexion est donc fermé.

Le TimeOut est utilisé aussi pour les serveur internet(HTTP, etc...).
Par exemple vous afficher la page du forum.
Si celle-ci passe plus de 60 secondes généralement(a réglé dans Apache/IIS ), le serveur coupe la connexion avec le client.

Cela permet de couper la connexion si le client ne répond pas, plutôt que garder une connexion active qui va couter de la RAM et du CPU, et qui dans le cas de Apache va obliger au bout d'un moment à créer une instance Child, en coupant la connexion il réduit cela.


"Un Child c'est quoi ?" bonne question

Quand ont dit que Apache crée une instance Child, cela veut dire que au bout d'un certains nombres de connexion active, il va créer une nouvelle instance de lui même.

Exemple sous windows:
Vous avez un processus apache lancé, donc apache.exe est lancé une fois.
Vous aez réglé pour que toute les 3 connexions il créer une nouvelle instance.
Dans ce cas là, vous avez 3 utilisateurs connecté, pas de problème.

Un quatrième veut se connecter, apache va lancer un second apache.exe
Vous voyez donc maintenant 2 apache.exe en mémoire RAM au lieu de 1.
si maintenant sur les 3 utilisateurs de départ, le second se déconnecte.
Il en reste que 2, le quatrième arrive, il va pouvoir se mettre sur l'instance normal d'apache.

Pour les rois des serveurs http:
J'ai pas pris en exemple la limitation de connexions sur une instance, j'ai supposé que l'ont avait pas définie de connexions total pour chaque instance.
Car oui ont peut définir un nombres de connexion au total sur une instance, ce qui fait que si dans mon exemple ont avait demandé 3 connexions au total sur l'instance, il aurait quand même créer une nouvelle instance même si les 3 autres utilisateurs étaient parti.


Tous cela pour dire quoi ?
Faut prendre garde à tous quand ont lance un serveur.

La partie concernant apache, c'était juste pour expliquer le TimeOut.

Message en réponse au sujet:http://ttycoonfr.free.fr/forum/index.php?topic=272.0

Chaque carré de la carte fait 8 octets, décomposé de la manière suivante :
- m1 : octet
- m2 : mot (2 octets)
- m3 : octet
- m4 : octet
- m5 : octet
- m6 : octet

Donc faites le calcul

Surtout qu'OpenTTD n'utilise que la RAM système et le CPU (y'a pas d'accélération matérielle)

Tu regardes tous les jeux de maintenant, tous sans exceptions même les petits jeux sous linux utilisent la RAM vidéo

Mon pong sous linux n'utilise pas la la RAM video _D_

oui mais ces jeux qui on n'ont besoin si ottd en a besoin c'est pas grave