Discussion :

[sphynxounet]

Bonjour,

actuellement je développe une future application commerciale sous Windev.
J'ai commencé à suivre le tuto traduit de NeHe jusqu'à l'intégration de textures.
Dans l'exemple qui est fourni dans Windev, il y a un fichier .bmp qui est importé mais dans le code, chaque pixel de l'image est stocké dans une table, de colonnes et lignes égales à la taille de l'image.
Personnellement je trouve cette façon de faire un peu lourde et barbare.

J'ai parcouru un peu le net et j'ai vu qu'il y avait des fonctions avec GDI+ ou SDL pour gérer les textures.

J'aimerais avoir quelques conseils à savoir quelle API est la plus adaptée pour importer des textures dans OpenGL.

Merci.

[ash.ice.loky]

La méthode exposé te permet de créer ton propre loader d'images.

Sinon lorsque je faisais encore de l'opengl en C++ j'utilsiais SDL_images et DevIL.

Les 2 restent des références sûr dans ce domaine.

[ash.ice.loky]

Au fait pour ceux que ca intéresse, des tutos sur la création de loader sont présent ici:

http://jeux.developpez.com/tutoriels/?page=gl

[Mat.M]

Dans l'exemple qui est fourni dans Windev, il y a un fichier .bmp qui est importé mais dans le code, chaque pixel de l'image est stocké dans une table, de colonnes et lignes égales à la taille de l'image.
Personnellement je trouve cette façon de faire un peu lourde et barbare.

J'ai parcouru un peu le net et j'ai vu qu'il y avait des fonctions avec GDI+ ou SDL pour gérer les textures.

J'aimerais avoir quelques conseils à savoir quelle API est la plus adaptée pour importer des textures dans OpenGL.

Merci.

GDI+ n'a rien à voir avec Open GL ; GDI+ c'est une amélioration du GDI
Open GL fonctionne de manière similaire à Direct X à savoir court-circuiter le GDI pour tirer profit de l'accélération graphique.
Comme tu dis charger une bmp dans un tableau d'octets est lourde mais tu ne peux pas faire autrement.
Si tu prends une bibliothèque de code comme SDL cela reviendra parfaitement au même.

[sphynxounet]

Comme tu dis charger une bmp dans un tableau d'octets est lourde mais tu ne peux pas faire autrement.
Si tu prends une bibliothèque de code comme SDL cela reviendra parfaitement au même.

Ok.

En fait mon soucis actuel est d'adapter le tuto de NeHe qui est en C++ au langage Windev qui est ... particulier.
Dans le code de Nehe, dans le tuto sur les textures on a :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TextureImage[0]=LoadBMP("Data/NeHe.bmp")

alors que dans l'exemple de Windev il y a une boucle pour charger chaque pixel de l'image.

EDIT : je pose la question aussi pour la licence car sur le site il y a visiblement un changement de licence pour la version 1.3 et le logiciel que l'on développe sera un logiciel commercial.

Mon soucis principal est d'avoir des librairies (en .dll) qui me permettent d'alléger mon code avec des appels de fonctions, plutôt que de me faire moi-même des fonctions, ce qui me prendra beaucoup de temps pour un résultat pas forcément génial.
Je préfère éviter de réinventer la roue.

[sphynxounet]

Un petit message pour dire qu'en fait mon soucis ne venait pas de comment faire pour importer une texture mais plutôt où l'importer, puisque si en C il y a une fonction pour stocker un fichier image en mémoire, avec Windev le problème est que cette fonction n'existe pas.

Mais comme Windev s'inspire allègrement du C, il y a une fonction fOuvre qui permet de lire les octets d'un fichier et de les stocker dans une zone mémoire.
En tout cas ça fonctionne pour les BMP, je pense que pour le JPEG ça va être tout autre ...