SDL.library 68k ?

14 sujets de 1 à 14 (sur un total de 14)

thellier
9 mars 2024 à 17h55 #378061
Bonjour

J’essaye de recompiler le récent WipeOut 68k et il lui manque la SDL, j’utilise un vieux (gcc) egcs 2.90.27

J’ai bien une libSDL_libnix.a (que j’ai renommée libSDL.a) mais ça geint au linking qu’il trouve pas les références aux fonctions SDL, peut être que ce libSDL.a est pas prévu pour ce vieux compilo ? d’habitude j’utilise que de .library et juste les .a du système comme libm donc j’y connais pas grand chose

Mercis d’avance 😉

Je compile ça comme un bourrin ainsi

gcc -m68020-40 -m68881 -noixemul -O3 -c camera.c
gcc -m68020-40 -m68881 -noixemul -O3 -c droid.c
gcc -m68020-40 -m68881 -noixemul -O3 -c game.c
gcc -m68020-40 -m68881 -noixemul -O3 -c hud.c
gcc -m68020-40 -m68881 -noixemul -O3 -c image.c
gcc -m68020-40 -m68881 -noixemul -O3 -c ingame_menus.c
gcc -m68020-40 -m68881 -noixemul -O3 -c input.c
gcc -m68020-40 -m68881 -noixemul -O3 -c intro.c
gcc -m68020-40 -m68881 -noixemul -O3 -c main_menu.c
gcc -m68020-40 -m68881 -noixemul -O3 -c mem.c
gcc -m68020-40 -m68881 -noixemul -O3 -c menu.c
gcc -m68020-40 -m68881 -noixemul -O3 -c object.c
gcc -m68020-40 -m68881 -noixemul -O3 -c particle.c
gcc -Linclude -m68020-40 -m68881 -noixemul -O3 -c platform_sdl_amigaos.c
gcc -m68020-40 -m68881 -noixemul -O3 -c race.c
gcc -m68020-40 -m68881 -noixemul -O3 -c render_warp3d.c
gcc -m68020-40 -m68881 -noixemul -O3 -c scene.c
gcc -m68020-40 -m68881 -noixemul -O3 -c sfx.c
gcc -m68020-40 -m68881 -noixemul -O3 -c ship_ai.c
gcc -m68020-40 -m68881 -noixemul -O3 -c ship_player.c
gcc -m68020-40 -m68881 -noixemul -O3 -c ship.c
gcc -m68020-40 -m68881 -noixemul -O3 -c system.c
gcc -m68020-40 -m68881 -noixemul -O3 -c title.c
gcc -m68020-40 -m68881 -noixemul -O3 -c track.c
gcc -m68020-40 -m68881 -noixemul -O3 -c types.c
gcc -m68020-40 -m68881 -noixemul -O3 -c ui.c
gcc -m68020-40 -m68881 -noixemul -O3 -c utils.c
gcc -m68020-40 -m68881 -noixemul -O3 -c weapon.c

gcc -Llibs -lSDL -lgl -noixemul -o W3DWipeOut camera.o droid.o game.o hud.o image.o ingame_menus.o input.o intro.o main_menu.o mem.o menu.o object.o particle.o platform_sdl_amigaos.o race.o render_warp3d.o scene.o sfx.o ship_ai.o ship_player.o ship.o system.o title.o track.o types.o ui.o utils.o weapon.o
stephbb75
9 mars 2024 à 21h28 #378063
Salut,

Peut tu me dire ou tu a eu les sources ?
Je pense que pour Amiga les sources on été compilé (enfin celle que je connais) avec War3D.

Il n’y a pas vraiment de SDL pour 68k.
Une version 1 plus ou moins complète de mémoire, une version 2 (qui ne doit pas tout inclure de mémoire).
Il y en a une pour OS4

https://youtube.com/@stephbb75
thellier
9 mars 2024 à 23h06 #378064
C’est Arti qui a fait le port qui me les a passées, je retrouve plus le lien mais c’était un github ou qque chose comme ça
wipeout-sdl1-master.zip

Apparemment Arti a aussi un SDL 68k avec support de OpenGL (via StormMesa/Warp3D ou MiniGL/Warp3D ) c’est lui qui m’a passé son libSDL_libnix.a mais ça linke pas, c’est peut être pas sa lib le problème mais moi qui déconne dans mon linking
J’ai nettoyé ses sources de WipeOut : mis tout les includes du jeu dans leur répertoire wipeout, enlevé les trucs que mon compilo aimait pas comme les déclarations de variables au milieu du code et dans les boucles, corrigées quelques vrais erreur et là ca compile avec 0 errors/warnings dans ce vieux gcc, par contre ça linke pas

Ensuite l’idée serait de remplacer les appels à SDL (sauf son et joystick) par des appels à AmigaOS (genre ouvrir un écran) et enlever les appels à OpenGL pour les remplacer par du pur Warp3D pour que ça aille plus vite
Le vrai but serait que WipeOut tourne à une vitesse décente dans la Vampire via Wazp3D/Maggie.
Là il marche déjà dans la vampire mais bien trop lent….
En plus WipeOut doit avoir un pb de conception car il tourne moins vite en rendu hard que soft dans WinUAE/Wazp3D = à investiguer
Jul
10 mars 2024 à 17h54 #378069
Juste par curiosité, et comme ta question dépasse la compétence moyenne des utilisateurs du forum, je l’ai posée (telle quelle ainsi que ton deuxième post) à ChatGPT. Je ne sais pas si ses suggestions apportent vraiment quelque chose mais c’est assez impressionnant de le voir “comprendre” ton problème dans un écosystème de niche tel que l’Amiga ! Voici ses réponses :
Le problème que tu rencontres pourrait être lié à plusieurs facteurs. Voici quelques pistes pour essayer de résoudre le problème de liens avec la SDL sur Amiga en utilisant gcc egcs 2.90.27 :

Compatibilité de la libSDL : La version de la libSDL que tu utilises (libSDL_libnix.a) doit être compatible avec le compilateur et l’architecture cible (dans ton cas, Amiga 68k). Si cette version de libSDL a été compilée pour une autre version de compilateur ou une autre architecture, cela peut causer des problèmes de compatibilité et expliquer pourquoi le linker ne trouve pas les références aux fonctions SDL.

Options de Lien : Assure-toi que le chemin vers le dossier contenant libSDL.a est correctement spécifié dans les options de lien. Tu utilises -Llibs, mais si libSDL.a se trouve dans un autre dossier, tu devras spécifier ce dossier correctement avec l’option -L.

Ordre des bibliothèques dans la commande de lien : L’ordre des bibliothèques dans la commande de lien peut être important. Les dépendances doivent parfois être spécifiées après les fichiers objets qui en dépendent. Si libSDL dépend de libgl (ou inversement), changer l’ordre pourrait aider.

Symboles manquants spécifiques : Identifie quels sont exactement les symboles manquants. Cela peut te donner des indices sur ce qui pourrait manquer dans ton processus de compilation ou de lien. Tu peux utiliser des outils comme nm pour lister les symboles dans les fichiers objets et les bibliothèques.

Vérifie la compilation de la SDL : Si tu as accès au code source de la SDL pour AmigaOS et que tu es capable de la compiler toi-même, essaie de la recompiler avec le même compilateur que tu utilises pour ton projet. Cela garantira la compatibilité des symboles.

Utilisation de .library vs .a : Puisque tu mentionnes habituellement utiliser des .library et juste les .a du système comme libm, assure-toi que l’utilisation d’une bibliothèque statique comme libSDL.a est bien supportée dans ton environnement et par ton processus de build.

Mise à jour ou alternative au compilateur : Bien que ce ne soit pas toujours possible, voir si une version plus récente du compilateur est disponible et compatible avec ton projet peut parfois résoudre ce genre de problèmes. Sinon, vérifie s’il existe des alternatives compatibles avec la SDL et ton architecture cible.

Si après avoir vérifié ces points le problème persiste, tu pourrais envisager de rechercher de l’aide spécifique à la communauté de développement Amiga, où tu pourrais trouver des personnes ayant eu à résoudre des problèmes similaires ou ayant une expérience spécifique avec la SDL sur cette plateforme.
Ton projet semble passionnant et assez complexe, impliquant à la fois des aspects de portage, d’optimisation et d’intégration spécifique au matériel. Voici quelques suggestions et étapes à envisager pour t’aider à avancer dans ton projet :

Résoudre le Problème de Linking

– Vérifie les Chemins : Assure-toi que les chemins vers les bibliothèques et les dossiers d’en-tête (-L et -I) sont corrects et que gcc peut les trouver.

– Dépendances SDL : Si SDL a des dépendances spécifiques, assure-toi qu’elles sont également incluses dans ta commande de lien. SDL peut dépendre d’autres bibliothèques que tu dois également lier.

– Analyse des Symboles Manquants : Utilise des outils comme nm sur libSDL_libnix.a et les fichiers .o pour voir si les symboles manquants sont bien présents quelque part. Cela peut te donner des indices sur ce qui pourrait manquer.

Remplacement des Fonctionnalités SDL par AmigaOS et Warp3D

– Fonctionnalités Essentielles : Identifie les fonctionnalités SDL actuellement utilisées (affichage, gestion des événements, son, joystick) et recherche les équivalents dans l’API AmigaOS pour les remplacer.

– Optimisation Warp3D : Pour les parties utilisant OpenGL, étudier comment les remplacer efficacement par des appels Warp3D. Cela peut nécessiter une refonte partielle de certaines parties du moteur de jeu pour tirer pleinement parti de l’architecture Amiga et des capacités spécifiques de Warp3D.

Optimisation pour Vampire via Wazp3D/Maggie

– Profiling : Utilise des outils de profiling pour identifier où les goulets d’étranglement se produisent, surtout si le jeu est plus lent en rendu matériel qu’en logiciel. Cela pourrait révéler des inefficacités dans l’utilisation d’OpenGL ou de Warp3D.

– Adaptation du Code : En fonction des résultats du profiling, adapte le code pour mieux utiliser les capacités matérielles disponibles. Cela pourrait inclure la réduction de la résolution des textures, l’optimisation des shaders, ou la simplification des modèles 3D pour réduire la charge sur le GPU.

Investigation du Problème de Conception

– Analyse Comparative : Effectuer des tests comparatifs entre les modes de rendu matériel et logiciel pour identifier spécifiquement pourquoi le rendu matériel est plus lent. Cela peut inclure l’analyse du nombre de draw calls, la complexité des shaders, ou l’utilisation de la mémoire.

– Optimisation du Rendu : En fonction des découvertes, il se peut que des optimisations spécifiques au rendu, comme le regroupement des draw calls ou la simplification des shaders, puissent améliorer les performances.

Collaboration et Ressources

– Collaboration avec la Communauté : Étant donné la nature spécifique de ton projet, interagir avec la communauté Amiga, notamment les forums et les groupes dédiés au développement Amiga, peut t’apporter un soutien précieux. Des personnes ayant travaillé sur des projets similaires ou ayant une expérience avec SDL sur Amiga pourraient offrir des conseils utiles.

– Documentation et Exemples : Cherche de la documentation et des exemples de code sur l’utilisation d’AmigaOS et Warp3D pour des projets similaires. Cela peut te donner des idées sur comment résoudre certains problèmes ou optimiser ton code.

Finalement, garde en tête que ce type de portage et d’optimisation est un processus itératif qui peut nécessiter plusieurs cycles de développement, de test, et d’optimisation pour atteindre les performances souhaitées. Bon courage dans ton projet !
Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233
__sam__
11 mars 2024 à 8h32 #378081
C’est une réponse générique. On obtient la même chose si tu remplaces Amiga par Linux en fait. Sur amiga pour que ca aille vite, il faut faire de l’asm, même sur vampire. Après pour la vitesse, les vamps sont certes rapide comparées aux 030 et 040, mais j’en suis revenu pour la partie calcul matriciels faute d’opérations SIMD sur les floats ou d’un calcul efficace de produit scalaire (opération FMA).

Il faudrait travailler en fixed-point sur 16bits pour commencer à bien exploiter l’AMMX en 3D, mais la précision ne sera pas terrible non plus. Genre 8:8, soit 8bit pour la partie entière et 8 pour la fractionnaire (opération PMUL88). Il faut dire que cette extension au 68k dérive du MMX PC, une techno de 27ans dont les limites sont vites apparues et qui a été étendue seulement 2 ans plus tard avec l’arrivée de SSE qui ne semble pas vouloir faire son apparition coté Apollo.

Et oui même à la pointe de la techno avec les FPGA, l’amiga reste quand même avec plus de 25ans de retard technologique. Une éternité.

Samuel.

Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
piark
11 mars 2024 à 9h06 #378083
Hello,

Tu aurais moyen de partager ta sortie de compilation dans un fichier texte ou quelquechose comme ça ?

Histoire de voir les erreurs.

J’ai pas encore réussi à utiliser gcc sur l’Amiga, donc ça va être avec mes souvenirs de gcc sur pc.

Essaye de faire un simple main avec sdl avec un tuto à la con déjà pour voir si la simple lib sdl ou son portage sont acceptés par le compilo, peut-être déjà ?

https://lazyfoo.net/tutorials/SDL/01_hello_SDL/index2.php
thellier
11 mars 2024 à 13h04 #378091
@ Jul
Il n’y absolument rien de faux dans ce qu’a répondu ChatGPT c’est une performance
Juste on peut pas optimiser les shaders dans Warp3D … car y en a pas mais je lui pardonne car c’était pas le coeur de la question

@__sam__
certes mais WipeOut se comporte vraiment mal dans WinUAE contrairement à BlitzQuake ou le Cube de Arti aussi donc je pense qu’il a un problème dans la façon dont il trace

@piark
Ok je teste ça, j’ai corrigé tout les warnings et erreurs donc les seuls erreurs qui restent sont au linking ce sont des undefined reference to “SDLfonctiontruc et “glfunctionmachin
thellier
11 mars 2024 à 13h21 #378092
Bon ChatGPT avait raison 😛

“Les dépendances doivent parfois être spécifiées après les fichiers objets qui en dépendent. Si libSDL dépend de libgl (ou inversement), changer l’ordre pourrait aider.”

J’ai essayé de permuter ainsi et j’ai plus d’erreurs concernant SDL et GL:

gcc -noixemul -o W3DWipeOut camera.o droid.o game.o hud.o image.o ingame_menus.o input.o intro.o main_menu.o mem.o menu.o object.o particle.o platform_sdl_amigaos.o race.o render_warp3d.o scene.o sfx.o ship_ai.o ship_player.o ship.o system.o title.o track.o types.o ui.o utils.o weapon.o -Llibs -lSDL -lgl

par contre il geint désormais sur gettimeofday et kprintf et aussi WaiTOF, Delay, atof, MapRawkey, Open, Close la plupart sont voulus par LibSDL.a (tous sauf gettimeofday et WaiTOF)
Jul
11 mars 2024 à 14h06 #378095
Haha, excellent. 😀 Du coup, voici la suite des suggestions de ChatGPT avec ton dernier post :
C’est une excellente nouvelle que le changement d’ordre dans la ligne de commande de lien a résolu les problèmes liés à SDL et GL ! Les erreurs que tu rencontres maintenant sont liées à des fonctions système AmigaOS non trouvées par le linker. Voici comment tu pourrais résoudre ces nouveaux problèmes :

gettimeofday : Cette fonction est utilisée pour obtenir l’heure actuelle avec une précision de microsecondes. AmigaOS utilise typiquement une approche différente pour mesurer le temps. Tu devras probablement écrire un wrapper ou utiliser une fonction équivalente fournie par AmigaOS, comme GetSysTime().

kprintf : kprintf est souvent utilisé pour le débogage sur AmigaOS. Si tu n’utilises pas le système de débogage du kernel ou si tu souhaites simplement utiliser printf, tu peux créer un wrapper autour de printf ou rediriger kprintf vers printf via un macro ou un wrapper.

WaitTOF : WaitTOF (Wait for Time of Flight) est une fonction spécifique à AmigaOS pour attendre le prochain rafraîchissement de l’écran. Assure-toi que les bibliothèques SDK AmigaOS sont correctement liées à ton projet pour que cette fonction soit reconnue.

Delay : Semblable à WaitTOF, c’est une fonction AmigaOS pour suspendre l’exécution pendant une période donnée. La disponibilité de cette fonction dépend également des bibliothèques AmigaOS que tu as incluses dans ton projet.

atof : Cette fonction de conversion de chaîne en flottant devrait être disponible dans la bibliothèque standard C (libm ou la libc standard). Assure-toi que tu as bien inclus ces bibliothèques dans ton projet.

MapRawKey : Utilisé pour convertir les codes clés bruts en caractères ASCII. Comme WaitTOF et Delay, assure-toi que la bibliothèque nécessaire (libkeymap.library pour MapRawKey) est incluse.

Open et Close : Ces fonctions sont utilisées pour ouvrir et fermer des ressources AmigaOS, comme des fichiers ou des bibliothèques. Elles devraient être disponibles dès lors que les bonnes bibliothèques SDK sont liées.

Pour résoudre ces erreurs, tu devras t’assurer que ton projet est lié avec les bibliothèques AmigaOS appropriées. Cela peut impliquer d’ajouter des chemins supplémentaires avec -L pour inclure les bibliothèques nécessaires et de spécifier ces bibliothèques avec -l dans ta commande de lien. Par exemple, si tu as besoin de libm pour atof, tu devras ajouter -lm à ta ligne de commande de lien.

