[Xav] Sonic the Hedgehog

[xav]

Merci, ça fait chaud au cœur

[slugman]

Heureux de te revoir parmis nous

[El magnifico]

Welcome back Xav, en espérant que ces histoires de santé font maintenant partie du passé et pour de bon.

[clio]

Re bienvenue !

[touko]

Bon xav, maintenant qu'on t'a fait des papouilles, va pas falloir chaumer

[MooZ]

Un peu de calme. Il est encore convalescent

[Laucops]

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é.

[dudule]

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........|^|

[touko]

[xav]

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.

Matte mon avatar, il se marre aussi

[xav]

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:

l'intégralité de la liste des entités est parcourus

Gros gaspillage, plus la liste est importante plus on perd du temps
La routine est déjà réécrite en asm, je vois pas comme faire plus

si l'entité est différente de NULL, ces coordonnées x/y sont vérifiés

É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.
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!

[touko]

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

[MooZ]

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.

Code : Tout sélectionner

inactiv_sprite:
    dec    <spriteIdxTblTop
    ldx    <spriteIdxTblTop
    lda    spriteIdxTbl, X
    sta    spriteIdxTbl, Y

Jusque là rien de génial. Mais en faisant ça les éléments allant de spriteIdxTblTop à spriteIdxTblSize contiennent les indices "libres" dans la SATB

Code : 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

Et au démarrage on a : spriteIdxTblTop = 0 et spriteIdxTbl = i .

[xav]

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

[dudule]

ça donne faim