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
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
C'est dans ses rêves que l'homme trouve la liberté cela fut, est et restera la vérité! (John Keating - Le cercle des poètes disparus)
Bonjour,
bibliothèque*
C/C++
Il faut te décider C ou C++ ?
Sinon
http://lmgtfy.com/?q=asynchronous+files+C%2B%2B
Oui désolé c'est l'habitude du mot anglais, mauvaise traduction^^
Je voulais dire par là en C ou C++, peu importe.
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
C'est dans ses rêves que l'homme trouve la liberté cela fut, est et restera la vérité! (John Keating - Le cercle des poètes disparus)
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?
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Je ne sais plus exactement mais grosso-modo, si j'ai bien compris ce qui était dit :
- 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.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 !Envoyé par Neckara
La je crois qu'il va te falloir etre plus precis.Envoyé par Neckara
Cela dépend aussi des optimisations qui peuvent être fait sur le code.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.
Essaye de retrouver le post car j'ai pas tout comprisLa je crois qu'il va te falloir etre plus precis.
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.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.
Bien que techniquement vrai, ce n'est pas forcément la solution optimale (duplication de code, réinvention de roues, etc.)
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
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 ?
C'est dans ses rêves que l'homme trouve la liberté cela fut, est et restera la vérité! (John Keating - Le cercle des poètes disparus)
Find me on github
Salut,Je ne me souviens plus vraiment du jeu, mais est-ce vraiment nécessaire
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 )
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
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 )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
A méditer: La solution la plus simple est toujours la moins compliquée
Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
Compiler Gcc sous windows avec MinGW
Coder efficacement en C++ : dans les bacs le 17 février 2014
mon tout nouveau blog
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.
Open Source Microsoft MediaFoundation
https://github.com/mofo7777
http://jeux.developpez.com/faq/directx/?page=dshow
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!
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
A méditer: La solution la plus simple est toujours la moins compliquée
Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
Compiler Gcc sous windows avec MinGW
Coder efficacement en C++ : dans les bacs le 17 février 2014
mon tout nouveau blog
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
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...
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.
Open Source Microsoft MediaFoundation
https://github.com/mofo7777
http://jeux.developpez.com/faq/directx/?page=dshow
Bien sûr que c'est possible.
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
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.
Open Source Microsoft MediaFoundation
https://github.com/mofo7777
http://jeux.developpez.com/faq/directx/?page=dshow
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 .
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager