Euh, tu as mal compris...
Dans ton devpack, y'a une image "r_new.bmp"...
Bin cette image je l'ai passé par convingCPC histoire de voir le nombre de couleurs utilisées, et quelles étaient elles...Juste pour analyse car comme je dit, j'essaye déjà de prendre mes marques.

Donc j'ai énuméré les rêglages de convimgcpc...c'est tout et ça rentre en hauteur me semble t'il.

Bon pour Paint.net, il est vrai que j'ai pas encore bien trouvé le truc pour lui filler la palette Amstrad Plus, je devrais aller jeter un oeuil sur leur site d'ailleurs.


bon pour les ambiances colorées :
C'est vrai que la version CPC est finalement une de celles avec boucoup de re-travail graphic je trouve.
Et une des seuls qui développe des ambiances colorées spécifiques (C64 : beuark...yurk...)
Genre il me semble que les dégradés de certaines tuiles contiennent même limites plus de teintes (bien que parfois dépareillées)
Et les photo de la Version Amiga du site que j'avais cité (là ou y'a les maps) bin soit son émulateur est merdic, soit il a mal fait son truc passque je les trouve moins bien...largement...que la version ST.

Pour le problème du nombre de couleurs pour le sprite de Rick bin euh oui, ça n'en est pas vraiment un il est vrai.

Mais le truc c'est que ces couleurs là sont plus ou moins immuables en fait.
Le seul truc vraiment commun à tous les levels, c'est Rick, ses balles et ses dynamites...

Or j'aimerai bien faire des ambiances assez différenciées entre les levels, donc la moindre couleur qu'on peu grapiller bin c'est une fenètre de liberté graphique en plus, lol.

Bon, il es vrai que la version ATARI est assez euh...plate.
Fine, couleurs sympatique (le côté photos sépia rétro du gris et marron quoi) mais en effet pas trop coloré.

En revanche, bin vu que le CPC n'a pas assez de gris, c'est trop coloré en fait, je trouve.
Le Plus peut donc amener un bon comprommis.

En effet : Amazonie : fôret...
Pourquoi ne pas alors passer en teinte plutot verte !

Pour le coup, ça évite de faire doublon avec la base de missiles qui est aussi Bleu...et ça fait une belle nouveauté.

Quand au level 3, le chateau, bin euh...le rouge je trouve ça quand même un peu trop...coloré justement.
En repassant en full gris, bin ça rend vraiment trés bien je trouve.
ça fait mieux ressortir les sprites et l'avant plan.

enfin bon, je vais voir tout ça.


arf, Tiles studio est incapable de faire un palette de 4096 couleurs me semble t'il...

Sinon pour le moteur du jeux : je suppose qu'il y a un systeme qui permet d'inverser de droite à gauche les sprites, ce qui explique pourquoi y'en a qu'un seul jeux.

Ensuite je suppose aussi qu'il y a un systme de contour des sprites (je sais plus le nom en fait de la technique) le truc qui fait qu'on a un contour des sprites bien marqué par rapport aux décors (genre ce qu'il n'y avait pas sur R-type...).

Donc si par "hasard" je souhaite redéssiner un peu les sprites, bin il me faudra faire attention à ce que ça reste dans le dessin originel, pas ajouter des trucs qui dépassent quoi...

Je pensait par exemple pour les soldat allemands, passer leur contour en noir au lieux du bleu foncé...
j'ai jamais aimé les contours colorés genre princesses disney...lol.

allez, je vous laisse et vais faire des essais.

Ok , je comprends mieux, d'un autre coté je ne vois pas ce que convimgcpc vient faire la dedans lol


Tiens vomis encore un coup :


Bah oui , on est pas limité à 4 couleurs par tiles nous !


voilà , idem pour les tiles

On va dire que oui, lol disons que tu as une marge de variation mais chaque couleur a sa fonction...

Ce système s'appelle couleur numéro 4

