je viens vers par rapport au lancement de projet sdl (ver 1.2.15) et sdl2.
Dans les 2 cas, lorsque je créé un projet , le fichier qui s'ouvre est un main.cpp autant avec sdl normal que le sdl 2, j'ai cherché sur internet mais je ne trouve pas de tutoriel qui explique comment le lancer en c et non en cpp. Si quelqu'un peut m'aider svp
#include <SDL/SDL.h> , il faut le remplacer par #include <SDL.h> tout simplement peut etre une variation selon les versions...
En fait ça dépend du chemin que tu as renseigné pour le dossier des fichiers include !
PS, ce n'était pas ta question ?
(Pour ceux qui tomberont sur ton sujet) : Tu utilises un IDE qui te crées automatiquement un fichier main.cpp et bien tu le supprimes et tu crées un fichier main.c que tu ajoute à ton projet !
C'est tout bon, si sa pourra aider certain, en faite j'ai vu dans les fichiers include qu'il est ecrit
#include <SDL/SDL.h> , il faut le remplacer par #include <SDL.h> tout simplement peut etre une variation selon les versions...
Non rien n'a voir avec une variation de version , ça dépend de ton path tout simplement ,mais il faut mieux privilégier #include <SDL/SDL.h> (plus portable vu que sur Linux par exemple , c'est le chemin par défaut ) , sur windows , , il suffit juste de créer un dossier SDL et mettre les include dedans.
Merci pour ton retour, en fait j'ai surfé sur plusieurs sites et regardé plusieurs vidéos pour bien comprendre. J'ai crée un genre de mémo (Ou template pour ceux qui préfère), je vais faire un copié collé pour ceux à qui sa pourrai intéresser :
LINKER SETTINGS :: -lmingw32 -lSDL2main -lSDL2 -mwindows :: to other links options.
SDL || C LANGUAGE TEMPLATE
Dedicatiel :
Pour commencer, créons un projet en C. Nous allons configurer le projet nous-mêmes, donc nous choisissons un projet en console et n’utilisons pas le template de Code::Blocks pour la SDL. Allons dans le dossier de notre projet, et créons tous les dossiers dont nous aurons besoin :
Personnellement j'ai crée un projet SDL2 et supprimé le fichier automatiquement crée en .cpp puis j'ai agencé les dossiers moi même avant de crée un fichier nommé "main.c". (Comme sa j'ai l'aide dédié au SDL2 lors du codage.)
les dossiers src, include et lib. Bien sûr,
déplaçons le fichier main.c créé en même temps que le projet dans le dossier src que nous venons de créer. Maintenant, plaçons les fichiers de la SDL correctement.
Nous copions le fichier SDL2.dll du dossier bin dans le dossier de notre projet, le dossier SDL2 du dossier include dans le dossier include de notre projet et les fichiers
libSDL2.dll.a et libSDL2main.a du dossier lib dans notre dossier lib.
Vous pouvez mettre tout les fichiers et dossier du dossier lib de la SDL, a mon avis c'était dans les anciennes versions.
Configurons maintenant notre compilateur. Allons donc dans le menu « Project » → « Build options ». Là, commençons par indiquer au compilateur les dossiers lib et include,
dans les onglets « Search directories » → « Linker » et « Search directories» → «Compiler ». Et finalement, dans l’onglet « Linker settings »,
écrivons -lmingw32 -lSDL2main -lSDL2 -mwindows dans la partie « Other linker options » pour lier ces fichiers.
TEST CODE :
#include <stdio.h>
#include <SDL.h>
int main(int argc, char* argv[])
{
SDL_Window *window = NULL;
if(0 != SDL_Init(SDL_INIT_VIDEO))
{
fprintf(stderr, "Erreur d'initialisation de la SDL : %s\n", SDL_GetError());
return -1;
}
window = SDL_CreateWindow("Test", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED,
500, 500, SDL_WINDOW_SHOWN);
if(NULL == window)
fprintf(stderr, "Erreur de creation de la fenetre : %s\n", SDL_GetError());
else
{
SDL_Delay(500);
SDL_DestroyWindow(window);
}
SDL_Quit();
return 0;
}
C'est tout bon, si sa pourra aider certain, en faite j'ai vu dans les fichiers include qu'il est ecrit
#include <SDL/SDL.h> , il faut le remplacer par #include <SDL.h> tout simplement peut etre une variation selon les versions...
Non rien n'a voir avec une variation de version , ça dépend de ton path tout simplement ,mais il faut mieux privilégier #include <SDL/SDL.h> (plus portable vu que sur Linux par exemple , c'est le chemin par défaut ) , sur windows , , il suffit juste de créer un dossier SDL et mettre les include dedans.
Pourtant dans le dossier include je ne trouve pas SDL/SDL.h , le chemin pourtant est bien le bon.
La manière officielle d'inclure les headers de SDL2, c'est juste #include <SDL.h>. L'autre variante suggérée (#include <SDL2/SDL.h>) est à éviter. Le fait que cela puisse marcher sur Linux avec un paquet dev de SDL2 quand on a la flemme de mettre les bons flags de compilation n'y change rien (sauf si on veut faire du code non portable).
Il suffit de regarder les fichiers pkgconfig ou CMake config générés par la target install de SDL2.
Nous copions le fichier SDL2.dll du dossier bin dans le dossier de notre projet, le dossier SDL2 du dossier include dans le dossier include de notre projet et les fichiers
Bouh que c'est pas bien. Une installation agnostique de ses dépendances, et une configuration propre de son projet (compiler & linker flags) ce serait mieux.
"Le fait que cela puisse marcher sur Linux avec un paquet dev de SDL2 quand on a la flemme de mettre les bons flags de compilation n'y change rien (sauf si on veut faire du code non portable)." Justement ,je trouve que l'inverse l'est beaucoup moins portable
Je code souvent pour windows/Linux et j’utilise souvent la seconde #include <SDL2/SDL.h> , sans changer une ligne de code.
"Le fait que cela puisse marcher sur Linux avec un paquet dev de SDL2 quand on a la flemme de mettre les bons flags de compilation n'y change rien (sauf si on veut faire du code non portable)." Justement ,je trouve que l'inverse l'est beaucoup moins portable
Je code souvent pour windows/Linux et j’utilise souvent la seconde #include <SDL2/SDL.h> , sans changer une ligne de code.
Car tu injectes un chemin non officiel dans ton CFLAGS, c'est pas propre.
Tes include ne pourraient pas marcher de manière robuste dans un projet dont le système de build s'appuie sur pkgconfig ou le fichier config de CMake pour trouver et injecter SDL2, c'est à dire la majorité des systèmes de build utilisés aujourd'hui.
Juste une question: commen fait-on sur un système qui a besoin de sdl v1 (pour maintenance / flemme de migrer le programme) et sdl v2 pour les nouveaux développements ? Perso j'ai deux répertoires include: sdl et sdl2 (et donc #include <sdl/sdl.h> et #include <sdl2/sdl.h>)
- Edité par edgarjacobs 25 septembre 2021 à 17:55:35
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Juste une question: commen fait-on sur un système qui a besoin de sdl v1 (pour maintenance / flemme de migrer le programme) et sdl v2 pour les nouveaux développements ? Perso j'ai deux répertoires include: sdl et sdl2 (et donc #include <sdl/sdl.h> et #include <sdl2/sdl.h>)
Il faut que le chemin des fichiers include soit celui de la sdl que tu utilises (il ne faut pas mettre les deux chemins dans le même projet)
Oui, je sais, c'est juste pour dire que l'on peut faire ce que l'on veut selon les besoins. Dans mon répertoire include, j'ai aussi un répertoire curl et un répertoire fmod. Cela me semble plus propre, plus "cloisonné".
- Edité par edgarjacobs 25 septembre 2021 à 18:20:06
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Personnellement, quand je fait un projet, je mets juste ce que j'ai besoin et pas plus, si mon projet n'utilise pas curl par exemple, il n'y aura pas le chemin des fichiers include de curl dans la liste des chemins des fichiers include.
Toi tu déplace tous tes dossiers de fichiers include de chaque lib dans le dossier include de ton compilateur (comme cela tu n'as pas besoin de renseigner les chemins), c'est cela ?
Oui en faite c'est juste un chemin, mais dans tout les tuto ils expliques tous de mettre les fichier de SDL2 dans le répertoire parent include, donc j'ai suivi ce que montre tout le monde, mais j'ai compris en fait que ce n'est qu'un chemin...
SpaceIn a écrit:
La manière officielle d'inclure les headers de SDL2, c'est juste #include <SDL.h>. L'autre variante suggérée (#include <SDL2/SDL.h>) est à éviter. Le fait que cela puisse marcher sur Linux avec un paquet dev de SDL2 quand on a la flemme de mettre les bons flags de compilation n'y change rien (sauf si on veut faire du code non portable).
Il suffit de regarder les fichiers pkgconfig ou CMake config générés par la target install de SDL2.
Nous copions le fichier SDL2.dll du dossier bin dans le dossier de notre projet, le dossier SDL2 du dossier include dans le dossier include de notre projet et les fichiers
Bouh que c'est pas bien. Une installation agnostique de ses dépendances, et une configuration propre de son projet (compiler & linker flags) ce serait mieux.
- Edité par SpaceIn il y a environ 1 heure
Donc dans ce cas je ne créer pas tout ces dossiers mais dans linker et compileur je choisi le chemin du dossier sdl2 qui est dans le dossier codeblocks ?
Toi tu déplace tous tes dossiers de fichiers include de chaque lib dans le dossier include de ton compilateur (comme cela tu n'as pas besoin de renseigner les chemins), c'est cela ?
C'est exactement cela, mais en créant un répertoire pour la lib concernée. Si j'ai besoin de curl, je fais un include <curl/curl.h> le culr.h se trouvant de le répertoire curl du répertoire include que le compilateur connait.
Donc, si je reprends mingw, dont les include "classqiues" se trouvent dans X:\mingw\include, j'inclus <stdio.h> pour io, et <curl/curl.h> pour curl. Répertoire curl que j'ai créé dans X:\mingw\include et dans lequel j'ai mis tous les include de la lib curl.
- Edité par edgarjacobs 25 septembre 2021 à 19:13:29
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Toi tu déplace tous tes dossiers de fichiers include de chaque lib dans le dossier include de ton compilateur (comme cela tu n'as pas besoin de renseigner les chemins), c'est cela ?
C'est exactement cela, mais en créant un répertoire pour la lib concernée. Si j'ai besoin de curl, je fais un include <curl/curl.h> le culr.h se trouvant de le répertoire curl du répertoire include que le compilateur connait.
Donc, si je reprends mingw, dont les include "classqiues" se trouvent dans X:\mingw\include, j'inclus <stdio.h> pour io, et <curl/curl.h> pour curl. Répertoire curl que j'ai créé dans X:\mingw\include et dans lequel j'ai mis tous les include de la lib curl.
- Edité par edgarjacobs il y a environ 1 heure
C'est une mauvaise pratique de polluer sa chaine de compilation.
Il est préférable d'avoir un répertoire "externe" par n-uplet (librairie, version, cible (os/arch), compilateur, options de build de la librairie, flags de compilation et de link, static/shared), et injecter le bon paquet suivant les besoins.
Torq a écrit:
Oui en faite c'est juste un chemin, mais dans tout les tuto ils expliques tous de mettre les fichier de SDL2 dans le répertoire parent include, donc j'ai suivi ce que montre tout le monde, mais j'ai compris en fait que ce n'est qu'un chemin...
SpaceIn a écrit:
La manière officielle d'inclure les headers de SDL2, c'est juste #include <SDL.h>. L'autre variante suggérée (#include <SDL2/SDL.h>) est à éviter. Le fait que cela puisse marcher sur Linux avec un paquet dev de SDL2 quand on a la flemme de mettre les bons flags de compilation n'y change rien (sauf si on veut faire du code non portable).
Il suffit de regarder les fichiers pkgconfig ou CMake config générés par la target install de SDL2.
Nous copions le fichier SDL2.dll du dossier bin dans le dossier de notre projet, le dossier SDL2 du dossier include dans le dossier include de notre projet et les fichiers
Bouh que c'est pas bien. Une installation agnostique de ses dépendances, et une configuration propre de son projet (compiler & linker flags) ce serait mieux.
- Edité par SpaceIn il y a environ 1 heure
Donc dans ce cas je ne créer pas tout ces dossiers mais dans linker et compileur je choisi le chemin du dossier sdl2 qui est dans le dossier codeblocks ?
La manière la plus propre est celle que je donne dans le message juste au dessus:
- Installer SDL2 dans un répertoire quelconque (indépendant des librairies systèmes, du compilateur et de ton projet).
- Dans le système de build de ton projet, renseigner proprement les paramètres du compilateur (répertoire d'include et éventuelles définitions des dépendances) et de l'éditeur de liens (répertoire des librairies, et les librairies compilées en elles-mêmes (statiques ou partagées selon ce que tu désires)). Dans un bon système de build, on peut faire ça sans mettre des chemins en dur dans les fichiers. Et dans l'idéal, c'est la dépendance qui communique au projet comment elle doit être injectée (car cela peut être très complexe dans certains cas). Mais comme tu utilises CodeBlocks, je suppose qu'il ne faut pas trop compter là dessus.
C'est une mauvaise pratique de polluer sa chaine de compilation. Il est préférable d'avoir un répertoire "externe" par n-uplet (librairie, version, cible (os/arch), compilateur, options de build de la librairie, flags de compilation et de link, static/shared), et injecter le bon paquet suivant les besoins.
Je ne suis pas un professionnel de la programmation, juste un quidam quelconque. Je n'ai pas des compilateurs, pas des flags de compilation suivant ceci ou cela, pas de link avec libs dynamiques ou statiques, pas de création d'exécutables suivant l'os cible, alors franchement, je ne considère pas mon idée de créer un répertoire pour les include d'une lib dans le répertoire include connu du compilateur comme une pollution
- Edité par edgarjacobs 25 septembre 2021 à 23:52:53
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
PS : Évites de polluer les sujets des autres, crée plutôt ton propre sujet. En plus tu ne l'as pas lu !
...
SDL
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent