Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Un nouveau sujet pour recenser les améliorations possibles pour ce jeu cpc :
- corriger les bugs signalés par les joueurs (du style les princesses sont quasi-impossibles à voir )-> OK - ajout de musiques pendant le jeu que les auteurs voulaient mettre ?! -> va falloir me donner un peu plus de détails
- gestion des banks supplémentaires pour éviter les chargements nombreux. - gestion du lecteur de disquette a et b -> fait le 02/04/2012 (ça m'a pris 5 minutes ) ! - une version amélioré avec des scènes en plus : princesses - une version cpc+ / cpc old avec des écran FullScreen - version traduites dans d'autres langues - version jouable depuis un disque 3"1/2 unique (Gestion de la double face) -> à voir si utile à la fin du projet (surtout si on utilise de la compression + les banks mémoire supplémentaires) - pour les combats entre armées : le faire comme Nord&Sud !
note de l'auteur : Oui 64Ko. J'aurais amélioré la jouabilité avec moins d'accès disque. Les trucs que j'ai foiré sur DoC: -Le déclenchement des scènes avec les princesses: un bug de dernière minute qui fait qu'on les voit presque jamais - Laurent doit me haïr pour ça! -> corrigé ! -L'anim des sprites pendant la joute. Trop haché. -> corrigé ! reste juste la dernière à revoir complétement
optimisation du code possible : - remplacer les CALL + RET par des JP : gain de place (un octet) et de vitesse d'exécution (5+3 -> 3 en nops) -> en cours -> très mauvaise idée, c'est volontaire et utilisé par certaines fonctions (ex : PLACARD) avec la pile pour les paramètres !!! donc si on remplace par un jp -> plantage ! - faire une table pour les enchainements simplement de call (exemple : je charge le screen, je l'affiche, j'affiche un message, etc.) : gain de place, légère perte de vitesse mais gros gain de place et de faciliter à faire évoluer ces enchainements. - faire une table également pour les chargements : face/disque, nom de fichier, type extension, adresse destination, checksum éventuel ou info sur le dé-compactage : éviter la redondance d'info, la centraliser dans une table et cela doit être plus facile à gérer et faire évoluer !
optimisation de la mémoire
répartition mémoire originale :
&0000 ] système + interruption z80 &003F ] &0040 ] zone tampon de chargement écran et sprites &3FFF ] &4000 ] code (main + routines diverses : affichage texte, sprites, player son/musique + gestion clavier) (&84FF ] pour l'instant le code va jusqu'ici mais j'ai viré du code pour le chargement en track de 6ko !) &8A00 ] code contextuel (joute, robin, raid, victoire, etc.) &A200 ] musique ou bruitage &A9FF ] &AA00 ] debut vecteurs système (appel amsdos, rom, etc.) &BFFF ] début pile &C000 ] zone écran &FFFF ]
le code chargé en &4000 ou en &8a00 contient systématiquement des datas (texte et petit sprite (ex : flèche))
proposition d'optimisation de la mémoire :
&0000 ] &0037 ] &0038 ] mise en place d'une interruption pour la gestion des couleurs, du clavier et de la musique/son -> nécessite que l'on ne se serve plus de l'amsdos ou des routines de la rom ! &0040 ] code principal et certaines sous-routines (exemple : gestions des chargements, affichage du menu ou écran) &3FFF ] &4000 ] datas (écran, sprites, musique et texte) et certaines routines (player musique ou affichage des sprites par exemple) avec gestion des banks supplémentaires &7FFF ] &8000 ] voir si mise en place d'un double buffer ? ou utilisation de cette zone mais nécessite de se passer d'amsdos et de remplacer toutes les routines de la rom ! &BFFF ] &C000 ] &FFFF ]
1) pour utiliser les banks, je vais commencer par extraire tous les datas textes (hors texte de changement de disquette car à terme il faudra surement charger/ou déplacer en &4000 pour alimenter les banks) -> OK 2) ensuite je ferrai de même avec la partie player et data musique 2a) il faut ressourcer le fichier defender.son au préalable !
ajout effectué et optimisation du code effectuée : cf changelog.txt - gestion du chargement en fichier (avec les vecteurs systèmes) -> OK - gestion du lecteur de disquette a et b -> -> OK
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Dernière édition par Megachur le 06 Mai 2012, 06:33, édité 16 fois.
Sinon déjà avoir une version jouable depuis un disque 3"1/2 unique (Gestion de la double face, gestion du lecteur B, bref gestion d'un disque en 720K...).
Et enfin sortir des version traduites dans d'autres langues afin d'en faire profiter nos amis du monde.
Je vote pour des scènes de sexe un peu plus explicites...
blagues à part... concrètement dans une première phase, il n'y a vraiment pas grand chose à "ajouter", juste des choses à corriger en fait.
le jeux de base était déjà vachement bien léché et fidèle aux version 16bit.
Citer :
- gestion du lecteur de disquette a et b -> fait le 02/04/2012 (ça m'a pris 5 minutes) !
ok donc en fait le lecteur depuis lequel tu lance le jeux devient le lecteur par défaut. Mais il n'y a pas encore une gestion plus poussée du fait d'avoir 2 lecteurs... ce qui pourrait faire gagner du temps sur les changements de faces... avec une face par lecteur (le jeux tenant sur 1 seul disk = 2 faces si il est gravé avec un lecteur kité...) Cela impliquera un peu plus d'option/menus pour paramétrer la gestion des multiples lecteurs, comme ça se faisait sur PC ou sur ST/Miga... parfois...
Mais hélas :
Citer :
- version jouable depuis un disque 3"1/2 unique (Gestion de la double face) -> à voir si utile à la fin du projet (surtout si on utilise de la compression + les banks mémoire supplémentaires)
cela rend tout simplement obsolète d'avoir vraiment besoin de 2 lecteurs... en tout cas avec la version actuelle je présume (il doit y avoir des subtilités dont je n'ai pas conscience sinon).
ou alors le jeux en 3"1/2 (720k) et un second lecteur (n'importe quoi tant qu'il marche) pour une D7 de sauvegardes...
C'est que bon, avec 2 faces de 360k = 720K, on est largement bon même avec un peu de truc en plus... reste que la gestion des pistes peut largement différer, de même que la façon d'accéder aux faces (plus besoin de demander de tourner le disk par contre...
Bref oui, pas forcément aussi trivial que ça.
Citer :
- ajout de musiques pendant le jeu que les auteurs voulaient mettre ?! -> va falloir me donner un peu plus de détails
les musiques étaient elles déjà faites ou ne peut on pas "simplement" ripper les zique Atari ST au pire... (ça serait déjà un bon début).
Ces musiques risquent par contre de prendre un peu plus de RAM et de CPU, donc une version 128K...
Citer :
- version traduites dans d'autres langues
Pour ça il faut voir si il vaut mieux ripper les datas depuis d'autres version (copier/coller, genre...) ou refaire les traductions à la main depuis le "fichier" des textes de la version CPC... Et alors demander chez CPCwiki de donner un petit coup de main... après tout c'est pour eux et en plus ils ont pleins de programmeurs chez nos voisins.
Citer :
Je vote pour une version amélioré avec des scénes en plus
Il faut alors voir si il ne faut pas attendre d'avoir une version old relativement finalisée (musiques, pas de bugs, gestions des différents lecteurs...) ou si il ne faut pas re-traivailler un peu plus en profondeur le jeux dans son ensemble...
En effet si c'est juste des scènes cinématiques, après tout c'est juste du "média Player"...
De même revoir la palette peut soit demander un palette swap basique, soit de la vrai retouche avec séparation des encres, re-dessinage, etc...
Et il serait bon de savoir si délocker les features PLUS (délocker l'ASIC) ne crée pas quelques bugs car il n'est pas dit que le code de départ fut bien prévu pour un ASIC unlocked aussi.
l'ajout de sprites Hards, ça devient de suite plus lourd aussi car pas mal de trucs à revoir dans les instruction au CPC et la gestion de la RAM (mais là on table sur la RAM en plus qui laisse de la marge, reste à voir pour le temps CPU mais là encore, c'est pas un shooter avec gros scrollings... mais un jeux relativement tour par tour...
hummm... tant qu'on est dans la gestion du lecteur de D7 "modernes" (à savoir en avoir 2 ou avoir un 3"1/2 en DD...) il serait bien alors d'avoir des version Disque dure ou "Cartouche 512K"/RomBox...
Citer :
euh, finalement, y'a pas foule qui est intéressé pour faire évoluer ce jeu ?
le problème c'est qu'il faut un seul programmeur chef de projet.
les autres collaborateurs ne seront que des donneurs d'idées ou suggestions (si d'autres programmeurs) ou des artistes qui fourniront en fonction des demandes du programmeur justement. Car c'est le programmeur qui définit la marge de manoeuvre du moteur et les spécifications...
Si tu ne peut pas avoir d'écrans en fullscreen pleins de rasters et de sprites hards, avec des couleurs qui cyclent... bin ça sert à rien qu'un "artiste" sorte ça de son derrière...
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
MacDeath26 a écrit :
le jeux de base était déjà vachement bien léché et fidèle aux version 16bit.
-> je vais rejouer à la version amiga pour voir cela !
MacDeath26 a écrit :
Citer :
- gestion du lecteur de disquette a et b -> fait le 02/04/2012 (ça m'a pris 5 minutes) !
ok donc en fait le lecteur depuis lequel tu lance le jeux devient le lecteur par défaut. Mais il n'y a pas encore une gestion plus poussée du fait d'avoir 2 lecteurs... ce qui pourrait faire gagner du temps sur les changements de faces... avec une face par lecteur (le jeux tenant sur 1 seul disk = 2 faces si il est gravé avec un lecteur kité...) Cela impliquera un peu plus d'option/menus pour paramétrer la gestion des multiples lecteurs, comme ça se faisait sur PC ou sur ST/Miga... parfois...
euh, je ne sais pas si tu as vraiment testé... en effet si tu lances le jeu depuis le lecteur B, tu peux l'utiliser comme seul lecteur... mais si tu mets un autre dsk sur le lecteur A, la modification que j'ai faite, le gérera sans pb -> merci de retester !!!
MacDeath26 a écrit :
Mais hélas :
Citer :
- version jouable depuis un disque 3"1/2 unique (Gestion de la double face) -> à voir si utile à la fin du projet (surtout si on utilise de la compression + les banks mémoire supplémentaires)
cela rend tout simplement obsolète d'avoir vraiment besoin de 2 lecteurs... en tout cas avec la version actuelle je présume (il doit y avoir des subtilités dont je n'ai pas conscience sinon).
ou alors le jeux en 3"1/2 (720k) et un second lecteur (n'importe quoi tant qu'il marche) pour une D7 de sauvegardes...
en fait, la refonte de la partie chargement, sera faite si on enlève l'utilisation de l'AMSDOS pour charger les fichiers. une fois fait, gérer un disque 3p 1/2 double face ne sera pas un pb !!!
MacDeath26 a écrit :
Citer :
- ajout de musiques pendant le jeu que les auteurs voulaient mettre ?! -> va falloir me donner un peu plus de détails
les musiques étaient elles déjà faites ou ne peut on pas "simplement" ripper les zique Atari ST au pire... (ça serait déjà un bon début).
Ces musiques risquent par contre de prendre un peu plus de RAM et de CPU, donc une version 128K...
on a le choix : soit convertir les musiques ST (le code de 68000 en z80), soit en YM avec un player (prend un peu plus de place mais moins de cpu à priori), soit les refaire en starkos ou autres format cpc !
MacDeath26 a écrit :
Citer :
- version traduites dans d'autres langues
Pour ça il faut voir si il vaut mieux ripper les datas depuis d'autres version (copier/coller, genre...) ou refaire les traductions à la main depuis le "fichier" des textes de la version CPC... Et alors demander chez CPCwiki de donner un petit coup de main... après tout c'est pour eux et en plus ils ont pleins de programmeurs chez nos voisins.
une de mes premiers changements va être d'extraire tous les textes du code pour les mettre en bank surement (cf optimisation mémoire)
MacDeath26 a écrit :
Citer :
Je vote pour une version amélioré avec des scénes en plus
Il faut alors voir si il ne faut pas attendre d'avoir une version old relativement finalisée (musiques, pas de bugs, gestions des différents lecteurs...) ou si il ne faut pas re-traivailler un peu plus en profondeur le jeux dans son ensemble...
En effet si c'est juste des scènes cinématiques, après tout c'est juste du "média Player"...
si ça intéresse effectivement un artiste cpc de faire un ou des propositions complètes, j'attends ses fichiers écran et sprites/anim !!!
MacDeath26 a écrit :
Et il serait bon de savoir si délocker les features PLUS (délocker l'ASIC) ne crée pas quelques bugs car il n'est pas dit que le code de départ fut bien prévu pour un ASIC unlocked aussi. l'ajout de sprites Hards, ça devient de suite plus lourd aussi car pas mal de trucs à revoir dans les instruction au CPC et la gestion de la RAM (mais là on table sur la RAM en plus qui laisse de la marge, reste à voir pour le temps CPU mais là encore, c'est pas un shooter avec gros scrollings... mais un jeux relativement tour par tour...
pour la version CPC+, à voir, mais si on fait sur old déjà se sera pas mal !
MacDeath26 a écrit :
Citer :
euh, finalement, y'a pas foule qui est intéressé pour faire évoluer ce jeu ?
le problème c'est qu'il faut un seul programmeur chef de projet.
les autres collaborateurs ne seront que des donneurs d'idées ou suggestions (si d'autres programmeurs) ou des artistes qui fourniront en fonction des demandes du programmeur justement. Car c'est le programmeur qui définit la marge de manoeuvre du moteur et les spécifications...
Si tu ne peut pas avoir d'écrans en fullscreen pleins de rasters et de sprites hards, avec des couleurs qui cyclent... bin ça sert à rien qu'un "artiste" sorte ça de son derrière...
je veux bien, pour l'instant, regarder ce qui est possible de faire... on verra ensuite, selon la profondeur des modifications, si il y a pas d'autres programmeurs qui veulent aider !
Petite remarque pour les musiques. Le format YM est à mon avis à exclure, trop gourmand en place. Les musiques étant principalement jouées pendant des introductions, la notion de vitesse n'est pas forcément importante. Si vous partez des versions ST/Amiga (que je ne connais pas), un portage Arkos Trakker ou Starkos semble indiqué (ou tout autre player plus compact).
Faire tenir le jeu sur deux faces (avec éventuellement une troisième pour l'introduction) serait un plus. On pourrait avec deux lecteurs se passer de swap, ce qui serait une belle avancée ! Ca doit être peut-être possible avec les crunchers actuels, même si je crains que les images d'introduction ne se compressent pas très bien (beaucoup de couleurs et de tramages).
J'ai joué un peu hier soir avec le jeu, c'est clair que le combat à l'épée est un peu simpliste. Mais bon, ce n'est pas forcément le coeur du jeu.
pour la version CPC+, à voir, mais si on fait sur old déjà se sera pas mal !
le truc c'est que pour une fois qu'on a des sources complet avec conseils des créateurs en prime, et le tout pour un style de jeux qui fait la part belle aux beaux graphismes... ça serait plus que dommage de ne pas en profiter pour offrir au PLUS une pièce de choix dans sa maigre ludothèque, sachant que sans trop se mouiller on arrivera bien a un résultat assez proche de l'Amiga (juste des graphismes un poil plus blocky par contre)...
je veux dire, de l'overscan, des rasters, quelques patches en sprites PLUS... les pages de cinématique non animée peuvent vraiment devenir magnifiques malgré les gros pixels Mode0.
Moi j'avais ce jeux en version PC CGA... donc euh... là on vas l'éclater cette version PC CGA (et EGA!), et la version ST en prime (ils devront nous pondre une version STE ou Falcon si ils veulent mieux faire !)
Tiens d'ailleurs, une petite idée : des "samples DMA PLUS"... genre du bruit de cavalcade, de combats, de clairons... Bon ne nous avançons pas trop non plus, lol.
Citer :
je veux bien, pour l'instant, regarder ce qui est possible de faire... on verra ensuite, selon la profondeur des modifications, si il y a pas d'autres programmeurs qui veulent aider !
Voilà, déjà dégrossir l'analyse du code, rajouter des commentaires en plus de ceux des créateurs, et expliquer un peu son architecture et essayer de voir les marges de manoeuvres, et surtout débugger les quelques petits bugs...
Après si ce travail préliminaire est fait, d'autres codeurs pourront dire si ils sont partant pour s'en occuper si il y a des mods plus lourds à faire... voire répartir les taches.
Mais il ne faut pas que plusieurs fassent ça chacun dans leur coin et que ça devienne ensuite la guerre des releases.
Citer :
Faire tenir le jeu sur deux faces (avec éventuellement une troisième pour l'introduction) serait un plus. On pourrait avec deux lecteurs se passer de swap, ce qui serait une belle avancée ! Ca doit être peut-être possible avec les crunchers actuels, même si je crains que les images d'introduction ne se compressent pas très bien (beaucoup de couleurs et de tramages).
Franchement, entre ceux qui ont un HxC floppy disk emulator, et ceux qui ont une vieille nappe de lecteur 5"1/4+quelques jumpers et une alim 5V pour un vieux lecteur 3"1/2 (et une boite de D7 vièrges neuves...)
installer un lecteur externe B en 3"1/2 c'est vraiment super facile en fait. il n'y a même pas de modifs à faire sur le cable..2-3 jumpers en fait) il faut juste réussir a cannibaliser une vieille machine et donc avoir le cable et le lecteur (et l'alim...).
soient des éléments qui sont en fait généreusement offerts dans la moindre convention Démoparty.
à l'Alchimie111111 ils en donnaient plein, j'ai moi même un stock de lecteur de D7 3"1/2 et des nappes pour lecteur 5"1/4... qui sont donc des nappes pour lecteur 3"1/2 sur amstrad au final...
En plus il faut se dire que si on remplace les graphismes existant (passage en fullscreen) bin ça ne doublerai pas vraiment la place total en fait. la surface de graphismes nécessaires pour couvrir un écran fullscreen, c'est 24k et non pas 2x16k... (même si ça pompe 32K de RAM me semble t'il).
720ko par D7 c'est quand même assez gros pour un CPC. C'est même presque gigantesque.
à moins de viser une version PLUS avec moult sons samplés, pleins de ziques non moins DMA, et le jeux intégralement en fullscreen... et un usage très massif des sprites Hards (patches grahiques, animations, curseur souris animé...) c'est même pas dit que les 720K ne suffisent pas largement.
Et quand bien même on utiliserait 2 disk en 3"1/2... et bien les changement de disk seraient optimisables et donc ne gèneraient pas le jeux.
si les version cracked classiques utilisaient 3-4 faces de D7 et avaient alors besoin constant de changer les faces, c'est surtout qu'il y avait la volonté des codeurs derrière ça car cela faisait partis du système de protection.
Et qu'à l'époque quasi personne n'avait de lecteur 3"1/2 sur son CPC, ni même de second lecteur de D7 en externe (pour les possesseurs de 664 et 6128).
Mais bon c'est vrai qu'il faut quand même prévoir une version "stock CPC" off the shelf... au cas où.
or là on ne cherche pas a plomber le jeux, donc ça sera optimiser logiquement si le nouveau codeur fait son boulot, et on est plus à l'époque des CPC en 64K de RAM non plus. on a presque tous des 6128 me semble t'il..au moins en France et en Allemagne), les sceners ayant aussi souvent accés a des extension de RAM ou autre...
Citer :
voir si mise en place d'un double buffer ? ou utilisation de cette zone mais nécessite de se passer d'amsdos et de remplacer toutes les routines de la rom !
Quel intéret auraient on a un double buffer ? ça pompe du CPU ou de la RAM ? l'affichage est plus "fluide" ou plus confortable ?
le jeux ne garde t'il pas en permanence les info relative au jeux quelque part en RAM ? l'avantage d'avoir les 128K de "dispo" c'est qu'alors on peut mettre un "bankswitch" avec les infos relatives au jeux dans un coin au chaud, et avoir la RAM CPU de dispo pour les "vidéos".
un loader à la sauce Batman begin pour avoir de la zique pendant des chargements c'est possible ?
Enfin bon, ça va te faire du boulot quand même tout ça. à combien évalurais-tu les délais, Megachur ?
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
Le premier travail identifié est évidemment de corriger le bug des princesses. (autres ?) Je partage l'idée de voir deux versions : CPC et CPC+. (reposant sur le même jeu)
Maintenant, quitte à revoir les adressages mémoires, pourquoi ne pas faire une ROM de 512K avec 64K de RAM pour ces derniers ? Ainsi, le jeu serait jouable sur toute la game, sans temps de chargement.
Concernant le CPC, il est effectivement tellement courant d'utiliser un lecteur 3"1/2 qu'un format "720K" sur une seule disquette serait à privilégier. La version 3", après tout, c'était celle de l'époque.
EDIT: Il me semble aussi que l'un des personnages est plus "fort" que les autres. Ca avait été corrigé dans la version CDTV entre autre. (DotC2)
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
euh, j'entends parler de bugs depuis pas mal de temps : mais quels sont-ils exactement ? Est-ce que vous pouvez être plus précis sur la description de ces vilaines bêtes ?
difficile de corriger un truc genre "le bug des princesses" !!!
Moi, y'a un truc qui me gonfle dans le jeu mais je ne sais pas si c'est un bug : c'est la conquête d'un territoire ennemi sans armée où on est qd même obliger de combattre et de perdre un soldat alors qu'il y a 0 soldat en face !!!
côté jouabilité, la partie épée, pourrait être un peu mieux également -> très difficile de gagner !
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
Megachur a écrit :
difficile de corriger un truc genre "le bug des princesses" !!!
Parfois une princesse se fait kidnapper, et l'on te propose de la sauver. Mais sur CPC, tu ne vois pas (ou rarement ?) la séquence correspondante parce qu'il y a donc un "bug".
Concernant la force des personnages, en considérant par exemple que : Faible = 1, Moyen = 2, Bon = 3, Fort = 4 Si tu fais la somme de chaque personnage, il y en a un qui a 1 point de plus que les autres. Sur DotC2 (qui n'est que le 1 avec des correctifs et des séquences en plus), tout le monde est au même niveau.
Megachur a écrit :
Moi, y'a un truc qui me gonfle dans le jeu mais je ne sais pas si c'est un bug : c'est la conquête d'un territoire ennemi sans armée où on est qd même obliger de combattre et de perdre un soldat alors qu'il y a 0 soldat en face !!!
C'est lourd en effet... Autant corriger si ça n'a pas d'influence sur le gameplay.
faudrait mater des longplays des autres version aussi, ça peut être intéressant, notament des longplays solutions avec commentaires...
Citer :
Il me semble aussi que l'un des personnages est plus "fort" que les autres.
en fait chacun des perso est spécialisé, ce qui influance sur la manière optimum pour jouer (donc des stratégies différentes).
je me souviens qu'on peu même gagner en abusant sur les tournois...
Mais l'un des perso est légèrement au dessus des autres si on fait le total des "points de compétences"... sachant que le système n'est pas non plus du niveau d'un gros WRPG.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 56 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum