[ZS DX 1.7.0 x86/PPC] OS X 10.4 -> 10.8

[lelinuxien]

Salut.
Après avoir récupéré toutes les librairies nécessaires, j'ai pu compiler ZSDX sous Tiger. J'ai essayé la version 1.3 (avec les fichiers nécessaires au fonctionnement sous OS X) ainsi que le dernier dépôt git et le résultat final est le même.
Pour compiler correctement, il a fallu néanmoins corriger le fichier suivant: /src/CMakeLists.txt, la ligne suivante:

Code Sélectionner Étendre

src/lowlevel/osx/SDLMain.m
par

Code Sélectionner Étendre

../src/lowlevel/osx/SDLMain.m
Il a fallu également ajouter les fichiers SDL_ttf.h et SDL_image.h dans le dossier include car malgré la présence des frameworks SDL_image et SDL_ttf sur mon système, ces fichiers ne sont pas trouvés.
Une fois cela effectué, le tout peut être compilé correctement.

C'est au moment de l'exécution que ça se gâte:

Code Sélectionner Étendre

terminate called after throwing an instance of 'std::logic_error'
 what():  Cannot create the text surface for string 'Français': Text has zero width
Abort trap
Même message avec la quête ZSXD. La seule différence dans le message d'erreur est string 'English' au lieu de 'Français'.

[vlag67]

Suite aux MP que j'ai pu avoir avec lelinuxien, je postes les infos "importantes" ici.

Pas de souci pour le retard. Je te souhaite bon courage.
De mon côté, ces derniers temps, j'ai un peu mis de côté les compilations.
Je me suis concentré sur le mode plein écran de Solarus DX sous Lion. Pour cela, j'ai utilisé la version disponible en téléchargement sur le site. J'ai mis le mode vidéo = 3 dans config.ini pour forcer le lancement en mode plein écran. Comme attendu, ça plante au lancement.
J'ai donc fait la même chose que pour les Zelda de Vincent (ROTH, OLB et 3T): j'ai injecté une version patchée du sdl.framework. A présent, le jeu ne plante plus au lancement mais contrairement aux jeux de Vincent qui s'affichent correctement, j'obtiens un écran brouillé comme si la résolution d'écran définie était supérieure à celle gérée par l'écran (screenshot ci-dessous):
http://img717.imageshack.us/img717/7469/zsbrouille.png
La résolution des jeux en mode plein écran semble être de 800x600 (cela concerne ZSDX et les jeux de Vincent). Cependant, pour les jeux de Vincent, c'est en réalité du 640x480 centré (donc avec des bords noirs en haut, en bas, à gauche et à droite).
Je te donne également le lien de la librairie SDL rendue compatible avec Lion en mode plein écran:http://goo.gl/Pu6V0
Apparemment, c'est SDL_QuartzVideo.m qui a dû être patché. Plus de détails ici:http://www.atariage.com/forums/topic/187657-guintv/
Sinon, concernant les architectures compatibles, les Zelda de Vincent compilés par Skyjedi sont des Universal Binaries (compatibles PPC et Intel donc). Il semblerait que la configuration requise pour les dernières versions de SDL, SDL-image et SDL-ttf soit MacOS X 10.4. Reste à voir pour les autres librairies.

et

