La Place des Développeurs Final Smash Cette fois c'est le bon !?
aoineko :
En tout cas ça pèse pas lourd par rapport aux 12 KB des sprites de joueurs, mais là, ça risque d'être beaucoup plus compliqué car c'est des données que j'envoie continuellement au VDP et devoir les décompresser à la volé risque de me couter cher en perfs.
Voyons déjà ce que je peux gagner en comprimant les images Screen 2...
Voyons déjà ce que je peux gagner en comprimant les images Screen 2...
Déjà une simple compression rle fait gagner beaucoup.
Ensuite, tu as la RAM qui peut servir de buffer : tu décompresses à l'init en RAM et après tu l'utilises comme source. J'ai lu que tu avais repoussé l'adresse RAM à $E000 pour être compatible avec les modèles MSX 8K, mais franchement, personne ne t'en voudras si tu reviens à $C000 ... Ces machines sont plutôt rares, et même à l'époque, beaucoup de jeux n'étaient pas compatibles avec elles. Et cela te fait gagner 8K de place pour un buffer en RAM.
Enfin, il te reste les mappers megarom (ASCII ou Konami).
Très simples d'utilisation, ils te permettront de passer à 64K.
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)
Metalion :
Déjà une simple compression rle fait gagner beaucoup.
Comme toujours avec les algo de compression, tout dépend des données. En l'occurrence, j'ai très très peu de plages avec des 1 contiguës, mais pas mal avec des 0.
Du coup, je m'oriente vers une RLE un peu particulier :
- Un header 8-bits avec 1-bit de type et 7-bits pour la longueur
- Si le type est 0, c'est une plage d'au moins 16 zéros (je stock juste le nombre)
- Si le type est 1, c'est une plage non compressé avec des 1 et/ou moins de 16 zéros consécutifs
Et vu la configuration de mes données, je pense compresser directement au niveau des octets ; la plupart des plages de 0 étant alignées sur 1 octet.
Ca sera beaucoup plus rapide à décompresser et ça devrait pas changer grand chose en terme de compression.
Metalion :
Ensuite, tu as la RAM qui peut servir de buffer : tu décompresses à l'init en RAM et après tu l'utilises comme source. J'ai lu que tu avais repoussé l'adresse RAM à $E000 pour être compatible avec les modèles MSX 8K, mais franchement, personne ne t'en voudras si tu reviens à $C000 ... Ces machines sont plutôt rares, et même à l'époque, beaucoup de jeux n'étaient pas compatibles avec elles. Et cela te fait gagner 8K de place pour un buffer en RAM.
J'ai 16 KB de sprites qui tous peuvent être nécessaire à envoyer au VDP à tout moment (2 joueurs * 27 sprites * ~6 couches * 16x24 pixels).
Donc tout décompresser en RAM n'est pas envisageable.
La seule alternative c'est donc de décompresser à la volé selon les besoins.
Ce qui m'embête avec cette option c'est que ça tiendra surement pas dans une frame avec l'envoie des données au VDP (qui sollicite déjà beaucoup le Z80) et que je devrais mettre en place une sorte de streaming ou je décompresse les données sur quelques frames avant de pouvoir les envoyer.
Si j'ai pas le choix, je le ferai, mais si je peux m'en passer, je serais pas contre.
Metalion :
Enfin, il te reste les mappers megarom (ASCII ou Konami).
Très simples d'utilisation, ils te permettront de passer à 64K.
Très simples d'utilisation, ils te permettront de passer à 64K.
J'ai toujours pas regardé comment fonctionne les mappers et je voulais finir ce projet avant de me pencher sur la question.
Peut-être que je me complexifie la tâche pour rien, mais d'un autre coté, si on aimait pas la difficulté, on essayerai pas de faire des jeux aussi complexe pour nos chers MSX.
On est toujours ignorant avant de savoir.
En fait, en réanalysant mes données, je me dis que la meilleure compression serait surement un système de détection de patterns.
J'ai souvent des motifs binaires qui se répètent (sur un pas de 1 à plusieurs octets).
L'avantage de la technique, c'est que ça marcherait à la fois pour les zones vides (pleines de 0), mais aussi pour tous les autres patterns.
L'autre avantage c'est que la recherche de patterns est assez couteuse en compression (coté PC), mais très peu pour la décompression (coté MSX).
Si ça vous intéresse, je vous expliquerai la technique.
J'ai souvent des motifs binaires qui se répètent (sur un pas de 1 à plusieurs octets).
L'avantage de la technique, c'est que ça marcherait à la fois pour les zones vides (pleines de 0), mais aussi pour tous les autres patterns.
L'autre avantage c'est que la recherche de patterns est assez couteuse en compression (coté PC), mais très peu pour la décompression (coté MSX).
Si ça vous intéresse, je vous expliquerai la technique.
On est toujours ignorant avant de savoir.
JIPEMSX :
testé sur émulateur pour l'instant : il y a un bug de sprites quand on passe de 1 joueurs a 2 joueurs
Ah merci ! J'ai réussit à reproduire le bug.
C'est quand tu quittes une partie alors que le texte est affiché et que tu relances une partie.
Il manque une initialisation.
EDIT : C'est corrigé.
On est toujours ignorant avant de savoir.
j'ai testé sur mon MSX1 VG8010 avec la manette et ça fonctionne
petite remarque : est ce que le START ne pourrait t'il pas se trouver sous les lignes des choix au lieu d'être au dessus ?
exemple
petite remarque : est ce que le START ne pourrait t'il pas se trouver sous les lignes des choix au lieu d'être au dessus ?
exemple
Ce que je voulais, c'est surtout que le curseur soit par défaut sur le Start pour qu'on puisse commencer une partie très rapidement.
Hors, dans mon système de menu, c'est toujours la première entrée d'une page qui est sélectionnée par défaut.
C'est pour cette raison que j'ai mis le Start en premier.
Le scintillement des parties ombrées était un peu/beaucoup/trop visible ?
Hors, dans mon système de menu, c'est toujours la première entrée d'une page qui est sélectionnée par défaut.
C'est pour cette raison que j'ai mis le Start en premier.
JIPEMSX :
j'ai testé sur mon MSX1 VG8010 avec la manette et ça fonctionne
Le scintillement des parties ombrées était un peu/beaucoup/trop visible ?
On est toujours ignorant avant de savoir.
vu l'écran que j'utilise pour mes test je ne vois pas les scintillements 
au premier plan dans le slot cartouche on peux voir ma sram Elektor modifiée pour avoir une sauvegarde avec une capa gold
( le composant vert qui se trouve sur l'autre face de la cartouche )
au premier plan dans le slot cartouche on peux voir ma sram Elektor modifiée pour avoir une sauvegarde avec une capa gold
( le composant vert qui se trouve sur l'autre face de la cartouche )
Alors, j'ai pas encore implémenté le décompresseur coté MSX, mais voici déjà les gains cotés data :
Je suis sur un taux de compression moyen de 37% ; ce qui est bien vu la tronche des données.
Ca me débloque 1400 bytes ; ce qui est vraiment pas mal, mais certainement insuffisant pour finir le jeu.
Je vais m'occuper du décompresseur MSX (pour m'assurer que tout est OK), mais ensuite je vais peut-être devoir me pencher sur le problème des sprites (pas les joueurs, mais le reste).
A coté de ça, j'ai gagné aussi presque 1200 bytes en changeant ma config de build pour ne garder que les partie de ma lib dont j'avais besoin.
Ca sera toujours pas assez à mon avis, mais au moins, ça va permettre d'être tranquille quelques temps.
Je suis sur un taux de compression moyen de 37% ; ce qui est bien vu la tronche des données.
Ca me débloque 1400 bytes ; ce qui est vraiment pas mal, mais certainement insuffisant pour finir le jeu.
Je vais m'occuper du décompresseur MSX (pour m'assurer que tout est OK), mais ensuite je vais peut-être devoir me pencher sur le problème des sprites (pas les joueurs, mais le reste).
A coté de ça, j'ai gagné aussi presque 1200 bytes en changeant ma config de build pour ne garder que les partie de ma lib dont j'avais besoin.
Ca sera toujours pas assez à mon avis, mais au moins, ça va permettre d'être tranquille quelques temps.
On est toujours ignorant avant de savoir.
JIPEMSX :
vu l'écran que j'utilise pour mes test je ne vois pas les scintillements
Ca fait bien plaisir de voir son jeu sur un vrai MSX
On est toujours ignorant avant de savoir.
Finalement il aura pas fallu attendre longtemps pour une nouvelle version : Final Smash v0.2.08
Au programme (pas grand chose de visible) :
- Implémentation de l'algorithme de décompression coté MSX de mon format de compression (nommé P-RLE pour Pattern-based-RLE).
- Clean de code non utilisé
- Correction du bug de score qui restait affiché après un retour au menu
La décompression ajoute une toute petite attente avant de lancer un match ; mais ça me semble pas gênant.
Il me reste 2680 octets sur les 48K.
Ca me suffira certainement pas pour finir le jeu.
J'hésite sur la suite... je vais y réfléchir.
Au programme (pas grand chose de visible) :
- Implémentation de l'algorithme de décompression coté MSX de mon format de compression (nommé P-RLE pour Pattern-based-RLE).
- Clean de code non utilisé
- Correction du bug de score qui restait affiché après un retour au menu
La décompression ajoute une toute petite attente avant de lancer un match ; mais ça me semble pas gênant.
Il me reste 2680 octets sur les 48K.
Ca me suffira certainement pas pour finir le jeu.
J'hésite sur la suite... je vais y réfléchir.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie