Bin si tu te sent de faire une sorte de tuto...lol.
Après l'idée dans tout ça, c'est que je pense que la flashouille selon saint Slyvester...
Bin y'a des trucs pas forcément exploités...
En gros utiliser les sprites Hards c'est euh...plus facile sauf que c'est une ressource rare le sprite hard...
LA plupart des flashouilles sont pour des écrans fulls... genre tu passe 2 écrans statiques en palete différentes (ou relativement différentes...) Ce qui n'empèche pas de laisser des doublons d'encres pour avoir du vrai noir ou du vrai blanc, surtout pour le mode 0 par exemple... Car bon le CPC old n'as pas non plus 2x16 couleurs différentes...mais plutôt 2x13,5 de fait... on garde le Noir-Gris-Blanc (neutres) en commun non ?
Mais ça ne me semble pas avoir été exploité avec les sprites, qui pourtant sont prompts à flashouiller sans qu'on le veuille... .
Le Mode 16 couleurs par exemple (mode 0 comme vous vous en doutez) peut permettre déjà pas mal de couleurs en plus rien qu'en utilisant les 16 couleurs déjà utilisées... Juste en appliquant la flashouille aux sprites, vu que souvent on utilise un fond normal, et une 2ème couche de sprites softs...
le fait d'avoir alors non pas des changements de palette totales (totaux ?) en 25Hz+25Hz alternés, mais un fond toujours le même (50Hz donc ne flashant pas vraiment) et une couche de sprites avec masque tramés (fameuse pseudo encre transparente) qui patchent le tout par endroit (en statique mais en mouvement faut voir ce que ça peut donner).
dans le cas de "sprites" ou "tuiles avec masque" (plus statiques) et une trame de pixels 'transparents'... C'est par contre sans doute assez lourd niveau CPU...
Et tout réside dans la technique de masquage. Théoriquement... je suppose qu'on peut par exemple faire comme pour un sprite normal... qu'on afiche avec un masque... Sauf qu'en fait il y aurait 2 masques et on alternerai entre les 2 d'un rafraichissement écran à l'autre.
Ensuite une version plus advanced et pas forcément possible serait de faire des masques tramées-alternants sélectifs... Genre tu ne met ça que pour telle ou telle encre de sprite...
Genre le Noir reste noir ?
ça peut aussi permettre de jouer sur des effets donc.
En mode1 c'est peut être même bien jouable.
Genre :
Noir+Blanc + 2 couleurs...
ton fond est normal... donc 4 couleurs. Tes patches/sprites, bin euh... en fonction des sprites/patches, tu peux déjà en faire avec le Noir et blanc qui reste normal d'un rafraichissement à l'autre, mais dire que (si sprite ou tuile plus ou mons fixe) que la couleur 1 ou 2 (est tramée et pas l'autre... (surtout pour les patches de type fixe/tuile), faire des sprites animés fantômatiques totalement, ou pas... ou partièlement...
euh, ça peut alors être super lourd dans le cadre d'un jeux, mais dans le cadre d'une démo...bin c'est peut être optimisable ou pré-calculable...
Pour ces sprites, d'ailleurs, le tramage de 2 couleurs n'est parfois pas aisé avec une pixélisation...
Utiliser de la flashouille pour les sprites, c'est alors aussi une facon de foutre des couleurs en plus (bien que flashante... sans doute...)
Exemple : Jaune+Bleu+Noir+Blanc (mode1...)
Oui on peut faire du vert en tramant le Bleu et le Jaune... Sauf que la résolution n'est pas non plus si fine que ça, les sprites pas trés volumineux... Bref euh...on peut pas spécialement faire les détails qu'on voudrait en vert. à moins de flashouiller sélèctivement alors.
et puis une animation n'utilise pas 50 ou 25 frames par seconde (n'est pas en 50 ou 25 Hz donc)... Bref en doublant les tuiles sprites (merci la version 128K de Ram...) voire une routine soft pour appliquer les trames à telle ou telle encre pour tel ou tel sprite/tuile ..?
On peut alors avoir du noir, Blanc, Bleu, Jaune, Gris, jaune clair et foncé, bleu clair et foncé et vert... théoriquement...
Au moins pour les sprites, voire un effet de pseudo transparence avec le décors...
Ce que l'on perd en routines de modif de l'image (tuiles/sprites et application de matrices binaire de transparaence... et flashouille...) on le gagne aussi un poil et hypothétiquement en ne changeant pas la palette... après je ne connais pas les détails en NOPs..Fano ? tes lumières ?)
Et dans le cadre d'un PLUS, y'a en plus les sprites Hards...qui sont un truc en plus des sprites Softs. et ont surtout leur propre palette avec facilité de pixels transparent... Bon c'est clair que ça en fait peu, ça bouffe de la mémoire ou temps de chargement et c'est pas super malléable rapidement...
Et puis faire un simple travail de tramage traditionel peut aussi avoir un rendu suffisant... Mais ça reste une possibilité toujours présente voire complémentaire, car la texture n'est pas forcément la même non plus.
Bref oui messieurs les démomakers, il serait bon au moins de tester le rendu d'un tramage-flashouilles-transparentes..
Bon concrètement, sans chercher les techniques tirées par les cheveux, c'est théoriquement un affichage de sprites masqué par matrice binaire, en 50Hz... mais avec 2x plus de Sprites en Ram et 2x plus de masques en Ram aussi.
il faut juste soit doubler les Datas de Sprites (pas toujours ?) si on veut flashouiller les couleurs "normalement", voire doubler les trames de transparence (masques).. voire les 2 à la fois... Bref pas on plus forcément facile à compresser alors.
Si on mélange les types de sprites/tuiles avec effets, ça pompe de la routine... mais si on reste sur telle ou telle technique seulement (plus en démo) ça peut être jouable ?
Bref différencier différents types de sprites/tuiles... euh...ah oui quand même...
Et vu que concevoir une flashouille traditionelle semble déjà assez complexe, bin là c'est sans doute pire quoique plus localisé...
Et n'avoir pas de vrai changements de palette (encres) peut être une certaine simplification alors... Plus de Ram prise mais moins de temps CPU dans les cas les plus simples...ou moult temps CPU si tu fait un simple sprite classique unique mais applique de la modif software sur l'image ou les encres au "cas par cas" (ou par catégories de cas)...
En tout cas sans aller sur de la flashouille de sprites Hards pour effet fazntôme comme j'évoquais au début du topic, la flashouille partielle pour certaines tuiles ou sprites me semble un effet pas trop utilisée encore qui ne prend "que" un doublement e certains datas (les sprites et tuiles usant de cette technique) et des routines d'alternance entre ces datas doubles.
Arf merde déjà ça devient chaud en fait...
Mais déjà que faire un bon truc sans ça en 50Hz c'est pas simple...
Le bug de priorité n'existe que dans le cas de résolution fine. Zoom minimal des sprites hard. Dans ce cas et pour cas particulier de placer les sprites très proches les uns des autres alors il existe un bug de priorité ou le sprite 0 n'est plus le sprite prioritaire.
tu prends le background ,qu'on appelle B . Tu prends ensuite 2 sprites A et C, avec A de priorité plus élevée que C.
Tu affiches ton Background B, tu affiche A avec une priorité inférieure au background B ,et C supérieure background B.
Sur l'exemple, A a un pattern du pillone, identique à B .. Quand C arrive dans le pillone c'est là que le bug se produit, avec un C de priorité sup. à B, mais inférieure à A, d'ou l'effet d'ombre,le VDC est perdu. Ce bug existe sur PCE, MD, et snes, donc pourquoi pas sur CPC+ ..
Peu importe la réso, le bug se produit quand même, mais bon peut être aussi que niveau sprites hard le CPC+, ne fonctionne pas de la même façon, et ce bug n'existe pas .
Dans le cas du plus, déjà il y a peu de sprites comparé aux consoles que tu as cité, mais en plus les sprites sont toujours au dessus du non sprite... Il n'y a pas me semble t'il la notion de foutre des tuiles (soft) avec transparance ou pas qui peuvent passer par dessus les sprites Hards...
Après je ne désespère pas que 'on trouve un jour des trucs non documentés sur ces sprites, ça serait même assez cool...
Mais hélas, l'Asic semble ne pas être totalement aboutis... Voire buggé.
Moi je considère plus les sprites Hards du CPC comme des tuiles hards de premier plan qu'autre chose...même si y'a quand même moyen d'en faire des sprites.
SwitchBlade GX4000 est justement un usage "tuile" de ces sprites...
Mais en l'état, il faudrait genre 2x plus de slots de sprites ou alors qu'ils aient des fonctions en plus pour en faire le même usage intensif qu'il y a sur les machines Japonaises...
Originellement ça reste un CPC, donc le soft reste super présent...C'est pas pour rien que la GX4000 possède pas mal de RAM comparé à d'autres consoles pourtant plus puissantes...
Dernière édition par MacDeath26 le 07 Avr 2011, 09:29, édité 1 fois.
Mais je me rappelle plus ou j'ai entendu cela déjà
MacDeath26 a écrit :
Dans le cas du plus, déjà il y a peu de sprites comparé aux consoles que tu as cité, mais en plus les sprites sont toujours au dessus du non sprite... Il n'y a pas me semble t'il la notion de foutre des tuiles (soft) avec transparance ou pas qui peuvent passer par dessus les sprites Hards...
Ok, si c'est le cas, c'est mort alors ..
Pour le nombre de sprites, peut être qu' il y a matière à utiliser du multiplexage de sprites.
Avec une rupture classique au milieu de l'ecran on peu en avoir 32,ils sont dupliqués,mais le contenu ne peu pas etre changé.On peu aussi mettre un sprite genre Y=0 et ensuite lui dire Y=64,une fois que le balayage ecran a depassé la taille en Y du sprite.
Iron pourra préciser mes dire,voir me corriger
_________________ Tout le monde il es beau,tout le monde il est gentil .
Tu es sur de cela ?? Il me semble que la limite par ligne ne peut être contournée à cause du timing( pas assez de temps au circuit pour gérer plus de sprites sur une ligne), mais je me trompe peut être ..
Par contre, la technique que tu cites est bien du multiplex de sprites .. Afficher par exemple les 8/16 sprites hard en haut de l'écran, et les mêmes en bas (ou ailleurs), et tout ca sur une même frame .
Dernière édition par TOUKO le 07 Avr 2011, 11:57, édité 2 fois.
Tu es sur de cela ?? Il me semble que la limite par ligne ne peut être contournée à cause du timing( pas assez de temps au circuit pour gérer plus de sprites sur une ligne), mais je me trompe peut être ..
Par contre, la technique que tu cites est bien du multiplex de sprites .. Afficher par exemple les 8/16 sprites hard en haut de l'écran, et les mêmes en bas (ou ailleurs), et tout ca sur une même frame .
Je parlais de doubler en y,pas sur la meme ligne,cela dit avec de la rupture verticale tu peu les doubler sur la meme ligne
_________________ Tout le monde il es beau,tout le monde il est gentil .
Si tu es curieux de voir plein de sprite,récupere sur cpc-p0wer la preview "delirium tremens" du pote iron
"Le fond de l'écran ce compose d'une ondulation plasma tandis que devant se déplacent 64 sprites hards par ligne. Le tout en 31 couleurs et une résolution de mode 1 (pixels carrés)."
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 9 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