Outillage pour développement de jeux sur TO8

Samuel Devulder · **Posté:** 15 Nov 2022, 10:34

Ah ok c'est le bug dont tu parlais. :jap:

Bentoc · **Posté:** 15 Nov 2022, 21:42

hum ... je pense savoir d'où ça vient.

Certains objets ont la capacité de se supprimer eux même lorsqu'ils sont hors camera.
Or cette suppression efface les liens avant/après stockés par les objets.
si l'objet qu'on execute est en milieu de chaine, au retour au code appelant : RunObjects, on regarde l'objet suivant et comme il est à 0000 bah on pense être en bout de liste.
En fait non, on vient juste de supprimer l'objet courant.
Comme les objets suivants ne sont pas executés ils n'apparaissent pas sur la frame en cours.
A la boucle suivante ils réapparaissent car la liste chainée à bien été mise à jour lors de la suppression.

=> il faut donc sauvegarder l'objet suivant AVANT d'appeler le code objet courant.
Je vais essayer ça.

Bentoc · **Posté:** 15 Nov 2022, 23:55

Voila c'était bien ça.
J'ai corrigé le problème et commit.

Il reste un petit clignotement (1 frame) uniquement sur les ponts quand on avance bien et qu'on revient en arrière lorsque l'on remonte sur le pont, il doit y avoir un autre cas (le pont est fait d'un objet principal + 2 sous-objets avec les rondins)

Sur les pics descendant on voit aussi un petit clignotement mais c'est parce que l'objet est grand et qu'il sort partiellement de la zone affichage et donc est masqué automatiquement.
Il faut que je le découpe en sous objets plus petits si je veux éviter ça (comme pour les plateformes mobiles). Je verrai au moment d'implémenter la logique des pics.

Bentoc · **Posté:** 16 Nov 2022, 00:23

Dans le cas des ponts, l'objet principal delete ses enfants et lui même dans le même appel.
Donc la sauvegarde avant exécution du suivant ne fonctionne pas dans le cas ou plusieurs de ces objets (effacés d'un coup) se suivent.
Il faut que je réfléchisse a cette problématique ...

hum si c'est ça qui se produit dans le dernier bug a corriger c'est étrange car il n'y a pas de raison de faire un delete de l'objet à ce moment là (le pont est dans la zone visible).
Je vais vérifier, on a peut être une désallocation/allocation qui s'enchaine ici et que je ne voyait pas avant.
ça avance ;-)

Bentoc · **Posté:** 16 Nov 2022, 07:56

ça y est c'est trouvé (test OK + commit)

Il suffit, au moment de supprimer un objet enfant, de vérifier si cet objet n'est pas le suivant à exécuter.
Si c'est le cas : on met à jour l'objet suivant dans RunObjects avec le suivant stocké dans l'objet à supprimer

exécution d'un objet

Code:

RunObjects
        ldu   object_list_first
        beq   @rts
!       ldb   id,u                     ; Load an object with id=0 allows to book a empty slot
        beq   @skip                    ; that will be usable later, we need to skip in this case (no object index)
        ldx   #Obj_Index_Page
        abx
        lda   ,x              
        _SetCartPageA         
        aslb                  
        ldx   #Obj_Index_Address
        abx
        ldd   run_object_next,u        ; in case of self-deletion by current object
        std   object_list_next         ; we need to save the next object in run list
        jsr   [,x]              
        ldu   #0
object_list_next equ   *-2    
        bne   <         
@rts    rts   
@skip   ldu   run_object_next,u
        bne   <
        rts

suppression d'un objet

Code:

UnloadObject_u
        pshs  d,x,y,u
        cmpu  object_list_next         ; if current object to delete
        bne   >                        ; is the following to execute
        ldy   run_object_next,u
        sty   object_list_next         ; then update the next object in RunObjects routine
        beq   @noNext
!       ldy   run_object_next,u
        beq   @noNext
        ldx   run_object_prev,u
        stx   run_object_prev,y
        beq   @noPrev
        sty   run_object_next,x
        bra   @clearObj
@noPrev sty   object_list_first
        bra   @clearObj
@noNext ldx   run_object_prev,u
        beq   >
        sty   run_object_next,x
!       stx   object_list_last
        bne   @clearObj
        stx   object_list_first
@clearObj
        leau  object_size,u ; move to end of data object structure
UnloadObject_clear
        ldd   #$0000        ; init regs to zero
        ldx   #$0000
        leay  ,x

        fill $36,(object_size/6)*2 ; generate object_size/6 assembly instructions $3636 (pshu  d,x,y) 

        IFEQ object_size%6-5
        pshu  a,x,y
        ENDC

        IFEQ object_size%6-4
        pshu  d,x
        ENDC

        IFEQ object_size%6-3
        pshu  a,x
        ENDC

        IFEQ object_size%6-2
        pshu  d
        ENDC

        IFEQ object_size%6-1
        pshu  a
        ENDC

        puls  d,x,y,u,pc

Ajout d'un objet

Code:

LoadObject_u
        ldu   #Dynamic_Object_RAM
@loop
        tst   ,u
        beq   @link
        leau  next_object,u
        cmpu  #Dynamic_Object_RAM_End
        bne   @loop
        rts                            ; return z=1 when not found
@link
        pshs  x
        ldx   object_list_last
        beq   >
        stu   run_object_next,x
        stu   object_list_last
        stx   run_object_prev,u
        puls  x,pc                     ; return z=0 when found
!       stu   object_list_last
        stu   object_list_first
        puls  x,pc                     ; return z=0 when found

Les routines Load et Unload sont déclinées :
- avec le registre u (utilisé quand on travaille sur l'objet courant)
- avec le registre x (utilisé quand on travaille sur un objet enfant ou parent)
=> ça évite les transferts de registre.

A noter que la valeur de retour (flag zero) est inversée par rapport au code d'origine de Sonic car ça nécessite moins de code si on gère le flag dans ce sens.
les beq et bne sont donc inversés au retour du code d'appel.

Samuel Devulder · **Posté:** 16 Nov 2022, 14:04

Ca marche.. Mais un truc m'interpelle. Si je change un tout petit peu la routine empty_tile de tilemapbuffer.asm, ca compile..

Fichier(s) joint(s):

TilemapBuffer.zip [5.29 Kio]
Téléchargé 244 fois

Mais à l'execution ca plante avant même d'atteindre la portion de code modifié.

Plus précisément la trace montre l'initialization des zones mémoires puis: un JSR ,X nous envoie dans le décors

Code:

6181 CC0000     LDD    #$0000              3      7251847   D=0000 X=DDDD Y=DDDD U=FFB0 S=9F00 DP=9F CC=C5 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
6184 DDEF       STD    <$EF                5      7251852   D=0000 X=DDDD Y=DDDD U=FFB0 S=9F00 DP=9F CC=C5 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
6186 FC9F15     LDD    $9F15               6      7251858   D=02AF X=DDDD Y=DDDD U=FFB0 S=9F00 DP=9F CC=C1 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
6189 B37089     SUBD   $7089               7      7251865   D=025B X=DDDD Y=DDDD U=FFB0 S=9F00 DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
618C DDED       STD    <$ED                5      7251870   D=025B X=DDDD Y=DDDD U=FFB0 S=9F00 DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
618E 8605       LDA    #$05                2      7251872   D=055B X=DDDD Y=DDDD U=FFB0 S=9F00 DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
6190 B778F3     STA    $78F3               5      7251877   D=055B X=DDDD Y=DDDD U=FFB0 S=9F00 DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
6193 B69811     LDA    $9811               5      7251882   D=785B X=DDDD Y=DDDD U=FFB0 S=9F00 DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
6196 B7E7E6     STA    $E7E6               5      7251887   D=785B X=DDDD Y=DDDD U=FFB0 S=9F00 DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
6199 BE9834     LDX    $9834               6      7251893   D=785B X=2B17 Y=DDDD U=FFB0 S=9F00 DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
619C 8600       LDA    #$00                2      7251895   D=005B X=2B17 Y=DDDD U=FFB0 S=9F00 DP=9F CC=C4 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
619E AD84       JSR    ,X                  7      7251902   D=005B X=2B17 Y=DDDD U=FFB0 S=9EFE DP=9F CC=C4 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
2B17 DDDD       STD    <$DD                5      7251907   D=005B X=2B17 Y=DDDD U=FFB0 S=9EFE DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
2B19 DDDD       STD    <$DD                5      7251912   D=005B X=2B17 Y=DDDD U=FFB0 S=9EFE DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
2B1B DDDD       STD    <$DD                5      7251917   D=005B X=2B17 Y=DDDD U=FFB0 S=9EFE DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
2B1D DDDD       STD    <$DD                5      7251922   D=005B X=2B17 Y=DDDD U=FFB0 S=9EFE DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
2B1F DDDD       STD    <$DD                5      7251927   D=005B X=2B17 Y=DDDD U=FFB0 S=9EFE DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
2B21 DDDD       STD    <$DD                5      7251932   D=005B X=2B17 Y=DDDD U=FFB0 S=9EFE DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
2B23 DDDD       STD    <$DD                5      7251937   D=005B X=2B17 Y=DDDD U=FFB0 S=9EFE DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
2B25 DDDD       STD    <$DD                5      7251942   D=005B X=2B17 Y=DDDD U=FFB0 S=9EFE DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
2B27 DDDD       STD    <$DD                5      7251947   D=005B X=2B17 Y=DDDD U=FFB0 S=9EFE DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1
2B29 DDDD       STD    <$DD                5      7251952   D=005B X=2B17 Y=DDDD U=FFB0 S=9EFE DP=9F CC=C0 | Banques: SYST=0 ROM=1 RAM=03 MEMO=0 VIDEO=1

littéralement ! ($DDDD ce sont le décors initialisé en noir, non?)

Ca à l'air de déconner dans LevelSizeLoad.

Code:

6199 BE9834           (     _MountObject):00003 [6]     272             ldx   Obj_Index_Address+2*ObjID_EHZ
619C 8600             (_RunObjectRoutine):00002 [2]     274             lda   #0        
619E AD84             (_RunObjectRoutine):00003 [7]     281             jsr   ,x

Est-ce possible que le grossissement de empty_tile fasse décaler des trucs en mémoire suffisamment pour faire planter l'assemblage des binaires ? (aucune erreur lors de la génération)

[EDIT] j'ai trouvé ! J'avais utilisé un RMB 2 au lieu d'un FDB pour avoir 2 octets de libres. Avec RMB ca plante, avec FDB ca passe. Les binaires à trous (RMB) posent soucis. Il faut remplir les données et pas laisser des trous.

Bentoc · **Posté:** 16 Nov 2022, 14:21

Oui effectivement il ne faut pas les utiliser

Bentoc · **Posté:** 16 Nov 2022, 17:15

Fichier(s) joint(s):

wddebug.gif [ 220.45 Kio | Vu 7647 fois ]

Je vais ouvrir un fil spécial pour ce nouvel outil de debug que je viens de créer, mais je partage ici la première capture :coolfuck:

C'est un outil indépendant qui vient lire les données mémoire d'un processus (ici DCMOTO, mais ça peut fonctionner avec n'importe quel émulateur).

Implémenté en java et DearImGui.

Evidement le test est très basique, mais on peut faire énormément à partir de ce concept. lwasm peut générer un fichier map qui pourrait être pris en entrée de ce debugger par exemple.

Les ihms proposées par DearImGui sont orientées debug donc on a plein de choses disponibles ...

ça fait tellement longtemps que je veux implémenter ça !!! trop content que le principe fonctionne.

C'est un outil d'observation, mais on peut aussi proposer de modifier des valeurs qui sont donc injectées directement dans l'émulateur.
Le processus étant totalement indépendant ça n'impacte pas les performances d'émulation.

Samuel Devulder · **Posté:** 16 Nov 2022, 17:41

Ca veut dire que:
1) on a le droit de lire la mémoire d'un autre processus pas prévu pour ca en java ?
2) la mémoire de DCMoto est facilement lisible: pas de tableaux de tableaux de fonction opaques à utiliser ?
Ca m'intrigue :voyons:

Bentoc · **Posté:** 16 Nov 2022, 17:54

la je suis sous windows et j'utilise des libs natives pour faire ça.

Les données sont visibles et modifiables entre processus (j'ai découvert ça récemment).
Il doit y avoir moyen de bloquer ça, mais dans notre cas c'est plutôt utile.

La RAM est émulée dans DCMOTO par un ou des tableaux.
Daniel nous le dira certainement.

J'ai fait ça rapidement donc je n'ai pas encore établi les adresses pour les pages de données, pour le moment j'ai juste trouvé où était la zone 0x6000-0x9FFF pour faire un test vite fait.

Je mettrai le code à dispo dès que j'aurai une version propre, mais c'est très simple à mettre en oeuvre.

Imagine ça : je vais pouvoir afficher la liste des mes objets instanciés, les données de chaque objet ... ça va révolutionner ma manière de travailler

J'envisage aussi d'afficher le buffer vidéo de travail (celui qui est masqué en double buffering) ... ce ne sont pas les idées qui manquent !!!

Samuel Devulder · **Posté:** 16 Nov 2022, 18:03

Fascinant ! :sol:

Daniel Coulom · **Posté:** 16 Nov 2022, 18:13

Dans dcmoto la RAM est émulée par un tableau. La RAM vidéo, la RAM non commutable et les banques mémoire sont définies par des pointeurs vers cet unique tableau.

Code:

// memory
char ram[0x80000];    //ram (maxi 512K pour TO9+)
char port[0x40];      //ports d'entrees/sorties
char ddr[0x40];       //registres de direction des PIA 6821
char pline[0x40];     //peripheral input-control lines des PIA 6821
char car[0x20000];    //espace cartouche 8x16K (pour OS-9)
char x7da[0x20];      //stockage de la palette de couleurs

Bentoc · **Posté:** 16 Nov 2022, 18:32

C’est parfait ! Merci Daniel

Bentoc · **Posté:** 16 Nov 2022, 23:30

et voila le nouveau fil dédié :

http://www.logicielsmoto.com/phpBB/viewtopic.php?f=2&p=8118#p8118

Samuel Devulder · **Posté:** 17 Nov 2022, 10:35

Micro optim de empty_tile: Je me suis rendu compte qu'on pouvait économiser un saut.

Fichier(s) joint(s):

image_2022-11-17_134002188.png [ 131.75 Kio | Vu 7617 fois ]

Avec cela les boucles empty_tile passent de 3.07% (position 9) de temps des hotspots à 2.11% (position 11).

C'est toujours ca de gagné.

Logicielsmoto.com

Outillage pour développement de jeux sur TO8

Qui est en ligne