Messages

1

Général / Re : Re : Système de ressources à la Qt : viable ou pas ?

« le: Août 28, 2014, 05:13:26 pm »

Pourquoi faire ?

Pour ne pas stocker toute la musique en mémoire d'un coup. Je ne décompresse que les parties de la musique demandées par sf::Music au InputSteam.

La lecture se fait dans un thread, oui. std::istream n'est pas thread-safe, donc dans tous les cas il faudra que tu rendes certaines parties de ton système thread-safe.

Du coup il faudra que j'utilise plusieurs std::ifstream (si on peut lire un fichier à partir de plusieurs ifstream en même temps). Cela me permettra aussi de faire un dégradé de musiques, du genre je baisse progressivement le son d'une musique pendant qu'une autre commence à se jouer. C'est pour ça que je veux pouvoir lire plusieurs musiques "en même temps".

Sûrement. Mais il existe très probablement déjà pas mal de gens qui ont fait des choses similaires. Après, dans tous les cas ça ne peut pas faire de mal de partager ton travail.

Oui c'est ce que je veux faire, il faut juste que j'apprenne à utiliser un dépôt git pour partager mon code source. Sinon tout est stable, du moins j'ai pas rencontré de bug, de plus c'est assez évident à utiliser, et portable.

Ca c'est vraiment une drôle de question...

Quels problèmes peut me poser un tel système de fichier ?

2

Général / Re : Système de ressources à la Qt : viable ou pas ?

« le: Août 27, 2014, 11:57:15 pm »

UP.

Je reviens sur ce topic pour parler à peu près de la même chose mais cette fois, j'ai terminé un système de fichiers data qui fonctionne. [EDIT : Le fichier data permet de stocker des fichiers sous forme compressée et de restituer leur contenu dans un programme.] Le fichier data (utilisant zlib) a un index au début qui contient la liste des fichiers et leur position par rapport au début du premier fichier (se trouvant donc à la position 0). Les fichiers sont compressés à la suite, et j'ai une fonction pour renvoyer le contenu du fichier voulu (en gros le fichier original) sous forme de std::string. J'utilise un std::string parce que c'est plus facile de travailler avec une chaîne de caractères qui peux varier en taille à mon goût. J'aurais quelques questions pour pousser un peu plus ce système :

- Devrais-je découper les fichiers en plusieurs morceaux compressés, du genre plusieurs parties de 1 ko ? Quelle taille me conseilleriez-vous pour les parties ? (je tiens à utiliser sf::InputStream pour lire les musiques, c'est l'idéal dans mon cas) ;

- En parlant de InputStream, cela risque-t-il de me gêner ? Je veux dire, est ce que la fonction

bool sf::Music::openFromStream  (       InputStream &   stream  )      

lance un thread ? Si c'est le cas, alors je ne vais pas pouvoir utiliser mon fichier pour autre chose en même temps, donc lire un son à partir du même fichier. Si les std::ifstream sont optis pour le multithreading alors je suis tranquille.

