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 26 sur 40 |
Auteur: | Samuel Devulder [ 23 Avr 2022, 23:01 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Note: il y a un truc que je pige pas avec le PULS final. On dépile dans l'ordre D puis X puis U. Or la dernière valeur empilée est U (au début de DBT_cloop). Donc D se récupère la valeur d'entrée de U, et X et U eux-mêmes ne se récupèrent rien de bon. Le code est-il bon ? Par ailleurs dans la boucle de DrawHighPriorityBufferedTile on rencontre deux b<cc> à chaque tour (beq et bra = 6 cycles). Code: DrawHighPriorityBufferedTile Or on peut faire ca avec un seul b<cc> par tour (donc 3 cycles seulement):ldy #tmb_hprio_tiles @loop ldb ,y+ stb $E7E6 beq @exit ldx ,y++ ldu ,y++ stu <glb_screen_location_1 ldu ,y++ jsr ,x bra @loop @exit rts Code: DrawHighPriorityBufferedTile ldy #tmb_hprio_tiles bra @entry ; déplacé hors de la @loop @loop ldu 3,y stu <glb_screen_location_1 ldu 5,y leay 7,y jsr [-6,y] ; on a pas besoin de X et on gagne 2 cycle en virant ldx 1,y (-6,y après le LEA revient à 1,y) @entry ldb ,y stb $E7E6 bne @loop rts Tu aussi pourrais tirer les data via le mécanisme de pile en échangeant le role de Y et U mais ca fait pas mal changer le code, donc le coup des offset constants me semble le meilleurs compromis pour le moment. |
Auteur: | Bentoc [ 24 Avr 2022, 06:02 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Voila le séquencement : -------------------------- avant la boucle : on fait deux pshs d ; (loc2 et loc1) début de boucle : pshs u ; (ptr sur buffer) après appel au sprite compilé : puls d,x,u ; on récupère le ptr buffer dans d, loc1 dans x et loc2 dans u on calcule la nouvelle pos des deux locs (colonne suivante) et on les repousse dans la stack : pshs x,u on fait les calculs sur le ptr de buffer avec d, qu'on tfr dans u tfr d,u On reboucle ... ... ou on passe au dernier tile dans la colonne : pshs u ; (ptr sur buffer) après appel au sprite compilé : puls d,x,u ; on récupère le ptr buffer dans d, loc1 dans x et loc2 dans u on calcule la nouvelle pos des deux locs (changement de ligne) et on les repousse dans la stack : pshs x,u on fait les calculs sur le ptr de buffer avec d (ligne suivante) , qu'on tfr dans u tfr d,u On reboucle ... ... ou on sort car plus de ligne (fin) à ce moment là on dépile x et u dont on n'aura plus besoin, pour que le rts utilise la valeur du pc sauvegardée. On pourrait très bien avancer S de 4, ce qui serait plus économe ... car on se fiche bien du contenu de x et u en sortie (les routines sont indépendantes les unes des autres). J'aurai du repousser le code en entier que voici : Code: DrawBufferedTile lda glb_force_sprite_refresh bne @a rts @a ; compute number of tiles to render ; saves one tile row or col when camera pos is a multiple of tile size ; --------------------------------------------------------------------- ldb #tmb_vp_h_tiles-1 ; nb of tile in screen width lda <glb_camera_x_pos+1 anda #%00000111 bne @skip decb @skip stb DBT_ccpt stb DBT_ccpt_bck ldb #tmb_vp_v_tiles ; nb of tile in screen height lda <glb_camera_y_pos+1 anda #%00001111 bne @skip decb @skip stb DBT_lcpt ; compute top left tile position on screen ; position is rounder to 2 px horizontally beacuse of 2px per byte ; and vertically beacuse of interlacing ; --------------------------------------------------------------------- lda <glb_camera_x_pos+1 anda #%00000110 ; mask for 8px tile in width nega adda #12 ; on screen position of camera ldb <glb_camera_y_pos+1 andb #%00001110 ; mask for 16px tile in height negb addb #20 ; on screen position of camera lsra ; x=x/2, sprites moves by 2 pixels on x axis lsra ; x=x/2, RAMA RAMB interlace bcs @RAM2First ; Branch if write must begin in RAM2 first @RAM1First sta @dyn1 lda #40 ; 40 bytes per line in RAMA or RAMB mul addd #$C000 ; (dynamic) @dyn1 equ *-1 std <glb_screen_location_2 pshs d std s_loc2 suba #$20 std <glb_screen_location_1 bra @end @RAM2First sta @dyn2 lda #40 ; 40 bytes per line in RAMA or RAMB mul addd #$A000 ; (dynamic) @dyn2 equ *-1 std <glb_screen_location_2 pshs d std s_loc2 addd #$2001 std <glb_screen_location_1 @end pshs d std s_loc1 ; compute position in cycling buffer ; --------------------------------------------------------------------- ldb <glb_camera_x_pos+1 ; col mask (0-32) andb #%11111000 ; tile width 8px (>>3) lsrb ; col size 4 bytes (<<2) stb @dyn2 ldb <glb_camera_y_pos+1 anda #%00000000 andb #%11110000 ; line mask (0-16) _lsld ; tile height 16px (>>4) _lsld ; line skip 128 bytes (<<7) _lsld addd #0 ; (dynamic) add x position to index @dyn2 equ *-1 addd #tile_buffer tfr d,u ldy #tmb_hprio_tiles ; high priority tiles queue ; ************************************** ; * Tile rendering Loop ; ************************************** DBT_lloop std ls_pos andb #%10000000 std l_pos ; tiles in col ; **************** DBT_cloop pulu d,x pshs u stb $E7E6 beq @skip tsta bpl @low stb ,y+ stx ,y++ ldx <glb_screen_location_1 stx ,y++ ldx <glb_screen_location_2 stx ,y++ bra @skip @low ldu <glb_screen_location_2 jsr ,x @skip puls d,x,u leau 2,u stu <glb_screen_location_2 leax 2,x stx <glb_screen_location_1 pshs x,u anda #%00000000 andb #%01111100 ; cycle thru this line (0-127) by 4 bytes addd #0 l_pos equ *-2 tfr d,u dec DBT_ccpt bne DBT_cloop lda #0 DBT_ccpt_bck equ *-1 sta DBT_ccpt ; last tile in col ; **************** pulu d,x pshs u stb $E7E6 beq @skip ldu <glb_screen_location_2 jsr ,x @skip puls d,x,u ; next line ; **************** ldu #0 s_loc2 equ *-2 leau 40*16,u stu <glb_screen_location_2 stu s_loc2 ldx #0 s_loc1 equ *-2 leax 40*16,x stx <glb_screen_location_1 stx s_loc1 pshs x,u ldd #0 ls_pos equ *-2 ; line start pos addd #128 anda #%00000111 adda #tile_buffer/256 ; add base address tfr d,u dec DBT_lcpt bne DBT_lloop @rts puls x,u lda #0 sta ,y ; end marker for high priority tiles rts DBT_lcpt fcb 0 DBT_ccpt fcb 0 tmb_hprio_tiles fill 0,tmb_vp_h_tiles*tmb_vp_v_tiles*7 ; all tiles in high priority ... that's crazy fcb 0 ; end marker align 2048 tile_buffer fill 0,16*128 Pour l'autre routine, oui c'est une piste d'utiliser U avec la pile, mais je l'utilise déjà comme paramètre pour le sprite compilé ... donc trop de changement pour l'instant (et impact de perf peut etre ailleurs si je change le registre). Merci pour les dernières remarques. |
Auteur: | Bentoc [ 24 Avr 2022, 06:14 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Autre truc dans DrawHighPriorityBufferedTile Il faudrait que je sauvegarde le y avant l'appel au sprite compilé (jsr ,x) et que je restaure la valeur après ... je ne sauvegarde pas tous les registres à l'appel au sprite compilé (gain de perf). La sauvegarde est à la discrétion de l'appelant qui sait ce qu'il a besoin de conserver. Là ça fonctionne car Y est appelé en dernier recours dans les sprites compilés (sur des grandes longueurs de pixels contigus), mais je joue avec le feu, il faut que je corrige ça ;-) ex de sprite compilé pour un tile : Code: DRAW_Tls_EHZ_301
LEAU 441,U LDD #$5555 STD 119,U STD 39,U STD -41,U STD -121,U LEAU -320,U STD 119,U STD 39,U STD -41,U LDD #$4444 STD -121,U LDU <glb_screen_location_1 LEAU 441,U LDD #$5555 STD 119,U STD 39,U STD -41,U STD -121,U LEAU -320,U STD 119,U STD 39,U STD -41,U LDD #$4444 STD -121,U RTS |
Auteur: | Samuel Devulder [ 24 Avr 2022, 07:55 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Citation: à ce moment là on dépile x et u dont on n'aura plus besoin, pour que le rts utilise la valeur du pc sauvegardée. On pourrait très bien avancer S de 4, ce qui serait plus économe ... car on se fiche bien du contenu de x et u en sortie (les routines sont indépendantes les unes des autres). Ouais carrément. LEAS c'est 5 cycles, alors que PULS X,U c'est 9 cycles, près du double. |
Auteur: | Bentoc [ 30 Avr 2022, 13:26 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Hello, Petit update : https://youtu.be/Ds3HkIOO0YU - Suite au retrait de la routine d'attente VBL, petit problème sur les artefacts liés au palette cycling. Avant, le changement de couleurs de la palette intervenait hors zone écran (car déclenché juste après l'attente VBL), maintenant il se balade ... il faut donc que je l'intègre à l'IRQ et que je cale l'IRQ pour quelle se déclenche quand le spot est hors écran. => sur la todo list. - Ajout des tiles animés en arrière et avant plan, hourra ! - Gestion des cascades en transparence (pas toutes, juste celles qu'il faut) - dédoublonnement des tiles (outil de conversion java) - Optimisation d'affichage quand il n'y a que des tiles "pleins" (sans aucune transparence), à ce moment la on n'affiche plus l'arrière plan. ça régle ainsi le pb de "lenteur" quand on est au max des tiles à afficher. Pour ça : le convertisseur d'images en sprite compilé regarde si le tile contient de la transparence, si oui il ajoute un "stb <glb_AlphaTiles" en début de tile compilé. Ainsi au runtime je consomme "seulement" 4 cycles par tile (max 792 cycles donc) et j'obtiens un flag qui me permet à chaque tour de boucle de savoir si je dois afficher ou non le fond. (b est chargé avec l'id de page RAM donc != 0). Ce n'est pas parfait car il y a un décalage entre ce flag (qu'on obtient après le rendu des tiles) et le fait qu'on ait besoin de l'info avant ... mais ça ne se voit peu car l'artefact se produit sur une seule frame lorsqu'on revoit de nouveau le fond. => Gain 13000 cycles économisés quand on est dans une zone avec que des tiles pleins, ça vaut le coup ! En ce qui concerne les tiles animés ça fonctionne comme ça : On déclare des scripts pour chaque "compteur" : Code: Animated_EHZ_script fdb Animated_EHZ_1 fdb Animated_EHZ_2 fdb Animated_EHZ_3 fdb Animated_EHZ_4 fdb Animated_EHZ_5 fdb 0 Animated_EHZ_1 ; Flowers 1 fcb -1,6 fcb 0,127 fcb 3,19 fcb 0,7 fcb 3,7 fcb 0,7 fcb 3,7 Animated_EHZ_2 ; Flowers 2 fcb -1,8 fcb 3,127 fcb 0,11 fcb 3,11 fcb 0,11 fcb 3,5 fcb 0,5 fcb 3,5 fcb 0,5 Animated_EHZ_3 ; Flowers 3 fcb 7,2 fcb 0 fcb 3 Animated_EHZ_4 ; Flowers 4 fcb -1,8 fcb 0,127 fcb 3,7 fcb 0,7 fcb 3,7 fcb 0,7 fcb 3,11 fcb 0,11 fcb 3,11 Animated_EHZ_5 ; Pulsing thing against checkered background fcb -1,6 fcb 0,127 fcb 3,9 fcb 6,11 fcb 9,23 fcb 6,11 fcb 3,9 La première ligne correspond à : * Global frame duration. If -1, then each frame will use its own duration, instead * Number of frames Les lignes suivantes : * Tile ID (image) * Frame duration. Only here if global duration is -1 La routine suivante : TileAnimScript s'exécute à chaque boucle principale du jeu et vient mettre à jour la frame active en fonction du script. Code: ; =========================================================================== ; ZONE ANIMATION SCRIPTS - TODO mettre dans une lib ; ZACurIndex equ 0 ; current index in animation script ZACurFrame equ 1 ; current frame in animation ZADuration equ 2 ; remaining duration of current frame (20ms by step) ZAMaxFrame equ 3 ; max index in animation script ZASize equ 4 ; size of this data structure TileAnimScriptData fill 0,16*ZASize TileAnimScriptInit stx TileAnimScriptList ldu #TileAnimScriptData @loop ldy ,x++ beq @rts ldd ,y ; load global frame duration, number of frames in animation bpl @globalduration stb ZAMaxFrame,u ldd 2,y incb std ZACurFrame,u ; and ZADuration bra @common @globalduration inca std ZADuration,u ; and ZAMaxFrame lda 2,y sta ZACurFrame,u @common lda #0 sta ZACurIndex,u leau ZASize,u bra @loop @rts rts TileAnimScript ldx #0 ; (dynamic) TileAnimScriptList equ *-2 beq @rts ; no animation script to process ldu #TileAnimScriptData @loop ldy ,x++ ; process a script beq @rts ; at the end of script list ? lda ZADuration,u suba Vint_Main_runcount ; tick down animation frame in sync with elapsed 50hz IRQ bcs @loadScript sta ZADuration,u ; animation is not over leau ZASize,u bra @loop @loadScript lda ZACurIndex,u ; animation frame is over, load next one inca cmpa ZAMaxFrame,u ; at the end of script ? bne @a ; if not continue lda #0 ; otherwise reset animation @a sta ZACurIndex,u ; save new index ldb 1,y stb ZAMaxFrame,u ldb ,y ; load global frame duration bpl @globalduration asla ; 2 data bytes per index adda #2 ; skip header ldd a,y bra @b @globalduration adda #2 ; skip header lda a,y @b std ZACurFrame,u ; and ZADuration leau ZASize,u bra @loop @rts rts TileAnimRun ldb a,x stb $E7E6 inca jmp [a,x] Cette variable globale (une par script) donne l'indice de frame à utiliser pour le rendu de chaque tile animé. Ainsi la routine suivante est appelée à la place du sprite compilé, elle récupère l'id de frame pour son script et appelle le sprite compilé correspondant. Code: TlsAni_EHZ_flower1 lda TileAnimScriptData+0*ZASize+1 ldx #TlsAni_EHZ_flower1_imgs jmp TileAnimRun TlsAni_EHZ_flower1_imgs INCLUDEGEN Tls_EHZ_flower1 index ; replacé par le builder avec les ptr vers les sprites compilés de chaque frame d'animation On a donc des scripts d'animations "communs" à l'opposé des sprites qui ont leur propre script pour chaque instance. |
Auteur: | Yoann Riou [ 02 Mai 2022, 14:27 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Je trouve ca completement dingue, sans dec. C'est incroyable a voir comment ca bouge bien. |
Auteur: | Samuel Devulder [ 02 Mai 2022, 17:18 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
C'est cool, ca rends super bien Citation: - Suite au retrait de la routine d'attente VBL, petit problème sur les artefacts liés au palette cycling. Le cyclage de palette est utilisé pour quels effets ? L'animation de la cascade ou des trucs en plus comme les reflets sur la mer ?
|
Auteur: | Bentoc [ 02 Mai 2022, 19:44 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Oui les deux : l'effet des cascades et les reflets sur l'eau. J'ai limité à trois couleurs (au lieu de quatre à l'origine). Avec le système décrit ci dessus je n'ai plus de problème, je cale le déclenchement de l'IRQ à la fin de la dernière ligne affichée, après on a la marge basse, le retour du spot en haut et la marge haute, le changement de palette à cet endroit est invisible. Le registre a contient le numéro de ligne sur laquelle se synchroniser (dans notre cas #199): Code: irq_timer_ctrl equ $E7C5
irq_timer equ $E7C6 IrqSync ldb #$42 stb irq_timer_ctrl ldb #8 ; ligne * 64 (cycles par ligne) / 8 (nb cycles boucle tempo) mul tfr d,y leay -32,y ; manual adjustment IrqSync_1 tst $E7E7 ; bmi IrqSync_1 ; while spot is in a visible screen line IrqSync_2 tst $E7E7 ; bpl IrqSync_2 ; while spot is not in a visible screen line IrqSync_3 leay -1,y ; bne IrqSync_3 ; wait until desired line stx irq_timer ; spot is at the end of desired line rts |
Auteur: | Bentoc [ 13 Mai 2022, 19:08 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Ajout des contrôles de Sonic : - walk - run - turn - roll - spindash - jump - duck - lookup - wait Ajout des effets sonores qui vont avec les mouvements (j’ai enfin corrigé les derniers bugs du driver son pour jouer musique + bruitages) Ajout du tracking camera Ajout des effets de poussière (sprites independants) N’oubliez pas de monter le volume pour écouter les bruitages ! En vidéo : https://youtu.be/9seAqQ3YoYc Je vais pouvoir enfin attaquer la partie collision avec le decors ! |
Auteur: | adnz [ 13 Mai 2022, 19:43 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
ouaa c'est incroyable !! ta utilisé des pistes (de la carte son) pour les bruitages ? |
Auteur: | Bentoc [ 13 Mai 2022, 20:02 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
La musique prend toutes les voix des deux chipset son, donc le driver mute les voix dont il a besoin juste au moment de jouer les bruitages et reactive les voix des que le bruitage est terminé. Les pistes sont organisées pour que les mélodies principales ne soient jamais utilisées par les bruitages |
Auteur: | adnz [ 13 Mai 2022, 20:17 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
et les bruitages c'est des samples ? |
Auteur: | Bentoc [ 13 Mai 2022, 20:36 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Non ici on a un générateur FM (YM2413) et un SN76489 (square + noise) Le pilote prend en entrée des commandes comme celle-ci : Code: ; jumping sound Sound20 fdb $0000,$0101 fdb $8080,@a-Sound20,$F400 @a fcb $F5,$00,$9E,$05,$F0,$02,$01,$F8,$65,$A3,$15,$F2 La première ligne c'est le header, la seconde c'est le header de piste (il n'y en a qu'une ici). Ensuite on a : $F5 $00 : set tone 00 Un tone c'est un index dans une table "d'enveloppe" de volume, ainsi quand on va jouer un son ça va faire varier le volume dans le temps : Code: Flutter1 fcb 0,0,0,1,1,1,2,2,2,3,3,3,4,4,4,5 fcb 5,5,6,6,6,7,$80 Flutter2 fcb 0,2,4,6,8,$10,$80 ... Bon ici on n'utilise pas ça (valeur 0) Ensuite : $9E $05 C'est une note suivi d'une durée $F0,$02,$01,$F8,$65 : $F0 c'est la commande pour demander une modulation du signal (modification de la fréquence dans le temps). ici on attend $02 frame avant de la déclencher, la vitesse de modulation est toute les frames, on applique -8 (/4) à la fréquence de la note pendant $65 frames Ensuite : $A3 $15 C'est une note suivi d'une durée $F2 : balise de fin Code: ; 70 notes (Note value $81=C3 $C7=G#8) with direct access ; (Note value $C8 is reserved for PSG3 to drive noise PSG4) ; Other notes can be accessed by transpose PSGFrequencies fdb $03F8,$03C0,$0388 ; A2 - B2 fdb $0356,$0327,$02FA,$02CF,$02A5,$0281,$025C,$023B,$021A,$01FC,$01E0,$01C4 ; C3 - B3 fdb $01AB,$0193,$017D,$0167,$0152,$0140,$012E,$011D,$010D,$00FE,$00F0,$00E2 ; C4 - B4 fdb $00D5,$00C9,$00BE,$00B3,$00A9,$00A0,$0097,$008E,$0086,$007F,$0078,$0071 ; C5 - B5 fdb $006A,$0064,$005F,$0059,$0054,$0050,$004B,$0047,$0043,$0040,$003C,$0039 ; C6 - B6 fdb $0035,$0032,$002F,$002C,$002A,$0028,$0025,$0023,$0022,$0020,$001F,$001D ; C7 - B7 fdb $001A,$0019,$0017,$0016,$0015,$0014,$0012,$0011,$0010,$0001 ; C8 - G#8 Tu vois qu'il faut peu d'octets pour jouer l'effet sonore d'un saut ! On est bien plus efficace qu'un sample ... mais il faut une carte son ;-) |
Auteur: | stefff285 [ 17 Mai 2022, 22:21 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Bonsoir ! Alors je ne capte rien au code mais je tenais à vous témoigner toute mon admiration devant ce boulot ! Sachez que vous explosez tout sur teo ^^ Merci à vous ! YoG |
Auteur: | Bentoc [ 18 Mai 2022, 07:30 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Merci pour ton message, ça fait toujours plaisir d'avoir des retours positifs ! |
Page 26 sur 40 | Heures au format UTC + 1 heure |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |