Logicielsmoto.com

Nous sommes le 19 Mar 2024, 12:00

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 598 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5, 6 ... 40  Suivante
Auteur Message
MessagePosté: 28 Fév 2021, 07:57 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 432
Localisation: Var
:sol:


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 28 Fév 2021, 08:17 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 432
Localisation: Var
J’y pense ... mais je ne sais pas encore si je vais l’utiliser comme une « disquette » en stockant les données compressées par exomizer (ça fonctionne super bien bravo !) ou en accédant directement aux données (pas de recopie mais on ne bénéficie plus de la compression) en montant une page.
Peut-être un mix des deux...

Mais ce n’est pas pour tout de suite, je reste concentré sur ma roadmap ;)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 28 Fév 2021, 09:17 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 432
Localisation: Var
Au passage une petite anecdote sur l'intro de Sonic2 (jeu d'origine sur megadrive) :
Quand on appuie sur un bouton lors de l'intro on court-circuite l'animation pour arriver sur la situation finale de l'écran titre.
Dans le code d'origine j'avais remarqué une inconsistance sur les priorités (layers) des sprites.
ça se vérifie dans les images du jeu d'origine :
- normal.png : si on laisse défiler l'écran titre sans rien faire
- court circuit.png : si on appuie sur un bouton

Dans le premier cas la mèche de Tails est derrière Sonic.
Dans le second elle est devant.

Je sais ce n'est pas une grosse révélation ... mais ça m'amuse :lol:


Fichiers joints:
court circuit.png
court circuit.png [ 16.65 Kio | Vu 6373 fois ]
normal.png
normal.png [ 16.92 Kio | Vu 6373 fois ]
Haut
 Profil  
Répondre en citant le message  
MessagePosté: 03 Mar 2021, 23:15 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 477
p'tin ça tape cette intro sur to8 de sonic ! :oui:
vous êtes trop fort ...

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Mar 2021, 08:47 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 432
Localisation: Var
Merci pour vos commentaires, c'est très motivant.

Ces derniers jours j'ai revu la structure de données pour stocker les "image set".
ça fonctionne très bien et offre de nouvelles possibilités en terme de fluidité d'affichage.

Quand on assigne une image à un sprite, on le fait comme ça:
Code:
        ldd   #Img_SonicWalk
        std   image_set,u
        ldb   #$01
        stb   priority,u
        ldd   #$807F
        std   xy_pixel,u


Dans le fichier properties de l'objet on a :
Code:
sprite.Img_SonicWalk=./Sonic2/Objects/TestImageSet/Sonic_017.png;NB0,NB1,XB0,XB1,YB0,YB1,XYB0,XYB1


On y retrouve l'étiquette et un ensemble de codes en seconde position de paramètre qui demande au builder de générer des variantes de sprites compilés.
Voici la signification des codes:
Code:
#            NB0  : no flip, background backup / draw / erase compilated sprite, no x offset
#            ND0  : no flip, draw compilated sprite, no x offset
#            NB1  : no flip, background backup / draw / erase compilated sprite, 1px x offset
#            ND1  : no flip, draw compilated sprite, 1px x offset
#            XB0  : x flip, background backup / draw / erase compilated sprite, no x offset
#            XD0  : x flip, draw compilated sprite, no x offset
#            XB1  : x flip, background backup / draw / erase compilated sprite, 1px x offset
#            XD1  : x flip, draw compilated sprite, 1px x offset
#            YB0  : y flip, background backup / draw / erase compilated sprite, no x offset
#            YD0  : y flip, draw compilated sprite, no x offset
#            YB1  : y flip, background backup / draw / erase compilated sprite, 1px x offset
#            YD1  : y flip, draw compilated sprite, 1px x offset
#            XYB0 : xy flip, background backup / draw / erase compilated sprite, no x offset
#            XYD0 : xy flip, draw compilated sprite, no x offset
#            XYB1 : xy flip, background backup / draw / erase compilated sprite, 1px x offset
#            XYD1 : xy flip, draw compilated sprite, 1px x offset


Dans le cas ci dessus, le moteur de jeu va utiliser un sprite compilés pour les position x "pair" et un autre dans le cas d'une position x "impaire" .
Si on retire les balises qui se terminent par un 1 dans la configuration, le moteur considère qu'il n'y a pas de différence de position et x=0 sera pareil que x=1, on ne rafraichit rien.

La définition ci dessus permet également de basculer le sprite facilement sur des variantes "miroir" :
Code:
        lda   render_flags,u
        eora  #render_ymirror_mask
        sta   render_flags,u