- Sachant que mon système de fichiers data fonctionne (j'ai même créé un exécutable à la 7z pour décompresser les fichiers data, ou créer des fichiers data à partir des fichiers choisis), et qu'il est portable (il écrit automatiquement en little endian, à la lecture convertit en big endian si nécessaire, et n'écrit que par octets), pourrait-il intéresser des gens ? Je veux dire, compresser plusieurs ressources dans un fichier, et pouvoir restituer leur contenu à l'intérieur d'un jeu si par exemple on veut une image, est-ce que cela intéresserait d'autres développeurs ?

- Est-ce que j'ai d'autres questions à me poser sur ce système de fichiers data ?

Merci d'avance et merci d'avoir pris le temps de lire. :p

3

Général / Re : SFML bug

« le: Août 21, 2014, 08:00:13 pm »

Bonjour,

- Vérifie que tu utilises parfaitement la même version de compilation partout (32/64 bits ? dynamique/statique ? release/debug ?) ;
- Vérifie, si tu as compilé en dynamique, que les .dll sont à côté du programme ;
- Normalement une fenêtre sfml se déclare comme tel :

sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");

- Ta fonction main est censée retourner un int, ajoute la ligne

return EXIT_SUCCESS;

à la fin de la fonction main, juste avant l'accolade.

4

Général / Re : SFML et la 3D stereo Quad buffer

« le: Août 18, 2014, 04:02:53 pm »

La SFML n'a pas de problème de compatibilité avec openGl à priori :
http://sfml-dev.org/tutorials/2.1/window-opengl-fr.php

5

Général / Re : Configuration Visual Studio

« le: Août 18, 2014, 03:15:46 pm »

Dis toi bien que pour les gros projets, le codage est une infime partie du travail.

6

Général / Re : Système de ressources à la Qt : viable ou pas ?

« le: Août 12, 2014, 06:51:32 pm »

C'est peut-être le fait que je "stocke" la ressource dans le return d'une fonction qui augmente le temps de compilation, alors que Qt stocke les ressources dans des variables globales statiques au fichier de ressources. Je vais essayer de voir si je peux faire pareil, ce qui ne m'enchante pas. :/ Au début de pensais le faire à "ma façon" mais mon système a ce problème qui est le temps de compilation, problème que le système de ressources de Qt n'a pas.

Au fait, j'ai quand même réussi à compresser le tableau de pixels avec zlib, j'ai réussi à mettre 5476 Uint8... dans un tableau d'une vingtaine d'Uint8. La décompression fonctionne bien. Maintenant que je sais comment faire, il faut bien le faire, en gros comme Qt. :p Parce que pour l'instant, la compilateur compile en 2 secondes un fichier ressources Qt, alors que mes fichiers ressources prennent 5 minutes à être compilés...

Il faut savoir que je n'utilise absolument aucun pointeur, j'utilise des std::vector pour éviter les fuites de mémoire, ou plus généralement tous les problèmes de mémoire. C'est vachement plus sécurisé, et je me casse pas la tête.

EDIT : J'ai trouvé ce qui ralentit la compilation : lorsque je crée le tableau à l'intérieur de la fonction, la compilation est lente. Lorsque je crée la variable sous forme de "globale statique" au fichier, la compilation est instantanée. Par contre ce qui m'énerve, c'est que le tableau statique est alloué au début du programme, alors que si je le crée dans la fonction, la compilation est lente mais le tableau est alloué lorsque j'en ai besoin (c'est à dire lorsque la fonction de chargement le demande). J'aimerais avoir les 2 avantages (compilation instantanée + tableau alloué si nécessaire) mais je n'ai vraiment pas d'idée. Quelqu'un aurait une solution s'il vous plaît ? (je parle du tableau qui contient les données sur les fichiers sous forme compressée, par exemple les pixels pour les images, les samples pour les sons)

EDIT : Finalement je laisse mon test de côté. Je me pencherai sur cette mécanique qui est de mettre ses ressources sous une autre forme que celle d'origine plus tard, mais pour l'instant j'en n'ai vraiment pas besoin, j'ai bien réfléchi. Merci tout de même pour l'aide apportée dans ce topic.

7

Général / Re : Système de ressources à la Qt : viable ou pas ?

« le: Août 12, 2014, 02:32:25 am »

Merci pour ta réponse Laurent. Je viens de terminer et je me rends compte d'un gros problème avec les fichiers générés : le temps de compilation. En effet pour des petites images 30x30 la compilation du fichier généré prend 5 secondes max alors qu'avec un fichier supérieur avec plus de 1000 pixels ça commence à prendre des minutes de compilation. Je vais essayer de voir si je peux compresser les données avec zlib (pour décompresser à l'exécution), le problème c'est que je dois faire un choix : soit je compile lentement et le programme est rapide parce qu'il ne fait pas beaucoup de traitements, soit je compile vite et le programme est lent parce qu'il fait beaucoup de traitements. C'est valable pour toutes les alternatives je suppose.

8

Général / Système de ressources à la Qt : viable ou pas ?

« le: Août 11, 2014, 10:18:16 pm »

Bonjour,

Je cherche à créer un système de ressources à la Qt (pour avoir les ressources dans l'exécutable) avec une fonction qui renvoie les informations sur les images lorsque celles-ci sont demandées (selon le nom de leur fichier sans le répertoire avant). J'ai déjà réussi à générer le C++ pour le tableau d'Uint8 de l'image (les composantes des couleurs). Je choisis les fichiers, je choisis un fichier source à créer, et je lance la compilation. Je n'ai pas terminé, les fichiers source générés ne sont pas encore utilisables.

Mais avant d'aller plus loin, j'aimerais quand même savoir si ce que je cherche à faire est viable et portable (en dehors du fait que j'utilise bien le type portable sf::Uint8).

Voici un exemple de code généré :

#include "RessourceManager.h"

void RessourceImage::registeredImages(sf::String filename, RessourceImage * img)
{
if(filename.toUtf8() == sf::string("block1.png").toUtf8()){
unsigned int pX = 37;
unsigned int pY = 37;
const sf::Uint8 pixels[] = { composantes des couleurs };
//stockage des informations dans img
else {
unsigned int pX = 0;
unsigned int pY = 0;
const sf::Uint8 pixels[] = { 0 };
// stockage des informations dans img
}
}
 

pX = nombre de pixels en longueur
pY = nombre de pixels en hauteur
const sf::Uint8 pixels[] = tableau des composantes des couleurs

Comme je l'ai dit je n'ai pas terminé, je ne cherche pas des critiques sur le code généré, mais bien de savoir si l'idée est bonne, conventionnelle, et si elle peut me poser des problèmes. J'ai mis le sujet ici car le système ne concerne pas qu'un module, mais tous les modules qui peuvent utiliser des ressources.

Merci d'avance.

9

Général / Re : Compiler la SFML en statique pour l'utiliser dans un programme non open source ?

« le: Août 07, 2014, 02:50:10 pm »

Merci pour cette réponse claire, c'est exactement ce que je voulais savoir. Je tiens à dire au passage que la SFML est puissante et que je ne vois pas de meilleure alternative en C++ voire dans d'autres langages pour le binding. Longue vie à la SFML. :p

10

Général / Re : Installation

« le: Août 07, 2014, 04:38:53 am »

Bonjour,

Tu as ici bon nombre de bibliothèques compilées sous bon nombre de configs (quasiment toutes les configs, par config je veux dire compilateur/version debug ou release/32 ou 64 bits) :

http://www.nightlybuilds.ch/compiler/show/7/Visual%20Studio-2013-32/

Personnellement j'ai compilé moi-même la SFML de mon côté pour Visual Studio 2013, si tu n'as pas compris quelque chose dans le tutoriel n'hésite pas à demander (je ne te garantis rien).

11

Général / Compiler la SFML en statique pour l'utiliser dans un programme non open source ?

« le: Août 07, 2014, 04:30:48 am »

Bonjour !

J'ai bien fouillé Google avant de poser cette question, j'ai du passer 2h à chercher ma réponse et je pense qu'elle est dans la licence mais par soucis de compréhension, parce que je ne comprends pas toujours tout, je pose quand même la question. Peut-être que cela va vous paraître idiot, mais j'ai vraiment peur de me tromper sur ce qui peut être fait ou non sous la license zlib/libpng. Bref, tout ça pour dire : pas taper sur les doigts.

Est-ce qu'il y a une différence autre que la présence des fichiers .dll entre distribuer un programme auquel est lié la SFML statique et la SFML dynamique ? Est-ce qu'il faut faire quelque chose de plus, du genre distribuer le code source du programme compilé avec la SFML statique ? Ou est-ce que c'est exactement la même chose ? Compiler un programme SFML statique <=> compiler un programme SFML dynamique ?

Je parle bien aux yeux de la licence, et non pas de la taille de l'exécutable ou autre chose.

Bien sûr tout cela n'exclut pas que je tiens à remercier quand même explicitement l'auteur de la bibliothèque. J'ai bien compris que c'était apprécié mais pas obligatoire.

Ah oui, et si j'avais pu trouver la réponse que je cherche avec une recherche... Pas taper sur les doigts quand même.

Merci d'avance pour vos réponses.