Communauté PortableDev

Citation de: alekmaul le 08 Mars 2013 à 06:28:27
Quand tu dis "propre gestion des sprites", c'est pour gérer quoi exactement ? Qu'est-ce qui manque dans la version actuelle pour toi ?

Bein je parlais surtout de mon code ? moi, c'était pas relatif ? la librairie, mais toi tu voulais dire dans la lib ou dans le wiki ?
Dans le wiki il manque clairement des infos pour aller plus loin (voir tous les probl?mes que j'ai eu pour comprendre comment ajouter proprement un 2eme sprite). C'est pour ça que lorsque je j'aurai corrigé mon propre code et que je me sentirai parfaitement ? l'aise avec cette gestion j'aimerais compléter le wiki pour que tout le monde ne gal?re pas autant que moi.

Au niveau de la lib ce qui manquerait peut-?tre c'est un niveau d'abstraction supplémentaire, o? on aurait pas ? s'occuper des emplacements mémoires ou de la gestion des palettes, o? on aurait pas ? se prendre la t?te sur les histoires de sprites entrelacés, les décalages etc. C'est vrai que c'est intéressant car on comprend mieux le fonctionnement et les limitations de la "b?te", mais ça peut aussi rebuter ? mon avis.
Maintenant je suis bien conscient qu'on est sur SNES et que c'est déj? pas mal de pouvoir faire du C dessus :-[

Citation de: alekmaul le 04 Mars 2013 à 06:12:55
nan, pas de temps sur le multitap, je suis moi m?me "trop" pris sur une autre console ...
Un peu d'aide sur pvsneslib serait sympa pour faire progresser la lib ...
Pour le wiki, j'ai changé tout cela ce week end, suite ? un message hier d'un autre membre ....
Y'en a, que ça ? foutre ... J'ai donc désactivié les inscriptions automatiques sur le wiki, faudra me demander pour modifier ...

Ok je vais voir ce que je peux faire, sans garantie de résultat hein mais ça aura le mérite de me faire mettre les mains dans le cambouis  ;)
Mais je vais déj? mettre au propre ma gestion des sprites sur ma démo et écrire une partie du wiki ? ce sujet (que je t'enverrai pour correction et pour mise en ligne)

Bonjour !

J'ai pris un peu de retard (j'étais sur un hack de Super Mario Kart qui m'a pris beaucoup de temps :-[), mais je suis toujours motivé !
As-tu eu le temps de jeter un coup d'?il ? mes histoires de multitap ? Aucune urgence je pourrai tester mon principe avec 4 joueurs / 2 manettes en attendant.

Sinon y'a encore des rigolos qui s'amusent avec la page d'accueil du wiki .
Hier c'était un texte sur l'Afrique, aujourd'hui ce sont des portes industrielles  >:( Ils n'en finiront donc jamais...

Citation de: alekmaul le 10 Janvier 2013 à 06:32:23
yes, take a look here : http://www.portabledev.com/wiki/doku.php?id=sprites_en

Priority flag (3rd) is : priority relative to BG : 0 for Low and 3 is the highest

That's where I redirected him too.
His problem is that he wants to have, in Mode 1, 2 BG of 16 colors and his sprite between that 2 BG (so in fact a BG and a FG).
He has succeded to put the sprite between the two layers with 0 and 2 as BG's id and 1 as priority flag.
It doesn't seem to work with another combination.
But with that solution he looses the 16 colors of the 2nd background, because of the limitations of Mode 1 I guess

Mode    # Colors for BG
         1   2   3   4
======---=---=---=---=
0        4   4   4   4
1       16  16   4   -
2       16  16   -   -
3      256  16   -   -
4      256   4   -   -
5       16   4   -   -
6       16   -   -   -
7      256   -   -   -
7EXTBG 256 128   -   -

Have you tried this setting  ?
bgInitTileSet(1, &patterns_bg, &palette_bg, 4, (&patterns_end_bg - &patterns_bg), (&palette_end_bg - &palette_bg), BG_4COLORS, 0x6000);
bgInitTileSet(0, &patterns_fence, &palette_fence, 5, (&patterns_end_fence - &patterns_fence), (&palette_end_fence - &palette_fence), BG_16COLORS, 0x5000);

bgInitMapSet(1, &map_bg, (&map_end_bg - &map_bg),SC_32x32, 0x4800);
bgInitMapSet(0, &map_fence, (&map_end_fence - &map_fence),SC_32x32, 0x4000);

oamInitGfxSet(&gfxpsrite_kyle_1, (&gfxpsrite_end_kyle_1 - &gfxpsrite_kyle_1), &palsprite_kyle_1, 0, 0x0000, OBJ_SIZE32);
oamSet(0,  mycharKyle.x, mycharKyle.y, 1, 0, 0, sprTiles[mycharKyle.positionOffSetSpriter], 0);
oamSetEx(0, OBJ_LARGE, OBJ_SHOW);

setMode(BG_MODE1, 0);


I have not tested but following the instructions of the wiki the priority parameter of the oamSet function is relative to the BG

Citationpriority    priority relative to BG : 0 for Low and 3 is the highest

In your code your backgrounds are numbered 0 and 1.
Your first test the priority at 0 masks you hide your sprites (lowest priority)
Your 2nd test the priority set to high (3) show you the sprites.
So my guess is if you set the priority to 1 your sprite will be between the both BG.

With 3 layers, noted 0,1,2 I supposed than that priority parameter can be set to 2 for example : It's not a binary (0 or 3) value, you can use 0,1,2 or 3  ;)

I hope alekmaul will confirm that point.

PS : sorry for my awful english  :-[

Merci !
Je vais essayer de mettre ça en ?uvre rapidement.
Par contre je ne comprends pas pourquoi on doit diviser par deux les adresses  ???
[...]Temps de réflexion[...]
Ok je me réponds ? moi m?me :
Dans oamInitGfxSet on a
// Init tiles
        dmaCopyVram(tileSource, ([b]address >> 1[/b]), tileSize);
Le >>1 (décalage de bits ? droite) équivaut ? une division par 2
C'est officiel je suis un boulet j'aurais du le comprendre plus tôt  :-[

D'ailleurs il faudrait peut-?tre mieux que je reprenne la notation ">>1" que le "/2", ça doit-?tre plus efficace au niveau du compilateur non ?

Merci encore, j'essaye de faire une petite démo pour bientôt !

Up !
Si tu pouvais trouver une minute ou deux pour mon probl?me je t'en serais infiniment reconnaissant  8)
Il n'y a pas de caract?re d'urgence ceci-dit, loin de moi l'idée de te vouloir te mettre la pression :-[ !

J'ai collé le fichier zip contenant le projet ? cette adresse

J'ai nettoyé le code pour ne laisser que l'affichage des sprites, malheureusement je s?che toujours :-(
Si j'utilise 3 oamInitGfxSet ça me donne ça sous, dans l'ordre, zsnes, no$snes et bsnes :

Je précise que le premier sprite (monstre vert) les 9 images sont situées de 0 ? 14+32, le deuxi?me (ours) commence en 64..78 et 96, et le troisi?me (boulette) s'étend de 128 ? 142 plus le 160 en bonus. J'avais pensé qu'ils se mettraient les uns ? la suite des autres (comprendre que le sprite de l'ours aurait du commencer en 32+2 soit 34) mais apparemment non  :-\
En gardant les m?mes offset pour les sprites et en changeant les 2 derniers oamInitGfxSet par les dmaCopyVram/dmaCopyCGram comme tu me l'as indiqué j'obtiens ceci :

Je n'ai que les sprites initialisés par l'oamInitGfxSet qui s'affichent  :(

Remarques :
-sous bsnes j'ai une couleur de fond, pas toujours la m?me, qui s'affiche alors que j'ai fait un disable des background...Et ça avec les deux techniques oam ou dma.
-toujours sous bsnes avec la méthode du triple oam j'ai les sprites d'offset 0, 64 et 128 qui ne s'affichent pas (cf la premi?re ligne est manquante) alors qu'ils sont bien l? avec les 2 autres émus
-bsnes, toujours, est le seul ? m'afficher quelque chose pour les lignes des sprites ours et boulette, m'enfin ça ressemble ? rien.

Merci d'avance pour ton aide !

Merci AlekMaul,
Tu as raison pour les dmaCopyCGram je ne sais pas pourquoi je suis allé coller OBJ_SIZE16 dedans...
Dans 16*2 le 2 c'est pour 2 octets c'est ça (16 sprites fois 16 bits) ?
Ok je me réponds moi m?me  :
\param size the size in bytes of the data to copy. 

Je vais rechecker mes oamset maintenant  ;)

Pour la nouvelle version de la lib il y a un param?tre de plus dans l'appel de la fonction oamInitGfxSet (la taille des palettes justement).  Par contre j'imagine que du tout les programmes écrits pour une version ne sont pas comptibles avec l'autre :-( Du coup si cette derni?re version fonctionne faudra mettre ? jour le wiki et la doc.

PS : sur le wiki il y a un rigolo qui a collé un lien sur la page d'accueil dans "Other" sur un truc ? Singapour...

Salut !
Je reviens ? la charge apr?s une petite pause, et je suis toujours bloqué avec cette histoire  :'(
J'en suis l? :
u16 adrenvramcopie=0x4000;
unsigned char palEntry;
WaitForVBlank();
setBrightness(0);
oamInitGfxSet(&gfxpsrite, (&gfxpsrite_end-&gfxpsrite), &palsprite, 0, adrenvramcopie, OBJ_SIZE16);
dmaCopyVram(&gfxpours, adrenvramcopie+sizeof(gfxpsrite),sizeof(gfxpours));
dmaCopyVram(&gfxpboulette, adrenvramcopie+sizeof(gfxpsrite)+sizeof(gfxpours),sizeof(gfxpboulette));
palEntry = (128+1*16);
dmaCopyCGram(&palours, palEntry, OBJ_SIZE16);
palEntry = (128+2*16);
dmaCopyCGram(&palboulette, palEntry, OBJ_SIZE16);
Un oamInitGfxSet pour les initialisations, deux dmaCopyVram pour les deux autres sprites, et deux dmaCopyCGram pour nos amies les palettes.
Les palettes ont l'air d'?tre OK (dans no$snes), mais les sprites en dehors du premier sont toujours invisibles.
J'ai fait une méga boucle de la mort pour afficher les 128 sprites et idem le 1er est l? mais pas les deux autres.
Le jour o? je comprends promis je rédige un paragraphe pour le wiki l? dessus  :)

Citation de: alekmaul le 20 Août 2012 à 08:12:28
Merci de tes tests sur MazezaM ;-)
Pour le game design, c'est vrai, c'est bizarre de tout bouger en m?me temps mais c'est le jeu qui veut cela. Faudrait que je trouve une autre forme qui fait plus "bloc" pour éviter ça.

Oui en effet y'a pas grand chose de faisable de ce côté l?...Il faudrait que les éléments liés aient un genre de tapis en dessous, pour montrer qu'il font parti d'un m?me élément. Mais bon ça reste déroutant sur les 2 premiers levels apr?s on s'en fiche.

Citation
Pour le temps entre 2 niveaux, il est de 15secondes, mais tu peux appuyer sur A ou START pour passer.

L? par contre tu peux faire quelque chose c'est afficher un "press start to continue" ou équivalent, voire un compteur qui indique le temps restant avant le prochain stage.
Si tu affiches un message tu peux m?me supprimer le lancement automatique du niveau en fait.
Ergonomiquement parlant ça me semble plus clair pour le joueur, mais je comprendrais que tu ne partages pas mon avis  :)

Salut,

Le lien du wiki m'a bien aidé et en me servant des deux docs j'ai presque réussi ? déchiffrer ce bazar.

Je te décris ici ce que j'ai cru en comprendre :

La solution standard est de brancher le multitap sur le port 2, et donc de n'avoir qu'une seule manette sur le port 1.

Ce qui est fait habituellement c'est de lire d'abord les pads 1 ? 3 en mode automatique (Auto-Joypad Read, ce qui est actuellement fait dans PVSnesLib), puis de switcher sur les ports 4 et 5 en changeant le IObit de 1 ? 0, la lecture de ces deux ports doit par contre se faire manuellement. Il est visiblement important de respecter cet ordre pour une question de synchronisation. Et il faut remettre le IOBit ? sa valeur initiale apr?s lecture des 2 manettes.

Etant donné qu'on a 4 registres pour récupérer les données en mode automatique (les fameux JOY1 ? JOY4) et que JOY1 et 3 sont affectés au port manette 1 et JOY2 et 4 au port manette deux on a donc effectivement les infos du joueur 3 sur le registre JOY4 (JOY3 étant réservé au port manette 1)

l'IOBit : c'est le bit n°6 ou 7 du registre IOPort ($4201 (ecriture) et $4213 (lecture))
C'est le bit 6 si le multitap est branché sur le port 1, et le bit 7 s'il est branché sur le port 2.
Donc en passant

