C'est vraiment étrange comme problème.
C'est pas forcément la solution, mais essais de lancer le projet en 32bits (entre Debug et Run tu peux choisir x64 ou x86, x86 étant 32bit).

Voilà ce que j'obtiens en x86

J'ai changé le chemin de l'image de absolut a relatif et j'ai ceci

Le problème vient réellement de cette fonction

Mais comment faire pour charger une image dans ce cas la

Le programme fonction seulement si je passe un chemin invalide donc quand l'image ne sait être lue c'est pour ca que ca fonctionnait chez toi car le chemin était en absolu si tu essaie de charger une image de ton propre ordinateur tu aura aussi un access violation mais je ne vois pas ou est le problème avec stbi_load je lui passe les bon arguments pourtant

J'ai vu que le chemin etait absolu, et je l'ai passé en relatif, et l'image est lu correctement et le pointeur retourné est correcte. C'est pour ca que je comprends pas ce qui se passe de ton coté et de celui de lapintade aussi.

Et oui ton appel me sembke tout a fait correcte.

Il y a d'autre facon de charger une, stb etant de loin la plus simple ... Il existe plein de lib pour le faire, je ne les connais pas toutes (j'utilise la libpng en general si il n'y a pas de methode disponible dans l'environement ou j'en ai besoin).
En cherchant rapidement j'ai vu passer lodepng qui a l'air simple a integrer (juste un fichier .h et un .c a integrer au projet)

Tu reussis a afficher une texture sur l'écran de ton coté ?

Le 05 mars 2022 à 21:34:08 :
J'ai vu que le chemin etait absolu, et je l'ai passé en relatif, et l'image est lu correctement et le pointeur retourné est correcte. C'est pour ca que je comprends pas ce qui se passe de ton coté et de celui de lapintade aussi.

Et oui ton appel me sembke tout a fait correcte.

Il y a d'autre facon de charger une, stb etant de loin la plus simple ... Il existe plein de lib pour le faire, je ne les connais pas toutes (j'utilise la libpng en general si il n'y a pas de methode disponible dans l'environement ou j'en ai besoin).
En cherchant rapidement j'ai vu passer lodepng qui a l'air simple a integrer (juste un fichier .h et un .c a integrer au projet)

C'est mega louche oui. (Pour repondre, je suis en Visual Studio 2019 community).
J'ai pas pu lancer en 32 bits, car les libs linkées sont en 64 bits.

Je comfirme pour lodepng, c'est ce que j'utilise dans mes petits outils, il est top.

voila mon code

// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
struct sImage
{
    // From PNG
    unsigned char* image;        // RGBA loaded from PNG
    unsigned width, height;      // From PNG
};

// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
std::optional<sImage> loadpng(std::string filename)
{
    sImage result;
    unsigned error;
    error = lodepng_decode32_file(&(result.image), &(result.width), &(result.height), filename.c_str() );

    if (error==78)
        std::cout << "ERROR FILE NOT FOUND (lodepng_decode32_file) File " << filename.c_str() << "\n";
    else if (error==77)
        std::cout << "ERROR lodepng_decode32_file ERROR WHILE READING\n";
    else if (error==0)
        std::cout << "Picture open " << filename.c_str() << "\n";
    if (error != 0)
        return {}; // Return error code
    else
        return result;
}

Le problème vient de stbi_load sure mais pourquoi car lorsque je ne load pas d'image et que je passe NULL a la place de image tout fonctionne correctement

Le problème vient de stbi_load sure mais pourquoi car lorsque je ne load pas d'image et que je passe NULL a la place de image tout fonctionne correctement

Car c'est tout à fait valide, lors de l'appel à glTexImage2D, avec un pointer NULL vers data, tu crée une texture "vide" (alors en fait le contenu est indéfinit), tu alloue l'espace mémoire pour stocker la texture, mais sans spéficier les données.

En tout cas ce problème avec stb image est vraiment très curieux...

Oui ce que ca implique est que la lsource du problème est effectivement stbi_load de plus je charge la même image que dans le tutoriel

J'ai du nouveau je n'avais pas inclus stb.c dans texture.c cepandant ca ne fonctionne toujours pas j'ai de nouvelle erreur toute liée a stb_image

et j'en ai beaucoup d'autre toute dans stb

stb image me semblait correctement intégré (c'est une lib un peu spécial qui utilise qu'un fichier .h et une macro pour "déclencher" la définition)

Et puis je me suis demandé si c'était le cas, et en fait peut être quie non....
tu peux essayé de rajouté juste

#include "stb/stb_image.h"

au début de texture.c?
Et garde stb.c comme il était :

#define STB_IMAGE_IMPLEMENTATION
#include "stb/stb_image.h"

Mon idée, mais on pas de warning du compilateur, c'est que stbi_load n'est normalement pas connue dans texture.c, et donc le compilateur part du principe qu'elle retourne un int, d'ou le troncage de l'adresse à 32 bits.

Edit: Je suis bête, biensur que si on a le warning,

 1>f:\downloads\vs\project1\texture.c(41): warning C4013: 'stbi_set_flip_vertically_on_load' undefined; assuming extern returning int
1>f:\downloads\vs\project1\texture.c(42): warning C4013: 'stbi_load' undefined; assuming extern returning int

Donc inclure stb/stb_image.h dans texture.c devrait régler le problème (alors pourquoi chez moi ca marche sans, ca c'est un mystère...)

Edit 2: Ca fonctionne chez moi car l'adresse retourné par stbi_load est du genre 0x0000000005460070, et donc casté en 32bit devient 0x05460070, ce qui est la même chose! Chez Lapintade et je suppose aussi chez toi, c'était 0xFFFFF... quelque chose.

Oui en effet, je pense que tu as bien mis le doigt sur le probleme. Definition implicite du parametre de retour, int 32 bits et donc tronquage quand l'adresse est trop haute.
J'avais pas regardé les warnings, bouhhhhh

J'avais pas regardé les warnings, bouhhhhh

Moi non plus ... c'est en lisant le dernier message de stuart sur l'intégration de stb_image, et en pensant que c'était correcte, je suis retourné voir dans le code si le .h était bien aussi inclus ailleurs que dans stb.c...

Le problème venait bel et bien de la merci pour votre aide