La dimension d'un sprite dans Rick est 12*21 pixels.TOUS les sprites font cette dimension et en fait les bmps qui sont avec le devkit sont les pixels extraits tel quel sans modifier l'agencement en mémoire (tu regardera avec Winape , tu te places en #2100 et tu te mets en 6*21).De toute façon si tu redonnes à bouffer au script ces bmps en modifiant les dimensions, tu vas avoir des sacrés surprises après avoir patché...

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Ce système s'appelle couleur numéro 4

Cela s'appel plutôt du masquage... Je ne sais pas ou t'as trouvé ce terme de "couleur numéro 4" mais jamais entendu parler de cela... Dans Rick il y a un masque de stocké quelque part ?

C'était de l'humour , c'est effectivement du masquage tout ce qu'il y a plus classique avec la couleur 0 transparente, je dis ça car la couleur numéro 4 est utilisé pour faire un contour noir autour de Rick.

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Bin, simplement qu'il possède les bonnes implémentation de palettes, autant pour le plus que le old...
Donc quand je veux faire des coloriages en Amstrad, un petit pasage par Convimgcpc permet de vite voir le nombre de couleurs necessaires, et aussi de tester différentes encres facilement...
Mais pour la retouche c'est pas terrible bien sur.

Donc non ça sert à rien, sauf que c'est pratique pour faire les premières analyses, les prises de repères..
je fonctionne comme ça.
Je triture "à vide" histoire de voir un peu les couleurs, le nombre de donnée, trier les trucs...
Et quand ça a bien maturé, bin splortch, je me lance vraiment.

--Ah, la version C64...
ce mélange de pseudo mode 0 et 1 beurk en fait.
Et les méchant sont über moches en fait.
Dire que le type du site sur Rick dit que la version CPC est la moins bonne des 8 bit.
Rien que pour ça on devrait le troller.

Il dit même qu'on aurait du acheter un ZX speccy...lol.

--Ah oui, c'est la technique du masquage des sprites.
ça mange une couleur ou en fait non c'est juste une technique soft ? (je penche pour la 2ème solution)
ça serait bien d'arriver à trouver où c'est dans le code..ça ferait déjà une zone d'ombre en moins, lol) et de les sortirs en BMP...

--Sinon pour l'inversion gauche droite, esque c'est fait en soft ou alors y'a t'il le double des sprites ?

Une telle technique d'inversion soft des sprites, ça m'interesse de savoir comment on le fait, voir si c'est plus avantageux que de doubler les sprites quoi.

De même esque c'est possible avec par exemple du sprite Hard de PLUS ?

--sinon j'en suit surtout à essayer de trouver une méthode potable de travail en fait.
Je pensais séparer les tuiles et sprites en fonction du level...numéroter et ranger tout ça quoi.
Histoire de pouvoir me concevoir des palettes pour chaque niveau.

Donc bien classer les couleurs obligatoires (celles de Rick, Balles et dynamite, caise de munition aussi).
Pour le reste, il doit bien y avoir 5-6 couleurs possibles.


--Euh, les bonus de points à ramasser... (statuettes, missiles) il me semble qu'il n'y en a pas vraiment au niveau 2.
Esque c'est simplement la tete du sarcophage qui est recyclée de la sorte?

En tout cas, si y'a sur le plus long terme moyen d'avoir une analyse bien complète du jeux, donc moyen de faire de nouveaux levels, bin ça m'interesse de designer des levels alors.

--sinon, pourrais tu me donner la liste des encres exactes utilisées par Rick (version original et ta version retouchée), avec leur ordre exacte (la numérotation exacte utilisée par le soft donc).
histoire que j'essaye de respecter ça un peu quand même.

--enfin pour finir, peux tu cher Fano m'envoyer les version old des graphismes : donc les tuiles, les sprites et Rick stp ? en version non retouchées donc...

Tout depend de la technique utilisée pour le masquage... Ca peux manger une couleur comme ne pas en manger...
Pour l'histoire d'inversion, faut bien comprendre les avantages et désavantages... Avantage de faire l'inversion en soft: 2fois mois de données; desavantage: ca bouffe un peu plus de tps machine si on le fait pendant le jeu... La méthode intelligente est de le faire au lancement du jeu une fois pour toute Du coup moins de données à charger, mais une fois l'inversion faite, c'est pret pour être affiché dans le jeu !!!

Pour le faire sur les sprites hard, oublies d'avance ca prend trop de CPU... petit rappel: pour les sprites hard, envoyer 1 pixel equivaut a envoyer un octet... Soit 2 nops mini !!!

Une petite question : à la base tu travailles en vraies couleurs ou en indexé ?

Non c'est soft

Tout dépend si tu privilégies la vitesse ou l'occupation mémoire.

Pareil que au dessus lol

[mode fanboy on] adoptes grafx2 , tu travailles directos tes GFX pour le plus sans rien avoir à retoucher [mode fanboy off]



Voilà pour Rick :


Pour le reste , c'est l'original , il n'y a que la palette qui change.

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Ok.

Mode fan boy : euh, lol...fanboy c'est presque une insulte sur 4chan... à la limite du Troll...
Mais bon, ok j'y jetterai un oeuil quand même rassures toi.

Bon, donc l'inversion de sprites soft c'est bien, en Hard, bin non...ok.
Décidément, ces sprites hards...heureusement qu'il permettent aussi de mettre +15 couleurs avec de la bonne résolution à l'écran...

Après bin euh, c'est clair que si ça permet au final de remplacer la moitié des Sprites par un petit sous programme...

Mais c'est clair que Rick Dangerous a aussi tendance à avoir de bons gros ralentissement.

Genre quand on a 3 adversaires, ou quand on fait péter une dynamite...lol.
Mais bon, ça reste potable quand même.
En tout cas en mode 128Ko pour un bon gros Shm'up...mieux vaut peut être multiplier les sprites.
Pour un pseudo Rick, faut voir.

Sinon euh, raffraichissez moi la mémoire.
Rick dangerous, esqu'il recharge entre les level ou esqu'il charge tout d'un coup ?
(je sais, il me faudrait le relancer un peu et ressortir mon CPC...)

Rick Dangerous fais 40ko et il ce charge en une fois.

Muarf...c'est pourtant un des meilleurs jeux CPC...
bon bien sûr il ralentis pourtant parfois (mais bon, peu d'incidence sur le jeux en fait...) et c'est clair qu'il était prévu pour un format cassette et 64Ko Ram...

Mais ça veut aussi dire qu'une véritable version D7 aurai trés bien pu "facilement" inclure toutes les Features des versions 16 bit finalement.

facilement : un peu plus de temps de la part des développeurs donc, lol...

D'ailleurs il me semble que Rick 2 est plus finis de ce côté là...

Rien que de recharger entre les levels, ça permettrait théoriquement de caser léquivalent de tout le jeux en tuiles et sprites...pour un seul niveau en fait.


Bref idéalement, il faudrait le décrypter encore un poil plus et faire alors une véritable version longue...facile à dire je le reconnais.

En tout cas ça a au moins l'avantage de laisser un peu de champ libre à Fano pour ajouter des Plusseries genre le "Wwwwaaaaahhhhh"...

Sinon y'a plein de truc à repomper je pense...
Par exemple les sauts du perso, j'ai toujours trouvé que c'était le bondisseur le plus agréable à manier, un vrai mario...


Il me semble qu'il utilise une compression des données, non ?
ça peut expliquer aussi pourquoi c'est pas forcément simple à bien analiser comme code.

Post edit : sinon je sais plus si je l'ai déjà dit, mais il me semble qu'il manque des sprites dans les truc que tu m'a filé, cher Fano.

pas de bonus tête de pharaon par exemple, ni de caisse de dynamite me semble t'il...

Comme dit plus haut, c'est le choix entre la vitesse et l'occupation mémoire.Mais tu remarquera que l'affichage des sprites dans Rick est assez bien foutu puisque les sprites sont masqués, ont des priorités et en plus passent derrière certains éléments du décors, tout est géré en plus dans un buffer intermédiaire ce qui explique aussi que ce soit un peu lent parfois (si tu est un peu curieux, vas voir pendant que le jeu tourne en #A3D2 avec des colonnes à 2, c'est instructif sur la méthode utilisée)

Sinon, pour la caisse et le pharaon, justement ils se trouvent dans ce buffer intermédiaire et sont déplacés en #DE00 au démarage, les mecs devaient vraiment manquer de place !
Sinon , une fois le jeu démaré, tu vas voir avec Winape en #DE00 , en 6*21 , format CPC.

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Bin mine de rien, ça fait quand même 512 tuiles... (en fait moins, certaines sont toutes noirs, disont 489 ?

Mais il est fort possible que certaines soient en fait utilisées en déclencheurs...

J'ai déjà passé une bonne partie de la nuit a essayer de les déméler, voir où elles vont et tout.
en utilisant Tile studio.
Non pas pour modifier, mais bien pour les trier, car il garde leur ordre et les numérautes...

après c'est chiant il me semble qu'on peut pas faire de zoome avec la barre des tuiles (surtout en mode map) donc en 4x8, bin faut sortir la loupe IRL, lol...

Mais en gros, je vais devoir jongler en multitache et faire des manipes de ouf...
j'essaye de me motiver donc... lol.

Sinon ci joint, un essais super grossier (oui c'est pas super étaloné) : que pensez vous du 3ème level en gris ?
Et accessoirement les Soldaten en contour noir (ça j'aime bien... le contour bleu il me semble que c'est plus un truc de portage depuis le C64...lol.)


à ce propos, les sprites que tu m'a envoyé (et oui je suis chiant) c'est sur fond noir et (ça dépend des quels) il semble qu'il y a un contour genre un couleur à la con (marron super foncé ou bleu super foncé) c'est quoi en fait ?
ç'est un truc pour faire ressortir sur le noir ou c'est comme ça ?

C'est que en passant ça au noir, les sprites ressortent vachement bien je trouve.

Je t'avais dit que c'était un truc d'homme

Rien ne t'empêche de doubler ou quadrupler la taille pour tilestudio en important les tiles plus grandes , c'est ce que je fais pour Project Wildfire

Sinon pour l'essai , je trouve que c'est un peu monochrome, c'est dommage d'avoir les pierres du fond de la même couleurs que les autres.La couleur autour des sprites, c'est les graphistes qui l'ont fait pour que les personnages se démarquent.Sinon la couleur numéro 4 en marron c'est moi, d'origine elle est noire.

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Oui, c'est un truc d'homme...


l'essais, c'est vraimment fait à l'arrache, histoire de voir si ça donne en gris à la Atari ST.

Bien sur je pense garder le rouge du fond, mais grace au 4096 couleurs, bin fair un truc moins vif.
Sinon en original, les grosse pierre ont le dégradé suivant :
bleu foncé, grisbleu, gris, blanc.
j'ai trouvé qu'en remplaçant le bleu foncé par du noir, tu assombris un poil mais en fait fait ressortir plus le côté forteresse sombre et lugubre...
Bien sur en palette plus, je verrais plus un dégradé vraiment gris, en 4 teintes : Blanc, Noir et 2 gris...
Mais sinon un gris trés foncé donc en 5 teintes...à voir.

Pour le coup du contour bleu des Nazis, bin disont qu'au niveau 3 ça fait ressortir, mais au niveau 4 bin euh...effet inverse, lol.
Et au niveau 3, bin ça allourdi et grossis les sprites alors qu'en noir le contour se fond dans le fond (noir+marron+rouge...) devenant plus une ombre qu'un gros contour bleu.

un truc qu'on peu hélas trop souvent reprocher aux jeux 8 bits, c'est le contour des sprites.

Genre dans les Speccy ports, bin souvent les sprites sont même entourés en "blanc" et sont en fait vachement plus épais.

le contours en noir affine justement les sprites et ajoute du contraste.

genre les soldats sont verts.
Bin ils ressortent forcément sur le fond rouge ou gris ou bleu.

Idem pour les sauvages qui ressortent forcément : chair sur du bleu.
etc quoi.
Sinon j'ai vaguement essayé de passe le fond du niveau 1 en vert...le problème c'est que j'ai utilisé la palette old donc beurk (trop clair) mais en Plus ça devrait passer...

Sinon je renouvelle mes demandes... pourrais tu me donner :
--les tuiles et sprites divers...en version originales ET recoloré par tes soins. (enfin, j'ai déjà les version recoloré, et les version originals du sprite de rick seulement)
--les palettes de ta version et l'originales, avec l'ordre software et tout et tout, une belle liste quoi...

--serait il aussi possible d'avoir une paire d'image par niveau avec ta modif de palette aussi ?

En effet la palette original est instructive aussi.
et des écrans complets avec tes modifs, ça permet de voir un peu le rendu en fonction des couleurs de rick que tu as mis.

Par exemple les tuiles des grosse pierre jaune au niveau 2 (egypte) ont du rose en fait (chair).
Bin j'ai trouvé qu'en remplaçant ça par le jaune clair ça passe en fait bien et démarque un poil les grosses pierres justement.


car oui, je suis toujours une quiche sous winape et une merde en Assembleur.

Pour les deux premières questions , tu les as déjà.Je m'explique et je me répète : il n'y a que les palettes qui changent.Donc si tu prends la palette de rick original et que tu l'appliques au tiles et au sprites , bah ça réponds à la première question.
La palette des bmp en mode + est la palette appliqué sur CPC quand tu travailles avec Grafx2.
Il n'y a pas de différence entre la palette Hardware et Software ici.
Par contre, si tu regardes le fichier r_new.bmp , c'est la version modifiée de Rick.

Si tu les veux sous forme de chiffre, voilà la palette old , à gauche ce que je donne à l'ASIC sous la forme GRB, à droite l'équivalent sur la palette soft cpc old(pas G.A)

.palette_0 ;old colors
dw #000 ;BG
dw #0F0,#0F8,#8F8 ;6,7,16
dw #000 ;black
dw #00F ;2
dw #80F ;11
dw #800 ;9
dw #F00 ;18
dw #080 ;3
dw #8F0 ;15
dw #FF8 ;25
dw #008 ;1
dw #808 ;10
dw #888 ;13
dw #FFF ;26
dw #000 ;border

Sinon, la nouvelle palette, avec la même équivalence CPC à gauche

.alternate_1
dw #000 ;BG
dw #4A0,#4F8,#AF8 ;6,7,16
dw #000 ;0 black
dw #44D ;2
dw #80F ;11/14
dw #844 ;9
dw #F88 ;18
dw #280 ;3
dw #8F0 ;15
dw #DF8 ;25
dw #224 ;1
dw #88A ;10
dw #AAD ;13
dw #DDF ;26
dw #000 ;border

Sinon voilà mes palettes de travail sur le PC avec la palette old et la palette + :



Oilà des screen que j'ai pris au fur et à mesure du dev

allez travailles bien

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)