faut lire ;-)

> il faut avoir dans le repertoire sounds/ les memes 17 sons mais en .wav

cad que si on avait dans sounds/
toto.ogg
tata.ogg
titi.ogg
etc...
il faut avoir désormais

toto.wav

tata.wav

titi.wav
etc...
tous au format wav

Mais le but étais pas de fournir une release du jeu qui marche mais juste les sources à Huno pour un de ses projets

Alain

Ah d'accord, j'attendrais...

Côté OS3, j'avance tout doucement.
M'inspirant de la méthode d'Alain, j'ai aussi utilisé un datatype, ça a l'air pratique (pour l'instant).

Elles sont normales ces couleurs ?

Ah non :)))
Il faut que je récupère la palette.
Et le code est fait de telle façon que les datas sont "blittées" en boucle vers l'écran.
Ca marche nickel sur des machines modernes (PC, Wii, AmigaNG), mais sur du Classic c'est la cata :))

Edit : ça avance...



Edit : j'ai implémenté le double buffer dans ma pseudo classe SDL.
L'intro s'affiche proprement sans flickering.
La boucle principale de jeu fait un "stack overflow" quand je l'appelle.


Message édité par : astrofra / 19-01-2015 23:11
Message édité par : astrofra / 21-01-2015 14:05

>stack overflow

Ca m'étonne pas car presque tout est alloué dans la stack dans ce programme déjà la map du jeux y prend plus de 80 k alors avec tout le reste

Faut mettre une grosse stack au démarrage genre 200 à 500 k

Pour ma part je jette l'éponge voici ma dernière version

http://thellier.free.fr/abbayeos4.lha

1) Y a toujours la bug avec ma gestion du clavier qui semble pas faire SDL_KEYUP si bien que le héros reste accroupi une fois accroupi = j'ai patché ça mais je suis toujours pas sûr que la gestion du clavier soit bonne car le heros marche tout le temps

2) Durant le jeu ça plante sans raison = tout d'un coup tout l'OS fige :-(

Bref je suis pas doué pour faire des portages de jeux :-/

Alain

PS: Faute de compositing ça marche évidemment pas dans WinUAE-ppc

 

 

Ah oué! 500Ko de stack. Maman!
J'avais testé avec 8Ko, forcément, ça risquait pas de passer.
Ptain, c'est la moitié de la ram d'un 500+ \o/

Bien joué quand même pour ton début de portage.
HunoPPC sera ptet interessé ? :)

De mon côté, si j'arrive à passer ce pb de stack, je vais m'attaquer au tracé du décor et ensuite à celui du joueur/enemis avec des bobs <3

Enfin quand je dis 500ko c'est pour etre tranquille et pas me casser la tete
Mais au final il suffit peut etre de 100 k

Après on peut toujours allouer la map avec mallloc
genre
enlever
struct map gamemap; /* celle ci est dans la stack */
et faire
M=malloc(sizeof(struct map));
et un
free(M);
à la fin

Evidemment on utilisera toujours 80k pour la map mais plus dans la stack
Peut etre que la map pourrait etre faite avec des UBYTEs et non pas des int : faut lire tout le code pour voir si ça géne ou pas

Y a un truc moche dans ce jeu c'est que la planche "tiles" contient ensemble les décors (sans transparence) et les sprites (avec une transparence simple = noir ou pas)

Y serait plus radical de tout tracer au cpu
(ou alors le décor au blitter (ou au writepixelarray sur du rtg) sans transparence et les sprites au cpu)

Un deuxième truc moche c'est que la planche "tiles" est très grande = mieux vaudrait plusieurs petites planches que l'on pourrait tracer comme des textures avec Warp3D sur les gros amiga 68k

Alain

PS: Faudrait que je rajoute à mon prog ObjDumpFunctions le calcul de la taille de la stack d'un prog

Citation : thellier 
Après on peut toujours allouer la map avec mallloc

Ouhlà c'est toi qui dit que ce jeu était "codé avec les pieds" :-P

Mais sur le fond tu as raison alors je m'y suis remis

Gros nettoyage des sources = toutes les fonctions ont un seul paramètre G sur une struct game
+ réduction de la taille de la map (WORD vs LONG) => plus de pb de stack

 

C'est plus propre mais au final y a  toujours les mêmes problèmes sur le clavier mal géré et le freeze aleatoire :-/

 

Alain