Cross compilation avec SDL

je penses que tu commence à cerner le problème. Il faut que tu trouve une astuce soi pour éviter d'utiliser cette fonction, soit pour améliorer ton algorithme.

J'ai finalement utilisé la fonction SDL_GetTicks() et je constate que sur XP, une de mes fonctions est 8 fois plus lente et sur Vista, 6 fois plus lente. Les autres fonctions sont trop rapide (< 1 ms) donc SDL_GetTicks n'est pas assez précis.
Cette fonction qui est plus lente contient une boucle et des SDL_BlitSurface. Cette fonction de la SDL serait plus lente sous Windows ?
Parce que si ce serait 1,5 fois plus lente, cela pourrait aller mais là, c'est catastrophique !!!

Quand j'utilise, gprof pour Linux, ça marche bien mais avec Windows, gprof me dit bien combien de fois les fonctions ont été appelé mais tous les temps sont à 0.00 ms. J'ai voulu essayé de trouver les temps de chaque fonction à l'aide de GetTickCount() mais j'ai un problème à la compilation.
Je ne sais vraiment plus quoi faire.

Bon, déjà, fait un effort, lit la notice de gprof ! (man gprof)
il faut lui donner le nom du programme, gmon.out ne se suffit pas à lui même.
Comme je t'ai dit, MS et Linux gère la mémoire de façon un peu différente, donc c'est normal d'avoir des différences.
Moi, j'ai remarque é que mes exécutable windiws était plus volumineux, selon la taille du .exe, ça peut expliquer la différence. Ensuite, les bibliothèques peuvent aussi être différentes, et programmer du graphique sous wi, c'est normalement plus compliqué, donc peut être plus couteux en mémoire.
Sur la vitesse, concentre toi sur gprof, selon que la perte de temps est global ou localiser, il faudra aviser.
là, c'est le contraire :
https://openclassrooms.com/forum/sujet/sdl-fluidite-28699

Tu mets bien -O3 sous windows lors de la compilation ?

Sous Linux, j'ai compilé avec -pg et exécuter le programme mais je n'ai pas réussi à lire gmon.out avec gprof : j'obtiens une erreur : gmon.out n'est pas un exécutable.
Bref, j'ai tout de même trouvé d'où venait la fuite et je l'ai corrigée, j'ai compilé pour Windows et Linux mais j'obtiens des résultats étranges.
Sous Linux, la vitesse est normale et le programme utilise 3,4 Mio de mémoire vive.
Sous Windows XP, la vitesse est lente et le programme utilise 8,3 Mo de mémoire vive.
Et sous Vista, le programme fait planter tout le système !!!!
Pourquoi ces différences ???

J'ai pas tout compris à tes histoires de gcc et mingw32. là tu me parle de temps de compilation.
En fait, ce n'est pas l'option -Q, mais -pg qu'il faut ajouter. Ensuite, tu exécute le programme et tu regarde la différence avec gprof grace au fichier qui est créé : "gmon.out".
une fuite de mémoire, si elle est différente sur Linux et Win, c'est que le problème est dans une bibliothèque, car ton programme est le même.

J'ai ajouté l'option -Q en compilant avec gcc puis avec i586-mingw32msvc-gcc et je vois que, avec gcc, ça prend plus de temps qu'avec mingw32 (2 ms secondes de plus, au total). Mais, je voudrais plutôt trouver où a lieu ma fuite de mémoire et j'aimerais savoir comment utiliser un compilateur avec gcc qui me dit, quand je le demande, la mémoire qui est allouée : par exemple, dans une fonction, je mets plusieurs breakpoint et à chaque fois, j'ai un message qui s'affiche avec la mémoire allouée ce qui me permet de savoir où se trouve le problème. Ou alors, il existe une fonction avec stdio.h ou stdlib.h qui permet de faire ça (je ne sais pas, je demande).

D'après ce que j'ai lu sur le OOM killer de Linux, il est possible que la gestion optimiste de Linux sur la mémoire fasse que le programme va vite, et inversement sur Win, qui gère la mémoire différemment.
Utilise un profiler (gprof) pour voir où tu passe le plus de temps sous Win et sous Linux, tu pourra ensuite en tirer les conclusion (compilation avec l'option -q si je me souviens bien)
regarde là pour oom : https://linuxfr.org/forums/linux-redhat/posts/raisons-susceptibles-du-d%C3%A9clenchement-doom-killer ;)

Non, c'est tout aussi lent sur XP mais je me demande si ce n'est pas due à une fuite de mémoire de mon programme bien que je me demande pourquoi ça ne ralentit pas sous Ubuntu.

Erreur étrange, le manque de DLL... J'utilise peu les dll, en général Window t'alerte qu'elle manque.
Avec un peu de mauvaise fois, je dirai : "à cause de Vista qui est de la merde".
Est-ce que SDL est pleinement compatible Vista ? car il est possible que SDL ne prenne pas en compte les nouveauté et tourne en un mode dégradé. Test avec un bon vieux XP. Sinon, la compilation qui est moins optimiser ou une connerie du genre.

Finalement, j'ai trouvé d'où venait le problème : c'était le fonction IMG_Load qui ne marchait pas car ... car ... car j'avais oublié ... une DLL !!!!!!!!!!!!

Enfin, merci beaucoup pour toute ton aide !!!

Malgré tout, pourquoi mon programme est-il beaucoup plus lent sur Vista ?

Donc, si l'erreur vient de la SDL, la variable qui vaut 3 dans SDL_error.h est SDL_EFSEEK. Pour le moment, ça ne m'aide pas beaucoup !
Mais je me demande si on peut utiliser un débugger en même temps que l'on exécute le programme de manière "pas à pas"; je ne sais pas du tout me servir des débugger (d'habitude, ça marche !).
Et si je comprend bien, j'ai plus trop d'autres choix pour faire marcher mon programme !!!

