L'affaire FAREWELL

[nagame]

Présentation
L’affaire Farewell est un jeu vidéo amateur développé entre 2004 et 2005 sur la console de jeu GameBoy Advance. Le projet était vécu comme un passe-temps, avec ses hauts et ses bas, ses moments de découragement et ses joies. Par manque de temps, son développement s’est arrêté fin 2005, aprés la réalisation du "défi de Noël".

Galerie d'images

Autres Informations
Le site web : http://www.nagame.net/index_1-l-affaire-farewell.html

[Nesgba]

OOHH tres joli jeu !!

le premier de PA en + :cool:

[nagame]

Avant tout, grand bravo pour le nouveau PA et chapeau bas à l'équipe

Au tableau des nouveautés de ma modeste MAJ :

- Ma bibliothéque sonore pour compilo SDT est pratiquement terminée.
Au menu : compatiblité SDT , format PCM/ADPCM, "séquencage facile" des échantillons directement depuis l'encoder.

- Une première recherche photographique
+ voir la banque photos

- Je viens de plonger dans la lecture d'un nouveau livre "KGB en FRance" paru en 87. Soit trés peu de temps aprés l'affaire Farewell
+ voir (bibliographie)

[Shock The Dark Mage]

Envoyé par nagame

- Ma bibliothéque sonore pour compilo SDT est pratiquement terminée.
Au menu : compatiblité SDT , format PCM/ADPCM, "séquencage facile" des échantillons directement depuis l'encoder.

Pourquoi tiens tu réelement à utiliser le compilateur SDT de ARM alors qu'il y a devkitPro qui utilise GCC 4.0 maintenant (le SDK de Nintendo c'est GCC 2 je crois) et qui est gratuit ? Est-ce que le compilateur SDT pour ARM7 est encore mit à jour ?

[nagame]

Quand j'avais commencé à m'intéresser au dev sur GBA, les kit complet comme HAM n'existait pas. Seul GCC et SDT, compilateur nu de toute lib était dispo. J'avais fait, à l'époque, des test comparatifs sur la qualité de compilation. Et SDT écrasé clairement GCC (de l'ordre de 25%) en vitesse pur. Test qu'il allait dans le même sens que tous les autres comparatifs dispo sur le net.
Depuis, de l'eau a coulé sous les ponts, des libs trés optimisé sont sortie, qui ont tiré il est clair, GCC vers le haut. Mais ce choix (logique sur le moment, mauvais sur le long temps) m'a permis d'apprendre à gérer le hardware en direct. Je suis persuadé que si j'avais développé sur HAM, j'aurais utilisé les libs existantes et je serais passé à coté de plein de chose.

Au boulot, je fais mes choix technique sur des raisons de productivité. Pour Farewell, je test, restest, change d'avis, reviens, perd du temps mais surtout apprend et prend du plaisir.

A noter que plusieurs autres codeurs de PA travaillent aussi directement sans lib (comme Nrx). ARM fait bien sûr évolué son compilo. La dernière version est l'ADS 1.2 de mémoire.

[Nesgba]

a propos nagamé j'ai consulté ton code que tu avais posté et (malgré la petite expriance que j'ai en dev) je pense qu'on peut encore optimiser pas mal de chose , a commencer par les decalages binaires et encores d'auteres bricoles sur les sprites. d'ailleur pour le fun je suis entrain de convertir ton code pour gcc pour tester la rapidité de rendu au final

on verra bien si sdt enterre toujours gcc

[nagame]

Ca, j'en doute pas . Je trouve moi même, de temps en temps, des coquilles ca et là. Surtout, publie tes résultats et tes optimisations. Je suis preneur :cool:

Le code de Farewell est en perpetuel évolution et la dernière version en cours de dev est encore un peu plus rapide. Ce que j'aime c'est que le moteur a quelques bonnes cartes a exploiter : en 1*1 bien sûr, mais surtout le mode tiles qui devrait permettre le vieux rêve du 1er jeu GBA avec lunette 3D.


