Bon, pour pousser, j'ai donné mon avis sur le forum technique ici même et on m'a rit au nez en me disant : c'est bien un mec qui connais pas les ordinateurs qui parle ...
Les erreurs/crash/lags/freeze viennent d'un leak mémoire, mais la question a savoir c'est quelle mémoire ?
Plus sérieusement, le problème viens de la pile mémoire qui gère le texturing, elle est donc en rapport avec plusieurs choses : l'OS utilisé et notament son kernell (et oui il y a un kernell sous windows NT/XP/VISTA/Seven, programmation POSIX inside.) la quantité de mémoire vive et la quantité de mémoire vidéo.
Explication vite fait :
L'OS gère les textures en les chargeant d'abord en ram a partir du disque dur puis ensuite en mémoire graphique quand il y a besoin de les afficher. Sauf que pour optimiser, on charge biensûr pas toutes les textures, ni en ram, ni en mémoire graphique ...
L'OS encore, sur un système XP alloue une certaine quantité de mémoire a chaque programme au moment de leurs création (2g) en mémoire non étendue (hors PAE, soit dans la limite des 32 bits maximum), cette fameuse mémoire non étendue inclue la mémoire basse (ou mémoire directe) de 640k, réservée a l'os prise en mémoire vive (addresse de 0000 0000 a 0000 00FF) puis la mémoire haute (0000 0100 a 0000 FFFF) prise en mémoire vive aussi ... Ensuite la mémoire graphique (0001 0000 jusqu'a la quantitée de mémoire maxi de votre carte vidéo en hexa) pour une question de DMA (les blocks d'addresse DMA sont accessible via tout bon soft de gestion, genre everest ...) et enfin le restant de votre ram jusqu'a remplir les 32 bits d'addressage (FFFF FFFF soit 4g de ram addressable en direct sur un OS 32 bits, les OS 64 bits etant soumis a la quantité maxi de memoire addressable par le processeur, generalement 48 bits sur un x86) (
je précise : mon explication sur ce point n'est pas rigoureuse ni même exacte en totalité, c'est beaucoup plus compliqué que ca, et y'a des cas particulier ...)
Le programme en question est soumis a se qu'on appelle des leaks mémoires, parce que les textures donc ne sont pas bien déchargées de la mémoire graphique (qui fonctionne sous forme de roundbus sans protection en ecriture, se qui veux dire que quand une zone n'est plus utilisée, la texture reste en mémoire mais on peu sans soucis réécrire dessus) se qui ne pose pas de problème en soit, mais la ou le bat blesse, c'est qu'elles ne sont pas du coup bougées de la ram ... Donc on accumule des textures en ram jusqu'a saturer la mémoire allouée par l'os, le problème ne se pose qu'a un moment précis :
Quand l'os va chercher a charger une nouvelle texture en mémoire graphique. L'os va detecter ca comme un "bufferoverflow" et bloquer les appels memoire du programme, et le programme va l'interpreter comme une defaillance de son propre systeme.
Moralité : tournez avec une carte graphique avec 256 megs de memoire, 2g de ram sous xp 32 bits et vous aurez juste des problemes de lenteur du moteur ... Après c'est la roulette russe et actuellement personne ne pourra vous dire : c'est ok pour toi ca tournera. (pour donner une idée du probleme, un "petit" defaut dans la memoire graphique peu faire qu'avec PC1 et PC2 etant exactement la meme config, PC1 plantera jamais alors que PC2 plantera, voir un faux contact sur un port pci express, une legere chauffe des puces j'en passe et des meilleurs)