Messages récents

Pages: 1 [2] 3 4 ... 10
11
PVSnesLib section Française / Re : besoin de certains éclaircissements ^^
« Dernier message par alekmaul le 15 décembre 2014 à 12:33:35 »
donc en questions :
- Comment faire pour ajouter de l'asm directement dans le code en C ? (me sera necessaire pour placer des JMP particuliers)
- J'ai réussi tant bien que mal a convertir un spc pour l'intégrer, mais ca n'a été ni simple, ni intuitif... et impossible de dépasser les 32ko (il faut peut etre découper en bank de 32ko ?)
Quel est la manip (ou plutot son) pour faire un truc "propre" ?
- je n'ai pas très bien compris comment était géré les "layers" (si ils s'appellent comme ca sur snes)
car j'aurais voulu un plan en 256 couleurs (background), lui pas de souci avec les exemple dans la lib et un autre en 16 couleurs pour ecrire du texte + curseur (certainement en sprites) (au 1er plan pour ces derniers), j'ai pris le mode 3 qui semble fonctionner avec 2 plans...
- pour finir mais c'est moins "grave", est-il possible de faire ca directement en Hirom, car par défaut j'ai vu que c'était du Lorom.
Désolé, j'avais zappé ton message, alors mes réponses :
- ajouter de l'asm dans le C, j'ai jamais testé, je fais directement des fichiers asm. Ce n'est pas à faire de mixer du C et de l'ASM en plus car il faut jongler avec les registres, donc il faut bien maitriser tout le source (je parles sur SNES, pas en général).
- Le son , c'est la galère, le mieux est les fichiers MOD car le spc, c'est pas géré. Regarder le tracker de shiru, il peut aider pour créer des fichiers SPC. Et oui, comme on est en lorow, du 32Ko max.
-pour les layers, j'ai pas bien compris ce que tu veux faire. Pour le mode 3, il faut positionner les tiles pour être en priorité MAX sinon.
- Pour les roms en HIROM, pas possible hélas en l'état, que du lorow ...
12
PVSnesLib English section / Re : Limit address of sprites in oamInitGfxAttr(...)?
« Dernier message par faeldaniel le 04 novembre 2014 à 14:36:11 »
Oh yes is one limit, I have an idea how to solve the problem, thanks  :D
13
PVSnesLib section Française / besoin de certains éclaircissements ^^
« Dernier message par ichigobankai le 03 novembre 2014 à 20:31:16 »
Bonjour et merci à Alekmaul !

j'essai de faire un petit menu pour une compile Snes (compile des Final Fight) et j'avais pensé faire ca simplement avec la Pvsneslib, car c'est en C et donc plus facile (pour moi) a coder.

J'ai déjà fait ±la même chose pour Master System il y a quelques semaines :
https://www.youtube.com/watch?v=kFS8aZscvKc
ca n'est pas la derniere mouture, car maintenant il y a musique & sfx + une action du bouton reset qui fait revenir au menu (uniquement compatible master system 1)

donc en questions :

- Comment faire pour ajouter de l'asm directement dans le code en C ? (me sera necessaire pour placer des JMP particuliers)

- J'ai réussi tant bien que mal a convertir un spc pour l'intégrer, mais ca n'a été ni simple, ni intuitif... et impossible de dépasser les 32ko (il faut peut etre découper en bank de 32ko ?)
Quel est la manip (ou plutot son) pour faire un truc "propre" ?

- je n'ai pas très bien compris comment était géré les "layers" (si ils s'appellent comme ca sur snes)
car j'aurais voulu un plan en 256 couleurs (background), lui pas de souci avec les exemple dans la lib et un autre en 16 couleurs pour ecrire du texte + curseur (certainement en sprites) (au 1er plan pour ces derniers), j'ai pris le mode 3 qui semble fonctionner avec 2 plans...

- pour finir mais c'est moins "grave", est-il possible de faire ca directement en Hirom, car par défaut j'ai vu que c'était du Lorom.