Edit : en fait, je ne sais pas pourquoi mon programme ne faisait pas marcher mes printf() mais en compilant sous Windows, j'ai trouvé que l'erreur se trouvait à la ligne :
rBalle.x = ecran->w / 2 - sBalle->w / 2;
A la suite de cela, j'ai une erreur qui renvoie 0x3.

l'option -mwindows (ou -mwindow, je ne suis pas certain) permet de faire une programme windows qui ouvre ou non un fenêtre console.
Une fois que tu as le code erreur, il faut savoir à quoi il correspond. Il est fort possible que ça vienne de la SDL donc cherche dans le code source des exit() ou abort() qui enverrai 3 (là bonne chance, car en général on met des variables, ou pire, des macros)
Mais si même la première ligne du main n'est pas exécuter, c'est bizarre. J'ai ce problème sous Linux avec pthread lorsque je lie sans spécifier -lpthread, car il arrive à lier avec la bib standard, mais ça cause une erreur lors de l'exécution. J'ai aussi ce problème des fois avec QT, mais là je reconstruit tout le projet et ça va mieux.
Puisque tu as windows sous la main, tu peux aussi tenter une compilation directement dessus, avec mingw32.

Quand j'utilise ou non start, j'obtiens un %ERRORLEVEL% = 3 ! Je ne sais pas ce que ça veut dire mais bon !
J'ai déjà essayé de le débugger avec printf() mais le premier que j'avais placé avant mes déclarations n'est même pas apparu ce qui voudrait dire que l'erreur a lieu avant le main().
Non, je n'utilise pas l'option -mwindows (car je ne sais pas à quoi elle sert) mais je vais essayé.
J'ai également recherché sur Internet que voulait dire l'erreur de Wine mais je n'ai rien trouvé.

Edit : il se passe toujours la même chose même en ajoutant -mwindows.

lance ton programme dans la console, peut être avec "start" afin de le bloquer, et regarde le code de retour avec
echo %ERRORLEVEL%
Sinon, il faut débugguer à coup de "printf" le long du programme.
Si ton application est graphique, compile tu avec l'option -mwindows ? Sinon, comme le suggère wine, il est possible qu'il y ai un problème entre la SDL et windows au niveau de la gestion du clavier. Bien que le message de wine me soit très obscure. (recherche sur internet d'où peu venir cette erreur)

Sous Windows, quand je le lance depuis la console, je n'ai aucun message d'erreur mais la fenêtre s'ouvre et se referme quand même :
>brik.exe
(La fenêtre s'ouvre et se referme)
>

Je viens d'utiliser le débugger avec casiment toutes les options possibles (-g, -g3, -gstabs, -gstabs+, ...) et je n'ai jamais eu de message d'erreur.

lance le depuis une console voir si il y a des messages d'erreur. Sinon, utilise le debugueur, relève le code de sortie de l'erreur et réfère toi au manuel.

Bah, une fois compilé, ça ne marchait pas sur wine alors j'ai testé sur Windows mais il m'arrive la même chose, le programme s'affiche et disparaît immédiatement.

J'ai eu le même problème avec wine, il me disait de recompiler wine.
Je te conseil de tester avec un PC windows, là tu cumul les ennuies : est-ce que ça viens de wine ou de ta compilation ?? Si le programme s'affiche c'est au moins une bonne nouvelle. Je pencherai pour un problème wine.

Oui, je n'avais pas tout les headers !
Maintenant, quand je compile, tout se passe bien mais lorsque j'exécute avec wine, j'obtiens les erreurs suivantes :
$ wine brik.exe
fixme:keyboard:X11DRV_LoadKeyboardLayout L"00000409", 0080: stub!
fixme:keyboard:X11DRV_LoadKeyboardLayout L"040c040c", 0001: stub!
Et je vois le programme s'afficher puis disparaître très rapidement.
Pourquoi ? Et qu'est-ce que je dois faire ?