Un simple changement de bit et le moteur se charge de rétablir le fond en respectant les priorité de sprites, affiche le sprite mirroré et declenche le rafraichissement des sprites en collision au dessus.

De la même manière on peut passer d'un sprite compilé avec sauvegarde de fond à un sprite compilé sans sauvegarde.
Code:
        lda   render_flags,u
        ora   #render_overlay_mask
        sta   render_flags,u   


La désallocation des données de fond sauvegardées pour le précédent sprite est maintenant bien effectuée: ouf !
L'inverse fonctionne aussi, on peut repasser en sprite compilé avec sauvegarde si on pass le flag overlay à 0.

Si on fait appel à une image qui n'existe pas dans "l'image set" (ex: on veut un mirroir X mais on ne l'a pas déclaré dans le properties) : le moteur de jeu efface l'image actuelle si elle existe et n'affiche rien en remplacement, le moteur continue sans planter (ce qui n'était pas le cas semaine dernière).

Toutes ces nouvelles fonctions n'ont quasiment pas d'impact sur les perfs, l'algo du moteur va même dans le sens de la simplification, çe qui est bon signe.

Pour encoder l'index de données pour cet ensemble de sprites compilés relatifs à une image j'ai créé la structure suivante:
Fichier(s) joint(s):
TO8 game engine-Data Structures-ImageSet.png
TO8 game engine-Data Structures-ImageSet.png [ 149.38 Kio | Vu 6351 fois ]

Pour que cette structure n'occupe pas trop de place (imaginez avec 400 sprites ...), elle est de taille variable.
les lignes "mapping_frame" qui ne sont pas utiles ne sont pas écrites dans cette structure.
On joue sur les offsets en bleu pour indiquer au moteur su le mapping_frame est absent (offset:0) ou s'il existe à quel offset le trouver.
La première ligne contient 4 offsets pour chaque mode mirroir.
Chaque mode mirroir a de nouveau 4 offsets pour le mode normal/overlay et le décalage d'un pixel.

Un "image set" avec une seule image donne donc :
Code:
Img_star_4
        fcb   $06,$00,$00,$00,$0A,$16
      fcb   $06,$00,$00,$00,$FB,$F5
      fcb   $08,$A0,$00,$09,$A0,$00,$01


Gros gain de place ...

Un dernier dessin pour expliquer X1, Y1, x_size, y_size:
Fichier(s) joint(s):
TO8 game engine-Sprite Coordinates.png
TO8 game engine-Sprite Coordinates.png [ 63.08 Kio | Vu 6351 fois ]