En lecture manuelle, avec une manette sur le port 1 et le multitap sur le 2, ça donne donc ça, donné par nocash :

  [4016h].Bit0=1                                 ;-strobe on (to player 1-5)
  [4016h].Bit0=0                                 ;-strobe off (to player 1-5)
  read any number of bits from [4016h].Bit0      ;-read Player 1 data
  read any number of bits from [4017h].Bit0/Bit1 ;-read Player 2/3 data
  [4201h].Bit7=0                                 ;-select Player 4/5
  read any number of bits from [4017h].Bit0/Bit1 ;-read Player 4/5 data
  [4201h].Bit7=1  ;(prepare here for next frame) ;-select Player 2/3
  do no further access until next frame (allow [4201h].Bit7=1 to stabilize)


On voit que l'IOBit pour le port 2 (bit 7 du registre 4201) passe de 1 ? 0 (puis l'inverse). On récup?re ensuite les bits informations des manettes sur les registres 4016 (port 1 alias JOYA) et 4017 (port 2 alias JOYB).
Si j'ai bien compris en lecture manuelle les infos Data1 sont au bit 0 de JOYA/B (soit l'équivalent de JOY1 et JOY3) et le data2 au bit 1 (JOY2 et JOY4). D'apr?s le wiki il faut lire data1 et Data2 en m?me temps !