Sinon, en me promenant sur le web je suis tombé, par hasard, sur ca : http://www.gamesover.net/284/Toundra_GBA.html .
Une page sur Toundra . Ca fait chaud au coeur surtout quand on s'y attend pas.
Vous connaissez le site gameover.net ? Une référence ? un inconnu ?
Quelqu'un pourrais le traduire ?

[Smealum]

[nagame]

Ouaaaaa un niveau caché !
Smealum, je te nomme meilleur "designeur de niveaux" de tout les temps :chapeau:

Mais c'est pas un flingue que tu devrais tenir mais plutot une...un radar

[Nesgba]

Envoyé par nagame

Ca, j'en doute pas . Je trouve moi même, de temps en temps, des coquilles ca et là. Surtout, publie tes résultats et tes optimisations. Je suis preneur :cool:

ben moi quand je voit ca ca me fait mal au coeur :'{

// Copie le buffer en mémoire réel (à faire aprés la VBL)
void CopyOAMBuffer(void)
{
REG_DMA3SAD=(u32) OAMBuffer;
REG_DMA3DAD=(u32) OAM;
REG_DMA3CNT= MAX_OAMSPRITE * 2 | DMA_32NOW;
}

deja la copie OAM doit se faire PENDANT la vbl (meme BigN l'impose au jeux commerciaux) et ensuite il faut absolument eviter les copies DMA surtout si tu utilise un decompresseur ADPCM par la suite (si tu en fait trop d'affilée ca crachotte donc autan prendre de bonnes habitudes)
et ensuite le x2 est t-il vraiment necessaire ? au pire tu fout un "<<1" mais un "*2" comme ca en plein millieu de ton programme c'est inacceptable monsieur tout simplement !! une honte !!(a faire avec une voix de petit vieu )

et enfin etant donné que tu utilise meme pas 20 sprites esce vraiment necessaire de remettre a jour les 4 attributs des 128 sprites ?? BIEN SUR QUE NON MONSIEUR !! dison que 64 suffirons amplement

et enfin mettre des sprites en 256 couleurs pour afficher des chiffres j'orai tout vu !! c'est IMPARDONNABLE MON BON MONSIEUR !!

a la rigueur les bras + le fusil je suis ok tu peut prendre disons les 10 premieres palettes pour cela ca te fait 160 couleurs c'est amplement suffisant mais les 5 dernieres tu les laisses en mode 16 couleurs et tu affiche tes lettres et ton radar avec ca te fait deja un gain de place sur la rom et un gain de copiage puisque tu as moitié moin a copier.


tien regarde ca c'est joli

void IN_IWRAM Copie32(int *src,int *dst,unsigned int taille)
{
unsigned int loop=0 ;
for (loop=0;loop<taille;loop++)*dst++ = *src++ ;
}

void CopyOAMBuffer(void)
{
Copie32((void*)OAMBuffer,OAM,128); // copiage des 4 attibuts de 64 sprites (en 32 bit donc seulement 128 )
}

ps: bien sur prennez ce post au second degré j'ai volontairement exagéré quelques remarques (comme si un x2 en moin allai te faire gagner 1 fps XD)
ca doit etre le nouveau site qui me donne cet effet XD

pss: sinon j'ai remarqué que ton code est hyper orianté et tres difficilement utilisable pour un autre type de jeu, tu devrai generaliser un peu + ptet

psss: j'ai trouvé un memcpy aussi, c'est une fonction super lente remplace la par un Copie32() (enfin je parle pour gcc qui genere du code asm frenchement louche parfois, pour sdt je sais pas )

[Yodajr]

Premier projet sur le new forum, premiere news sur le site
Bravo et merci Nagame

Message à tous les codeurs qui ont un projet en cours, n'hésitez pas à faire de même (l'update n'est pas obligatoire, juste creer un topic similaire au précédent sur l'ancien PA suffira)
Pour les projets finis, c'est pas la peine, tout est prévu