Ce SDL me semble mieux que celui que j'ai trouvé précédemment: celui que j'ai trouvé précédemment  (il y a une semaine) fonctionnait parfaitement avec ROTH mais sous ZSDX présentait l'écran brouillé avec un problème supplémentaire: de mauvaises couleurs, tout avait tendance à être bleuâtre (aussi bien en mode fenêtré qu'en plein écran). Et je ne connais pas la version (peut-être 1.3SVN, ce qui n'est pas top). Celui que je t'ai passé est apparemment le 1.2.14 patché. Espérons que ça fonctionne.  

Ca avance pour le plein écran ^^

Pour revenir au problème de compilation du premier message, la fonction mise en cause de trouve dans TextSurface.cpp , c'est TTF_RenderUTF8_Solid() dans TextSurface::rebuild().
Lelinuxien teste les différents paramètres depuis 2 jours et apparemment tout est ok. La font est reconnue et loadée, la string est bien valide, en UTF8 et contient le caractère 0 final, la couleur est également valide.

Pour moi, il ne reste plus que la possibilité du TTF_init() foireux.

Christopho, tu pourrais expliquer brièvement comment sont gérées en interne tes fonctions TextSurface::initialize() et ::quit() ?  Ou plutôt à quel moment ces fonctions sont appelées.
Je ne pense pas que le soucis soit de ce coté, mais il ne reste plus beaucoup de coté crédible, donc bon ... ^^
Est-il possible que dans certains cas, rebuild() (et donc TTF_RenderUTF8_Solid() ) soit appelé sans que TTF_init() le soit ?

[Christopho]

TextSurface::initialize() est appelé à l'initialisation du programme, bien avant toute création de TextSurface. On peut le vérifier facilement en regardant le code ou avec un débuggueur. Et de même, TextSurface::quit() est appelé tout à la fin lorsqu'on ferme le programme.

[lelinuxien]

Je suis très heureux d'annoncer que Solarus fonctionne enfin sous Tiger.  

En fait, j'ai résolu mon problème en remplaçant le framework SDL_ttf par la version 2.0.9.

Il reste à présent à faire un paquetage, et voir si ça tourne sous PPC (là par contre, je ne sais pas comment je vais tester).

EDIT: Je n'ai pas de son dans le jeu. Je vais encore devoir vérifier ça.
L'erreur est la suivante: Cannot copy the sound samples into buffer 3.

[vlag67]

Yeah bien joué !

Ca ne fonctionne pas du tout avec SDL_ttf 2.0.11 ?

Pour le paquetage je ne sais pas si tu sais comment procéder. En gros l'idée c'est de jouer avec les commandes otool -L et install_name_tool pour écrire en dur le chemin des dépendances (sur le binaire principal ET celui des frameworks embarqués). Dans le cas des framework/dylib embarqués, ca commencera par un truc du style @executable_path/../Framework/ .
Il doit surement y avoir un moyen plus propre de procéder, mais à moins d'utiliser Xcode je ne l'ai pas trouvé ^^
J'ai accès à court terme sur un 10.4 PPC pour faire les tests si tu veux

Je jetterais un oeil en parallèle pour le son

[lelinuxien]

SDL_ttf 2.0.11 ne compile pas sous Tiger.
Quant à la version 2.0.10, il me semble qu'elle soit compatible Tiger mais apparemment, elle nous a bien embêté jusqu'à aujourd'hui.
Maintenant, je vais vérifier ce qu'il se passe au niveau du son. Ensuite, je te passerai une copie du jeu une fois empaquetagé.

[vlag67]

Effectivement j'avais oublié ce détail ^^

Pour le son, à première vue, ça ressemble plus a un soucis OpenAL que ogg ou vorbis, quoiqu'on ne teste pas vraiment les retours du décodage vorbis.
Tu as utilisé les frameworks présent dans le bundle Leopard ou pris/compilé des universels?


Ote moi d'un doute : tu pourrais tester, dans Sound::decode_file de src/lowlevel/Sound.cpp , remplace
bytes_read = ov_read(&file, samples_buffer, 4096, 0, 2, 1, &bitstream);
par
bytes_read = ov_read(&file, samples_buffer, 4096, 1, 2, 1, &bitstream);

Je ne sais pas comment marche une virtual box, mais en toute logique il y a des chances que tu soit en train d'émuler un processeur PPC .... et surpriiise : vorbis ne fournit apparemment pas non plus cette couche d'abstraction ^^

[lelinuxien]

Non, je fais tourner une machine Intel, j'en suis certain.
Pour OpenAL, j'utilise en fait le framework intégré à Tiger.
Suite des tests... plus tard dans la journée.

[vlag67]

Ca marche, j'ai lu trop vite. Autant pour moi ^^

Éventuellement tu peux essayer, toujours dans src/lowlevel/Sound.cpp , dans la fonction Sound::initialize() de remplacer :

device = alcOpenDevice(NULL);
par
device = alcOpenDevice("Generic Hardware");

Sinon essaye le dernier framework OpenAl ou OpenAl-soft ici http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx

Et si toujours non, tu pourra vérifier que les drivers sont à jour ?


EDIT: remplace aussi, dans Sound::decode_file(),

Code Sélectionner Étendre

if (alGetError() != AL_NO_ERROR) {
 std::cout << "Cannot copy the sound samples into buffer " << buffer << "\n";
par

Code Sélectionner Étendre

ALenum buferror = alGetError();
if (buferror != AL_NO_ERROR) {
 std::cout << "Cannot copy the sound samples into buffer : error " << buferror << "\n";
Histoire de savoir quelle erreur est générée.
Si, quand tu testera, buferror vaut 3 (AL_INVALID_VALUE), tu pourra faire passer ce code une ligne plus haut, avant alBufferData(...); , pour être sur que l'erreur n'est pas plus en amont.

[lelinuxien]

Actuellement, je tente de transférer le projet compilé sur une autre machine pour tester. Pour les frameworks, ça semble OK mais pour les dylib, ça coince: au lancement du jeu, les librairies sont recherchées dans /usr/local/lib, ce qui est embêtant car l'utilisateur ne va pas copier à la main les librairies dans ce dossier. Une fois ce problème résolu, j'envisage de tester s'il se lance aussi sous Leopard, Snow Leopard et Lion.

Pour le problème de son, j'y travaillerai plus tard. J'ai déjà récupéré le framework de http://connect.creativelabs.com/openal/Downloads/OpenAL_Installer_OSX.dmg mais si je le mets à la place de celui fourni avec Tiger ça ne fonctionne plus (architecture incompatible). Cette version du framework semble être compatible avec MacOS X 10.2.8 et ultérieurs (ça pourrait donc servir pour une version PPC de ZSDX, fonctionnant sous Jaguar ou Panther). Mais bon, je n'apprivoise qu'un félin à la fois.^^

[vlag67]

Pour le paquetage je ne sais pas si tu sais comment procéder. En gros l'idée c'est de jouer avec les commandes otool -L et install_name_tool pour écrire en dur le chemin des dépendances (sur le binaire principal ET celui des frameworks embarqués). Dans le cas des framework/dylib embarqués, ca commencera par un truc du style @executable_path/../Framework/ .
Il doit surement y avoir un moyen plus propre de procéder, mais à moins d'utiliser Xcode je ne l'ai pas trouvé ^^

Pour te donner un exemple, ca te donne un truc du genre
$ otool -L /usr/local/bin/solarus
Qui renvoie le chemin théorique de chaque dépendance.
L'idée, c'est que chaque dépendance non native au système Mac soit embarqué dans l'application.

Du coup, on modifie les lignes qui vont bien en faisant
$ install_name_tool -id @executable_path/../Frameworks/Ton_Framework_ou_dylib /usr/local/bin/solarus
pour changer la première ligne renvoyée par otool -L , et
$ install_name_tool -change Ancien_Chemin @executable_path/../Frameworks/Ton_Framework_Ou_Dylib /usr/local/bin/solarus
pour les autres

A vérifier aussi sur les framework et dylib embarqués

Ca me fait voir que j'ai peut-être fait une connerie, et il est possible que ca explique le problème de son :/ . Il me semble que OpenAl est dans les framework du système depuis bien avant 10.4, donc je n'ai pas besoin de l'embarquer.
Fait juste un coup de install_name_tool -change sur le chemin d'OpenAL, pour pointer vers celui du système (je ne suis pas sur mon mac mais c'est un truc du genre /Developer/Frameworks/OpenAL.framework )

Sinon il n'y a pas de raisons que ca ne marche pas jusqu'a 10.6, à condition d'avoir tous les frameworks et le binaire principal compatible i386,x86_64, ppc et ppc64 . Par contre à partir de Lion, vu les changements internes, ca me parait compromit avec les anciens frameworks ... :/

[lelinuxien]

Je n'avais pas trop compris le fonctionnement de otool et de install_name_tool mais j'ai fini par y arriver. Je viens de transférer mon application compilée sous Tiger vers mon Snow Leopard. Le jeu se lance... avec le même petit message d'erreur à propos du fichier sonore. En fait, il n'y a aucun problème de son dans le jeu. C'est juste le petit "cling" au lancement du jeu qui est bizarre. Je vais à présent tester mon paquetage sous Tiger (10.4.4), Leopard (10.5.5), Snow Leopard (10.6.8) et Lion (10.7.2) et je vous tiens au courant des résultats. 

[Christopho]

vlag : je n'ai toujours pas appliqué les patchs que tu m'as soumis sur github. Vu que j'ai un peu de mal à suivre n'y connaissant rien à Mac OS, est-ce qu'ils sont toujours d'actualité ?

[lelinuxien]

http://home.scarlet.be/~tsg79539/SolarusDX.app.zip

Ça fonctionne, de Tiger à Lion (au moins sous les versions Intel). J'y ai inclus la version SDL 1.2.15 UB compatible Tiger et Leopard mais qui fonctionne aussi sous les OS Snow Leopard et Lion. Par contre, le mode plein écran est brouillé (je précise que ça se lance sans crasher sous Lion), aussi bien sous Tiger que sous Lion. Utilisant la dernière version GIT, j'en déduis que Chris n'a pas encore inclus les patches. SDL-image est en version 1.2.10 et SDL-ttf en version 2.0.9. Libmodplug, libphysfs, ogg et vorbis sont dans leur dernière version.

J'ai également constaté que les librairies Lua ne sont pas nécessaires au fonctionnement de l'application (uniquement à sa compilation).

Sinon, pour OpenAL, comme je le disais précédemment, c'est inclus avec l'OS, pas besoin de l'intégrer donc.

[vlag67]

Christopho : Oui les patch sont toujours d'actualité, enfin je me suis un peu embrouillé et il n'y a que le premier a prendre en compte en fait https://github.com/christopho/solarus/pull/13 , j'ai intégré les suivants dedans.
Normalement ca devrait regler le soucis de fullscreen partout, puisque l'appli 10.4 fonctionne sur Lion

Lelinuxien : Yeah bien joué !
Si lua n'est pas nécessaire, c'est que tu l'as compilé statiquement. En soit ce n'est pas grave, puisque de toute façon Apple éduque les gens pour ne pas trifouiller les bundle et retélécharger toute l'appli pour mettre à jour une dépendance ^^ (au passage, lua est passé à 5.2.0)

Par contre il reste un dernier point pour être totalement compatible. Il faudra vérifier, sur le binaire principal et les framework/dylib, avec quelles architectures ils sont compatibles.
Un coup de
$ file TonFichier
pour vérifier.
Idéalement, tu devrais avoir 4 lignes (i386, x86_64, ppc et ppc64). Je ne l'ai pas encore fait sur mon .app (il n'y a que x86_64, et depuis le debug du fullscreen, i386), donc je ne sais pas exactement quelle manière de procéder est a choisir, mais je compile les librairies, et solarus avec les flags "-arch i386 -arch x86_64 -force_cpusubtype_ALL -mmacosx-version-min=10.5" (pour cflag et ldflag sur les makefiles), a modifier pour ton cas.
On pourra le rajouter sur le depot git aussi, dans une condition #ifdef, quand ce sera sur.

Il faudra que je me procure le sdk 10.5 pour pouvoir compiler pour ppc et ppc64 de mon coté, mais ca avance

Et effectivement on peut virer OpenAL des libs embarquées ^^

EDIT: Effectivement, après test, le plein ecran plante chez moi ^^

[Christopho]

Je viens d'intégrer le patch et de le modifier un peu pour simplifier les modifications de VideoManager. J'espère que ça fonctionne toujours, normalement je n'ai rien changé. Je vous laisse vérifier, désolé par avance si j'ai fait une erreur ^^

[lelinuxien]

Pour l'instant, j'ai compilé avec les options par défaut, donc je ne pense pas que ce soit Universal Binaries.
Par contre, pour que ce soit compatible avec les 4 architectures (PPC, PPC64, Intel 32 et 64 bits), c'est 10.5 minimum. Pour une appli compatible Tiger, il faut renoncer au 64 bit (mais les applis 32 bits fonctionnent de toute façon sous un OS 64 bits, ça ne tire pas pleinement parti du processeur). En d'autres termes, il faut choisir entre application optimisée pour processeurs 64 bits ou application compatible Tiger. L'idéal est de proposer 2 versions donc. D'ailleurs, la plupart des applications actuelles sont plus légères car elles ne proposent que du code Intel (32 et 64 bits) mais ne fonctionnent que sous 10.5 et ultérieurs.

Je me pose déjà la question si une version 10.3 serait possible (j'ai peut-être de quoi faire tourner 10.3.9 PPC). Ensuite, on attaquera OS Classic.  

En attendant, il me reste à recompiler cette application pour qu'elle fonctionne en plein écran. Ensuite, je verrai si je peux faire une Universal Binary compatible Tiger (PPC et Intel 32 bits).

Je vais tester les modifs de Chris dans la soirée, voire ce week-end.

[vlag67]

Chris: Je testerais un peu plus tard mais normalement c'est niquel

Lelinuxien: Par contre je viens de penser que pour Tiger, si tu utilises l'ancien framework SDL "buggué", le code temporaire enlevé devrait faire revenir le soucis de couleur...

Ah ouai tu pars loin dans la cross-compile quand meme, OS Classic est pas encore collector ^^
Je pense que 2 versions sera le meilleur choix effectivement, à moins que la version que tu prépare tourne correctement sur toutes les machines, dans ce cas la on pourra peut-être négliger la surchage/perte due à la retrocompatibilité ?

[lelinuxien]

J'utilise bien la dernière version de SDL (1.2.15) et malgré que l'écran se brouille, je n'ai eu aucun souci avec les couleurs. C'est au niveau de SDL-image et SDL-ttf que j'utilise les versions précédentes.
La version compatible Tiger tournera probablement sans souci sous Lion mais ne sera pas optimisée 64 bits et pèsera probablement quelques Mo de plus.

Par contre, pour une version Panther, si je trouve de quoi essayer, les versions de SDL risquent d'être anciennes. Et puis, il faudra une version de CMake compatible avec le projet et compatible Panther. D'ailleurs, la version actuelle de CMake est proposée en 2 versions:
- Mac OSX 64/32-bit Intel, 10.6 et +
- Mac OSX 32-bit Universal Intel / PPC, 10.4 et +
Pas sûr que CMake 2.6 passe sous OS X 10.3.9...


EDIT: je viens de compiler la dernière versions avec les modifications et je rencontre à présent le bug des couleurs, qui n'est pas lié à SDL mais SDL_image. Et le mode plein écran est brouillé avec de grandes bandes noires. Par contre, en plein écran, les couleurs semblent correctes.

[vlag67]

Yep effectivement c'est SDL_image, plus précisement IMG_Load_RW() sur les png 8bits.

Du coup il va falloir remettre le code temporaire chez toi ... (les modifs sur Color.h, Color.cpp et Surface.cpp )
https://github.com/christopho/solarus/commit/475ed8a137a67cfb18fd3427699774656bf51b87

Concernant le plein écran, là pour le moment je sèche. Il faudrait que je voie pour débugguer en profondeur chez moi avant de pouvoir te proposer un début de solution.
Ca commence a devenir un bordel cette histoire ^^

[lelinuxien]

Je viens de compiler ZSDX 1.4 et ZSXD 1.5 sous Tiger (après avoir replacé color.h, color.cpp et surface.cpp pour être compatible avec la version de SDL_image utilisée). Ça fonctionne sous tous les Mac Intel 32 bits (à partir du Core Duo, sorti avant les Core2). J'ai testé sous Tiger, Leopard et Snow Leopard. Pour la compatibilité PPC, je verrai plus tard, à mon retour d'Australie.

Les liens de téléchargement (mon hébergement chez Scarlet n'aimant pas les connexions FTP depuis une IP étrangère):
http://www.zeldaforce.net/solarus/SolarusXD-1.5.zip
http://www.zeldaforce.net/solarus/SolarusDX-1.4.1.zip

EDIT du 25/02: La version 1.4 a été remplacée par la 1.4.1. Comme d'habitude, compatible MacOS X 10.4 Intel 32 bits et ultérieurs.

[lelinuxien]

Après les versions x86 de ZS DX et ZS XD, je vous propose ce soir les versions PPC (compilées pour G3):
http://www.zeldaforce.net/solarus/SolarusXD_10.4PPC.zip
http://www.zeldaforce.net/solarus/SolarusDX_10.4PPC.zip
(Mon FTP personnel ne veut pas de ZS DX pour Tiger, l'upload plante à chaque fois)

En principe, ça devrait fonctionner. J'ai testé sous 10.4.11. Si vous avez un PPC sous Leopard, n'hésitez pas à les essayer (ça devrait marcher sans souci). Comme d'habitude, tout comme pour la version Tiger x86, ancien OS, anciennes librairies. Ces versions fonctionnent probablement sous x86 grâce à la couche d'émulation Rosetta mais il va de soi que les versions x86 sont plus appropriées.

EDIT: Réupload avec SDL 1.2.15 au lieu de 1.2.14. Il semblerait cependant que SDL 1.2.15 n'aime pas l'affichage en 15 bits de couleurs (pas de problème avec la 1.2.14). En 32 bits de couleurs (je pense qu'actuellement, toute carte graphique est capable de cela), pas de problèmes. Je n'ai pas testé en 16 bits par contre. Problème intéressant à souligner en tout cas.

REEDIT: La version x86 (de ZS XD et DX) a subi 2 mises à jour mineures: le script de lancement qui n'aimait pas les espaces dans le nom de l'application et le passage à lua 5.1.5. Elle utilise donc exactement les mêmes librairies, scripts, etc que la version PPC compilée hier.


Dernier EDIT: Aucune nouveauté si ce n'est une Universal Binary (fusion des versions PPC et Intel). Si vous avez un Mac datant d'environ 6 ans, tournant sous Tiger, qu'il soit équipé d'un Core Duo, G5, G4 ou G3, ceci est pour vous:
ZS DX 1.4.1 Universal Binary: http://www.zeldaforce.net/solarus/SolarusDX_10.4UB.zip
ZS XD 1.5 Universal Binary: http://www.zeldaforce.net/solarus/SolarusXD_10.4UB.zip
Versions testées et fonctionnelles sous OS X 10.4.4 Intel, 10.4.11 PPC et 10.6.8.

[Sam101]

Chez moi (Mac OS X 10.4.0 - PowerPC G4 400mhz - 192mo de ram), le jeu est complètement injouable, beaucoup plus que sur Android avec un processeur armv6. Je suspecte que c'est à cause de la ram, je retrouve de la PC100 et je redis ça. Une version G3 à alors peu d'utilité selon moi...

Une capture d'écran pour la route

http://img11.hostingpics.net/pics/538404ZSDX.png

[lelinuxien]

Salut à toutes et à tous.
Tout d'abord, désolé pour le retard, j'étais occupé à d'autres choses (voyage aux USA, etc). Aujourd'hui, j'ai pris le temps de compiler Solarus 0.9.2 ainsi que les dernières versions de ZS DX et XD. La surprise fut particulièrement agréable: aucune nécessité de modifier quoique ce soit dans les fichiers source pour que ça compile correctement. En outre, je n'ai pas repris les vieilles versions de certains fichiers reprenant le code temporaire (Color.h, Color.cpp et Surface.cpp). Bref, sans modifier quoique ce soit, pas de problème de couleurs sous les vieux félins d'Apple. De plus, le mode plein écran fonctionne sans souci (excepté sous la version PPC 10.4.11 où l'image n'est pas centrée mais dans le coin supérieur gauche, problème que j'ai également rencontré avec Zelda ROTH, je soupçonne dès lors un problème de pilote). Bref, testé avec succès en mode fenêtre et plein écran mes compilations sous:
- MacOS X 10.4.4 Intel.
- MacOS X 10.4.11 PPC (voir la remarque ci-dessus).
- MacOS X 10.5.5 Intel 32 bits.
- MacOS X 10.6.8.
- MacOS X 10.7.3.
- OS X 10.8 (après avoir autorisé les applications non signées numériquement).

Solarus XD 10.5.2: http://www.zeldaforce.net/solarus/SolarusXD_10.4.zip
Solarus DX 10.5.1: http://www.zeldaforce.net/solarus/SolarusDX_10.4.zip

La seule chose avec ces versions par rapport aux officielles, c'est qu'elles ne sont pas optimisées 64 bits et que pour des raisons de compatibilité, certaines librairies ne sont pas dans leur dernière version (SDL_image 1.2.10 et SDL_ttf 2.0.9).

Si vous avez un Mac avec un processur PPC ou Intel 32 bits ou encore une ancienne version de MacOS X, n'hésitez pas à télécharger.  

EDIT du 21/05: Remplacement de ZS DX 1.5.0 par la version 1.5.1. Vous pouvez dès à présent la télécharger.

[Christopho]

Même question que sur l'autre topic : peut-on envisager de proposer ces versions sur la page de téléchargement ?
Je suis un peu perdu, quelle est la différence avec la version actuelle qui restreint à 10.6 ou supérieur ?

[lelinuxien]

Oui, bonne idée pour les mettre sur la page de téléchargement.
Ces versions n'utilisent pas les dernières versions de certaines librairies et sont 32 bits uniquement. La version nécessitant 10.6 ou ultérieur est optimisée 64 bits et utilise la dernière version de chacune des librairies.
Mais pour la version Windows, on pourrait dès lors faire de même: une version optimisée 64 bits mais celle-ci ne fonctionnerait que sous les versions de Windows les + récentes.

Lorsque ZS DX et XD seront portés sur la version 1.0 du moteur, je compilerai comme précédemment:
- Une version Universal Binary PPC/Intel32bits pour 10.4.x et ultérieurs.
- Une version PPC pour les vieux Mac 10.2.8 -> 10.3.9.

[Christopho]

C'est fait. Merci beaucoup
Je me permets de déplacer les 2 topics car ils n'ont plus grand chose à faire dans la partie bugs.

[vlag67]

Yeah on est finalement arrivé à uniformiser la partie OSX des sources, plus besoin de faire de changements manuels, enfin !
[Edit] Ah non en fait, je viens de voir la date du message, faudra quand même tester avec les dernières modifs, ça risque d'être encore plus pratique pour toi ^^ [/Edit]

En fait, on pourrait limite supprimer le bundle 10.6+ de la page des téléchargements, puisque pour l'utilisateur final ça ne fait aucune différence de jouer avec des optimisations 64bits et sur d'anciennes version des lib. Ca clarifierait aussi la page des téléchargements du même coup.

[Christopho]

Ah bon, la version 10.6+ ne sert à rien ?

[vlag67]

C'est pas qu'elle ne sert à rien, c'est qu'elle n'a plus de réelle utilité si une version 10.4+ est maintenue.

Concrètement, la seule "vraie" différence est qu'elle est compilée avec support 32 & 64 bits. Or les appli 32bits-only tournent très bien (pour le moment) sur les machines 64bits.
Je n'ai pas testé les perfs, mais je doute que le moteur soit gourmand au point de demander des optimisations sur les processeurs actuels.
Du coup je me demandais si c'était encore une bonne idée de maintenir cette version officiellement, that's why

[Christopho]

Ok. Donc j'enlève la version 10.6+ ? Effectivement ça simplifierait la page.

[vlag67]

Si Lelinuxien est d'accord pour maintenir sa version 10.4+, aucun soucis de mon coté

[lelinuxien]

Oui, j'envisage de compiler la prochaine version de ZS DX sous MacOS X. En espérant que cela se déroule correctement. Si je rencontre des erreurs, je vous le ferai savoir.  
Je me souviens aussi de la raison pour laquelle je n'ai pas fait une Universal Binary compatible à la fois PPC 10.2.8 et Intel 10.4. Dans le paquetage pour 10.2.8 à 10.3.9, non seulement j'inclus une version de SDL un peu plus ancienne mais surtout j'inclus une version d'OpenAL compatible avec ces versions de MacOS X. Or, pour 10.4 et ultérieurs, OpenAL est non seulement inclus dans l'OS mais la version du paquetage 10.2.8-10.3.9 est incompatible car PPC-only.
Sinon, ne pas oublier de modifier le paramétrage interdisant les applications non signées par Apple sous 10.7.3-10.7.5 et 10.8.x.

Un bug mineur est cependant présent sous MacOS X 10.4 PPC en mode plein écran: le jeu n'est pas centré mais se lance dans le coin supérieur gauche (aucun plantage n'a lieu, contrairement à ce qu'on avait rencontré auparavant). Or sous 10.2.8, 10.3.x et 10.4 Intel, c'est correctement centré. Reste à voir ce que donnera la future version du jeu.

Les futures compilations seront testées sous 10.4.4 Intel, 10.4.11 PPC, 10.5.5 Intel, 10.5.8 Intel, 10.6.8, 10.7.5 et 10.8.3. Je ne peux tester sous 10.5 PPC (dernière version de MacOS X pour PPC) mais si l'Universal Binary fonctionne sous 10.4 Intel et PPC ainsi que 10.5.x Intel, aucune raison pour que ça ne marche pas sous 10.5 PPC.

Solarus XD 10.7.0: http://www.zeldaforce.net/solarus/SolarusXD_10.4.zip
Solarus DX 10.7.0: http://www.zeldaforce.net/solarus/SolarusDX_10.4.zip