Re: Sgdk - Sega Megadrive / Genesis Development Kit

par Invité Mer 3 Déc 2014 - 21:25

C'est surtout pratique pour les calculs de score dans les jeux, bcp plus rapide que les méthodes software .

par Stef Mer 3 Déc 2014 - 21:58

Oui c'est sur mais franchement c'est la *seule* utilité de cette instruction pour un jeu Wink

Et c'est pas le calcul du score qui va te mettre dans la mouise niveau cycle machine :p
Pour un micro ordinateur l'instruction avait au départ une réelle utilité mais dés que les CPU sont devenus un peu plus puissants c'était terminé.

par r_songo Mer 3 Déc 2014 - 22:33

Stef, c'est combien la taille max de la rom géré par sgdk ?

par Stef Jeu 4 Déc 2014 - 1:32

Tu peux compiler jusqu'à 10 Mo sans bank mais ça ne fonctionnera que sur le Mega Everdrive et sans le MegaCD ni le 32X. Sinon c'est 4Mo sans banking (avec banking tu n'as pas vraiment de limite).

par r_songo Jeu 4 Déc 2014 - 8:28

Oula, il va falloir que je revois les musique alors. Car sinon ca va être limite.
J'en suis déja à 1.3Mo avec juste la musique pour le monde 1.

par Invité Jeu 4 Déc 2014 - 9:46

Stef a écrit:Oui c'est sur mais franchement c'est la *seule* utilité de cette instruction pour un jeu Et c'est pas le calcul du score qui va te mettre dans la mouise niveau cycle machine :p
Pour un micro ordinateur l'instruction avait au départ une réelle utilité mais dés que les CPU sont devenus un peu plus puissants c'était terminé.

Effectivement à part ce cas là, j'ai pas encore trouvé une utilité pratique, mais pour le coup ça simplifie grandement les calculs car tu n'as pas à faire de conversion BCD à la mano .

Code:: sed ; // Active le mode décimal lda <val_temp1 clc adc _score ; // Unites & dixaines sta _score lda <val_temp1 + 1 adc _score + 1 ; // Centaine & milliers sta _score + 1 cla adc _score + 2 ; // 10 aine de millier & 100 aine de millier sta _score + 2 cla adc _score + 3 ; // million & 10 aine de millions sta _score + 3 cld

par Stef Jeu 4 Déc 2014 - 10:10

r_songo a écrit:Oula, il va falloir que je revois les musique alors. Car sinon ca va être limite.
J'en suis déja à 1.3Mo avec juste la musique pour le monde 1.

Tu passes par le driver ADPCM ?
Sinon oui la musique full PCM c'est la cata pour ça...
Tu peux essayer de découper ta musique en plusieurs parties :
- intro
- main (avec loop éventuellement)
- ending
de cette manière tu peux réduire pas mal la taille de la musique par contre c'est pas forcément évident de bien découper la musique (surtout qu'il faut aligner la taille des samples sur 256).

par r_songo Jeu 4 Déc 2014 - 10:17

Stef a écrit:Tu passes par le driver ADPCM ?
Sinon oui la musique full PCM c'est la cata pour ça...
Tu peux essayer de découper ta musique en plusieurs :
- intro
- main (avec loop éventuellement)
- ending
de cette manière tu peux réduire pas mal la taille de la musique par contre c'est pas forcément évident de bien découper la musique (surtout qu'il faut aligner la taille des samples sur 256).

Oui je passe pas le driver ADCPM.
Pour la musique du monde 1, je pense pouvoir gagner 200 Ko sur la taille de la ROM. J'avais déjà fait un test de découpe.

J'ai déjà la musique dans le jeu, alors que j'ai pas encore finit de porter mon moteur physique. C'est déprimant lol.

par Stef Jeu 4 Déc 2014 - 12:47

Haha d'habitude c'est plutot l'inverse en effet, le gameplay / moteur avant et la musique en dernier Wink

par r_songo Jeu 4 Déc 2014 - 13:26

Oui, je sais. Mais bon c'est rare avant de commencer un jeu d'avoir déjà les sons et graphismes.

par **philip** Jeu 4 Déc 2014 - 15:08

TOUKO a écrit:
Stef a écrit:Oui c'est sur mais franchement c'est la *seule* utilité de cette instruction pour un jeu Et c'est pas le calcul du score qui va te mettre dans la mouise niveau cycle machine :p
Pour un micro ordinateur l'instruction avait au départ une réelle utilité mais dés que les CPU sont devenus un peu plus puissants c'était terminé.
Effectivement à part ce cas là, j'ai pas encore trouvé une utilité pratique, mais pour le coup ça simplifie grandement les calculs car tu n'as pas à faire de conversion BCD à la mano .

Code:
sed ; // Active le mode décimal lda <val_temp1 clc adc _score ; // Unites & dixaines sta _score lda <val_temp1 + 1 adc _score + 1 ; // Centaine & milliers sta _score + 1 cla adc _score + 2 ; // 10 aine de millier & 100 aine de millier sta _score + 2 cla adc _score + 3 ; // million & 10 aine de millions sta _score + 3 cld

Un volontaire pour transformer ce code, en asm 68000 pour SGDK ?

par Invité Jeu 4 Déc 2014 - 16:50

Pour résumer ça ajoute un chiffre 0 -> 9999 ( val_temp1 (16 bits) mais on résonne en décimal ) au score, ça prend ici 60 cycles car c'est une fonction générique,mais ça peut facilement être plus rapide .

par Stef Jeu 4 Déc 2014 - 17:02

philip a écrit:
TOUKO a écrit:
Stef a écrit:Oui c'est sur mais franchement c'est la *seule* utilité de cette instruction pour un jeu Et c'est pas le calcul du score qui va te mettre dans la mouise niveau cycle machine :p
Pour un micro ordinateur l'instruction avait au départ une réelle utilité mais dés que les CPU sont devenus un peu plus puissants c'était terminé.
Effectivement à part ce cas là, j'ai pas encore trouvé une utilité pratique, mais pour le coup ça simplifie grandement les calculs car tu n'as pas à faire de conversion BCD à la mano .

Code:
sed ; // Active le mode décimal lda <val_temp1 clc adc _score ; // Unites & dixaines sta _score lda <val_temp1 + 1 adc _score + 1 ; // Centaine & milliers sta _score + 1 cla adc _score + 2 ; // 10 aine de millier & 100 aine de millier sta _score + 2 cla adc _score + 3 ; // million & 10 aine de millions sta _score + 3 cld
Un volontaire pour transformer ce code, en asm 68000 pour SGDK ?