Citation"Thus, you must read both bits at once, you can't choose to read only Data1 and leave Data2 for later."

. Par contre comment on fait pour lire ces bits exactement ça je n'ai pas bien compris (lit-on les 16 bits d'un coup ou faut-il le faire séquentiellement ...)

Si on veut 2 multitaps il faudrait donc faire la m?me manip que pour le multitap sur le port 2, c'est ? dire changer le IOBit du port 1 (bit 6 de JOYA) pour switcher des valeurs des manettes 1/2 ? 3/4 du port 1 (et enfin switcher le bit 7 de ce m?me registre pour passer de 5/6 ? 7/8 sur le port 2)
Je pense que la premi?re lecture en "Auto Joy Reading" doit permettre de lire les 4 manettes suivantes : 1 et 2 du port 1 et 1 et 2 du port 2 (aka les joueurs 5 et 6), ce qui nous remplirait les 4 registres d'un coup (JOY1 ? JOY4, soit 4218h, 421Ah,421Ch et 421Eh). Pour les 4 manettes suivantes ce sera en mode manuel (joueurs 3 et 4 sur le port 1 et joueurs 7 et 8 sur le port 2).

Concernant la détection des multitap je suis toujours dans le flou, voil? ce que dit le wiki :

CitationWhen Latch is active, 1s will be read from Data2 and 0s from Data1. This is sometimes used to detect the presence of an MP5 unit. The override switch disables this behavior.

((There is some confusion on this point: according to nintendo's book2, Data1 SHOULD keep returning normal controller data; that is, stuck on the first bit (B button) since shift-register is stopped when "latch is active". However, according to this document by Jim Christy, the first bit of controller data is not loaded onto the Data line until the falling edge of the latch pulse: presumably, therefore, the console can start the latch pulse, wait a bit, read the data lines to detect an MP5, end the latch pulse, wait a bit longer, then start the first clock pulse and sample the first bit of controller data.)).

Et voil? ce que dit nocash:

CitationDetecting the MP5 Hardware
Below can be used to detect MP5 in ports 1 (n=0) and 2 (n=1). Games do usually check both ports (and show an error messages when sensing a MP5 in port 1).

  [4016h].Bit0=1                              ;-strobe on (force MP5 Bit1=1)
  read 8 bits from [4016h+n].Bit1 to byte A   ;-read byte A
  [4016h].Bit0=0                              ;-strobe off (normal data mode)
  read 8 bits from [4016h+n].Bit1 to byte B   ;-read byte B
  if A=FFh and B<>FFh then MP5=present        ;-verify result

CitationIf there's no MP5 connected, then A and B will be typically 00h (since most controllers don't use [4017h].Bit1, exceptions are Turbo File, SFC Modem, Voice-Kun, and X-Band Keyboard).
If a MP5 is connected, then A will be FFh, and B will be first 8bit of data from joypad 3 or 5 (which can't be FFh since one can't push all four DPAD directions at once).

J'esp?re que ça aidera !

J'ai testé (avec zsnes) MazezamE c'est pas mal du tout ! Le rendu des musiques est tr?s propres je trouve.
Bon j'ai commencé ? bien m'énerver ? partir du 6eme puzzle et j'ai lâché l'affaire  ;D Mais je m'y remettrais d?s que j'aurais un peu de temps (quand j'aurais résolu mon probl?me de ^$@?! de sprites par exemple  :P).

Deux remarques :
- le temps de "pause" entre deux niveaux si on ne touche ? rien est peut-?tre un poil long.
- au niveau game design le fait que tous les éléments d'une m?me ligne bougent forcément tous ensemble n'est pas forcément intuitif (genre : mais pourquoi quand je déplace le pot de gauche celui de droite me suit ???), mais passé la surprise ça n'a plus d'importance ;-)

C'est pas le forum qui a un probl?me c'est moi, ? force de faire des allers-retours avec la doc j'ai laissé passé le timer d'une heure et j'ai été déconnecté automatiquement, je plaide coupable !

Merci pour le lien vers la doc, elle a l'air de dire en plus clair ce que celle que j'avais trouvé racontait, je vais potasser ça !