Logicielsmoto.com

Nous sommes le 28 Mar 2024, 12:47

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 598 messages ]  Aller à la page Précédente  1 ... 4, 5, 6, 7, 8, 9, 10 ... 40  Suivante
Auteur Message
MessagePosté: 16 Avr 2021, 14:43 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
En effet. Trois machines (les Plus et la GX4000) qui ont fait un four monumental. CQFD. Et il ne faut pas oublier que quand on dit "a sorti en [an x]", ca veut dire "a lancé le nouveau projet en [an x-3]" voire plus. Dans l'industrie, l'anticipation n'est pas chose facile, et encore moins en informatique.

Si on ramène ça à Thomson, les premières esquisses du Théodore c'est 1985, alors que les TO8/8D/9+/MO6/MO5NR n'étaient pas encore sortis. Ce qui est logique. On attaque la version suivante dès qu'on a une gold de la version courante, voire une beta. Il faut aller vite. De ce point de vue, l'équipe de dev était était plutôt agile, puisque les réflexions sur une machine à base d'ARM ont commencé alors que le Théodore n'était qu'un prototype.

Le 6309 n'arrivera que trois ans après. Trois ans après que Thomson avait commencé le travail sur une machine 32 bits. Donc je le redis : stop aux fantasmes. Du reste, le 6309 est lui aussi passé totalement inaperçu et c'est bien normal.

Mais nous devrions revenir au sujet d'origine :-) Il fabrique quoi, Bentoc ? :lol:


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Avr 2021, 16:29 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
... et bien ça avance pas mal !

Le builder produit de nouveau (depuis hier soir) une image FD fonctionnelle.
J'ai fait les adaptations du code asm en conséquence, j'ai encore qq optims asm a faire mais le principal est ok.

Le gros changement c'est que le code s'exécute depuis la zone cartouche et non plus depuis la zone data.
Le buffer vidéo est donc maintenant écrit depuis la zone data.
Le chargement des données en RAM se fait par des demi-pages exomizées (permet d'inverser les 2 blocs de 8ko, car les données sont chargées depuis la zone cartouche vers la zone data, puis ces mêmes données sont par la suite exécutées depuis la zone cartouche).
En plus d'être plus rapide, cette solution permet un gain de place en RAM car l'index de chargement est beaucoup plus petit.
Les index d'images et d'animations ne sont plus dans la zone principale (6100-9FFF) mais en page RAM >= 4
=> Tous ces changements sont maintenant opérationnels.
Il me reste à tester le changement de niveau de jeu et la fonctionnalité de données communes entre niveaux de jeu (qui ne sont donc pas rechargées entre chaque niveau).

Coté T2, il ne reste plus grand chose à faire coté builder pour produire une image rom (intégration du boot et du RAMLoader pour T2)
Par contre il faut que je fasse encore les devs asm de boot, de chargement des données exomizées de la ROM vers la RAM et de switch de page. Enfin il faut que je réalise un "loader" pour charger l'image de T2 sur la cartouche.

Bref encore un peu de travail avant de pouvoir montrer qq chose, mais c'est toujours sur les rails.

PS: J'ai commencé à récupérer les images de tiles et les maps de niveau de Sonic2, je pense avoir un modèle de donnée qui tient la route pour l'affichage des décors.

La map serait de taille maximum de 128x128 blocs (16ko), chaque bloc a donc une référence sur un octet.

Les 256 blocs de 128x128 pixels sont composés de 8x8 images de 16x16px, chaque définition de bloc fait donc 64 octets (16 ko pour les 256 définitions de blocs). Oui ça fait bien une map de taille maximum de 16384px par 16384px ! :sol:

Enfin l'index image fait 256x3 (un octet page, deux octets adresse) et pointe vers la routine d'affichage qui sera certainement un dérivé de celle des "sprites compilés".

Cette structure sera à multiplier pour chaque plan de tile a afficher (j'en ai prévu deux, un pour le fond, un autre pour les plateformes).
Les éléments en avant plan par rapport aux sprites seront gérés par le moteur de sprites et non par le système de tilemap.

Dernière précision, on pourra afficher la map à l'écran en déplaçant la "caméra" (zone affichée par l'écran) par pas de 16px (taille d'une image tile). Si vous avez bien suivi on perd donc 8 px en hauteur (l'image sera constituée de 20x16px en largeur et 12x16px en hauteur).


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Avr 2021, 17:09 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Aller ... pour se divertir un peu deux vidéos qui montrent le masquage automatique du sprite quand il sort de l'écran.
Tout est géré par le moteur de sprite en fonction de chaque image, j'ai juste donné le png en entrée le builder s'occupe de générer toutes les caractéristiques de l'image à destination du moteur de sprite pour qu'il fasse le nécessaire.

Deux modes (flag qu'on positionne sur le sprite au runtime):
- xloop off le sprite ne s'affiche plus dès qu'un de ses pixels est hors écran (axe x et y)
phpBB [video]


- xloop on le sprite ne s'affiche plus dès qu'un de ses pixels est hors écran (axe y uniquement)
phpBB [video]


Il y a deux modes de positionnements prévus dans le moteur :
- x et y précision 8bits (pour un affichage en coordonnées écran), seul ce mode est opérationnel pour le moment
- x et y précision 16bits (pour un positionnement dans une map), à réaliser !


Dernière édition par Bentoc le 16 Avr 2021, 18:12, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Avr 2021, 17:15 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
On peut observer aussi dans ces vidéos les deux modes de lecture du joystick : press ou held.
Quand le personnage se déplace vite, je lis la valeur "held", quand j'ai un déplacement au pixel près c'est que j'utilise la valeur "press".

Code:
* ---------------------------------------------------------------------------
* Controller Buttons
*
c1_button_up_mask            equ   $01
c1_button_down_mask          equ   $02
c1_button_left_mask          equ   $04
c1_button_right_mask         equ   $08
c2_button_up_mask            equ   $10
c2_button_down_mask          equ   $20
c2_button_left_mask          equ   $40
c2_button_right_mask         equ   $80
c1_button_A_mask             equ   $40
c2_button_A_mask             equ   $80

Joypads_Read
Dpad_Read                    fcb   $00
Fire_Read                    fcb   $00
   
Joypads
Joypads_Held                           
Dpad_Held                    fcb   $00
Fire_Held                    fcb   $00
Joypads_Press                         
Dpad_Press                   fcb   $00
Fire_Press                   fcb   $00

********************************************************************************
* Get joystick parameters
*
* Direction des Joypads
* ---------------------
* Registre: $E7CC (8bits)
*
* Joypad2     Joypad1
* 1111        1111 (0: appuye | 1: relache) 
* ||||_Haut   ||||_Haut
* |||__Bas    |||__Bas
* ||___Gauche ||___Gauche
* |____Droite |____Droite
*
* Boutons des Joypads
* -------------------
* Registre: $E7CD (8bits)
*
* 11 000000 (0: appuye | 1: relache)
* ||[------] 6 bits convertisseur numerique-analogique
* ||_Fire Joypad1
* |__Fire Joypad2
*
* Variables globales: Joypads_Held, Joypads_Press
* -----------------------------------------------
* (16 bits)
* Joypad2     Joypad1                                                         
* 0000        0000 (0: relache | 1: appuye) 00 000000 (0: relache | 1: appuye) 
* ||||_Haut   ||||_Haut                     ||[------] Non utilise             
* |||__Bas    |||__Bas                      ||_Fire Joypad1                   
* ||___Gauche ||___Gauche                   |__Fire Joypad2                   
* |____Droite |____Droite                                                     
*
********************************************************************************
   
                                       *; ---------------------------------------------------------------------------
                                       *; Subroutine to read joypad input, and send it to the RAM
                                       *; ---------------------------------------------------------------------------
                                       *; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||
                                       *
                                       *; sub_111C:
ReadJoypads                            *ReadJoypads:
                                       *    lea (Ctrl_1).w,a0         ; address where joypad states are written
                                       *    lea (HW_Port_1_Data).l,a1 ; first joypad port
                                       *    bsr.s   Joypad_Read       ; do the first joypad
                                       *    addq.w  #2,a1             ; do the second joypad
                                       *
                                       *; sub_112A:
                                       *Joypad_Read:
                                       *    move.b  #0,(a1)           ; Poll controller data port
                                       *    nop
                                       *    nop
                                       *    move.b  (a1),d0           ; Get controller port data (start/A)
                                       *    lsl.b   #2,d0
                                       *    andi.b  #$C0,d0
                                       *    move.b  #$40,(a1)         ; Poll controller data port again
                                       *    nop
                                       *    nop
                                       *    move.b  (a1),d1           ; Get controller port data (B/C/Dpad)
                                       *    andi.b  #$3F,d1
                                       *    or.b    d1,d0             ; Fuse together into one controller bit array
        ldd   $E7CC
        coma
        comb                           *    not.b   d0
        std   Joypads_Read       
        ldd   Joypads_Held             *    move.b  (a0),d1           ; Get held button data
        eora  Dpad_Read                *    eor.b   d0,d1             ; Toggle off buttons that are being held                       
        eorb  Fire_Read
                                       *    move.b  d0,(a0)+          ; Put raw controller input (for held buttons) in F604/F606
        anda  Dpad_Read                *    and.b   d0,d1
        andb  Fire_Read
        std   Joypads_Press            *    move.b  d1,(a0)+          ; Put pressed controller input in F605/F607
        ldd   Joypads_Read
        std   Joypads_Held
        rts                            *    rts
                                       *; End of function Joypad_Read


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 03 Mai 2021, 18:55 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Voici la nouvelle release !

ça y est la T.2 est intégrée au Builder et voici ce qui est produit :
Fichier(s) joint(s):
SONIC2_T2Loader.rar [103.11 Kio]
Téléchargé 246 fois


Il s'agit d'un fichier ".sd" a lancer sur un SDDRIVE qui programme la T.2.
Attention ce loader est rudimentaire, aucune confirmation n'est demandée.
Une fois lancé :
- une barre rouge s'affiche, cela signifie que la T.2 est intégralement effacée
- une barre de progression grise indique l'avancement de la programmation de la T.2
- une barre verte indique la fin de la programmation

Une fois le reboot effectué, appuyez sur 0 pour lancer la démo.
Le reboot suivant vous ne verrez plus la T.2 dans le menu de lancement, il faut faire un appui long (2 sec) sur le bouton de reboot pour forcer le retour à la page 0.

Avant de flasher la T.2 assurez vous d'avoir ce qu'il faut pour la réinitialiser avec les softs d'origine :p

Merci à Daniel pour sa routine qui permet d'accéder à plus de 2 disquettes dans un fichier sd depuis SDDRIVE.
Merci à Fool-DupleX pour les infos sur la T.2.

Les nouveautés

Je n'ai pas ajouté grand chose à la démo actuelle, mais quand même :
- nouveau compteur incrémenté par l'IRQ qui permet par exemple d'avoir un déplacement constant de l'étoile filante, peu importe le framerate
- optimisation du scroll de l'île
- réécriture de la routine de désallocation mémoire
- routine qui permet de charger les niveaux de jeu les uns après les autres (appuyez sur le bouton de la manette au "Press Start" ...)
- une gestion des données communes entre niveaux de jeu (qui sont persistante en RAM)
- 3 niveaux de jeu très "sommaires" avec quelques sprites
- le paramétrage qui permet de choisir pour chaque ressource (chaque image, index image, index animation, musique) si on souhaite exécuter les données depuis la ROM (T.2) ou en RAM (dans ce cas les données sont exomizées en ROM et décompressées au runtime en RAM).

Remarque : le builder produit toujours une image disquette, il y a peu de points de divergence dans le code entre exécution depuis la disquette et la T.2. La commutation de page T.2 ou RAM est traitée par une macro avec un IFDEF.

Il reste qq bugs a corriger, notamment un plantage dans les niveaux de jeux après le title screen ... lié aux routines d'alloc/désalloc mémoire.

Avant d'attaquer le moteur de Tile j'ai une petite idée que je vais implémenter ... je ne donne pas plus de détail mais ça devrait être très sympa.


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

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Quelle idée mystérieuse est-ce que cela peut-être ? :voyons:

Sinon une question: avec la T2 ca se charge vite ou très vite ? :D

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Mai 2021, 06:26 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
ça se charge "Méga" vite :ptdr:

Pour le Title Screen, on charge en RAM seulement :
- 11ko du moteur principal (page 1)
- 5ko pour les codes des objets (page 4)

Actuellement ces données sont exomizées, donc le temps passé au chargement est essentiellement lié à la décompression.
J'ajouterai plus tard (si le besoin s'en fait ressentir) une option pour pouvoir charger des données en RAM sans passer par exomizer pour des chargements plus rapides. C'est vrai que tant qu'on dépasse pas les 2Mo de la cartouche, exomizer les données n'a pas d'intérêt ...

Tout le reste est exécuté depuis la ROM (en particulier les sprites compilés).

Au boot on charge aussi le "RAM Loader" en page 4 mais c'est très rapide car le code et les index de chargement sont petits (871 octets dont le code exomizer).

Pour illustrer, voici l'index de chargement RAM du Title Screen :
Code:
        fdb   RL_RAM_index+13
gm_TITLE_SCREEN
        fcb   $0B,$04,$0A,$1D,$D3,$F1
        fcb   $0C,$01,$22,$CB,$CD,$2E
        fcb   $FF


Première ligne :
- on charge depuis la page $0B de la T.2 vers la page $04 de la RAM
- adresse de fin des données exo a lire depuis la ROM : $0A1D
- adresse de fin destination RAM : $D3F1 en zone données (sera visible en $0000-$13F1 en zone cartouche)

=> l'index de chargement charge des demi-pages qui sont préparées au build, donc cet index est beaucoup plus léger que si on avait un catalogue de fichiers avec un index pour chaque image ou bout de code ...
Seule la page 1 est chargée par page entière car il n'y a pas d'inversion des demi-pages de 8ko (le code n'est pas exécuté en zone cartouche contrairement aux autres pages de RAM, mais depuis $6100 évidement).


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Mai 2021, 13:52 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Voici la petite surprise (en fin de vidéo) avec cette fameuse "idée" (le tout sur machine réelle avec la T.2) :

phpBB [video]


Deux remarques :
- il y a un artefact en haut de l'écran du à une erreur du convertisseur de sprites compilés (à corriger)
- Le personnage se déplace à gauche car j'ai un problème avec ma manette :p

Je vous invite à essayer sur machine réelle, la capture vidéo ne rend pas justice ...
Version Pour T.2 (chargement depuis un .sd par SDDRIVE v20210212)
Fichier(s) joint(s):
SONIC2_T2Loader.rar [150.07 Kio]
Téléchargé 237 fois


Version sans T.2
(.fd)
Fichier(s) joint(s):
SONIC2.rar [151.66 Kio]
Téléchargé 253 fois

(.sd)
Fichier(s) joint(s):
SONIC2-sd.rar [157.03 Kio]
Téléchargé 251 fois


Pas besoin de l'extension mémoire pour ces deux versions.
Le personnage se déplace avec la manette (ne pas appuyer sur le bouton de la manette lors du special stage ;-)

Si vous n'avez pas de machine sous la main, le fichier .fd tourne sous DCMOTO avec la dernière version ici :
http://dcmoto.free.fr/emulateur/dcmoto_20210402.zip


Dernière édition par Bentoc le 06 Mai 2021, 06:24, édité 3 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Mai 2021, 13:59 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Lol il est bourré le sonic et fait du hors-piste :)

Le fond est-il un sprite lui aussi ?

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Mai 2021, 14:11 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Oui, l'image de fond utilise le moteur de sprite.
Comme l'image d'origine a des pixels de 2x2, je génère un sprite compilé qui n'affiche qu'une ligne sur deux.
J'instancie deux sprites dont un est décalé d'une ligne vers le bas.

La subtilité, c'est que le sprite compilé n'affiche que l'écart entre deux images :
Fichier(s) joint(s):
011.png
011.png [ 1.6 Kio | Vu 6906 fois ]
Fichier(s) joint(s):
012.png
012.png [ 1.66 Kio | Vu 6906 fois ]
Fichier(s) joint(s):
012.png_011_diff.png
012.png_011_diff.png [ 2.48 Kio | Vu 6906 fois ]


Ce qui donne pour passer de la frame 11 a 12 (le cas ci-dessus) :
cycles: 14165 taille du code du sprite compilé: 8178 (octets)

Les cycles sont a multiplier par deux évidement ... car l'affichage se fait par deux exécutions du même sprite avec un décalage d'une ligne.
Avec ce système on économise pas mal de place.


Dernière édition par Bentoc le 05 Mai 2021, 14:59, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Mai 2021, 14:16 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Ca fait quand même un super gros sprite. Ca marche bien!

PS: pour la machine réelle il faut une cartouche T2 c'est ca ?

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Mai 2021, 14:53 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Samuel Devulder a écrit:
Ca fait quand même un super gros sprite. Ca marche bien!

PS: pour la machine réelle il faut une cartouche T2 c'est ca ?


Oui la version que j'ai donné nécessite une T.2 et un SDDRIVE pour la charger.
J'ai ajouté dans mon post une seconde archive pour ceux qui n'ont pas de T.2.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Mai 2021, 19:07 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
chan..mé... :good:

c'est rapide ! je sais pas quoi dire !

ça fait des mois qu'en parallèle je réfléchis un moyen de faire le defilement d'une route avec des virages pour preparer un test d'un jeu de voiture (au graphisme de route maitrisé, pas juste des traits qui défilent !)

ton truc me donne des idées du coup ;)

bravo.

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Mai 2021, 20:26 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Merci !

Une remarque avec le double buffering, il faut faire un choix :

- Soit le sprite compilé affiche l'écart entre chaque image , mais tu es obligé d'avoir :
Img 1 dans buffer 1 (key image)
Img 1 dans buffer 2 (key image)
Ecart entre img 1 et Img 2 dans Buffer 1
Ecart entre img 1 et Img 2 dans Buffer 2
..
=> le framerate est divisé par deux, mais l'écart entre deux images est faible

- Soit tu fais :
Img 1 dans Buffer 1 (key image)
Img 2 dans Buffer 2 (key image)
Ecart entre img 1 et Img 3 dans Buffer 1
Ecart entre img 2 et Img 4 dans Buffer 2
...
=> le framerate est plus rapide, mais l'écart entre les images est plus grand donc l'image est plus lente à afficher (a voir en fonction du contexte)

Dans mon proto j'utilise l'option 1, sinon les écarts sont trop importants en sautant une image.
Par contre le sprite de Sonic lui se déplace et change d'animation à chaque swap de buffer vidéo.

Actuellement le proto tourne à maxi 41000 cycles par rendu de buffer.
Dans l'objectif de respecter les 8fps du fond (vitesse d'origine du jeu megadrive) il faut que tout le rendu complémentaire (anneaux, bombes, score, ...) rente dans 18000 cycles pour un total max de 60000 cycles par boucle principale du moteur de jeu (ça devrait le faire).
Si la cible est respectée, les animations et mouvements de sprites en dehors du fond atteindront les 16fps ce qui est honnête.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Mai 2021, 06:09 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
J’ai oublié de préciser que dans les cas d’une T.2 mon loader est fait pour fonctionner avec sddrive en version 20210212.
(Cf. Le code de Daniel ici : https://forum.system-cfg.com/viewtopic.php?f=25&t=9508&start=105).


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 ... 4, 5, 6, 7, 8, 9, 10 ... 40  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 33 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 à:  
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com