c'est tout pour le moment !
14
PVSnesLib English section / Re : Limit address of sprites in oamInitGfxAttr(...)?
« Dernier message par alekmaul le 03 novembre 2014 à 19:33:59 »
ok, will check.
But perhaps the limit is more regarding the alignement of memory for sprites. Will try to find an explanantion in no$sns documentaiton.
15
PVSnesLib English section / Re : Limit address of sprites in oamInitGfxAttr(...)?
« Dernier message par faeldaniel le 01 novembre 2014 à 02:31:40 »
I booked address 0x0000 to 0x2FF0 only sprites, maps and tiles i am using from 0x3000, I believe you quoted as being a limit. But lets go, the code is not otmized.


//Oh yes is big array, but is only for tests, in the future i go reduce this :)
unsigned short sprTiles16px[300] = {0,2,4,6,8,10,12,14,32,34,36,38,40,42,44,46,64,66,68,70,72,74,76,78,96,98,100,102,104,106,108,110,128,130,132,134,136,138,140,142,160,162,164,166,168,170,172,174,192,194,196,198,200,202,204,206,224,226,228,230,232,234,236,238,256,258,260,262,264,266,268,270,288,290,292,294,296,298,300,302,320,322,324,326,328,330,332,334,352,354,356,358,360,362,364,366,384,386,388,390,392,394,396,398,416,418,420,422,424,426,428,430,448,450,452,454,456,458,460,462,480,482,484,486,488,490,492,494,512,514,516,518,520,522,524,526,544,546,548,550,552,554,556,558,576,578,580,582,584,586,588,590,608,610,612,614,616,618,620,622,640,642,644,646,648,650,652,654,672,674,676,678,680,682,684,686,704,706,708,710,712,714,716,718,736,738,740,742,744,746,748,750,768,770,772,774,776,778,780,782,800,802,804,806,808,810,812,814,832,834,836,838,840,842,844,846,864,866,868,870,872,874,876,878,896,898,900,902,904,906,908,910,928,930,932,934,936,938,940,942,960,962,964,966,968,970,972,974,992,994,996,998,1000,1002,1004,1006,1024,1026,1028,1030,1032,1034,1036,1038,1056,1058,1060,1062,1064,1066,1068,1070,1088,1090,1092,1094,1096,1098,1100,1102,1120,1122,1124,1126,1128,1130,1132,1134,1152,1154,1156,1158,1160,1162,1164,1166,1184,1186,1188,1190};

//Custom oamInitGfxAttr, my sprites having 16X32 (see Val 6 in table Sprite sizes http://www.portabledev.com/wiki/doku.php?id=sprites_en)
REG_OBSEL = (6<<5) | (0x0000 >> 13);

//Copy the heros graphics for vram with dma, this point using 0x0000 to 0xC000
WaitForVBlank(); dmaCopyVram(&tileSourceHeros, 0x0000, &tileSourceHerosEnd-&tileSourceHeros);

//Copy the heros palette for vram with dma
dmaCopyCGram(&paletteEntryHeros, (128+0*16), 32);

//Copy the civis graphics for vram with dma, this point using 0xC000 to 0x2000
WaitForVBlank(); dmaCopyVram(&tileSourceCivis, 0xC000 , &tileSourceCivisEnd - &tileSourceCivis);

//Copy the civis palette for vram with dma
dmaCopyCGram(&paletteEntryCivis, (128+1*16), 32);

//Copy the objs graphics for vram with dma, this point using 0x2000 to 0x3000
WaitForVBlank(); dmaCopyVram(&tileSourceObjs, 0x2000, &tileSourceObjsEnd - &tileSourceObjs);

//Copy the objs palette for vram with dma
dmaCopyCGram(&paletteEntryObjs, (128+2*16), 32);


/*Table offset

   Offset              Sprite             Addres Real
   0                     Hero               0x0000
   16                   Friend1           0x0400
   32                   Friend2           0x0800
   48                   Civil1              0x0C00
   64                   Civil2              0x1000
   80                   Civil3              0x1400
   96                   Civil4              0x1800
   112                 Civil5              0x1C00
   128                 OBJ1              0x2000 //Dont working
   144                 OBJ2              0x2400 //Dont working
   160                 OBJ3              0x2800 //Dont working
   176                 OBJ4              0x2C00 //Dont working



*/

//0x0000
oamSetEx(0, OBJ_SMALL, OBJ_SHOW);
oamSet(0,  hero.x, hero.y, 0, 0, 0, sprTiles16px[0], 0);

