La Place des Développeurs Projet GOS Et oui, encore trop d'ambitions ^^
Reprise du message précédent
ericb59 :
Pour le mode transparent, je l’avais fait LMMC, c’est un peut plus lent que HMMC.
LMMC est surtout lent pour les modes 4-bits par couleur (comme les screen 5 et 7) et le mode 2-bits par couleur (comme le screen 6) car on doit envoyer 2 et 4 fois plus de data respectivement.
Metalion :
J'ai déjà eu ce problème ... Impossible de placer les tables au delà de 10000h, ça plantait.
Dans mon cas, c'était un bug dans mon code (un shift d'une mauvaise valeur).
Par contre, j'ai découvert un truc marrant.
Je pensais que les bit#7 à 9 de l'adresse de SAT devaient toujours être à 1 sur le V9938 pour que les sprites s'affichent.
C'est bien le cas du bit#9, mais les bits bit#7 et 8 ont un comportement différent ; ils semble modifier la façon dont est géré les couleurs des sprites.
En tout cas, en jouant avec des bits (pas de vilain jeu de mot
) on a des effets intéressants.Je vais creuser la question pour voir si c'est exploitable ou pas.
On est toujours ignorant avant de savoir.
@aoineko:
Tips ou pas ! J'ai simplifié ma routine de Print. Il s'avère que le décodage des caractères sur 8bits pour le Screen8 s'affiche parfaitement via un LMMC en screen 8... Mais aussi en screen mode 5,6 et 7 sans modification de code. Bien sur ca prend exactement le même temps d'affichage pour chaque screen mode, on a pas l'avantage de gagner du temps de décodage sur les modes avec moins de couleurs, mais c'est plus simple à gérer (pour moi) et permet le mode transparence en toute simplicité
Edité par
ericb59
Le 19/01/2021 à 19h52
Tips ou pas ! J'ai simplifié ma routine de Print. Il s'avère que le décodage des caractères sur 8bits pour le Screen8 s'affiche parfaitement via un LMMC en screen 8... Mais aussi en screen mode 5,6 et 7 sans modification de code. Bien sur ca prend exactement le même temps d'affichage pour chaque screen mode, on a pas l'avantage de gagner du temps de décodage sur les modes avec moins de couleurs, mais c'est plus simple à gérer (pour moi) et permet le mode transparence en toute simplicité
Edité par
ericb59
Le 19/01/2021 à 19h52
Si tu envois toujours 8 x 8 bytes quelque soit le mode graphique, le LMMC marchera effectivement.
Mais bon, envoyer 64 bytes par caractère pour un mode comme le screen 6 qui n'en demande que 16, c'est contre ma religion.
(même s'il est probable que ça change pas grande chose à la vitesse vu qu'on est surtout ralenti par le CPU pour le décodage)
Mais bon, envoyer 64 bytes par caractère pour un mode comme le screen 6 qui n'en demande que 16, c'est contre ma religion.
(même s'il est probable que ça change pas grande chose à la vitesse vu qu'on est surtout ralenti par le CPU pour le décodage)
On est toujours ignorant avant de savoir.
Voila un proof-of-concept dans lequel j'ai intégré tout ce que j'ai ajouté à ma lib :
- Les sprites (pour le curseur du joueur qu'on peut switch avec Graph/Alt)
- Les print via les sprites (pour les textes en surimpression : scrore / timer)
- La musique (5 KB)
- Les bruitages (banque de 20 sons)
Le tout rentre dans une cartouche de 32 KB avec 1,5 KB de marge (de toute façon, je compte toujours m'installer en page 0 à la place du BIOS donc je peux monter à 48K si besoin).
Ca tourne à 12 FPS (j'espère monter à 16) sur un MSX2 avec 128K de VRAM.
Voici : gos_0_3.rom.
Ca serait cool si vous pouviez la tester sur de vrais machines voir si tout marche bien.
EDIT : J'ai repéré un soucis avec le sprite du curseur. Je checkerai ça ce soir.
- Les sprites (pour le curseur du joueur qu'on peut switch avec Graph/Alt)
- Les print via les sprites (pour les textes en surimpression : scrore / timer)
- La musique (5 KB)
- Les bruitages (banque de 20 sons)
Le tout rentre dans une cartouche de 32 KB avec 1,5 KB de marge (de toute façon, je compte toujours m'installer en page 0 à la place du BIOS donc je peux monter à 48K si besoin).
Ca tourne à 12 FPS (j'espère monter à 16) sur un MSX2 avec 128K de VRAM.
Voici : gos_0_3.rom.
Ca serait cool si vous pouviez la tester sur de vrais machines voir si tout marche bien.
EDIT : J'ai repéré un soucis avec le sprite du curseur. Je checkerai ça ce soir.
On est toujours ignorant avant de savoir.
Super sympa... Mais y a un bug... J'trouve pas le ballon 
Les bruitages ? Pas entendu faut faire quelque chose peut être ?
La vitesse, ne me choque pas du tout, ca pourrait faire un bon kick off ça !
Ben ils ont tous 128K de Vram !?
Les bruitages ? Pas entendu faut faire quelque chose peut être ?
La vitesse, ne me choque pas du tout, ca pourrait faire un bon kick off ça !
Citation :
(j'espère monter à 16) sur un MSX2 avec 128K de VRAM.
Ben ils ont tous 128K de Vram !?
ericb59 :
Ben ils ont tous 128K de Vram !?
Non ... La norme minimum pour le MSX2 c'est 64K de VRAM, avec en option 128K ou 192K. Mais c'est vrai que les machines avec seulement 64K de VRAM étaient rares, et ont principalement vendues au Japon et en Argentine:
Canon V-25
Hitachi MB-H3
Sanyo MPC-25F
Talent TPP-311
Talent TPS-312
Toshiba HX-23
Le MSX-Magazine déconseillait de les acheter, car certains modes graphiques ne pouvaient pas être activés complètement. Edité par Metalion Le 26/01/2021 à 20h40
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)
ericb59 :
Super sympa... Mais y a un bug... J'trouve pas le ballon
Ca vient, ça vient
ericb59 :
Les bruitages ? Pas entendu faut faire quelque chose peut être ?
Tu as un "pouet pouet" quand tu changes de joueur avec Graph/Alt.
C'est la même banque de son que mon sample qui mix PT3 et ayFX.
ericb59 :
La vitesse, ne me choque pas du tout, ca pourrait faire un bon kick off ça !
Tu as essayé sur un vrai MSX ?
On est toujours ignorant avant de savoir.
@metalion, oui je sais bien. Mais ce sont les exceptions qui confirment la règle, qui se soucie de ces machines de nos jours
@aoineko, non mais Je testerai dès que possible sur un MSX2
@aoineko, non mais Je testerai dès que possible sur un MSX2
Ca à l'air de pas avoir progresser, mais en fait j'ai refait tout mon système de gestion des différentes entités pour avoir quelque chose de plus propre et optimisable.
Et... j'ai ajouté le ballon.
Bon pour le moment on peut rien en faire, mais ça viendra.
Voici la version 0.4 : gos_0_4.rom
Comme d'hab, si vous pouvez tester sur de vrais MSX (>= 2) que ça fonctionne bien, je suis preneur (j'ai coupé la musique dans cette version).
J'en ai profité pour clean mes propres outils et les renommer pour les retrouver plus facilement :
CMSXimg 1.9.1 (anciennement MSXimage)
- Un outil en ligne de commande pour exporter et compresser des blocs d'image
- La nouvelle version support le format de couleur 2-bits (4 couleurs) et l'export de divers tableaux (fonts header, index des sprites, copyright, etc.)
- La doc est dispo en français sur le wiki : http://msxvillage.fr/wiki/wiki.php?title=cmsximg
- Source et exécutable : https://github.com/aoineko-fr/CMSXimg
CMSXbin 1.1.0 (anciennement bin2h)
- Un outil en ligne de commande pour convertir un fichier binaire en fichier texte à inclure dans un code source
- La nouvelle version permet de skip des parties du fichier binaire (utile pour virer les 99 octets d'entête des fichiers PT3 par ex.)
- Source et exécutable : https://github.com/aoineko-fr/CMSXbin
CMSXmath 1.4.1 (anciennement MathTable)
- Un outil en ligne de commande pour générer des tables précalculés d'opérations mathématiques
- La nouvelle version inclus la génération de tableau de "mapping" (par ex., on peut faire correspondre un intervalle [0:31[ à [0:100] sans avoir besoin de faire des calculs)
- Source et exécutable : https://github.com/aoineko-fr/CMSXmath
Et... j'ai ajouté le ballon.
Bon pour le moment on peut rien en faire, mais ça viendra.
Voici la version 0.4 : gos_0_4.rom
Comme d'hab, si vous pouvez tester sur de vrais MSX (>= 2) que ça fonctionne bien, je suis preneur (j'ai coupé la musique dans cette version).
J'en ai profité pour clean mes propres outils et les renommer pour les retrouver plus facilement :
CMSXimg 1.9.1 (anciennement MSXimage)
- Un outil en ligne de commande pour exporter et compresser des blocs d'image
- La nouvelle version support le format de couleur 2-bits (4 couleurs) et l'export de divers tableaux (fonts header, index des sprites, copyright, etc.)
- La doc est dispo en français sur le wiki : http://msxvillage.fr/wiki/wiki.php?title=cmsximg
- Source et exécutable : https://github.com/aoineko-fr/CMSXimg
CMSXbin 1.1.0 (anciennement bin2h)
- Un outil en ligne de commande pour convertir un fichier binaire en fichier texte à inclure dans un code source
- La nouvelle version permet de skip des parties du fichier binaire (utile pour virer les 99 octets d'entête des fichiers PT3 par ex.)
- Source et exécutable : https://github.com/aoineko-fr/CMSXbin
CMSXmath 1.4.1 (anciennement MathTable)
- Un outil en ligne de commande pour générer des tables précalculés d'opérations mathématiques
- La nouvelle version inclus la génération de tableau de "mapping" (par ex., on peut faire correspondre un intervalle [0:31[ à [0:100] sans avoir besoin de faire des calculs)
- Source et exécutable : https://github.com/aoineko-fr/CMSXmath
On est toujours ignorant avant de savoir.
Voici la version 0.5 de GOS (alias Gods of Soccer) : gos_0_5.rom
Au menu :
- Le joueur peut récupérer la balle et tirer (Space=shoot, Graph/Alt=petit tir... ça sera la passe plus tard).
- La balle a une physique ultra basique (uniquement un frottement ; elle n'a pas encore de hauteur ni d'effet).
- Les joueurs sont maintenant triés pour qu'ils s'affichent dans le bon ordre (pour que les bitmap se superpose de façon cohérente).
- J'ai fait un scrolling "smooth" pour que la caméra suive la balle avec un petit retard (mais elle va pas assez vite pour suivre la balle avec les paramètres actuels).
Ca serait vraiment cool si vous pouviez tester sur de vrais MSX2 (128K de VRAM) pour être sûr qu'il n'y a pas de soucis.
Au menu :
- Le joueur peut récupérer la balle et tirer (Space=shoot, Graph/Alt=petit tir... ça sera la passe plus tard).
- La balle a une physique ultra basique (uniquement un frottement ; elle n'a pas encore de hauteur ni d'effet).
- Les joueurs sont maintenant triés pour qu'ils s'affichent dans le bon ordre (pour que les bitmap se superpose de façon cohérente).
- J'ai fait un scrolling "smooth" pour que la caméra suive la balle avec un petit retard (mais elle va pas assez vite pour suivre la balle avec les paramètres actuels).
Ca serait vraiment cool si vous pouviez tester sur de vrais MSX2 (128K de VRAM) pour être sûr qu'il n'y a pas de soucis.
On est toujours ignorant avant de savoir.
Testé sur VG8235. OK
La caméra suit la balle, mais attention que le joueur controlé ne finisse pas par se retrouver hors champ.
Je l'ai fait exprès, je sais, mais faut tester tout ! Je pense que tu devrais arrêter de recentrer la caméra si le joueur controlé se trouve en bordure d'écran.
La caméra suit la balle, mais attention que le joueur controlé ne finisse pas par se retrouver hors champ.
Je l'ai fait exprès, je sais, mais faut tester tout ! Je pense que tu devrais arrêter de recentrer la caméra si le joueur controlé se trouve en bordure d'écran.
ericb59 :
Testé sur VG8235. OK
Merci
ericb59 :
La caméra suit la balle, mais attention que le joueur controlé ne finisse pas par se retrouver hors champ.
Je l'ai fait exprès, je sais, mais faut tester tout ! Je pense que tu devrais arrêter de recentrer la caméra si le joueur controlé se trouve en bordure d'écran.
Je l'ai fait exprès, je sais, mais faut tester tout ! Je pense que tu devrais arrêter de recentrer la caméra si le joueur controlé se trouve en bordure d'écran.
Ce que font les jeux de foot moderne -- et ce que je compte faire -- c'est de laisser le joueur pouvoir sortir du champ de la caméra quand il a pas le ballon.
Par contre, il faudra que l'icone de sélection du joueur s'affiche au bord de l'écran pour montrer vers ou se trouve le joueur.
Le gros problème actuellement, c'est surtout que la balle va beaucoup plus vite que la caméra !
Je vais corriger ça ce soir.
On est toujours ignorant avant de savoir.
Bon, les amis, je suis face à un mur pour ce projet. 
Je pensais être limité par les capacités d'affichage du V9938 mais mes tests étaient assez concluant.
C'était pas super rapide, mais j'étais très agréablement surpris d'arriver à tout faire tenir en VRAM, à avoir un scrolling potable et à faire bouger 14 personnages bitmap en même temps (à 12,5 Hz).
Mes fonctions d'affichage sont bien optimisés donc le surcout à utiliser le C est assez faible.
Ce que j'avais sous-estimé, c'est le cout des opérations mathématiques (même simples) pour le CPU.
Là, même en optimisant bien, le C tue complètement les performances et je me retrouve avec 6 frames d'affichage pour 1 cycle gameplay... cycle durant lequel, je fais pas la moitié des opérations dont j'aurais besoin pour le jeu complet.
Je pense qu'en assembleur il y aurait moyen de faire tenir toute la logique de l'IA dans le temps de 4~6 frames d'affichage, mais si je continue en C, je vais me retrouver avec un jeu vraiment trop lent.
Je vais laisser reposer en paix le projet GOS et je vais réfléchir à quelque chose de plus réaliste.
La bonne nouvelle, c'est que j'ai maintenant un lib assez complète.
Et je compte bien en faire quelque chose !
Peut-être le jeu de tennis que j'avais en tête au départ.
Je pensais être limité par les capacités d'affichage du V9938 mais mes tests étaient assez concluant.
C'était pas super rapide, mais j'étais très agréablement surpris d'arriver à tout faire tenir en VRAM, à avoir un scrolling potable et à faire bouger 14 personnages bitmap en même temps (à 12,5 Hz).
Mes fonctions d'affichage sont bien optimisés donc le surcout à utiliser le C est assez faible.
Ce que j'avais sous-estimé, c'est le cout des opérations mathématiques (même simples) pour le CPU.
Là, même en optimisant bien, le C tue complètement les performances et je me retrouve avec 6 frames d'affichage pour 1 cycle gameplay... cycle durant lequel, je fais pas la moitié des opérations dont j'aurais besoin pour le jeu complet.
Je pense qu'en assembleur il y aurait moyen de faire tenir toute la logique de l'IA dans le temps de 4~6 frames d'affichage, mais si je continue en C, je vais me retrouver avec un jeu vraiment trop lent.
Je vais laisser reposer en paix le projet GOS et je vais réfléchir à quelque chose de plus réaliste.
La bonne nouvelle, c'est que j'ai maintenant un lib assez complète.
Et je compte bien en faire quelque chose !
Peut-être le jeu de tennis que j'avais en tête au départ.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie