[résolu]gcc/MorphOS, std::vector & portage jeu SDL

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

MaVaTi
26 décembre 2006 à 11h40 #4242
Bonjour,

quelqu’un a déjà réussi à faire fonctionner les vectors de la STL avec le gcc 2.95.3 du SDK de MorphOS ?

avec la version de départ, j’avais droit à un “internal compiler error”.

j’ai fais la mise à jour suivante ( http://bigfoot.morphos-team.net/test/sdk/ )

et maintenant ça compile, mais le programme gèle au démarrage…

Exemple simple essayé :

#include

#incude

void main(void )

{

printf(“Debutn”);

std::vector vectint;

printf(“Fin!n”);

}

On ne peux faire plus simple quand même !?

Et tout ça pour essayer à la base de compiler un jeu vite-fait…..!!!

qui malheureusement utilise un peu trop de complexités du C++ à mon goût pour quelque chose d’aussi simple…

(http://scorpioncity.com/sokoban.html)

Sinon, j’ai vu qu’existait gcc v4, mais pas testé pour l’instant, je ne sais pas si pour le C++ et la STL ça peux aider ?

Merci pour les billes éventuelles.
stan
26 décembre 2006 à 23h21 #74296
Je sais pas si ça va aider, mais je pense que ton programme est buggé. Il devrait être écrit “int main( void )” et “return 0;” à la fin.

(à moins que ce ne soit pas obligatoire en C++)
Fab1
27 décembre 2006 à 4h30 #74297
Avec ce gcc et une libnix récente, il ne devrait pas y avoir de problème du tout, je ne vois pas trop là. J’utilise des trucs stl tous les jours (et bien plus élaborés) sans problème.
MaVaTi
27 décembre 2006 à 15h02 #74298
Merci pour les infos, je viens d’appliquer les patchs de http://developer.morphosppc.com concernant libnix et libgcc.

Et aussi remis le flag -noixemul que j’avais enlevé de sdl-config !

Maintenant ça démarre (fenêtre SDL), mais ça gèle tout même MorphOS avant d’avoir le moindre pixel du jeu!

Je pars à la recherche du crash…. en essayant de localiser là où ça coince…

à+

PS: et sinon dommage quand même de ne pas avoir une archive SDK complète directement à-jour qu’on désarchiverais tout simplement dans un répertoire…
Fab1
27 décembre 2006 à 16h05 #74299
Mh, c’est quel jeu ? A tout hasard, je sais qu’il y’a une probabilité assez forte de plantade avec sdl_setcursor() avec la psdl actuelle, mais je dis ça comme ça, les causes de plantages peuvent être infiniment variées. Tu n’as plus qu’à tracer maintenant (objdump est ton ami aussi).
MaVaTi
27 décembre 2006 à 16h45 #74300
Il s’agit du jeu “Still Yet Another Sokoban”

http://scorpioncity.com/sokoban.html

que j’ai trouvé pas mal fait, et qui mériterait je pense d’être disponible sur MorphOS… surtout qu’à l’origine je pensais ne pas en avoir pour bien longtemps! un petit coup de “make” comme on dit, ouais, ouais, comme on dit…

objdump comment ça s’utilise ?

parce que là ça part en gel total, plus accès à rien…

à+
Fab1
27 décembre 2006 à 17h54 #74301
Euh, objdump -d binaire > dump et tu as le listing asm. Mais si ça gèle le système chez toi, ça me parait pas normal non plus. Ca suggère que tu as une ixemul foireuse, peut être.

Sinon je regarderai le jeu si j’ai le temps.
MaVaTi
27 décembre 2006 à 18h07 #74302
J’ai trouvé une piste:

dans Sokoban.cpp, j’ai trois tableaux de char qui sont alloués de cette façon:

char xxxxxx[65536] = {0};

et visiblement ça ne plaît pas du tout !!!

en passant par de classiques malloc( ), ça aide….

Ce qui est bizarre c’est que même en faisant un stack 1000000 dans le shell avant, ça ne change rien… pas pris dans la pile ?

(j’avoue avoir toujours nagé dans les fondements même des compilateurs avec le tas, pile, …)

Mais maintenant le niveau démarre mais avec un écran de jeu réduit en taille , et visiblement le placement des éléments à l’intérieur complètement déconnant.

Pas gagné quoi !
MaVaTi
27 décembre 2006 à 18h50 #74303
Bon, j’ai trouvé mon (dernier?) problème sur les niveaux…

en fait suite au passage par une allocation, j’ai oublié de “toucher” à la ligne suivante :

fgets(buf, sizeof(buf), fin );

hors buf étant maintenant un “char *” au lieu d’un tableau de char, ça vaut donc 4 octets (taille d’un pointeur) au lieu de 65536 précédemment !!!!

Donc un bon

fgets( buf, 65536, fin );

et tout redevient dans l’odre…

J’ai enfin pu jouer au premier niveau !

Et oui pas toujours évident une simple recompilation…

Mais ça m’étonne quand même ce problème concernant l’allocation par une grosse variable tableau sur MorphOS! (et le stack augmenté qui ne résoud rien…)

à+

PS: sinon quelqu’un intéressé par ce jeu ????

Eventuellement le mettre sur Aminet….?
Fab1
27 décembre 2006 à 20h04 #74304
la commande stack affecte la pile 68k. Les applications morphos (non ixemul) doivent définir la taille de leur pile elles-mêmes, avec la variable globale __stack ou l’appel à NewPPCTaskSwap(), la première solution étant la plus simple puisqu’elle consiste à ajouter :

unsigned long __stack = 100000; dans un des sources.

Pour les applications ixemul, on peut les changer avec la commande ixstack qui écrit la nouvelle taille de la pile dans l’exécutable.

Et soit dit en passant, je trouve ça mieux comme ça, car je ne vois pas pourquoi l’utilisateur lambda devrait connaitre les besoins en pile de chaque outil qu’il possède. Ce genre de chose ne devrait vraiment pas être du ressort de l’utilisateur, et les applications qui requièrent un stack 999999999999999 pour ne pas crasher sont juste l’oeuvre de fainéants.
MaVaTi
27 décembre 2006 à 22h28 #74305
Merci pour l’info pour changer la taille de la pile du powerpc, en plus c’est tout simple.

Je vais faire l’essai comme ça.

Aucune idée à combien peut bien être la taille de la pile par défaut, mais surement pas assez pour les gros 64ko demandés à la méthode bourrin!

En tout cas, pour de prochains portages SDL, je ferai gaffe à ce genre de problèmes !!!

Encore merci pour l’aide. à+
MaVaTi
28 décembre 2006 à 18h30 #74306
Je viens de l’uploader sur Aminet… donc ça ne devrait plus tarder à arriver pour ceux qui seront intéressés pour l’essayer ! Là j’ai fait les 4 premiers niveaux… finalement plus compliqué que de le porter !!!

Sinon, pas mal l’interface web maintenant pour poster des fichiers. Je m’étais arrêté au mécanisme sur le ftp du fichier et du readme !!!

Bye, bye.
Souldream
28 décembre 2006 à 19h05 #74307
Merci pour le portage ca pourra toujours servir !

++

...::: Mist - Mister FPGA - FPGA Arcade 060 - ZxUno :::...
...::: A500- A600/Gothek - Amiga 1230 Gotek CF 16GB - A3000 - A4000/30/64Mb/Vlab1.3/Oktagon :::...
...::: Vampire V4 SA :::...
...::: Zx 48/128+2/128+3/QL - Dragon32 - Atari 520STF/1040 :::...
...::: C64 + 1541 / C64 :::...