Ah ok c'est le bug dont tu parlais.
| Logicielsmoto.com http://www.logicielsmoto.com/phpBB/ |
|
| Outillage pour développement de jeux sur TO8 http://www.logicielsmoto.com/phpBB/viewtopic.php?f=3&t=620 |
Page 38 sur 40 |
| Auteur: | Samuel Devulder [ 15 Nov 2022, 10:34 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Ah ok c'est le bug dont tu parlais.
|
|
| Auteur: | Bentoc [ 15 Nov 2022, 21:42 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
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. |
|
| Auteur: | Bentoc [ 15 Nov 2022, 23:55 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
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. |
|
| Auteur: | Bentoc [ 16 Nov 2022, 00:23 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
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 ;-) |
|
| Auteur: | Bentoc [ 16 Nov 2022, 07:56 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
ç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. |
|
| Auteur: | Samuel Devulder [ 16 Nov 2022, 14:04 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
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): 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 littéralement ! ($DDDD ce sont le décors initialisé en noir, non?)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 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. |
|
| Auteur: | Bentoc [ 16 Nov 2022, 14:21 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Oui effectivement il ne faut pas les utiliser |
|
| Auteur: | Bentoc [ 16 Nov 2022, 17:15 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Fichier(s) joint(s): wddebug.gif [ 220.45 Kio | Vu 5318 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  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. |
|
| Auteur: | Samuel Devulder [ 16 Nov 2022, 17:41 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
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 
|
|
| Auteur: | Bentoc [ 16 Nov 2022, 17:54 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
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 !!! |
|
| Auteur: | Samuel Devulder [ 16 Nov 2022, 18:03 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Fascinant ! 
|
|
| Auteur: | Daniel Coulom [ 16 Nov 2022, 18:13 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
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 |
|
| Auteur: | Bentoc [ 16 Nov 2022, 18:32 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
C’est parfait ! Merci Daniel |
|
| Auteur: | Bentoc [ 16 Nov 2022, 23:30 ] |
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
et voila le nouveau fil dédié : http://www.logicielsmoto.com/phpBB/viewtopic.php?f=2&p=8118#p8118 |
|
| Auteur: | Samuel Devulder [ 17 Nov 2022, 10:35 ] | ||
| Sujet du message: | Re: Outillage pour développement de jeux sur TO8 | ||
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 5288 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é.
|
|||
| Page 38 sur 40 | Heures au format UTC + 1 heure |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|
