une belle image Mode0 avec la superbe palette PLUS (Amiga ou STE donc). => Non, dessin de Ced transferé sur CPC via ConvImgCpc J'aime bien le fait que les yeux clignent, c'est le petit détail qui manquait un peu sur wake Up je trouve. => Moi aussi j'aime bien
0:10 les boules sont du sprite Hard avec raster (changement de palette des sprites) et multiplexage vertical. Ils sont en résolution "Mode1" ou "mode2" ? => Je crois mode 2 mais je dois verifier ... a vue de nez il y a 12 boules maxi par ligne... à voir. => 16 boules maxi par ligne mais j'en ai peut-être utilisé moins
0:18 Ensuite on a un Crâne ailé ondulant... c'est aussi du sprite Hard avec effet de distortion. Pas de "multiplexage" mais changement des coordonnées pour chaque scanline... => Un petit split quand même quand le crane "descend" un sprite est moitié afficher en haut, moitier en bas les Pixels c'est du Mode0 ou Mode1 ou un mix des deux ? => Mode 0 en X et en Y je crois mais pareil je dois verifier (il me semble que j'utilise des pixels carrés) Je ne sais pas si c'est possible niveau CPU mais il me semble que l'image aurait pu être étendu verticalement (Multiplexage donc) pour faire toute la hauteur, donc plusieurs cranes en fait, défilant verticalement. à moiins que l'ondulation soit déjà un effet contraignant trop sur les Sprites hards. => s'eut été possible en effet (si on fait du précalcul des ondulations) mais je ne voyais pas d'interêt à le faire
0:40 : 16 boules... classique usage des sprites Hards, c'est beau, effet de profondeur par les couleurs (foncée en profondeur, plus clair en foreground) qu'il faut alors gérer. => Classique mais pas si facile, la matrice de rotation est tordu (pas de multiplications pour le z80) et l'algo de tri en profondeur doit être assez rapide => L'idée des boules de plus en plsu foncées dans la profondeur est une idée de Ced (Merci à lui)
2:00 les sprites sont utilisés pour mettre un patch/fenètre d'image rotative/zoom. Je suppose alors que l'on doit uploader ça au fur et à mesure que l'on le calcule... combien de sprites sont utilisés pour la fenètre Sprite hard ? ça à l'air Mode0 niveaux pixels... voire magnifié 4x2 (mode0 horizontal et 2 vertical = gros pixels carrés) . => Double buffering = 4 Sprites (Buffer 1) & 4 Sprites (Buffer 2) : On affiche un buffer pendant qu'on en calcule un autre => Pixels carrés mode 0 je crois
2:30 une bonnasse mode0 qui cligne des yeux. Elel est en premier plan, car le texte lui passe derrière (un peu de masquesclassique ou fait avec quelques sprites Hards ? => Yes, mais le masque est chargé pour chaque ligne (elle est trop grande pour du sprite) => Donc je superpose des sprites hard sur l'image de la nana avec la même image mais un fond transparent D'ailleurs pas de sprites hards dans ce passage si ? => Sprite hard pour le text qui bouge => incrustation dans le background pour le text static
Non,dessin de Ced transferé sur CPC via ConvImgCpc
Je citais les Miga et STE juste pour la palette (en référence), pas passque l'image serait un transfert Amiga/STE éventuel... bien que la question est quand même répondue... Et c'est vrai qu'avec cette palette mais les modes vidéo CPC (Mode0 et overscan) le PLUS possède un peu son identité visuelle propre je trouve, et un rendu relativement 16 bit quand même...
Citer :
=> Un petit split quand même quand le crane "descend" un sprite est moitié afficher en haut, moitier en bas
oui, ce qui permet le défilement visuel dans la "fenètre sprite" de l'image...
Citer :
=> s'eut été possible en effet (si on fait du précalcul des ondulations) mais je ne voyais pas d'interêt à le faire
Pas d'intéret ? tu parles de précalculer l'ondulation ou de rendre la fenètre SpriteHard affichée sur toute la hauteur ?
l'intéret est d'avoir un effet vertical plus haut... tout l'écran quoi... Après ça peut impliquer des complications en effet vu que l'ondulation est pour chaque ligne déjà, et que si on Multiplexe ça, ça doit par exemple doubler l'effet d'ondulation en plus d'ajouter l'effet de multiplexage, peut devenir quand même bien plus lourd... à tenter peut être la prochaine fois.
Citer :
=> Classique mais pas si facile, la matrice de rotation est tordu (pas de multiplications pour le z80) et l'algo de tri en profondeur doit être assez rapide => L'idée des boules de plus en plsu foncées dans la profondeur est une idée de Ced (Merci à lui)
en effet pas si simple en fait... car les mouvements et placements doivent quand même avoir un rendu 3D... le repalettage pour la profondeur, c'est pas le trucqui est fait systématiquement sur ce genre d'effet, et là je suppose que ça se fait avec du palette swap (changement d'encres) ou du sprite Swap voire un mélange des 2. il faut pouvoir gérer le fait que tel ou tel sprite passe devant tel ou tel autre sprite aussi. Bref si ce n'est pas trop précalculé, ça peut en effet pomper du CPU probablement. le changement de couleur par profondeur, ça bouffe aussi des encres (sur les 15 dispos pour les sprites) je suppose ce qui explique la texture relativement simple des boules ?
Citer :
=> Double buffering = 4 Sprites (Buffer 1) & 4 Sprites (Buffer 2) : On affiche un buffer pendant qu'on en calcule un autre => Pixels carrés mode 0 je crois
je demandais le nombre de sprites car en effet je me doutais qu'un double buffer pour les sprites était utilisé, pas simple sinon de changer les 16 sprites d'un coup assez rapidement...
Citer :
=> Yes, mais le masque est chargé pour chaque ligne (elle est trop grande pour du sprite) => Donc je superpose des sprites hard sur l'image de la nana avec la même image mais un fond transparent
Il suffit en théorie d'un seul sprite (voir 2) par bord (à gauche et à droite) de la nana... (ces derneirs sont bien sûr en Mode0). Quand on a passé le sprite en entier derrière elle, il suffit de le "désafficher" (état non affiché quoi...), jusqu'a ce qu'il soit censé être réaffiché de l'autre côté... En tout cas ça peut sembler logique si on ne veut pas afficher toute une bande de la nana ce qui prendrai plus de sprites... vu que par endroit il y a plusieurs zones a masquer ('la citrouille)
Il est vrai que faire toute l'animation en Sprite Hard ça simplifie sans doute grandement niveau qualité d'anim... mais j'aurai pensé qu'un peu plus de Soft pouvait aussi le faire, pas sûr... en faisant les lettres en sprites soft, leur scrolling serait peut être moins fluide et le maskage carrément plus complexe (par rapport au background surtout, pour le foreground la technique du sprite Hard reste d'actualitée)) mais alors des Sprites Hards libérés peuvent servir a rajouter une tranche d'effet quelque part (ou de graphismes fins ?)... à voir.
Je me doutais aussi que les lettres sont inscrite dans le décors en soft une fois qu'elles ne bougent plus (swap de tuiles sans doute).
Partie 1 : sprites : ==Logo Impact vertical probablement en sprite Hards... (genre vers 1 minute sur la vidéo)
Oui, c'est bien ça ! D'ailleurs, je pense publier le source pour ceux que ça interressera.
Citer :
==les boules qui bougent verticalement (vers 2 minutes 40) sont elles multiplexée ? (donc un seul slot de sprite)
Non, decompactage en temps réel des 16 sprites hard pendant la phase de plasma type old?
Citer :
vers 3:18... y'a une zone verte avec du texte en résolution fine. à vue de nez (video Youtube) il y a plus de 2 verts utilisés, donc un split raster peut être ? (le fond vert est il d'ailleurs entièrement en split raster ?)car les lettres Mode1 utilisent bien 2 couleurs (voire 3 mais avec le dithering de youtube, pas simple a dire pour le moment)
Bien deviné. Dans la grande tradition des demos 'Sanity' ce logo a été inspiré. Les lettres viennent de mon jeu 'Mario+' et sont en 2 couleurs. La troisième a été utilisée pour les sinus dots. J'aurai pu surement utiliser plus de couleurs mais, j'avoue ne pas y avoir pensé.
Citer :
Bien sur usage des Rasters interrupt PLUS pour les bandes horizontales de logos Mode1 (ou ce genre de choses).
Précise moi ce que tu veux dire là.J'utilise le PRI, 1 seule fois dans la démo. Le reste etant calculé tout au long de la frame en fonction de ce que je lance comme action et ceci en fonction d'un compteur d’évènement.
Citer :
5:00... 11 sprites "boules" qui bougent... y'a t'il multiplexage aussi ?
Désolé, aucun multiplexage cette fois-ci. J'avais déjà utilisé cette technique dans la Synergy Demo (Compte toute les boules à l'ecran!) et dans la Xmas (Multiplex de 4 sprites hard pour les 4 boules de noel qui 'flottent' soit 16 sprites en 4)
Citer :
5:30 : ce coup ci y'a 16 boules, donc tous les sprites semblent être utilisés et pas de multiplexage en théorie.
Bravo, tu comptes bien (! Il m'aurait été difficile d'utiliser du multiplex dans cette partie de la démo car il'y a aussi un plasma hard, donc...
Citer :
Encore que il me semble que ça aurait pu être fait avec genre seulement 8 sprites.
Que dire de plus. J'ai été très heureux de la collaboration avec F-Key, Shap et Ced. Merci encore les gars !
c'est rare devoir quelqu'un d'aussi intéressé, ça fait plaisir.
Citer :
Pas d'intéret ? tu parles de précalculer l'ondulation ou de rendre la fenètre SpriteHard affichée sur toute la hauteur ?
l'intéret est d'avoir un effet vertical plus haut... tout l'écran quoi... Après ça peut impliquer des complications en effet vu que l'ondulation est pour chaque ligne déjà, et que si on Multiplexe ça, ça doit par exemple doubler l'effet d'ondulation en plus d'ajouter l'effet de multiplexage, peut devenir quand même bien plus lourd... à tenter peut être la prochaine fois.
Oui tu as raison, Cependant je n'avais pas envie d'une barre verticale je préferais un sprite presque carré et je voulais que tous les calculs soient fait en temps réel.
Citer :
en effet pas si simple en fait... car les mouvements et placements doivent quand même avoir un rendu 3D... le repalettage pour la profondeur, c'est pas le trucqui est fait systématiquement sur ce genre d'effet, et là je suppose que ça se fait avec du palette swap (changement d'encres) ou du sprite Swap voire un mélange des 2. il faut pouvoir gérer le fait que tel ou tel sprite passe devant tel ou tel autre sprite aussi. Bref si ce n'est pas trop précalculé, ça peut en effet pomper du CPU probablement. le changement de couleur par profondeur, ça bouffe aussi des encres (sur les 15 dispos pour les sprites) je suppose ce qui explique la texture relativement simple des boules ?
En fait le temps de calcul des boules oranges (effet de profondeur sur les couleurs) et des boules bleues est le même. Sur PLUS, les sprites sont affiché du numero 15 au numéro 0 (donc le sprite 0 est au dessus du sprite 1 qui est au dessus du sprite 2, etc ...) Il faut donc après avoir calculé les coordonnées en Z des boules leur attribuer le sprite correspondant à leur ordre suivant l'axe Z (c'est là qu'intervient l'algo de tri). Et ensuite pour les boules oranges si tu regarde la palette et les sprites dans winape à ce moment là tu verra que le sprite numero zero a une couleur clair et que plus tu vas vers le sprite numero 15 plus les couleurs sont foncées. Ceci explique le fait que les boules oranges soient trés dépouillées.
Citer :
Il suffit en théorie d'un seul sprite (voir 2) par bord (à gauche et à droite) de la nana... (ces derneirs sont bien sûr en Mode0). Quand on a passé le sprite en entier derrière elle, il suffit de le "désafficher" (état non affiché quoi...), jusqu'a ce qu'il soit censé être réaffiché de l'autre côté... En tout cas ça peut sembler logique si on ne veut pas afficher toute une bande de la nana ce qui prendrai plus de sprites... vu que par endroit il y a plusieurs zones a masquer ('la citrouille)
Tout à fait logic en effet et c'était une de mes pistes de départ, mais j'ai préféré coder de cette façon parceque ça me semblait plus simple d'un point de vu des routines
Citer :
Il est vrai que faire toute l'animation en Sprite Hard ça simplifie sans doute grandement niveau qualité d'anim... mais j'aurai pensé qu'un peu plus de Soft pouvait aussi le faire, pas sûr... en faisant les lettres en sprites soft, leur scrolling serait peut être moins fluide et le maskage carrément plus complexe (par rapport au background surtout, pour le foreground la technique du sprite Hard reste d'actualitée)) mais alors des Sprites Hards libérés peuvent servir a rajouter une tranche d'effet quelque part (ou de graphismes fins ?)... à voir.
Oui c'est possible en soft, mais un peu plus lent sans doute et plus dur à coder. Le scroll était même plus fluide pendant la phase de création, mais j'ai du utiliser un step de 2 pixels pour accélérer un peu le mouvement car c'était vraiment trop lent.
Citer :
Je me doutais aussi que les lettres sont inscrite dans le décors en soft une fois qu'elles ne bougent plus (swap de tuiles sans doute).
Le problème des Sprites Hards du Plus c'est qu'ils sont intrinsèquement très limité... moi j'apelle plus ça des "tuiles uniques à uploader et avec une encre transparante de série" que de vrai "sprites" avec pointeurs en RAM. C'est là un peu le drâme du PLUS... ces sprites sont encodés en 8bpp mais n'affichent que l'équivalent de 4bpp (16 encres au lieux de 256... erf...) et sont une plaie a "rafraichir" avec une nouvelle "frame" (bref afficher autre chose avec). C'est limite ce qui gache un peu la machine, vraiment.Si ces sprites avaient été en 4bpp et pointeur vers de la RAM et donc 16 sprites par scanline, ça aurait certes bouffé de la RAM mais aurait vraiment permis d'afficher un second écran de 256xhauteur (magnifiable et multiplexable) par dessus l'écran CPC normal.
Bref un vrai plan sprite quand même.
Mais ok, les cartouches auraient du être facilement en 256k minimum et la RAM poussée en 128K au minimum.
Mais ce qui est sympa en quelque sorte, c'est qu'il faut alors se bouger le cul pour arriver a exploiter ces sprites au mieux... alors que sur certaines machinesl es Sprites Hards sont d'une facilité déconcertante, sur PLUS c'est pas facile quand même.
Et puis que les pixels des Sprites hards soient en 8bpp (1 octet par pixel) ça permet de les addresser individuellement aussi, parrait il.
Citer :
Tout à fait logic en effet et c'était une de mes pistes de départ, mais j'ai préféré coder de cette façon parceque ça me semblait plus simple d'un point de vu des routines
Donc tu remplis toute la ligne de la gonzesse en sprite Hard ? Après c'est vrai que devoir gérer l'éffacement des sprites puis leur réapparition, et de ne placer les patches de sprites sur la gonzesse qu'a des endroits précis, ça peut finalement impliquer plus de manipulations bouffeuses de NOP... ou des tableaux/listes plus complexes ou plus lourdes.
La Nana est elle mise intégralement en RAM aux formats "normal" (mode0) ET au format Sprite (8bpp) donc on upload direct les sprites depuis la RAM là ou il le faut avec les sprites qui sont par dessus ceux servant ensuite pour le texte, ou y a t'il une routine de conversion du Mode0 vers le 8bpp des sprites ? Idem pour le texte, doublon ou routine de conversion du mode 0 vers le mode sprite (ou inversement d'ailleurs)
Après c'est clair que la solution la plus complexe et élégante n'est jamais la plus efficace en fait.
hello tout le monde , je suis content de voir enfin cette demo ! , pour les images j'ai fait de la composition sur photoshop (pour la fille qui tiens le flacon c'est un trasfert retapé , je n'ai réelement déssiné que l'animation des yeux ) , puis j'ai reduis à 16 couleurs et j'ai tramé a la mainl , le plus dur à été de trouver les bonne palettes ( je n'ai pas trop l'habitude d'avoir autant de couleurs !!! )
Pour les couleurs c'est vrai que c'est assez "no limit" et donc les 16 couleures du mode0 sont la réelle limite, et là c'est le drame bien souvent. J'imagine mal aligner plus de 4096 de palette sur un 8 bit qui ne peut pas afficher bien plus que 16 couleurs.
Les MSX2+ et TurboR sont overkills d'ailleurs avec leur mode quasi true colour (j'apelle ça du demi true colour).
le Format VGA du temps ou ça ne pouvait qu'aligner 320x200x256 c'éest pareil d'ailleurs, 4096 couleurs sont déjà assez suffisantes pour les compos équilibrées (= pas 256 teintes de bleu par exemples).
Mais c'est vrai que le PLUS aurai déchiré avec du mode 160x200x256...
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
C'est certain qu'une telle palette pour afficher si peut, ça frise le ridicule.
Pour faire facilement son choix quand on peut en exploiter que 16, on peut se limiter à des multiples afin de garder une cohérence au niveau des teintes. Et créer des sous-palettes en fonction des usages...
Oups... Dans ma précipitation, j'ai oublié de créditer quelqu'un qui m'a grandement aidé dans le design ainsi que la re-colorisation de la démo.
Il a été présent tout au long du développement de ma part (RST#38) ! Merci pour les phases de Beta-Testing et les nombreux appels téléphoniques ou tu as su me rassurer.
Donc, un grand merci pour ton aide Amaury. (Ghost of BdcIron pour ceux qui ne l'auraient pas reconnu!)
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 12 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