[DEV] pour les nuls

[catharsis]

C'est pas compliqué, les sprites sur néo font 16x16 et la définition de la néo est de 320 en largeur sur 224 en hauteur.

http://wiki.neogeodev.org/index.php?title=Sprites pour la tailles des sprites.

Aprés, je ne serais trop te conseiller des bases en algo et d'utiliser le site du zéro ou autre pour comprendre un peu le c.

[ftek]

Ça sera surement mon unique post dans ce thread mais je le suivrais de près, je suis juste mauvais pour écrire des tutos avec tous les détails et toutes les étapes (je l'ai fait pour coder en asm sur gameboy, tout le monde s'en branlait).

Perso je ne jure que par l'asm (ou le C avec des routines bien foutues qui offrent beaucoup de flexibilité). Je trouve ça moche d’être limite par les libs sur une machine qui l'est deja pas mal de par sa vieillesse. Ouais j'ai dit que la neo était limitée, fuck the world !

Coder en asm ca oblige a bien comprendre comment la machine fonctionne, le C ca permet de faire des choses plus rapidement sans avoir a réinventer la roue comme certains aiment dire, mais on sait pas trop ce qui se passe derrière. Et quand notre programme déconne avec du bon code... On sait plus quoi faire.

Quand on connait pas trop la machine et qu'on code en C, ca donne des bourdes comme dans TotC avec le menu de config buggé. On omet des choses qu'on devrait pas pour faire un prog propre.
C'est pour ca que si t'as le temps, la motiv et que l'anglais te ]fais pas chier Chacha, je t'encourage vivement a passer du temps sur des cours d'asm 68k, sur la doc officielle et sur la wiki. Y'a des petits how-to avec du code asm commente et comment le compiler. Savoir comment utiliser le debugger de MAME ça aide énormément aussi (y'a pas grand chose a savoir).

Si ca te saoule de faire tout de ton cote je serais re en France jeudi, add moi sur msn et je pourrais t'aider en live

[HPMAN]

Par expérience quand ton bouzin de 50k lignes d'asm fonctionne pas, tu sais plus quoi faire non plus

C'est quand même bien plus facile de structurer un programme en C, après personne n'a dit de s'en tenir exclusivement aux éléments fournis avec dans le kit neobitz.
Tu importes tes libs persos en asm et en avant Guingamp.
Faut pas abuser sur les appels de fonctions, et pas penser le programme n'importe comment mais le C reste assez "optimisable" et proche du matériel (on peut demander qu'une variable soit stockée dans un registe CPU par exemple).


Apres oui y'a clairement des trucs à jeter dans la lib neobitz, par exemple textoutf, t'en fais genre 10 et la neo est à genoux

[ftek]

Par expérience quand ton bouzin de 50k lignes d'asm fonctionne pas, tu sais plus quoi faire non plus

Si c'est toi qui a ecrit les 50k lignes, que t'as un peu de methode et que t'utilises le debugger tu peux t'en sortir Ok des fois c'est l’ému qui est pourri.
Si tu fais aveuglement confiance a des libs buggees, tu peux encore chercher longtemps dans ton code C...

Le textoutf est horrible oui, un textout avec %x pour le debug et %u ca devrait suffire...

[tugs]

j'aime vous lire, c'est funky

[chacha]

Ne vous battez pas, c'est pour le fun ce topic .

CeL:

J'ai un problème avec ce qui suit : je dois mélanger les termes :

set_current_sprite(1); tu dis que l'on se positionne sur le sprite 1.

C'est quoi, le sprite 1 ? l'image bg; sa position sur l'écran ? la première image lue dans le fichier gfx ?

Je ne comprends ce qui suit alors :

write_sprite_data(0,0,15,255,14,20, (const PTILEMAP)&bg);

là, tu dis qu'on place bg en 0,0. Bien, mais alors que siginifie le set_current_data ?

Pour le second sprite (chunli), on se positionnne sur le sprite 21 (20 de plus que la largeur du premier). J'ai du mal à appréhender cette notion de sprite, en fait. C'est quoi, une adresse ? Les sprites de la valeur 1 à 20 sont remplis de bg ?

Je dois mélanger les termes.

Je vais ressortir mes "cours du zéro" pour revoir ces bases.


Le topic porte bien son nom (malade) .

[chacha]

Je suis en train de relire le premier topic NGF Dev.Inc© .

Je vais me replonger dans les pointeurs and CO, sinon, je serais perdu de toute façon.

[catharsis]

J'ai un problème avec ce qui suit : je dois mélanger les termes :

set_current_sprite(1); tu dis que l'on se positionne sur le sprite 1.

C'est quoi, le sprite 1 ? l'image bg; sa position sur l'écran ? la première image lue dans le fichier gfx ?

Je ne comprends ce qui suit alors :

write_sprite_data(0,0,15,255,14,20, (const PTILEMAP)&bg);

là, tu dis qu'on place bg en 0,0. Bien, mais alors que signifie le set_current_data ?