//0x0400
oamSetEx(4, OBJ_SMALL, OBJ_SHOW);
oamSet(4,  friend1.x, friend1.y, 0, 0, 0, sprTiles16px[16], 0);

//0x0800
oamSetEx(8, OBJ_SMALL, OBJ_SHOW);
oamSet(8,  friend2.x, friend2.y, 0, 0, 0, sprTiles16px[32], 0);

//0x0C00
oamSetEx(12, OBJ_SMALL, OBJ_SHOW);
oamSet(12,  civil1.x, civil1.y, 0, 0, 0, sprTiles16px[48], 1);

//0x1000
oamSetEx(16, OBJ_SMALL, OBJ_SHOW);
oamSet(16,  civil2.x, civil2.y, 0, 0, 0, sprTiles16px[64], 1);

//0x1400
oamSetEx(20, OBJ_SMALL, OBJ_SHOW);
oamSet(20,  civil3.x, civil3.y, 0, 0, 0, sprTiles16px[80], 1);

//0x1800
oamSetEx(24, OBJ_SMALL, OBJ_SHOW);
oamSet(24,  civil4.x, civil4.y, 0, 0, 0, sprTiles16px[96], 1);

//0x1C00
oamSetEx(28, OBJ_SMALL, OBJ_SHOW);
oamSet(28,  civil5.x, civil5.y, 0, 0, 0, sprTiles16px[112], 1);

//0x2000 - Dont working
oamSetEx(32, OBJ_SMALL, OBJ_SHOW);
oamSet(32,  obj1.x, obj1.y, 0, 0, 0, sprTiles16px[128], 2);

//0x2400 - Dont working
oamSetEx(36, OBJ_SMALL, OBJ_SHOW);
oamSet(36,  obj2.x, obj2.y, 0, 0, 0, sprTiles16px[144], 2);

//0x2800 - Dont working
oamSetEx(40, OBJ_SMALL, OBJ_SHOW);
oamSet(40,  obj3.x, obj3.y, 0, 0, 0, sprTiles16px[160], 2);

//0x2C00 - Dont working
oamSetEx(44, OBJ_SMALL, OBJ_SHOW);
oamSet(44,  obj4.x, obj4.y, 0, 0, 0, sprTiles16px[176], 2);

16
PVSnesLib English section / Re : Limit address of sprites in oamInitGfxAttr(...)?
« Dernier message par alekmaul le 31 octobre 2014 à 21:11:24 »
The limit is only regarding all the graphics you are using. 2000h is not a limit, it is perhaps because you are using 2000h for something else like map, tile and so on ...
Also, by the way, I think I remember that sprites are 8k align, so it is perhaps a limit. Please post a part of your code and I will try to test with no$sns ...
17
PVSnesLib English section / Re : Update oamSetXYEx (bug with oamSetEx as OBJ_SMALL)
« Dernier message par alekmaul le 31 octobre 2014 à 21:08:04 »
sorry, didn't remember that bug, will check the lib :/
18
PVSnesLib English section / Limit address of sprites in oamInitGfxAttr(...)?
« Dernier message par faeldaniel le 31 octobre 2014 à 19:22:56 »
I am put all graphics in VRAM with DMA Copy, the size of address of Sprites I am just using:
void oamInitGfxAttr(0x0000, OBJ_SIZE8);
Because i can only use  Sprites from address 0x0000 to 0x1FF0 (size 0x1FF0?) in gfxoffset? I need using between 0x0000 to 0x2FF0 for the Sprites, but the sprites is not operate from 0x2000, is one limit?
19
PVSnesLib English section / Update oamSetXYEx (bug with oamSetEx as OBJ_SMALL)
« Dernier message par faeldaniel le 20 octobre 2014 à 03:50:27 »
Hi alekmaul,

Remember that bug with the function oamSetXYEx, if your set oamSetEx as OBJ_SMALL and value of X in oamSetXYEx as value negative the sprite is changed for OBJ_LARGE while this sprite is negative I quoted here http://www.portabledev.com/smf/index.php?topic=324.0

you can find any solution?
20
hum, strange, will check again when i will have time ...
Really don't know where is the problem at this moment ...
Pages: 1 [2] 3 4 ... 10