Inscription : 15 Juin 2009, 09:00 Message(s) : 190
Le HUD en mode 0 Vertical , on est pas obligé me semble t-il .Après techniquement j'ai jamais compris comment ils avaient fait mais dans After the war le HUD est en mode 1 et le jeu himself est en mode 0 .... Donc C'est faisable ....
Inscription : 15 Juin 2009, 09:00 Message(s) : 190
Y a deux jeux que je trouve super pauvre pour notre cpc , c'est salamendar et airwolf2 ( dont j'adore la musique) .... Franchement ,comme dirait macdeath c'est speccy à mort ....Aucune couleur ( un peu mieux pour salamendar mais airwolf 2,ca serait du mode 2 ce serait pareil ....)
alors je t'explique : Mettre 2 zones de mode différent sur un même écran c'est faisible a condition que ça soit sur des lignes (rasters lines) différentes.
il faut donc un HUD "horizontale" et non vertical.
En théorie oui on peut plus ou moins faire un changement de Mode vertical, sauf que non ! enfin, euh, disont que c'est galère et pas forcément super exploitable.
Mais d'autres expliqueront ça mieux que moi.
Pour l'histoire, Antiriad aussi utilise 2 modes. Wec le Mans aussi... et plein d'autres en fait.
Le HUD en mode 0 Vertical , on est pas obligé me semble t-il .Après techniquement j'ai jamais compris comment ils avaient fait mais dans After the war le HUD est en mode 1 et le jeu himself est en mode 0 .... Donc C'est faisable ....
( corrigez moi si je me trompe ...)
Sauf que le changement de mode ce fait à la ligne... Tu ne peux pas dans un jeu changer le mode plusieurs fois sur une même ligne. Les contraintes sont trop grandes. Le changement de mode ce fait à la HBL.
Le HUD en mode 0 Vertical , on est pas obligé me semble t-il .Après techniquement j'ai jamais compris comment ils avaient fait mais dans After the war le HUD est en mode 1 et le jeu himself est en mode 0 .... Donc C'est faisable ....
Ouais, cette technique est également utilisée dans l’Armure Sacrée d’Antiriad et Gabrielle.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
J'étais bien tenté de répondre pour le mode mais je remet ce qui s'est dit plus haut :
TotO a écrit :
Un petit montage pour la route : (ne pas tenir compte de la partie de droite, je fais des essais)
PulkoMandy a écrit :
2)pour les sprites par recopie et pas par pointeur sur le plus : ce n'est pas possible autrement ! Je m'explique : Pour les trucs ajoutés dans le Plus, ils ont utilisé le "défaut" principal du CPC : le ralentissement du z80 par les accès à la mémoire vidéo par le CRTC/Gate Array. En effet sur la plupart des machines, le CPU n'est ralenti que lorsque la puce vidéo est vraiment en train de lire des pixels. Sur CPC, ils ont été au plus simple et le z80 est ralenti tout le temps. Sur CPC c'est du temps perdu quand on affiche du border et de la HBL/VBL. Sur Plus, l'ASIC met à profit le temps de HBL pour accéder à ses données. Petit calcul : sur une ligne on peut lire 1024 pixels mode 2 soit 128 octets. 80 sont utilisés par l'écran en mode standard. ça n'en laisse que 48 de disponibles (ce qui est déjà pas mal). Cependant, il est possible de faire de l'overscan (ou fullscreenborderless), et là, il ne reste plus grand chose. En pratique, l'ASIC ne fera des accès RAM que pendant la HBL ce qui lui laisse assez peu de bande passante en mémoire. Au final, il faut gérer avec ça les 3 canaux DMA pour le son, ce qui grignote encore un peu. Transférer les sprites avec les quelques octets restants aurait été encore plus lent qu'une recopie par le z80.
D'un autre côté, les plus malins auront remarqué qu'il reste plein de temps pendant la VBL. C'est vrai que ça aurait pu servir à transférer les sprites (qui ne changent a priori qu'une fois par VBL). ça aurait interdit le multiplexage. Il est probable compte tenu des infos dont on dispose que la bande passante disponible pendant la VBL ait été réservée à un éventuel DMA Disc qui n'a pas été implanté sur les puces (et qui est apparament présent en partie sur les premiers ASIC, ou certains octets permettraient de mettre en route le moteur du lecteur de disquettes).
Merci pour cette explication très intéressante.Sans à priori et juste pour ma curiosité, comment en est tu venu à cette conclusion ?
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
@fano : a force de lire quasar, d'écouter les récits de sceners en meeting, d'observer du code, de réfléchir un peu et de mettre tout ça en relation avec mes cours d'électronique à l'école.
Et oui en effet, les sprites sont stockés dans la page ASIC, pas dans la mémoire, donc il n'y a pas besoin d'accès RAM, donc ça peut être fait en dehors des HBL. Ce n'est qu'au moment ou l'ASIC veut accéder à la RAM/ROM qu'il doit respecter les priorités, on peut pas avoir tout le monde en même temps en train d'essayer d'accéder au BUS. en interne il fait ce qu'il veut
LE problème des sprites Hards du Plus, c'est que le mot sprite sert surtout pour les petit bonshommes qui se baladent dans les jeux, dans l'imaginaire des gens.
Or avec l'évolution des jeux vidéo, ces dernier sont devenus animés et gros (certains diront aussi "et en 3D"...lol).
Je pense qu'une définition plus "juste" serait de dire que l'Amstrad Plus possède des tuiles Hard.
Whaaa..on a 16 tuiles hard de premier plan sur le soft en 16x16 mode2 avec magnifiance x1/x2/x4 et possibilité de multiplex vertical, ajoutant 15 couleurs et des effets de transparence, et déplacement smooth.
Car il n'y a clairement pas les capacité pour en faire des superbes sprites de bonhommes animés et nombreux : ils sont lents a changer ou alors pas assez nombreux en réserve dans l'Asic, et pompent du data en Ram dans le cadre d'un jeux D7 (ou Rom en Cartouche, car en général on ne met pas de chargement d7 en cours de jeux) dès que l'on veut en utiliser plus de 16 en tout (sinon on les charge une fois quoi...).
Si on avait eut par exemple 32 slots (idéalement plus en fait) en mémoire dans l'Asic malgré le fait de n'en afficher que 16 ça aurait été bien plus exploitable par exemple pour des sprites animés justement. Et dans le cadre d'un soft sur D7...bin ça aurait au moins permis de faire une réserve de sprite lourd en Data donc grapiller de la Ram malgr un peu plus de chargement.
Ou bien sûr simplement qu'ils aient eut un système DMA ou la possibilité d'aller se servir eux même dans la mémoire (Ram ou Rom), ou de se changer plus rapidement... mais ça c'est encore autre chose.
Les sprites d'un C64 sont en 4 couleurs seulement (3+transparent me semble t'il) et sont donc bien moins gros aussi en Datas. Les MSX avaient des sprites Hards en "1 bit" (transparent+ 1 couleur). ils les exploitaient pour faire des bonhommes, il est vrai (et ce fut pas terribeule) mais surtout pour faire les tirs en fait (là ça le fait mieux)
Que sur Amstrad Plus, c'est limite un standard 16 bit avec les 16 couleurs et les magnification...ça prend vite de la place sur la Rom ou Ram que Amstrad à grapillé en restant cheap avec des version 64ko Ram et des cartouches en seulement 128Ko. Perso je pense que l'idéal c'est un Amstrad6256+, soit vraiment un demi 16 bit de l'époque (l'Atari 520STE divisé par 2 quoi). Pas tip top donc pour du gros tir de schmup en forte cadence, lol.
Bref déplaçables mais pas vraiment animables. En cela je trouve que la manière de les utiliser dans switchblade GX4000 fut réaliste et bien pensé (bien que pas encore assez exploitée, mais l'idée est là). Dans Prehistorik 2 aussi, les arbres, piliers ou nuages de premier plan, bien que je trouve qu'ils couvrent trop l'écran.
Alors qu'un Robocop 2 arrive bien sûr a en faire un usage massif, mais au final bin non, c'est mal. Il me semble que Robocop 2 n'utilise pas vraiment de sprites soft (pour les séquance d'action classiques) Robocop 2 est plus un jeux de plateforme pure qu'un réel jeux de run and gun (plus mario que Gryzor, voir carrément plus proche de JetSet Willy en fait) pour la simple raison qu'ils ne pouvaient pas afficher plus de 1-2 enemis à la fois.
Et les prisonniers en magnifié pixels 2x2 mode 1...bof quoi. Ou encore le saut pas animé de Robocop, euh..au moins il peut sauter dans cet opus, ce ne fut pas le cas dans robocop 1 qui en plus était tout de même légèrement lent...mais interessant évidament)
Bref plus les concevoir pour le décors et les effet de relief (premier plan) ou les merdouilles additionelles (bonus, special FX). Ce que fit d'ailleurs Fano pour Rick128+.
Sachant que honnètement un jeux pourtant mode1 avec une bonne utilisation de ces tuiles hard...bin honnètement y'a du potentiel inexploité je pense.
Shadow of the beast, il "suffit" (y'a qu'a faut qu'on) d'ajouter un poil de rasters pour certaines séquences (extérieurs, pour le ciel et la palissade du premier plan) et des fioritures en sprites hards (sachant que là les monstres sont pas boucoup animés d'ailleurs) et splortch, on a tout de suite un truc assez déspectrumisé (dé-rectumisé) a mon goût pour parraitre crédible. Ils ont tout de même fait l'éffort de soigneusement recoloriser les graphismes sur CPC, bin que s'eut put être mieux, et ils auraient surtout dùt virer ces 2 serpents de merde, lol, car ils empèchent toute rasterisation selon moi et pompent pas mal de tuiles en fait, tout en étant ridicules.
Et bien sûr pas mal de shooters de vaisseaux peuvent s'accomoder de tuiles déplaçables pour faire certains vaisseaux.
Sans compter les possibilité dans le cadre d'images fixes...Souvenez vous de Ghostbuster 2 avec ses petites images digitalisées Mode1 tirées du film... Bin là on peu les mettre en 15 couleurs, voir même facilement 15+4 en mélangeant avec des tuiles traditionnelles Mode1. Et faire alors plus gros que du 8x8 caractères Mode1 (16x16pix en 16 exemplaire, soit 4 sprites par 4 pour une image carré) en simplement patchant des images.
Une image Mode1 avec pleins de rasters et un patchage de "Tuiles Hard" pour masquer les ruptures horizontales tout en ajoutant de la couleur...ça devrait être super impressionnant je pense.
Bref il faut concevoir le sprite Hard sur amstrad plus d'une autre manière que sur les consoles (et arcades, avec du Full Hard plus puissant) ou que surtout le C64. Et faire preuve de plus d'inventivité donc.
Sachant qu'on reste sur un ordinateur traditionnel donc usage massif du soft hélas nécessaire.
En cela je trouve que Fano fut d'ailleurs peut être trop ambitieux avec son moteur de Wildfire qui fait selon moi trop appel au sprite Hard pour être réaliste. Mais je ne dit pas que ça n'est pas possible non plus, juste plus lourd a gérer au niveau du game design (les levels, etc...)
Un jeux comme déflector notament, qui pourtant utilise déjà un peu de raster et affiche 6 couleurs à l'écran me semble t'il, pourrait lui aussi être subtilement amélioré par un spritage discret (mais est-ce bien necessaire ?) pour les Gremlins ou le curseur notament.
Whaaa..on a 16 tuiles hard de premier plan sur le soft en 16x16 mode2 avec magnifiance x1/x2/x4 et possibilité de multiplex vertical, ajoutant 15 couleurs et des effets de transparence, et déplacement smooth.
Et horizontalement aussi tu peux le faire...
MacDeath26 a écrit :
En cela je trouve que la manière de les utiliser dans switchblade GX4000 fut réaliste et bien pensé (bien que pas encore assez exploitée, mais l'idée est là). Dans Prehistorik 2 aussi, les arbres, piliers ou nuages de premier plan, bien que je trouve qu'ils couvrent trop l'écran.
Alors qu'un Robocop 2 arrive bien sûr a en faire un usage massif, mais au final bin non, c'est mal. Il me semble que Robocop 2 n'utilise pas vraiment de sprites soft (pour les séquance d'action classiques) Robocop 2 est plus un jeux de plateforme pure qu'un réel jeux de run and gun (plus mario que Gryzor, voir carrément plus proche de JetSet Willy en fait) pour la simple raison qu'ils ne pouvaient pas afficher plus de 1-2 enemis à la fois.
Et les prisonniers en magnifié pixels 2x2 mode 1...bof quoi. Ou encore le saut pas animé de Robocop, euh..au moins il peut sauter dans cet opus, ce ne fut pas le cas dans robocop 1 qui en plus était tout de même légèrement lent...mais interessant évidament)
Dans switchblade oui c'est plus que bien (y'a plus qu'a passer le jeu en mode 0 et ca serait encore mieux selon moi).
Pour préhistorik2 l'utilisation des sprites fût fait de façon intelligente et suffisante, même si je suis d'accord sur le fait qu'ils cachent beaucoup le jeu en lui même (heureusement on peux les éteindre, comme quoi ca a été bien pensé).
Pour Robocop 2, je trouve justement que l'utilisation des sprites hard est très bonne. Du coup n'utilisant pas de sprites soft animés, le jeu est à 50Hz et plus que jouable. Cela reste un des meilleur jeu CPC+. Après on aime ou on aime pas. C'est vrai que notre Murphy a un balais dans le cul mais bon...
Tu oublies surtout Navy seals qui lui aussi n'utilise que des sprites hard et ce de façon parfaite. Les enemis sont la en nombre, suffisait juste de les placer de façon bien pensée pour qu'il n'y ai pas 50000 à la fois dans l'ecran. Pang lui aussi est une petite merveille de leur utilisation... Ah bein dis donc c'est marrant ca, on dirait bien que tous les jeux bien sur plus sont à 50Hz
Pour robocp2 je ne dit pas que c'est mal fait, juste que c'est mal, passque que perso j'aurai préféré un jeux un peu plus shooter genre gryzor ou Robocop1.
Mais oui Pang et navy seal laissaient présager mieux sur la gamme plus, si y'avais eut plus de jeux.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Merci pour les précisions les gars , c'est vrai que la connaissance de l'électronique permet de bien comprendre tout ça.Faudra vraiment que j'essaie d'apprendre un peu là dessus un jour. Sinon , si la HBL est trop courte pour que l'ASIC ait le temps d'éxécuter tout son code, ça fait quoi ?
MacDeath26 a écrit :
Je pense qu'une définition plus "juste" serait de dire que l'Amstrad Plus possède des tuiles Hard.
Pourquoi , le terme 'sprite' (lutin en Français) est accepté depuis des temps immémoriaux et nous sommes bien ici en présence de sprites.Tuiles (ou tiles) entend qu'elle sont liées entre elles comme dans une grille et non indépendants.
Après comme le dit Iron, si c'est bien géré , il n'y pas besoin non plus d'avoir des masses de sprites. Sinon , pour Wildfire , le prototype ne comprennait que les sprites Hard pour les enemis de taille petite à moyenne.Pour d'autre types d'objets il y a d'autres techniques
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 58 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
Connexion
Inscription
FAQ
au moins il peut sauter dans cet opus, ce ne fut pas le cas dans robocop 1 qui en plus était tout de même légèrement lent...mais interessant évidament)