La Place des Développeurs Final Smash Cette fois c'est le bon !?
Reprise du message précédent
aoineko :
EDIT : Avec un autre agencement des patterns en VRAM (en mettant tous les blocks 16x16 plein côte à côte), je descends à 8 groupes de blocks à envoyer. Ça confirme l'avantage de la 2e méthode.
C'est la confirmation d'un grand principe qu'il ne faut jamais oublier lorsqu'on développe en assembleur : l'organisation des données, et la valeur des données elles-mêmes, jouent un grand rôle dans l'optimisation.
Edité par
Metalion
Le 19/02/2021 à 10h46
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
En parlant d'agencement, c'est vraiment dommage qu'il ne soit pas "sûr" d'utiliser le Graphic mode 2 avec les flags pour n'avoir qu'un seul bloc de 256 patterns/colors pour tout l'écran. Là, je perds presque la moitié des 16 Ko de ma VRAM avec des zones non utilisés. 
Mais bon, comme je dépasse pas les 128 patterns pour mes sprites, j'ai réussi à casser 2 zones pour pouvoir faire du double buffering.
Mais bon, comme je dépasse pas les 128 patterns pour mes sprites, j'ai réussi à casser 2 zones pour pouvoir faire du double buffering.
On est toujours ignorant avant de savoir.
Grace à mes compétences en Tetris, j'ai réussit à faire tenir mon double-buffer pour les données des sprites (attribues et patterns) dans le Mode graphique 2 (Screen 2). 
Mon terrain de tennis utilise à peine 40 tuiles pour tout l'écran donc y a énormément de place gâché, mais à cause des limitations sur la "pas" des adresses mémoires des différents blocs de VRAM, je peux pas profiter de ces vides pour y mettre des choses utiles.
Par contre, j'ai regardé ce que ça donnerait en Mode graphique 1 (Screen 1) et là, ça serait la fête !
J'aurais la place de mettre un ring-buffer de 7 entrées qui pourrait me permettre de garder des frames d'animations précédentes de mes joueurs et limiter ainsi les cas ou j'ai besoin de les recharger.
Bon, ceci dit, j'suis pas sûr d'en avoir besoin, mais c'est bon à savoir.
Mon terrain de tennis utilise à peine 40 tuiles pour tout l'écran donc y a énormément de place gâché, mais à cause des limitations sur la "pas" des adresses mémoires des différents blocs de VRAM, je peux pas profiter de ces vides pour y mettre des choses utiles.
Par contre, j'ai regardé ce que ça donnerait en Mode graphique 1 (Screen 1) et là, ça serait la fête !
J'aurais la place de mettre un ring-buffer de 7 entrées qui pourrait me permettre de garder des frames d'animations précédentes de mes joueurs et limiter ainsi les cas ou j'ai besoin de les recharger.
Bon, ceci dit, j'suis pas sûr d'en avoir besoin, mais c'est bon à savoir.
On est toujours ignorant avant de savoir.
Si cela n'a pas été fait ou déjà prévu : Une p'tite idée pour la suite, changé de couleur de terrain pour simulé, terrain synthétique , herbeux ou terre battue 
Edité par
TurboSEB
Le 20/02/2021 à 04h47
Edité par
TurboSEB
Le 20/02/2021 à 04h47
MSX 1&2 + Moniteurs+divers (environ 0.70Tonnes)
TurboSEB :
Si cela n'a pas été fait ou déjà prévu : Une p'tite idée pour la suite, changé de couleur de terrain pour simulé, terrain synthétique , herbeux ou terre battue
Ca sera pour la version MSX2. Sur MSX1, j'ai besoin que le terrain soit de la même couleur que la peau, sinon ça va être vraiment moche.
Ou sinon, ça sera des p'tits hommes verts qui jouent sur le gazon.
On est toujours ignorant avant de savoir.
TurboSEB :
Oh tu sais, que les personnages soit vert, bleu ou rouge, en définitive, y'a rien de choquant
Tiens, tu me donnes une idée ! Pour les terrains herbe et synthétique, je pourrais mettre la couleur des vêtements à la même couleur que le fond et les faire disparaitre en premier quand on dépasse les 4 sprites par ligne.
On est toujours ignorant avant de savoir.
Voici la version 0.4 de Final Smash : fs_0_4.rom
Ca à l'air de rien, mais j'ai redessiné tous les sprites (et ajouté quelques étapes d'animation en plus), j'ai développer un player d'animation (ou je peux choisir l'ordre des images et la durée de chacune), j'ai mis en place mon double-buffering de sprite (l'adresse des patterns change à chaque frame) et surtout j'ai mis à jour mes outils (notamment CMSXimg) pour pouvoir transformer facilement des images en couleur en plusieurs couche de sprites monochromes.
Les touches Shift et Ctrl servent à jouer les animations de shoot/smash. F3 active/désactive l'ombrage par alternance des sprites noires.
La bonne nouvelle, c'est que j'ai maintenant techniquement tout ce qu'il faut pour faire un jeu.
Prochaines étapes :
- Retoucher certaines sprites (maintenant que je les vois en jeu, certaines animation ne vont pas du tout, notamment les déplacements haut/bas)
- Finir le double-buffering de sprites (pour limiter l'effet de scintillement) en mettant aussi les attribues en double-buffer
- Créer la physique de la balle
- Afficher le 2e joueur
Bref, y a encore du taf !
Ca à l'air de rien, mais j'ai redessiné tous les sprites (et ajouté quelques étapes d'animation en plus), j'ai développer un player d'animation (ou je peux choisir l'ordre des images et la durée de chacune), j'ai mis en place mon double-buffering de sprite (l'adresse des patterns change à chaque frame) et surtout j'ai mis à jour mes outils (notamment CMSXimg) pour pouvoir transformer facilement des images en couleur en plusieurs couche de sprites monochromes.
Les touches Shift et Ctrl servent à jouer les animations de shoot/smash. F3 active/désactive l'ombrage par alternance des sprites noires.
La bonne nouvelle, c'est que j'ai maintenant techniquement tout ce qu'il faut pour faire un jeu.
Prochaines étapes :
- Retoucher certaines sprites (maintenant que je les vois en jeu, certaines animation ne vont pas du tout, notamment les déplacements haut/bas)
- Finir le double-buffering de sprites (pour limiter l'effet de scintillement) en mettant aussi les attribues en double-buffer
- Créer la physique de la balle
- Afficher le 2e joueur
Bref, y a encore du taf !
On est toujours ignorant avant de savoir.
super ca avance bien !!!
on peut esperé avoir une version FEMME !!! avec jupette ... et des CRI de OUFFFF !!...
je delire !!! quoi que ??
on peut esperé avoir une version FEMME !!! avec jupette ... et des CRI de OUFFFF !!...
je delire !!! quoi que ??
TURBO-R FS-A1ST 512/128ko MSX2+ NMS 8250 F4 /Fix Audio /Ram 1/4Mb VDP9958 VRAM 192ko 2FDD SANYO WAVY PHC35J MSX2 NMS 8280 Ram 4Mb VDP9938 VRAM 192ko 2FDD NMS 8250 128/128ko 2FDD VG8235/39 128/128ko 1FDD SONY HB-F700D MSX1 MC810 32/16k VG 8020 64k HB75F 64k HX-22 64k RS232/ CX5M 32k HB501F EXT : My Exp 4X/[b] MegaFlashSCC 512ko/BERT R2/BEER CF/SUNRISE 2CF/FUNRICE V2.01/MAXIOL/MEGASCSI HDD-CD/SDMSX 1SD/FMPAC SRAM/NMS1205+1160/RS 232 Harukaze/GR8NET/DOS2/ HOMER V2 RAM512ko/Floppy Pack/MAXduino/ROM1664/FM Pak /GR8NET /AMIGA/ PC/ RaspB Pi(B) / ARDUINO
C'est tres prometteur 
Une remarque constructive
Généralement, pour rester coherent, un deplacement diagonal est égal à 0,5 d'un deplacement vertical + 0, 5 déplacement horizontal.
Au final, le déplacement diagonal est égal à 1:1 de déplacement V ou H
Actuellement, Diag, semble être égal à 1V + 1H ... soit 2 fois plus rapide qu'un déplacement V ou H.
Une remarque constructive
Généralement, pour rester coherent, un deplacement diagonal est égal à 0,5 d'un deplacement vertical + 0, 5 déplacement horizontal.
Au final, le déplacement diagonal est égal à 1:1 de déplacement V ou H
Actuellement, Diag, semble être égal à 1V + 1H ... soit 2 fois plus rapide qu'un déplacement V ou H.
Nouvelle version : fs_0_5.rom
J'ai ajouté le 2e personnage et je gère maintenant les coordonnées en avec des nombres à virgule pour pouvoir utiliser des valeurs plus petites que 0 (comme pour le déplacement en diagonale).
Pour la petite histoire, j'utilise un format Q12.4, c'est-à-dire un nombre 16-bits à "virgule fixe" avec 12-bits pour la partie entière et 4-bits pour la partie fractionnelle.
Prochaine étape, la physique de la balle !
J'ai ajouté le 2e personnage et je gère maintenant les coordonnées en avec des nombres à virgule pour pouvoir utiliser des valeurs plus petites que 0 (comme pour le déplacement en diagonale).
Pour la petite histoire, j'utilise un format Q12.4, c'est-à-dire un nombre 16-bits à "virgule fixe" avec 12-bits pour la partie entière et 4-bits pour la partie fractionnelle.
Prochaine étape, la physique de la balle !
On est toujours ignorant avant de savoir.
ericb59 :
Peux tu expliquer la petite histoire s'il te plaît ?
Comment ça marche et comment utiliser un Q12.4 ?
Comment ça marche et comment utiliser un Q12.4 ?
Voici : http://msxvillage.fr/forum/topic.php?id=3843
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie