Bonjour :)
Je cherche un librairie (C/C++) pour faire des opérations asynchrones sur les fichiers, si possible multi-plateforme (Windows et Linux minimum)
Merci bien :)
Kromagg
Version imprimable
Bonjour :)
Je cherche un librairie (C/C++) pour faire des opérations asynchrones sur les fichiers, si possible multi-plateforme (Windows et Linux minimum)
Merci bien :)
Kromagg
Bonjour,
:fessee: bibliothèque*
:fessee:Citation:
C/C++
Il faut te décider C ou C++ ?
Sinon :google:
http://lmgtfy.com/?q=asynchronous+files+C%2B%2B
Oui désolé c'est l'habitude du mot anglais, mauvaise traduction^^Citation:
Envoyé par Neckara
Je voulais dire par là en C ou C++, peu importe.Citation:
Envoyé par Neckara
Et la recherche google n'a rien donnée de concluant puisque je n'ai trouvé aucune bibliothèques multi-plateforme. C'est donc pour ça que je poste sur ce forum :)
Si j'ai bien lu, boost::asio permet de faire de la lecture aynchrone de fichier sous Windows (?) mais sous Linux, la lecture sera synchrone (car cela n'aurait pas de sens sous Linux).
Sinon, on trouve des codes ci-et-là, un simple #ifdef et le tour est joué.
EDIT : tu as aussi AIO pour Linux.
Après pourquoi veux-tu faire de la lecture de fichier asynchrone?
Pourquoi cela n'aurait-il pas de sens?Citation:
Envoyé par Neckara
Je ne sais plus exactement mais grosso-modo, si j'ai bien compris ce qui était dit :Citation:
Envoyé par Médinoc
- les lectures sont très "rapides" ;
- on a très souvent besoin d'attendre la fin de la lecture avant de continuer à exécuter la suite des instructions ;
- et il y a une histoire avec le kernel Linux.
Pour ces raisons là, la lecture asynchrone n'est pas vraiment utile sous Linux ce qui a été un frein à l'ajout complet de la lecture asynchrone dans boost.
Je crois que cela devait être dans un sujet de stackoverflow dans les premiers liens de la recherche que j'ai posté plus haut.
Après, je ne fais que reporter ce que j'ai cru comprendre.
@Neckara: je trouve bizarre ce que tu dis sur le coup ou alors je ne dois pas avoir la meme definition du mot asynchrone que toi...
Prenons par exemple une ecriture de donnee asynchrone sur un fichier, elle devrait en toute logique se faire sans ralentir l'execution du programme puisqu'elle serait executee en parallele du thread principal. N'est-ce pas la le but de l'asynchronisme ?
Cette affirmation me parait fausse puisque la vitesse de lecture / ecriture d'un fichier depend surtout du materiel sur lequel il est stocke ! Sur un SSD ca sera en effet tres rapide mais pour le reste ca peut causer de grosse latence.Citation:
Envoyé par Neckara
Pas necessairement. Une fois de plus prenons un exemple : un jeu video tourne, tu te balades et tu as besoin de charger une nouvelle texture (tres lourde). Tu ne vas pas stopper le jeu pendant ce temps-la, ce serait inconcevable !Citation:
Envoyé par Neckara
La je crois qu'il va te falloir etre plus precis. :mouarf:Citation:
Envoyé par Neckara
Cela dépend aussi des optimisations qui peuvent être fait sur le code.Citation:
Cette affirmation me parait fausse puisque la vitesse de lecture / ecriture d'un fichier depend surtout du materiel sur lequel il est stocke !
Après, comme je l'ai dit, je ne fais que rapporter ce que j'ai lu.
C'est pour cela qu'on utilise des threads et des écrans de chargements.Citation:
Envoyé par imperio
Essaye de retrouver le post car j'ai pas tout compris :aie:Citation:
La je crois qu'il va te falloir etre plus precis. :mouarf:
Justement, la lecture asynchrone, c'est pour quand on n'en a pas besoin. Quand on a besoin du résultat tout de suite, on fait une lecture synchrone.Citation:
on a très souvent besoin d'attendre la fin de la lecture avant de continuer à exécuter la suite des instructions
Traduction: Si on veut de la lecture asynchrone, on peut la faire soi-même.Citation:
Envoyé par Neckara
Bien que techniquement vrai, ce n'est pas forcément la solution optimale (duplication de code, réinvention de roues, etc.)
En fait je travaille sur un projet de jeux vidéos 2D, j'aimerai pour commencer reproduire le premier niveau de l'excellent Jazz Jack Rabbit 2 qui a bercé une partie mon enfance :) Et j'ai justement besoin de la lecture asynchrone pour charger le décors des niveau au fur et à mesure que le joueur progresse. J'ai pensé à développer mon système à base de thread mais pourquoi réinventer la roue.
Est-ce que le couple std::async/std::future pourrait faire l'affaire pour ce type de tâche ?
Très certainement !Citation:
Envoyé par Kromagg
Salut,Je ne me souviens plus vraiment du jeu, mais est-ce vraiment nécessaire :question:Citation:
Envoyé par Kromagg
Dans la plupart des jeux 2D, l'ensemble du niveau n'est qu'une composition basée un ensemble relativement limité de "briques de base".
Par "brique de base", j'entends bien sur les différents éléments du décors qui défile (et même, dans une certaine mesure, les différents méchants vilains pas beaux qui viennent t'embêter régulièrement :D )
Une fois que tu as chargé ces "briques de base", que ce soit sous la forme de "tuiles" en jpeg ou sous la forme de dessin vectoriel + texture, "tout ce qu'il faut faire", c'est être en mesure d'indiquer quelle brique va à quel emplacement dans le décors.
Pour peu que tu sois en mesure d'identifier clairement chaque brique de base (par exemple, au travers d'un indice de tableau), tout ton niveau peut donc se résumer en une grande matrice de n ligne et de m colonnes qui correspondent respectivement à la hauteur et à la largeur de l'intégralité du niveau envisagé et dont la correspondant à une position x, y correspond à la brique de base qu'il faut afficher pour cette position.
Tu peux donc mettre énormément d'informations dans un espace particulièrement réduit et ton niveau peut très certainement être chargé "en entier" en mémoire, surtout quand on voit les capacités actuelles des PC en la matière ;)
Dés lors, n'as tu pas l'impression de te faire du mal pour rien en essayant d'utiliser la lecture asynchrone :question:
Maintenant, je ne dis pas que tu te fais du mal pour rien, je dis juste que tu risques ou que tu as de grandes chances de le faire ;)
Si l'idée du thread est très certainement bonne, si tu ne devrais en effet pas avoir à réinventer la roue, je ne suis pas sur du tout que tu aies réellement besoin d'utiliser cette idée dans le contexte dans lequel tu te trouves (cf la première partie de ma réponse ;))Citation:
J'ai pensé à développer mon système à base de thread mais pourquoi réinventer la roue.
Ma réponse n'apporte évidemment pas de solution à ton problème de lecture asynchrone, mais elle a pour but de t'ouvrir peut être d'autres pistes de réflexion qui te permettront -- qui sait -- de ne pas en avoir besoin ;)
Bonjour.
Je confirme le message de koala01. On charge tous les éléments du niveau une seul fois au début.
Le faire en court de route, c'est exposer le joueur à de bon petits lags sympas.
Sous DirectX par exemple, on va utiliser des textures compressées au format DDS, afin de pouvoir charger la mémoire GPU au maximum.
Je dirai que la piste des textures compressées est à envisager avant le chargement asynchrone.
bonjour
[vraie question inside]
Et faire le chargement du niveau 2 en temps masqué arrivé à un certain stade du niveau 1 pour éviter une trop grosse pause, c'est pas envisageable?
Bien sur que c'est envisageable!Citation:
Envoyé par therwald
Mais cela ne nécessite toujours pas la lecture asynchrone ;)
Et puis, cela pourrait éventuellement poser des problèmes si le zero a encore l'occasion de mourir entre le moment où tu décides de charger le niveau suivant et le moment où il y arrive.
La solution est peut être viable, mais il s'agit de prendre tous les aspects que cela peut impliquer en compte ;)
Corrigé pour toi.Citation:
Envoyé par koala01
Le chargement "à l'avance" du niveau suivant ne peut être fait qu'en asynchrone. Mais ça peut être fait en asynchronisant soi-même (en faisant une lecture synchrone sur un autre thread) sans nécessiter que l'OS asynchronise pour toi.
Bonjour.
Et bien si le premier niveau occupe 75 % de la mémoire graphique et que le deuxième niveau aussi, cela fera 150% d'occupation mémoire. Ce qui n'est pas possible...Citation:
Envoyé par therwald
On pourrait toujours charger 25%. Mais le problème pourra être le lag. Si le jeu en cours d'utilisation prends 80% de la bande passante qui relie la mémoire vive à la mémoire GPU. Il ne reste que 20% pour charger les 25% de mémoire GPU. Si le processus asynchrone utilise plus de 20%, il y aura du lag. Et je pense qu'il y aura quand même du lag sur pas mal d'architecture.
Et comme tout cela peut dépendre de plein de choses, pour être compatible multi-GPU, cela va demander beaucoup de travail. Mais pourquoi pas...
Sous DirectX, le multithreading GPU est arrivé depuis Vista. C'est plutôt jeune comme concept.
Donc mon conseil, lorsqu'un jeu est cours d'utilisation, il faut éviter d'en rajouter à moins de savoir ce que l'on fait, donc de l'avoir éprouver sur beaucoup d'architecture différente.
Bien sûr que c'est possible.Citation:
Envoyé par moldavi
Tout ça grâce à cette merveilleuse invention qu'est la mémoire SWAP ;).
Après si on utilise toute la RAM + toute la mémoire SWAP, il est temps de se poser des questions...
Après pour le reste, je ne suis pas très calé en GPU mais si on a des écrans de chargements dans les jeux pros (et sans utiliser de tiles), je pense qu'il y a une très bonne raison. S'ils pouvaient s'en passer facilement, ce serait fait depuis très longtemps je pense.
Bonjour Neckara.
Ce n'est pas bien de jouer avec les mots :scarymov:Citation:
Envoyé par Neckara
Le swap est un Fake qui te fais croire que tout est en mémoire GPU. Sauf que tu n'as plus la main au niveau optimisation. Cela risque de swapper dans tous les sens.
Sous DirectX tu as la "Memory Managed". En gros s'il n'y a pas assez de place en mémoire GPU, ce sera en mémoire vive. Mais quand les shaders/textures sont utilisés, ils montent dans la mémoire GPU, au besoin. C'est un processus incontrôlable et source de lags.
Si les temps de chargement des niveau 1 et 2 sont de 15 secondes, de toute façon que tu swap ou pas, il faudra 15 secondes. A un moment les ressources doivent se trouver dans la mémoire GPU. Donc qu'elle est l'intérêt de charger le niveau 2 vers la fin du niveau 1, puisque tu n'échappera pas à ces 15 secondes. Avec le risque de faire lagger le niveau 1, et pour gagner quoi. 2 secondes sur 15...
De plus le risque, c'est que l'API décide de mettre les ressources de ton niveau 2 à la place de quelques ressources du niveau 1, qui ne sont pas utilisées depuis un moment. Malheureusement si une de ces ressources vient à être nécessaire, ça va re-swapper. Plutôt téméraire comme approche.
Ah moi je pensais juste chargement en mémoire : lecture du fichier pour mettre en mémoire vive.
Après, encore faut-il que ce soit le GPU et non le chipset graphique qui soit utilisé etc... Après... Je ne peux pas vraiment dire grand chose de plus, je ne suis vraiment pas calé dans ce domaine et je pense que tu dois t'y connaître un peu mieux que moi :mrgreen:.
Re.
Oui tout à fait. Un pré-chargement en mémoire vive, pourquoi pas. Cela ne mange pas de pain.
Pour un Giga de texture, cela peut-être intéressant. Mais si le joueur à la fin du niveau 1 quitte le jeu, tu auras chargé 1 Giga pour rien...
Et je ne pense pas qu'un joueur qui vient de faire un niveau 1 intense, en voudra au jeu de lui faire faire une petite pause, avant le niveau suivant. Je dirais même que c'est nécesaire.
Hello
Alors là, pas d'accord, après un niveau 1 intense, c'est hyper frustrant d'attendre :D mais bon c'est le cas sur pas mal de jeux donc les joueurs sont habitués.Citation:
Envoyé par moldavi
Les intervenants ont tous de bonnes idées, je suis personnellement pour le chargement asynchrone qui commence dès le début du niveau 1. Je ferais attention aux deux points suivants:
- Bien gérer la granularité des ressources : par exemple, si la RAM du joueur est limitée, c'est bien de ne charger que la moitié du niveau si ça l'occuperait trop, ou de charger les deux suivants s'il a de la place. Ce n'est pas trop gênant de beaucoup occuper la RAM car il est peu probable que le joueur lance un autre processus très consommateur en même temps (et si c'est le cas, c'est pas malin ^^).
- Attention au piège classique : si tu lances un chargement asynchrone, il faut prendre soin de pouvoir l'interrompre de manière réactive et fiable en cours d'exécution, si jamais le joueur décide de quitter la partie (pour quitter le jeu ou charger une sauvegarde vers un autre niveau par exemple). Interrompre proprement un thread est souvent plus délicat que le lancer. Un booléen atomique (C++11) peut être utilisé, ou bien libevent qui se révèle particulièrement adaptée en ce qui concerne la lecture de fichier.
Re jblecanard.
Si ton jeu a une durée de vie de 20 heures avec un bon joueur, il faut penser à sa santé et l'obliger à faire des pauses.
Je vois plutôt la chose comme cela. Entre chaque niveau tu fais une animation video, comme cela se fait souvent. Pendant la lecture de la video tu charges le niveau suivant.
Du coup le joueur fait un break, la video rend l'immersion dans le jeu un peu plus profonde, et il n'a pas le sentiment d'attendre.
moué...mon expérience perso c'est que ce qui fait le plus pour la santé des joueurs c'est de pouvoir arrêter pour se reposer sans tout perdre...le reste, ma foi...Citation:
Envoyé par moldavi