Voici un exemple générique de ce à quoi ta commande de lien pourrait ressembler une fois que tu as ajouté les bibliothèques nécessaires :

gcc -noixemul -o W3DWipeOut camera.o droid.o game.o hud.o image.o ingame_menus.o input.o intro.o main_menu.o mem.o menu.o object.o particle.o platform_sdl_amigaos.o race.o render_warp3d.o scene.o sfx.o ship_ai.o ship_player.o ship.o system.o title.o track.o types.o ui.o utils.o weapon.o -Llibs -lSDL -lgl -lamiga -lauto

Note que -lamiga et -lauto sont des placeholders pour les vraies bibliothèques dont tu as besoin. Tu devras les remplacer par les noms corrects des bibliothèques AmigaOS que tu utilises pour les fonctions comme WaitTOF, Delay, Open, Close, etc.

Enfin, pour les fonctions manquantes comme gettimeofday, envisage de créer des wrappers ou des fonctions alternatives qui utilisent des fonctionnalités équivalentes fournies par AmigaOS.
Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233
thellier
11 mars 2024 à 20h30 #378101
Bon j’ai ajouté
-lm -lamiga -ldebug -lnix

et la plupart des problèmes ont disparu… sauf gettimeofday
Donc j’ai fait (ce que j’aurais fait de toute façon pour en finir) ce que disait ChatGPT
“écrire un wrapper ou utiliser une fonction équivalente fournie par AmigaOS, comme GetSysTime()”
donc wrapper gettimeofday avec GetSysTime()
int gettimeofday(struct timeval *tv, struct timezone *tz)
{
GetSysTime((void *)&tv);
}

il a fallu desactiver aussi le chargement de timer.h qui avait une déclaration différente de la struct timeval
#define DEVICES_TIMER_H 1

et donc mettre le restant du contenu de ce timer.h dans le source

Bon on y est : 0 errors 0 warnings 0 dépendances qui manquent

O:-)

par contre le programme obtenu plante peu après avoir démarré :-/ mais on progresse……
__sam__
11 mars 2024 à 20h40 #378103
thellier wrote:

par contre il geint désormais sur gettimeofday et kprintf et aussi WaiTOF, Delay, atof, MapRawkey, Open, Close la plupart sont voulus par LibSDL.a (tous sauf gettimeofday et WaiTOF)

gettimeofday et kprintf c’est de l’unix. Ces fonctions ne doivent pas être émulés par libnix (-noixemul). Il te faut probablement ixemul pour y avoir accès, ou alors faire des bouchons (stubs).

WaitTOF, Delay, MapRawkey, Open, Close sont des fonctions amigaos. Essaye de linker avec amiga.lib ou approchant (-lamiga)

atof vient avec libm.a (maths), ajoutes “-lm”.

Bon ca GPT ne l’a pas dit en revanche 😛
==> Il est possible qu’avec VBCC ca se compile mieux .

Samuel.

Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
__sam__
11 mars 2024 à 20h51 #378104
Attention avec WaitTOF, ca bloque en attendant la VBL. Mais pendant ce temps là (20ms au pire), le CPU ne fait rien alors qu’il pourrait commencer à calculer l’autre frame. On peut l’utiliser facilement sur amiga si le WaitTOF est fait dans un thread séparé qui gère le double buffering de son coté pendant que le thread principal bourrine à fond à faire les calculs sur la page non affichée. Je ne suis pas certain que la lib SDL utilise ce mode de fonctionnement. (de toute façon pour DevilusionX, je bypass la libSDL sur la vamp et je poke les regs SAGA en direct: c’est le plus rapide, mais particulier aux vamps.)

Samuel.

Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
thellier
11 mars 2024 à 21h04 #378105
Ok je ferai attention à WaiTOF
De toute façon je vais virer la plupart des appels à SDL (à remplacer par Warp3D+RTG) sauf ceux pour le son et le joystick
__sam__
11 mars 2024 à 23h11 #378111
oui voilà: Paradoxalement, faire du SDL pour les trucs non graphiques est ce qu’il y a de mieux de mon expérience. Le bon coté c’est que hors vampire, on revient dans le berceau SDL et le prog marche sous winuae ou pi-storm correctement car ces machines là sont d’un niveau de perf bien au dessus.

Samuel.

Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)