Tu en as réellement besoin ? ou pour le fun de la comparaison ?
Car il existe déjà une méthode pour transformer un nombre en chaine de caractère dans SGDK (c'est un peu la même logique) : intToStr(..) ou uintToStr(..)
J'ai utilisé la méthode bourrin (division et modulo par 10) mais je pourrais la réécrire avec un peu d'asm pour effectivement tirer partie du BCD.

par **philip** Jeu 4 Déc 2014 - 17:35

Je rafraîchi le score une fois sur cinq car elle semble gourmande:
unite = score ℅ 10
dizaine = score / 10 ℅ 10
centaine = score / 100 % 10
millier = score / 1000 ℅ 10

Après quoi je fais la modification en vram pour ces quatre éléments, chacune de 0 à 9, et j'obtiens ainsi un sprite d'une taille de 32x8 pixels indiquant le score.

par Stef Jeu 4 Déc 2014 - 17:58

philip a écrit:Je rafraîchi le score une fois sur cinq car elle semble gourmande:
unite = score ℅ 10
dizaine = score / 10 ℅ 10
centaine = score / 100 % 10
millier = score / 1000 ℅ 10

Après quoi je fais la modification en vram pour ces quatre éléments, chacune de 0 à 9, et j'obtiens ainsi un sprite d'une taille de 32x8 pixels indiquant le score.

C'est vrai qu'il y a 7 divisions mais si tu utilises des valeurs 16 bits ça devrait pas être la mort.
La modif de la VRAM doit être limite plus gourmand je pense.
Un truc important, fait la mise à jour du score à la fin de ton code vblank (pour ne pas bouffer inutilement sur la bande passante VRAM).

par Invité Jeu 4 Déc 2014 - 18:02

La modif de la VRAM doit être limite plus gourmand je pense.

Bien sur, car il faut ensuite traduire le score en tile pour chaque chiffre ..

Effectivement à part ce cas là, j'ai pas encore trouvé une utilité pratique,

Ca peut aussi servir pour un timer Very Happy

Version optimisée 6280 (34 cycles)

Code:: sed clc ldx #LOW(score) set adc <val_temp1 ; // Unites & dixaines dans <score inx set adc <val_temp1 + 1 ; // Centaine & milliers dans <score+1 inx set adc #00 ; // 10 aine de millier & 100 aine de millier dans <score+3 inx set adc #00 ; // million & 10 aine de millions dans <score+3 cld

C'est pour ça que vous devriez essayer l'ASM avec sgdk le plus vite possible Wink

par vingazole Jeu 4 Déc 2014 - 18:43

J'ai été écoeuré à vie du BCD à cause du 8088 : tu as 4 opcodes pour le BCD non compacté selon l'opération que tu viens de faire (AAA - addition, AAS - soustraction, AAM - multiplication, AAD - division) et 2 autres pour le BCD compacté (DAA et DAS, respectivement pour l'addition et la soustraction).

source : http://fr.wikipedia.org/wiki/Jeu_d'instructions_x86#Instructions_originales_des_8086.2F8088 (je n'ai pas ressorti ça de mémoire, je vous rassure^^).

J'imagine que ça devait servir pour des applications de type "compta", comme l'infâme langage COBOL Wink

par Invité Jeu 4 Déc 2014 - 18:58

Déjà rien le nom BCD compacté te donne mal à la tête MDR

Il me semble que les 80XXX d'intel, n'était pas réputés pour être sympas à programmer en ASM ..

par vingazole Jeu 4 Déc 2014 - 19:27

L'ASM du 8086/8088 lui-même est assez "intuitif" (modes d'adressage variés et relative orthogonalité du jeu d'instruction, instructions pour la multiplication et la division, opérations "par blocs", opcode pour accéder à une LUT, etc...).

Ce qui était terrible c'était les accès à la mémoire : les concepteurs avaient imaginé des registres de segments pour "résoudre" le problème des adresses de plus de 16 bits (quand tu faisais un JUMP c'était associé au registre de segment de code - CS, quand tu faisais un PUSH ou un POP ça référençait le registre de segment de pile - SS, etc...).

Là où le truc était pervers, c'est que l'adresse effective était calculée par REGISTRE_DE_SEGMENT * 16 + OFFSET (avec REGISTRE_DE_SEGMENT et OFFSET codés sur 16 bits), limitant d'une part l'étendue des adresses à 1 Mo (alors qu'il semblerait plus logique de faire REGISTRE_DE_SEGMENT * 65536 + OFFSET et d'accéder du coup à un plus grand nombre d'adresses différentes), mais surtout que chaque adresse réelle pouvait être représentée par différentes combinaisons SEGMENT/OFFSET, je ne te raconte pas la difficulté pour le reverse engineering a mort les micros

par Invité Jeu 4 Déc 2014 - 19:33

Je m'en doute Mr. Green

Finalement avec nos CPU, on a pas été si mal lotie après tout amoureux

par vingazole Jeu 4 Déc 2014 - 19:38

C'est qu'on les aime, nos mille pa-pattes amoureux

par **philip** Ven 5 Déc 2014 - 18:55

Stef a écrit:
philip a écrit:Je rafraîchi le score une fois sur cinq car elle semble gourmande:
unite = score ℅ 10
dizaine = score / 10 ℅ 10
centaine = score / 100 % 10
millier = score / 1000 ℅ 10

Après quoi je fais la modification en vram pour ces quatre éléments, chacune de 0 à 9, et j'obtiens ainsi un sprite d'une taille de 32x8 pixels indiquant le score.

C'est vrai qu'il y a 7 divisions mais si tu utilises des valeurs 16 bits ça devrait pas être la mort.
La modif de la VRAM doit être limite plus gourmand je pense.
Un truc important, fait la mise à jour du score à la fin de ton code vblank (pour ne pas bouffer inutilement sur la bande passante VRAM).

où se situe la fin du code vblank ? Juste avant VDP_waitVSync(); (ou il faut une autre commande) ?

par Invité Ven 5 Déc 2014 - 19:04

philip a écrit:Je rafraîchi le score une fois sur cinq car elle semble gourmande:
unite = score ℅ 10
dizaine = score / 10 ℅ 10
centaine = score / 100 % 10
millier = score / 1000 ℅ 10

Après quoi je fais la modification en vram pour ces quatre éléments, chacune de 0 à 9, et j'obtiens ainsi un sprite d'une taille de 32x8 pixels indiquant le score.

D'où l'intérêt du mode BCD, en plus d'être bcp plus rapide, le code en est simplifié ..
J'ai été confronté au même soucis que toi la première foi, CAD un code complexe à cause de toutes les divisions, et assez lent .

Pk tu n'essais pas de le faire en ASM 68k avec sgdk pour tester ???

par **philip** Ven 5 Déc 2014 - 19:30

TOUKO a écrit:
philip a écrit:Je rafraîchi le score une fois sur cinq car elle semble gourmande:
unite = score ℅ 10
dizaine = score / 10 ℅ 10
centaine = score / 100 % 10
millier = score / 1000 ℅ 10

Après quoi je fais la modification en vram pour ces quatre éléments, chacune de 0 à 9, et j'obtiens ainsi un sprite d'une taille de 32x8 pixels indiquant le score.

D'où l'intérêt du mode BCD, en plus d'être bcp plus rapide, le code en est simplifié ..
J'ai été confronté au même soucis que toi la première foi, CAD un code complexe à cause de toutes les divisions, et assez lent .

Pk tu n'essais pas de le faire en ASM 68k avec sgdk pour tester ???

je n'ai ni le temps, ni le talent malheureusement. Déjà je pense qu'il faudrait commencer par une simple incrementation d'une variable, c'est ce que j'avais réussis à faire sur la console Lynx, c'était en 2010 si ma mémoire ne me joue pas des tours...

par Invité Ven 5 Déc 2014 - 19:38

Déjà je pense qu'il faudrait commencer par une simple incrementation d'une variable, c'est ce que j'avais réussis à faire sur la console Lynx, c'était en 2010 si ma mémoire ne me joue pas des tours...

Oui pk pas,ou tu peux faire une petite fonction très simple en C, et essayer de la traduire en ASM ..

Bon après le temps n'est pas extensible hélas Wink

par **philip** Ven 5 Déc 2014 - 23:40

En parcourant ce blog, j'apprend que le 68010 est 20% plus rapide qu'une 68000 à même fréquence ! Et donc à seulement 10MHz, les jeux qui le tolère sont très fluide :

http://www.gamekult.com/blog/totoonthemoon/?blogcategoryid=9406

Une question technique me vient alors à l'esprit : est ce que SGDK est compatible avec le 68010 ?

Up:
Et une question sur l'integration asm dans SGDK, je déclare la variable kiwi après int main( ):

u16 testasm1;

// variable asm :
asm(
"kiwi: dc.w 4"
);

Puis plus loin dans la boucle principale, je teste une addition:

asm(
" add.w #2,kiwi"
);

Il n'y a pas de message d'erreur, donc je suppose que cela fonctionne. Mais si je veux récupérer la valeur de kiwi dans testasm1 en faisant testasm1 = kiwi; alors il y a un message d'erreur ('kiwi' undeclared (first use in this function).

par Stef Sam 6 Déc 2014 - 22:32

Tiens bizarre j'ai loupé les derniers messages...

où se situe la fin du code vblank ? Juste avant VDP_waitVSync(); (ou il faut une autre commande) ?

Tu as surement une méthode sur l'interruption vertical pour mettre à jour tes données dans le VDP ?
Si c'est le la fin du blank c'est la fin de cette méthode (en gros).
Si tu n'as pas de méthode attachée à l'interruption verticale, alors la fin du blank je dirais que c'est avant ton VDP_waitVsync().

Sinon pour ta variable en assembleur, je pense que déclarer une variable dans le scope asm déjà c'est pas super ^^ (à mon avis elle reste locale).Tu devrais plutot la déclarer dans le scope C qui englobe et ensuite y accéder en asm.
Et aussi mixer du C et de l'asm, même si c'est supporté il vaut mieux en limiter l'utilisation car ça gène le compilateur C pour les optimisations.
Après si c'est vraiment pour mettre 3/4 instructions assembleur ok, sinon essai plutot de mettre ton code assembleur dans un fichier .s à part.
Tu peux regarder dans SGDK comment c'est fait (tu as plusieurs fichiers .s dans le répertoire src).

Sinon juste pour montrer qu'en C on peut faire déjà de belles choses, y'a djcc qui a releasé tout ces projet en cours et le dernier (un shoot horizontal) est vraiment pas mal fichu quand tu penses que c'est codé 100% en C :
http://gendev.spritesmind.net/forum/viewtopic.php?p=25264

par r_songo Sam 6 Déc 2014 - 22:45

Sympa toutes les demos

par **philip** Sam 6 Déc 2014 - 23:59

Stef a écrit:Tiens bizarre j'ai loupé les derniers messages...

où se situe la fin du code vblank ? Juste avant VDP_waitVSync(); (ou il faut une autre commande) ?

Tu as surement une méthode sur l'interruption vertical pour mettre à jour tes données dans le VDP ?
Si c'est le la fin du blank c'est la fin de cette méthode (en gros).
Si tu n'as pas de méthode attachée à l'interruption verticale, alors la fin du blank je dirais que c'est avant ton VDP_waitVsync().

..
Heu, non, je n'ai aucune méthode, et je met tout avant VDP_waitVsync(). L'interruption verticale est utile pour faire 5 défilements, avec un seul scroll, comme avec le jeu pinguoinbleu de djcc ? C'est très fort en tout cas.

Stef a écrit:Tiens bizarre j'ai loupé les derniers messages...

Sinon pour ta variable en assembleur, je pense que déclarer une variable dans le scope asm déjà c'est pas super ^^ (à mon avis elle reste locale).Tu devrais plutot la déclarer dans le scope C qui englobe et ensuite y accéder en asm.

Je suis content, je sais coder en asm sur MD !!! Wink

Alors, je déclare la variable qui englobe avant int main :
u16 kiwi;
int main( )
{

puis dans la boucle principale:
    if (lcha == 0) // test programmeur.
        {
        if (value & BUTTON_A) // test programmeur.
            {
            lcha=1;

asm(
"       add.w    #2,kiwi"
);
            }
        }

puis j'affiche le résultat :
    gsblip+=1; // economie ressource machine --> certaines des conditions n'ont pas besoin d'être lu à chaque boucle.
    if (gsblip>5)
        {
        gsblip=0;

        dbtest = kiwi;

        unite = dbtest % 10;            //unité
        dizaine = dbtest / 10 % 10;     // dizaine
        centaine = dbtest / 100 % 10;   // centaine
        millier = dbtest / 1000 % 10;   //millier

Sgdk - Sega Megadrive / Genesis Development Kit - Page 5 VjD0

Sgdk - Sega Megadrive / Genesis Development Kit - Page 5 VjD0

par Stef Dim 7 Déc 2014 - 0:14

Non l'interruption verticale n'a pas vraiment de rapport avec ça Wink

Sinon félicitation pour ta première ligne d'assembleur :p
Bon après pas sur qu'elle serve à grand chose dans le cas présent mais elle a le mérite de fonctionner :p

par **philip** Lun 8 Déc 2014 - 18:40

Stef a écrit:Non l'interruption verticale n'a pas vraiment de rapport avec ça
Sinon félicitation pour ta première ligne d'assembleur :p
Bon après pas sur qu'elle serve à grand chose dans le cas présent mais elle a le mérite de fonctionner :p

Oui, en fait c'est juste pour le fun. Wink