Pour le second sprite (chunli), on se positionnne sur le sprite 21 (20 de plus que la largeur du premier). J'ai du mal à appréhender cette notion de sprite, en fait. C'est quoi, une adresse ? Les sprites de la valeur 1 à 20 sont remplis de bg ?

Je dois mélanger les termes.

Je vais ressortir mes "cours du zéro" pour revoir ces bases.


Le topic porte bien son nom .

Quand tu veux afficher un sprite, cela ce décompose en plusieurs étapes.

D'abord tu attribues une palette à ton sprite, dans le code donné par cel il s'agit de :
setpalette(0, 256, (const PPALETTE)&palettes);

Ensuite tu donnes un numéro à ce sprite :
set_current_sprite(1)

Le numéro sert à désigner de façon unique ton sprite.
Il te faudra par exemple, utiliser ce numéro si tu veux déplacer spécifiquement ce sprite.

Ensuite tu affiches l'image avec ses coordonnées, facteur de réduction et taille du sprite :
write_sprite_data(0, 0, 15, 255, 14, 20, (const PTILEMAP)&bg);

Le sprite numéro 1 est donc le BG. car il est affiché juste après le set_current_sprite(1)

Les 0,0 du write_sprite_data, permettent de positionner en x (abscisses), y (ordonnées) ton spirite sur ton écran.

J’espère que je suis clair.
Amuse toi a changer les valeurs du write_sprite_data et à compiler, tu verras mieux a quoi servent les valeurs.

[ftek]

J'ai encore envie de l'ouvrir.

Sur la Neo la notion de sprite est un peu speciale. T'as pas de BG a proprement parler, tout n'est que sprites.
Un sprite c'est une bande de 16px de large et de max. 512px de haut (quand tu le reduis pas). Si tu veux un BG, il faut que tu foutes 20 sprites cote a cote (320/16=20).

Si tu veux afficher un perso qui fait 64*80px par ex. Ca va te bouffer 64/16=4 sprites. La hauteur c'est free party donc qu'il fasse 16px de haut ou 512px c'est la meme chose.

Par ex si tu veux faire un jeu avec 2 BG tu vas utiliser les sprites 1 a 20 pour le BG 1, les 21 a 40 pour le BG 2 et le reste pour dessiner tes persos. Faut pas utiliser le sprite 0, il est reserve par le gpu.

A savoir que les sprites sont dessines dans l'ordre (sprite 1 dans le fond, sprite 384 au premier plan).

[tugs]

Attention ftek, encore 2 messages et tu sors officiellement de la catégorie autiste ^^

[catharsis]

J'ai encore envie de l'ouvrir.

Fait toi plaisir, je suis disposé à être ton padawan

[chacha]

Bordel, je n'arrive plus à compiler.


Rhaaaaaaaa .

[chacha]

Quand tu veux afficher un sprite, cela ce décompose en plusieurs étapes.

D'abord tu attribues une palette à ton sprite, dans le code donné par cel il s'agit de :
setpalette(0, 256, (const PPALETTE)&palettes);

Ensuite tu donnes un numéro à ce sprite :
set_current_sprite(1)

Le numéro sert à désigner de façon unique ton sprite.
Il te faudra par exemple, utiliser ce numéro si tu veux déplacer spécifiquement ce sprite.

Ensuite tu affiches l'image avec ses coordonnées, facteur de réduction et taille du sprite :
write_sprite_data(0, 0, 15, 255, 14, 20, (const PTILEMAP)&bg);

Le sprite numéro 1 est donc le BG. car il est affiché juste après le set_current_sprite(1)

Les 0,0 du write_sprite_data, permettent de positionner en x (abscisses), y (ordonnées) ton spirite sur ton écran.

J’espère que je suis clair.
Amuse toi a changer les valeurs du write_sprite_data et à compiler, tu verras mieux a quoi servent les valeurs.

J'aime quand on me parle comme ça. Dès que j'arrive à compiler, je m'amuse avec les paramètres.

[tugs]

Bon allez chacha, fait nous une tite démo j'te prépare une tite musique

[chacha]

Bon, j'ai réussi à compiler quelque chose mais ça donne ça :

http://img402.imageshack.us/img402/4021/zx9.mp4

C'est bizarre, car on a "les couleurs" de bg et de chunli, mais pas les images en elles-même. Ces couleurs qui correspondent, est-ce le hasard, ou ça vient des palettes ?

Ce que j'ai fais :

j'ai pris 202-p1.bin et 202-s1.bin, j'ai fais un copier-coller dans la rom dézippée de PUZZLEDP, j'ai zippé à nouveau tous les composants, et voilà ce que cela donne dans MAME.

Comment intégrer les images dans cette compilation ?

A mes yeux, la compilation fonctionne mais ne va pas chercher les images au bon endroit, ou les images ne sont pas intégrées dans la compilation. J'opterai pour la seconde solution.

Dans le fichier TUTO, faut faire quoi en premier (et dans quel ordre ensuite), après avoir changé le main.c ?



Edit = La 052-s1.bin et la 052-p1.bin servent à quoi ?