Le sprite est positionné par des coordonées xy centré sur l'image (pixels transparents compris).
Pour détecter les collisions (dans le moteur d'affichage) et les sorties d'écran, on utilise l'offset et la taille réelle du sprite (hors pixels transparents).

Dernier truc codé hier soir mais je n'ai pas trop le temps de détailler :
Ajout d'un player PCM au moteur avec lecture d'un sample sur plusieurs pages de RAM.
Définition dans le properties:
Code:
sound.Pcm_SEGA=./Sonic2/Objects/SEGA/SEGA.bin

exemple d'appel :
Code:
        ldy   #Pcm_SEGA
        jsr   PlayPCM


SEEGAAA :lol:


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Mar 2021, 08:54 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1800
Localisation: Brest
Dis donc ca a l'air très pro ce moteur de sprites!

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Mar 2021, 15:50 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 477
question,
Ce moteur, c'est un moteur Ingame ? ou c'est genre une espèce de logiciel à fabriquer des sprites et animations ?

:good:

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Mar 2021, 17:46 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 432
Localisation: Var
L'outil est constitué de plusieurs composants :
- Un Builder Java qui construit l'image disquette à partir de tous les assets décrits dans les fichiers properties (Jeu, Niveau de jeu (Game Mode), Objets)
- Un générateur de sprite compilé (prend en entrée une image et produit l'asm), il est piloté par le builder et les properties
- Un ensemble de fichiers asm qui constituent le moteur de jeu exécuté au runtime, on retrouve :
* boot
* loader (charge les données disquette d'un niveau de jeu en RAM, décompresse par exomizer et lance l'exécution du niveau de jeu)
* moteur (boucle du jeu, données des objets, gestion de l'affichage des sprites (le gros du code), gestion palette, joypad, lecture pcm ...)

Ce qui n'est pas forcement clair, car je ne l'ai pas expliqué en détail :
Que ce soit pour le jeu d'origine de Sonic2 ou pour le la démo TO8, l'intro de Sonic2 utilise le même moteur de jeu (gestion des objets, moteur d'affichage) que celui de la phase de jeu.
Le seul code lié à l'intro est le code de l'objet TitleScreen qui fait 1000 lignes, dans lequel il n'y a aucun code spécifique ou astuce. Le code ne fait que séquencer la création des objets, changer les positions xy des sprites ...

En phase de jeu on aura donc d'autres objets (Sonic, ennemis, ...) mais le moteur sera strictement identique.
Il manque cependant au moteur (en dehors de ce qui est géré par les objets) :
- tout ce qui concerne l'affichage des graphismes des levels (tiles)
- la gestion du terrain (jeu de plateforme)
- l'instanciation/libération automatique des objets
- ...

ça reste très ouvert puisqu'on peut utiliser des variantes du moteur de jeu pour chaque Game Mode, voir même ne pas utiliser celui que j'ai développé.
On inclut ou pas des fichiers asm qui remplissent certaines fonctions.

Il n'aide pas à la fabrication d'image ou d'animations (il existe pro motion ou d'autres outils pour ça).
Il manque pas mal de choses pour faire un moteur de jeu complet mais ça avance bien.

Les prochains devs :
Un système pour instancier les objets
Dans un jeu comme Sonic, le moteur se base sur des données de chargement d'objets.
En fonction de la position du personnage principal dans le niveau, il charge ou décharge les objets (ennemis, ressorts, ...) en mémoire.
J'imagine que dans des jeux comme r-type le même système existe, mais basé sur le temps.
Si vous avez des infos sur ce genre de système je suis preneur ...

La conversion de PSGlib du z80 en 6809
Ces routines permettent de jouer des musiques et de gérer en // les sfx (bruits d'explosion, ...)
C'est pour pouvoir utiliser la carte son à base de SN76489 en cours de développement ici https://forum.system-cfg.com/viewtopic.php?f=18&t=11432&start=90
Si ça fonctionne on aura enfin de la musique, des bruitages sans se casser la tête a entrelacer les routines de génération de son au code du jeu.

Si certains veulent se joindre au projet je suis ouvert, vous pouvez me contacter en MP.
Il y a encore bcp de code asm a écrire pour faire une démo jouable :oui:


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Mar 2021, 20:08 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 492
adnz a écrit:
p'tin ça tape cette intro sur to8 de sonic ! :oui:
vous êtes trop fort ...


Carrement ! C'est fou de voir des sprites aussi gros sur TO. Maintenant, d'un cote pratique, si on doit passer 5 mins de chargement disquette pour une intro, ca casse le truc. Faudra voir dans un format cartouche.

En tout cas, c'est du delire ce moteur.

[edit : J'aimerais avec du temps pour recoder sur thomson ... mais bon, ca sera pour une autre vie ... ]


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Mar 2021, 20:25 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 432
Localisation: Var
Je suis d'accord avec toi : un passage sur cartouche est nécessaire :oui:


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Mar 2021, 21:29 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 681
Localisation: Provence (France)
SDSTREAM est une autre solution : http://dcmoto.free.fr/bricolage/sdstream/index.html


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Mar 2021, 22:36 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 432
Localisation: Var
C'est aussi une solution intéressante, il faut que je me penche dessus.

Dans l'idéal il faudrait pouvoir "builder" vers différents supports, en fonction des besoins du développeur.

Il faut donc développer :
- de nouvelles versions de builder adaptées chacune à des support différents
- des nouveaux boot et loaders adaptés (gère le chargement des données du jeu pour chaque phase/level)
- des variantes du moteur avec des permutations de pages différentes (cas de la cartouche si on veux accéder aux 128 pages de ROM au runtime en plus des pages de RAM)

Un gros chantier, mais super intéressant.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Mar 2021, 23:33 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 432
Localisation: Var
J'ai intégré mon portage de PSGlib dans le moteur, on a maintenant une belle musique qui se joue en // de la démo !
(J'utilise une version modifié de theodore que m'a donné dino et qui émule le chip SN76489, un grand merci à lui)

Sauf que ... si je cale la lecture de la musique sur la VBL (la musique ne nécessite que de mettre à jour les données du chip tous les 1/50s) bah ça ne fonctionne pas très bien, vu qu'il n'est pas imposé de faire du 50 images secondes par le moteur. Certaines frames prennent 39000 cycles pour être rendues ... d'autres 10000.

Donc je me suis lancé dans la mise en place d'un appel IRQ, comme on a besoin que d'un appel tous les 20000 cycles, ce n'est pas grave si les IRQ ne sont pas performantes sur Thomson.
Bon j'ai réussi à mettre ça en place grâce à toutes les infos trouvées sur le forum (merci sam).

Au final ça fonctionne (pour la musique) par contre j'ai quelques interférences avec mes routines de sprites compilés ... et on ne peut pas dire que je n'avais pas été prévenu.
Le problème est très bien écrit ici : https://blog.moertel.com/posts/2013-12-14-great-old-timey-game-programming-hack.html
Mais comme à l'époque je ne pensais pas avoir besoin des IRQ (pas de projet de carte son !) je n'ai pas tenu compte de la problématique.

Bon en fait j'utilise le pointeur S comme pointeur sur l'écran ... il faut que j'inverse avec U qui lui pointe sur le buffer de sauvegarde du fond.
Ainsi lors d'une interruption, la sauvegarde des registres viendra ecrire dans le buffer de sauvegarde et pas à l'écran.
Il suffit d'augmenter un peu la taille du buffer pour parer au cas ou l'interruption a lieu alors que le buffer alloué est rempli et le tour est joué.
que ce soit à l'écriture ou à la lecture du buffer les données écrites par l'IRQ se feront dans une zone déjà lue ou pas encore écrite ... OUF !
Pas d'impact sur les perf dans ce cas.

Seul impact "négatif" qui ne concerne que la version sprite compilé sans sauvegarde du fond : je vais devoir me passer du registre S dans ce cas.
On va perdre un poil en perf et le code prendra un peu plus de place en plus mais rien de trop méchant,
Le fait d'avoir de la musique et des bruitages ça va vraiment améliorer le rendu final.

Pour finir une question, voici mon code pour l'IRQ:
Code:
InitIRQ       
        ldd   #_IRQ                                   ; map IRQ routine               
        std   $6027
        ldd   #$09C4                                 
        std   $E7C6                                   ; timer to 20ms   
      
        lda   $6019                           
        ora   #$20
        sta   $6019                                   ; STATUS register
        andcc #:$10                                   ; tell 6809 to activate irq   


Puis la routine :

Code:
_IRQ
        lda   $E7E5
        sta   _IRQ_end+1                              ; backup data page
        jsr   PSGFrame
        jsr   PSGSFXFrame
_IRQ_end       
        lda   #$00
        sta   $E7E5                                   ; restore data page
        jmp   $E830        


Si je veux passer en FIRQ, je remplace juste
Code:
        andcc #:$10
par
Code:
        andcc #:$40
? Je pense qu'il doit y avoir une autre subtilité qui m'échappe ..
Dans le cas d'un FIRQ on a que PC et CC de sauvegardé c'est bien ça ?
Il faut toujours faire un
Code:
        jmp   $E830
pour rendre la main ou c'est différent ?

Merci pour le coup de main !


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Mar 2021, 23:41 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1800
Localisation: Brest
J'ai eu le même coup avec le S qui pointe sur un buffer et les interruptions dans la démo HNY2013. Soit on coupe les interruptions, le son est stoppé longtemps (ca n'oublions pas c'est le CPU qui fait tous les créneaux du son de HNY en utilisant le timer), soit on est malin et on fait en sorte de laisser les interruptions se produire mais d'utiliser le buffer "à l'envers" de sorte que les routines d'interruption peuvent empiler ce qu'elles veulent, mais cela n'écrasera pas les dernières données placées dans le buffer car elles sont "au dessus" du pointeur S.

Les interruptions timer sont toujours sur IRQ. Le FIRQ est utilisé exclusivement par le crayon optique. Il n'y a pas moyen de le détourner pour autre chose sans jouer du fer à souder et de la reprogrammation de la rom moniteur. Note que le ANDCC permet juste de laisser le CPU répondre aux IRQ ou aux FIRQ, mais ne permet pas d'indiquer au timer de générer une FIRQ à la place d'une IRQ (le timer est distinct du CPU).

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Mar 2021, 00:26 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 432
Localisation: Var
du coup lors d'un appel IRQ c'est 12 octets (D,X,Y,U,PC,DP,CC ) qui sont stockés dans la pile S ?
et ils sont restitués à la sortie ? (rien d'autre à faire)


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 598 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5, 6 ... 40  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 9 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com