[Smealum]

Envoyé par Yodajr

Pour les projets finis, c'est pas la peine, tout est prévu

Qu'est ce que tu veux dire ?

[Nesgba]

j'ai un bleme sur ton editeur de niveaux, j'arrive pas a afficher plusieurs elements traversables (poteau, lampe ...) y'en a qu'un seul qui s'affiche a chaque fois :'{

je fait un level special "prison"
mais c'est frenchement marran a faire, dommage que l'on puisse pas creer de vrais scenarios, et partir dans des delires bien louches XD

sinon superbe boulot meme si l'edition avec ce syste de pixels est chiante a la longue

ton systeme file me fait baver je veut le meme !!

[Yodajr]

Envoyé par Smealum

Qu'est ce que tu veux dire ?

Normalement ils devraient apparaitre prochainement sur le site.
Mais je me rend compte que les commentaires seront impossibles... donc j'ai rien dis, que tout le monde recrée ses topics de projet, fini ou pas

[nagame]

Ouaa... je suis en news
Marciiiii

Moa qui croyait que PA était de nouveau planté (le domaine ne passe pas...), c'est en lisant mes mails que j'ai vu que j'avais des posts pour Farewell sur l'url temporaire.


Bon Nes..... Qu'esst-ce qu'il a mon cooooooode ???!! .

Alors, dans l'ordre :
1. Pour la copie OAM pendant la VBL, je dirais : ha ! S'avais pas môssieur. Promis recommence pas.

2. Pour les copies DMA, je commence à bien les connaître les petits. Depuis les derniers sources publié, j'ai complétement revu la gestion DMA (inspirer de la méthode de Nrx) et surtout je stoppe et réinitialise correctement les DMA a chaque utilisation.

Sur ma derniere version (pas encore publier), je gére la zic de fond et les bruitages. Et tous ce petit monde fonctionne sans relentissement.

3. Pour les 4 attributs & 128 sprites. C'est impardonnable . Y a bien longtemps que je ne m'était pas intéressé à cette partie du code (au moins 1 an)

4. Pour les chiffres : ben je m'en fous des chiffres, ils sont temporaire. Au contraire, qu'ils ralentissent ! Ca seras dotant une bonne nouvelle pour la version finale.

5. Quoooaa une boucle for() tu veux que Farewell tourne à 1fps :hein:.
Horreur, je préfére encore memcpy. La dessus j'ai fais bcp de test sur sdt. Le mieux reste DMA, suivi de memcpy et bon dernier for(). Il est vrai que les DMA posent des problémes, disons qu'il faut trouver le bon enchainement.
Sinon IN_WRAM ca ne marche que sur GCC. La gestion de la WRAM est trés compliqué sur SDT, il faut copier manuellement la fonction à l'adresse voulu et créer un pointeur de fonction.

[nagame]

Ha ! Un beugg a l'éditeur de niveau ? Peux tu m'envoyer ton level par e-mail que je puisse le tester. Pourtant le niveau de la demo a été créé avec cette éditeur.

Clair que l'édition à la main c'est lourd. J'ai bien commencé un éditeur sous Windows. Il devrais intégrer le moteur de Farewell permettant de voir en temps réel le résultat. Mais je manque de temps....

[Brunni]

Nes> N'exagère pas quand même. Genre la copie DMA de l'OAM c'est bien, parce que ça ne représente que 1 ko. Si on prend les timings GBA lors d'un DMA (/2 car les timings sont exprimés en l'occurence pour une valeur 16 bits, sauf pour l'IWRAM qui est 32 bits):
Lecture (EWRAM): 3*(1024/2) = 1536 cycles
(OU BIEN Lecture en IWRAM: 1*(1024/4) = 256 cycles)
Ecriture (OAM): 1*(1024/2) = 512 cycles (théorique)
Total (en supposant qu'il utilise l'EWRAM): 2048 cycles, soit 122.1 ns (nanosecondes) où le processeur est inactif (nombre de cycles/16777216). Le fait qu'une lecture soit justement générée à ce moment là est un hasard et n'arrive pas à tous les coups, de plus le temps d'attente sera au pire de 122 ns (mais en général beaucoup moins).

Par contre pour les graphismes en VRAM le DMA c'est moins conseillé. Si on prend par exemple une copie de 64 ko depuis la ROM sans prefetching, réglages par défaut (lent), ça donne - sauf erreur de ma part:
Lecture (ROM): 6*(65536/4) = ~100'000 cycles
Ecriture (VRAM): 2*(65536/4) = ~33'000 cycles
Total pour ~131'000 cycles, soit quand même 7.8 millisecondes (plus du tiers d'une frame). Le clic sera génant, donc le mieux c'est de désactiver le son durant ce temps là, ou alors faire un copie software comme nes a expliqué (mais c'est très lent), ou encore décomposer en plusieurs plus petits DMA, ou alors dernière solution une copie optimisée en asm (à peine 10% plus lent qu'un DMA, et garde le processeur actif).

4. Pour les chiffres : ben je m'en fous des chiffres, ils sont temporaire. Au contraire, qu'ils ralentissent ! Ca seras dotant une bonne nouvelle pour la version finale.

Lol pareil dans mon Sonic les infos de débogage prennent plus de temps CPU que le jeu complet, alors ça fait du bien quand tu les désactives

Sinon IN_WRAM ca ne marche que sur GCC. La gestion de la WRAM est trés compliqué sur SDT, il faut copier manuellement la fonction à l'adresse voulu et créer un pointeur de fonction.

Ce qui ne fonctionnera peut-être pas pour des programmes plus compliqués (qui contiennent des adresses relatives). Tu ne reloges pas le code? (il doit y avoir une option de ton compilo pour dire que le code commence à tel endroit, tu pourrais par exemple redéfinir l'adresse de départ de la section .text de tes fichiers .c destinés à être copiés en iwram, il faudrait tester).

Sinon superbe boulot comme d'hab, ça fait plaisir de voir que notre GBA n'est pas morte bravo et continue comme ça

[MIKEGBA]

Bravo nagamé !!!

ça fait plaisir de voir à nouveau des news de ce projet !!

fait pas attention à Nes, il radote !!!

[Nrx]

Tiens, j'ai vu un truc en Flash qui m'a fait pense a toi nagame : http://www.minijuegos.com/juegos/html/index.php?id=3728 (note : il faut Flash 8).

[nagame]

Ben juste, un petit UP pour annoncer le retour de Farewell .

La prochaine maj (d'ici peu) devrait surtout consister à récupérer les avancées du moteur faites dans PA défi III. Par la suite, 2 pistes a travailler : finir l'IA et surtout travailler le graphisme.

Envoyé par Nrx

Tiens, j'ai vu un truc en Flash qui m'a fait pense a toi nagame : http://www.minijuegos.com/juegos/html/index.php?id=3728 (note : il faut Flash 8).

Excellent
J'avais vu, il ya longtemps, encore pire : un clone de Wolf3D en Javascript !!
Il y en a qui aime se faire mal

[Dr.Vince]

cool le retour de nagame !!

[Bodom-Child]

Bon courage pour la suite! Ce projet est vraiment excellent

[MaXleBourrin]

Yipee the return of the king

Bonne chance pour la suite

[nagame]

Merci à tous...
J'ai du temps à rattraper. Incroyable le nombre de projet DS

Envoyé par MaXleBourrin

Yipee the return of the king

Bonne chance pour la suite

Je viens de donnais une piéce à ton yoshi
Mais ca fait quoi de donner des piéces ?

[MaXleBourrin]

Ben enfaite, tu dois élever ton yoshi, le nourrir, le promener, avec les pièces, tu achète des items sois pour le faire évoluer, sois pour attaquer les autres!
Je te conseille de t'inscrire, c'est sympas comme mini-jeux

D'ailleurs je m'epresse de crer une team PA