Re: Sonic The Hedgehog SCD
Publié : lun. 14 juin 2010 21:27
Merci, ça fait chaud au cœur 
Page 30 sur 43
Re: Sonic The Hedgehog SCD
Publié : lun. 14 juin 2010 22:02
Heureux de te revoir parmis nous
Re: Sonic The Hedgehog SCD
Publié : mar. 15 juin 2010 08:53
Welcome back Xav, en espérant que ces histoires de santé font maintenant partie du passé et pour de bon.
Re: Sonic The Hedgehog SCD
Publié : mar. 15 juin 2010 10:19
Re bienvenue ! 
Re: Sonic The Hedgehog SCD
Publié : mar. 15 juin 2010 11:36
Bon xav, maintenant qu'on t'a fait des papouilles, va pas falloir chaumer 
Re: Sonic The Hedgehog SCD
Publié : mar. 15 juin 2010 12:47
Un peu de calme. Il est encore convalescent
Re: Sonic The Hedgehog SCD
Publié : jeu. 17 juin 2010 05:17
Salut Xav, content de te revoir sur le forum !
J'avoue que, comme tu m'avais glissé que t'avais des ennuis de santé y a 5 mois, et que depuis tu ne donnais plus signe de vie, je commençais sérieusement à songer au pire...
Soulagé.
J'avoue que, comme tu m'avais glissé que t'avais des ennuis de santé y a 5 mois, et que depuis tu ne donnais plus signe de vie, je commençais sérieusement à songer au pire...
Soulagé.
Re: Sonic The Hedgehog SCD
Publié : dim. 20 juin 2010 17:51
j'avais pas vu cet épisode, c'est cool que tu sois revenu, pas parce que ça veut dire que tu es en bonne santé (ça je m'en balance grave) mais qu'on va p'tetre enfin avoir du neuf sous la dent. 
ps: notez qu'il y a un smilaid hein........|^|
ps: notez qu'il y a un smilaid hein........|^|
Re: Sonic The Hedgehog SCD
Publié : dim. 20 juin 2010 19:56
Re: Sonic The Hedgehog SCD
Publié : dim. 20 juin 2010 22:40
Matte mon avatar, il se marre aussij'avais pas vu cet épisode, c'est cool que tu sois revenu, pas parce que ça veut dire que tu es en bonne santé (ça je m'en balance grave) mais qu'on va p'tetre enfin avoir du neuf sous la dent.
Re: Sonic The Hedgehog SCD
Publié : dim. 27 juin 2010 21:12
Ah je me heurte à un petit problème d'algorithmique amusant:
A chaque VBL (donc 60x par seconde) l'intégralité de la liste des entités est parcourus, si l'entité est différente de NULL, ces coordonnées x/y sont vérifiés et si elle est dans la zone active de la map ( zone légèrement supérieure à celle qui est réellement affiché à l'écran) l'entité réquisitionne un sprite hardware libre et apparait à l'écran
Comment optimiser ça?
Plusieurs pistes:
La routine est déjà réécrite en asm, je vois pas comme faire plus
Je pense implémenté un mécanisme de liste chainés pour gérer tous ça.
NB: Il devient urgent pour moi d'écrire carrément un éditeur de map compatible mappy ET seer!
A chaque VBL (donc 60x par seconde) l'intégralité de la liste des entités est parcourus, si l'entité est différente de NULL, ces coordonnées x/y sont vérifiés et si elle est dans la zone active de la map ( zone légèrement supérieure à celle qui est réellement affiché à l'écran) l'entité réquisitionne un sprite hardware libre et apparait à l'écran
Comment optimiser ça?
Plusieurs pistes:
Gros gaspillage, plus la liste est importante plus on perd du tempsl'intégralité de la liste des entités est parcourus
La routine est déjà réécrite en asm, je vois pas comme faire plus
Écrire une routine qui reclasse la liste quand une entité est détruite ou créer de façon à supprimer les entités nulles, éliminant ainsi ce test.si l'entité est différente de NULL, ces coordonnées x/y sont vérifiés
Je pense implémenté un mécanisme de liste chainés pour gérer tous ça.
NB: Il devient urgent pour moi d'écrire carrément un éditeur de map compatible mappy ET seer!
Re: Sonic The Hedgehog SCD
Publié : lun. 28 juin 2010 09:08
Je dirai sauvegarder les sprites de libres à un autre moment ..
Exemple, tu tues un ennemie, tu mets son sprite comme libre ..
ou alors une ou plusieurs valeurs 8 ou 16 bits, dont les bits représentent tes sprites, donc il te faut 64 bits (si 64 sprites dispos possibles).
tu passes tes bits à 1 si sprite dispo, et à 0 si non dispo, cela devrai déjà être plus rapide qu'un tableau ou des déplacements mémoire,c'est ce que je fais avec galaxian , c'est très rapide même en C.
Ton système de liste chainée est une bonne méthode, mais qui implique la création de pseudos structures (ce qui est déjà surement le cas avec ton système d'entités), car huc ne le gère pas .
Et la gestion de tout ça en ASM pour plus d'efficacité.
Pour l'éditeur de map, tu vas en chier de la vaisselle cassée à réinventer la roue.
Au pire écris un convertisseur mappy -> seer ..
En tout cas ça fait plaisir de voir que tu es à nouveau regonflé à bloc
Exemple, tu tues un ennemie, tu mets son sprite comme libre ..
ou alors une ou plusieurs valeurs 8 ou 16 bits, dont les bits représentent tes sprites, donc il te faut 64 bits (si 64 sprites dispos possibles).
tu passes tes bits à 1 si sprite dispo, et à 0 si non dispo, cela devrai déjà être plus rapide qu'un tableau ou des déplacements mémoire,c'est ce que je fais avec galaxian , c'est très rapide même en C.
Ton système de liste chainée est une bonne méthode, mais qui implique la création de pseudos structures (ce qui est déjà surement le cas avec ton système d'entités), car huc ne le gère pas .
Et la gestion de tout ça en ASM pour plus d'efficacité.
Pour l'éditeur de map, tu vas en chier de la vaisselle cassée à réinventer la roue.
Au pire écris un convertisseur mappy -> seer ..
En tout cas ça fait plaisir de voir que tu es à nouveau regonflé à bloc
Re: Sonic The Hedgehog SCD
Publié : lun. 28 juin 2010 10:35
Le plus simple à mon avis serait d'avoir une table contenant les indices des sprites actifs. Dès qu'un sprite devient inactif, il suffit d'échanger l'indice dans la table par le dernier.
Jusque là rien de génial. Mais en faisant ça les éléments allant de spriteIdxTblTop à spriteIdxTblSize contiennent les indices "libres" dans la SATB
Et au démarrage on a : spriteIdxTblTop = 0 et spriteIdxTbl = i .
Code : Tout sélectionner
inactiv_sprite:
dec <spriteIdxTblTop
ldx <spriteIdxTblTop
lda spriteIdxTbl, X
sta spriteIdxTbl, YCode : Tout sélectionner
new_sprite:
ldy <spriteIdxTblTop
inc <spriteIdxTblTop
ldx spriteIdxTbl, Y
lda satbAddrTblLo, X ; On pourrait le calculer à la volée mais bon
sta <_di
lda satbAddrTblHi, X
sta <_di+1
jsr set_satb ; fonction magique
Re: Sonic The Hedgehog SCD
Publié : lun. 28 juin 2010 22:45
Oh j'ai oublier un point important, la liste doit conserver un ordre précis, je m'explique, voila en C le contenue de la liste de l'acte 1 de la Green hill Zone:
const int object[] = {
GEM , 243<<4, 18<<4, 0, 0, 0,0,0,
GEM , 1608, 552-3, 0, 0, 0,0,0,
GEM , 101<<4, 6<<4, 0, 0, 0,0,0,
E_STATIC , 113<<4, 43<<4, 0, 0, (0x5d00-0x5000)>>6, 0x1D, SZ_32x32|NO_FLIP_X|NO_FLIP_Y,
E_STATIC , 123<<4, 41<<4, 0, 0, (0x5d00-0x5000)>>6, 0x1D, SZ_32x32|NO_FLIP_X|NO_FLIP_Y, Ici nous avons les buissons notez qu'ils sont placer AVANT Sonic dans la liste, ils apparaitront donc DEVANT Sonic
PLAYER_EFFECT, 0, 0, 0, 0, 0,0,0,
E_PLAYER, 0, 0, 0, 0, 0,0,0, Ici l'effet de bouclier ou d'invincibilité et le sprite de sonic, vous noterez que l'effet et DEVANT Sonic
MONITOR_SHIELD, 22<<4, 22<<4, 0, 0, 0,0,0,
MONITOR_RING, 168<<4, 43<<4, 0, 0, 0,0,0,
MONITOR_GOD, 127<<4, 41<<4, 0, 0, 0,0,0, Le monitor apparaitra DERRIERE Sonic
MONITOR_CHECK, 70<<4, 11<<4, 0, 0, 0,0,0,
MONITOR_LIFE, 45<<4, 43<<4, 0, 0, 0,0,0,
MONITOR_LIFE, 248<<4, 7<<4, 0, 0, 0,0,0,
MONITOR_RING, 226<<4, 9<<4, 0, 0, 0,0,0,
E_STATIC , 246<<4, 44<<4, 0, 0, (0x7e80-0x5000)>>6, 0x1e, SZ_16x16|NO_FLIP_X|NO_FLIP_Y,
E_STATIC , 8<<4, 41<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16|NO_FLIP_X|NO_FLIP_Y,
E_STATIC , 10<<4, 41<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 87<<4, 14<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 89<<4, 14<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 50<<4, 40<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 52<<4, 40<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 110<<4, 40<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 112<<4, 40<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 137<<4, 13<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 139<<4, 13<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 178<<4, 41<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 180<<4, 41<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 26<<4, 20<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 28<<4, 20<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 228<<4, 36<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 230<<4, 36<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC, 96<<4, 39<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6, 0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC, 104<<4, 39<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6, 0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC, 149<<4, 39<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6, 0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC, 151<<4, 39<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6, 0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC, 151<<4, 29<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6, 0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC, 100<<4, 20<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6,0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
PIRA, 100<<4, 20<<4, 20<<4, 0, 1,0,0,
E_STATIC, 150<<4, 20<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6,0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
PIRA, 2400, 20<<4, 20<<4, 0, 1,0,0,
E_STATIC, 21<<4, 47<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6,0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
PIRA, 336, 47<<4, 47<<4, 0, 1,0,0,
WATER, 213<<4, 46<<4, 0, 0, 0,0,0,
PIRA, 3408, 46<<4, 46<<4, 0, 2,0,0,
WATER, 220<<4, 46<<4, 0, 0, 0,0,0,
PIRA, 3520, 46<<4, 46<<4, 0, 2,0,0,
WATER, 160<<4, 45<<4, 0, 0, 0,0,0,
PIRA, 160<<4, 45<<4, 45<<4, 0, 2,0,0,
MOTORBUG, 800, 688, 928, 640, 0,0,0,
BEE, 1000, 96, 1296, 928, 1,0,0,
BEE, 205<<4, 7<<4, 211<<4, 198<<4, 1,0,0,
MOTORBUG, 2900, 688, 3312, 2704, 1,0,0,
MOTORBUG, 5<<4, 17<<4, 13<<4, 0, 1,0,0,
MOTORBUG, 120<<4, 16<<4, 145<<4, 107<<4, 1,0,0,
0
};
NB: En réalité certaine valeur comme le type ou l'adresse en Vram des entité statique sont sur 8bits pour une question d'optimisation
On a 54 entités et on pourrait en mettre bien plus (128 max), alors que seer ne réserve seulement que 32 sprites hardwares sur les 64 dispos ( le reste c'est pour les sprites auto)...
Mais on s'en fout Tant qu'on ne dépasse pas 32 entités à l'écran seer alloue les 32 dynamiquement à chaque VBL.
Ce n'est donc pas la SAT qui pose problème puisqu'elle est de toute façon rafraichit constamment mais bien le traitement de la liste.
Mooz en lisant ton post je suspecte qu'il doit y avoir un tas de variable caché fort utile
const int object[] = {
GEM , 243<<4, 18<<4, 0, 0, 0,0,0,
GEM , 1608, 552-3, 0, 0, 0,0,0,
GEM , 101<<4, 6<<4, 0, 0, 0,0,0,
E_STATIC , 113<<4, 43<<4, 0, 0, (0x5d00-0x5000)>>6, 0x1D, SZ_32x32|NO_FLIP_X|NO_FLIP_Y,
E_STATIC , 123<<4, 41<<4, 0, 0, (0x5d00-0x5000)>>6, 0x1D, SZ_32x32|NO_FLIP_X|NO_FLIP_Y, Ici nous avons les buissons notez qu'ils sont placer AVANT Sonic dans la liste, ils apparaitront donc DEVANT Sonic
PLAYER_EFFECT, 0, 0, 0, 0, 0,0,0,
E_PLAYER, 0, 0, 0, 0, 0,0,0, Ici l'effet de bouclier ou d'invincibilité et le sprite de sonic, vous noterez que l'effet et DEVANT Sonic
MONITOR_SHIELD, 22<<4, 22<<4, 0, 0, 0,0,0,
MONITOR_RING, 168<<4, 43<<4, 0, 0, 0,0,0,
MONITOR_GOD, 127<<4, 41<<4, 0, 0, 0,0,0, Le monitor apparaitra DERRIERE Sonic
MONITOR_CHECK, 70<<4, 11<<4, 0, 0, 0,0,0,
MONITOR_LIFE, 45<<4, 43<<4, 0, 0, 0,0,0,
MONITOR_LIFE, 248<<4, 7<<4, 0, 0, 0,0,0,
MONITOR_RING, 226<<4, 9<<4, 0, 0, 0,0,0,
E_STATIC , 246<<4, 44<<4, 0, 0, (0x7e80-0x5000)>>6, 0x1e, SZ_16x16|NO_FLIP_X|NO_FLIP_Y,
E_STATIC , 8<<4, 41<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16|NO_FLIP_X|NO_FLIP_Y,
E_STATIC , 10<<4, 41<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 87<<4, 14<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 89<<4, 14<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 50<<4, 40<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 52<<4, 40<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 110<<4, 40<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 112<<4, 40<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 137<<4, 13<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 139<<4, 13<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 178<<4, 41<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 180<<4, 41<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 26<<4, 20<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 28<<4, 20<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC , 228<<4, 36<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC , 230<<4, 36<<4, 0, 0, (VADR_WING-0x5000)>>6, 0x1e, SZ_16x16 | FLIP_X | NO_FLIP_Y,
E_STATIC, 96<<4, 39<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6, 0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC, 104<<4, 39<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6, 0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC, 149<<4, 39<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6, 0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC, 151<<4, 39<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6, 0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC, 151<<4, 29<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6, 0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
E_STATIC, 100<<4, 20<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6,0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
PIRA, 100<<4, 20<<4, 20<<4, 0, 1,0,0,
E_STATIC, 150<<4, 20<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6,0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
PIRA, 2400, 20<<4, 20<<4, 0, 1,0,0,
E_STATIC, 21<<4, 47<<4, 0, 0, (VADR_WATERFALL-0x5000)>>6,0x18, SZ_32x64 | NO_FLIP_X | NO_FLIP_Y,
PIRA, 336, 47<<4, 47<<4, 0, 1,0,0,
WATER, 213<<4, 46<<4, 0, 0, 0,0,0,
PIRA, 3408, 46<<4, 46<<4, 0, 2,0,0,
WATER, 220<<4, 46<<4, 0, 0, 0,0,0,
PIRA, 3520, 46<<4, 46<<4, 0, 2,0,0,
WATER, 160<<4, 45<<4, 0, 0, 0,0,0,
PIRA, 160<<4, 45<<4, 45<<4, 0, 2,0,0,
MOTORBUG, 800, 688, 928, 640, 0,0,0,
BEE, 1000, 96, 1296, 928, 1,0,0,
BEE, 205<<4, 7<<4, 211<<4, 198<<4, 1,0,0,
MOTORBUG, 2900, 688, 3312, 2704, 1,0,0,
MOTORBUG, 5<<4, 17<<4, 13<<4, 0, 1,0,0,
MOTORBUG, 120<<4, 16<<4, 145<<4, 107<<4, 1,0,0,
0
};
NB: En réalité certaine valeur comme le type ou l'adresse en Vram des entité statique sont sur 8bits pour une question d'optimisation
On a 54 entités et on pourrait en mettre bien plus (128 max), alors que seer ne réserve seulement que 32 sprites hardwares sur les 64 dispos ( le reste c'est pour les sprites auto)...
Mais on s'en fout
Tant qu'on ne dépasse pas 32 entités à l'écran seer alloue les 32 dynamiquement à chaque VBL.Ce n'est donc pas la SAT qui pose problème puisqu'elle est de toute façon rafraichit constamment mais bien le traitement de la liste.
Mooz en lisant ton post je suspecte qu'il doit y avoir un tas de variable caché fort utile
Re: Sonic The Hedgehog SCD
Publié : mar. 29 juin 2010 06:23
ça donne faim