Oui, au Québec!

ah vi c'est EA qui vire a tout va, ca marche mieux pour UBI, faut dire qu'il son partie sur de bonne base ...

Bon, sinon histoire de ne pas ouvrir un mouveau topic...
Vu qu'ici on parle bien du plus et d'engines de jeux...

j'ai entendu dire (ici me semble t'il) que les sprites hard du Plus pouvaient se rendre plus "rapide/light/acceptable pour le CPU" si on les passait en 4 couelurs...
ça marche comment ?

en gros il me semble que ça permet de doubler les sprites, c'est vrai ?
ou superposer 2 séries de sprites en 1 seule...?

Bien sûr on se souvient de GhostNgoblin et ghoulsNghosts qui utilisaient 4 couleurs pour le fond et 4 couleurs pour les sprite, faisant un impressionnant mode0 en 8 couleurs même pas...lol...
Quoique ça permit néanmoins d'avoir ghoulsNghost en ovezrscan et assez fluide, mais bon, graphismes de merde (surtout pour le sprite d'artur...) et sprite même pas masqués me semble t'il...

Mais pour le Plus, y'a bien un truc comme ça ? ou puis-je trouver des infos là dessus ?

Merci d'avance.

Car il me semble que en utilisant un moteur mixte, ça peut avoir de bonne application, notament pour certains tirs dans des run and gun ou schmups...
à tester donc.
Mais en Schmup verticaux, y'a du potentiel avec le multiplexage, non ?

Autre question aussi :

sur rick dangerous, j'ai appris qu'il est possible de nb'avoir que les Data des sprites (softs) d'un seul côté, mais de les inversr en Software...R-Type fait de même d'ailleurs.
Avantage : une routine permet de caler 2x moins de sprites voire de tuiles car il suffit de placer cet effet miroir alors.

peut on faire de même avec les sprites hards d'un Amstrad Plus ?

Bien sur je me doute que l'ASIC ne le fait pas, mais une routine qui recode en direct les Datas des sprites hards afin justement de les "inverser"...c'est logiquement possible, à voir si c'est jouable niveau cycles machine dans un jeux d'action..

En gros, il me faudrait un système capable de tourner/inverser deu data pour du Hard comme du soft.
LEs applications en terme de moteurs de jeux sont assez énormes me semble t'il.

Avec le Zoomage des sprites hards, un sprite de 16x16 en pseudo mode 0 (donc rectangulaire, en fait 32x16 en surface) peut alors se mettre en vertical, donc 16x32...sort of (avec les pixels doubles en vertical et non horizontal) et vice versacé (versatché, la haute couture...).

Bref entre ça, le multiplexing éventuel et la technique des sprites en 4 couleurs...
il me semble qu'on peut virtuellement faire plus avec les sprites hard du Plus.

Enfin, qu'en serait il alors de faire du sprite hard en 2 couleurs, donc en fait une seule couleur+transparent ?

Xénon2 mégablast, bin les tirs sont blanc et rien d'autre...

2-4-16...niveaux bits/binaire ça me semble correct.
peut on le faire alors ?

Bah en fait , si mes souvenirs sont bons , on donné comme nom le 'dual playfield' à cette technique.Ca consiste simplement à séparer les bits par paquets de 2 au lieu de paquets de 4.Exemple :

Soit 4 bits : 3210

on va considérer qu'il sont en fait 2 plan distincts :
-plan 0 : 32
-plan 1 : 01

Tu vas me dire, c'est juste une vue de l'esprit parce que tu as toujours 4 bits et le materiel interprete les 4 bits soit 16 couleurs.C'est vrai mais avec une palette bien agencée ça marche.
En fait tu combines simplement les bits par plan et ta palette fait le reste.par exemple , si on considère que la couleur 3 ( 0x11) du plan 0 couvre le plan 1 , on va mettre toutes les variantes 0x11XX de la même couleurs soit 0x1100 , 0x1101 , 0x1110 et 0x1111 seront de la même couleur.
Pour faire court , on peut dire que tu utilises la palette comme un filtre en tenant compte de la combinatoire de tes 2 * 2 bits.A noter que ce n'est pas 8 couleurs que tu as mais 7 car un des deux plans a une couleur transparente.

C'est faisaible dès lors que tu assez de bitplans (au moins 2) mais ça n'augmente pas ton nombre de sprites.Perso, je n'en rafole pas , surtout sur plus où je vois mal l'interêt de la technique.


pas de quoi

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

t'as au moins Mission Genocide , Jail Break et Paranoia Complex qui utilise cette technique, et même dans une demo la "Fucking Exams" des Logon avec ce scrolling de Fred Crazy qui passe devant est derrière un scan d'un dessin de Gotlib.

en cherchent un peu j'en ai trouver d'autres : War Hawk , Moon Buggy, Spy Hunter et Led Storm

Paranoia Complex ? lol, Paranoia as eut une version sur micro...je le savais même pas...

Mais concrètement quesqu'on gagne avec cette technique ?
C'est que la limitation en couleurs, c'est quand même moche quoi...surtout qu'on se retrouve avec un Mode0 donc.

tu gagne en vitesse sur l'affichage , l'effacement et les collisions entre sprites , regarde comme GNG est fluide sur CPC...

Sur plus aucun interet, chaque octet correspondant à un pixel, tu devras toujours envoyer un octet... Donc légende: tu ne gagnes rien du tout...



Tu peux tout a fait le faire pour les sprites hard sans problème. L'interet de ce genre de chose est seulement au chargement: tu charges un sprite dans un sens puis le recopie en RAM inversé. Ne pas le faire pendant le jeu sinon tu perds du CPU... A moins de ne vraiment plus avoir de RAM pour faire autrement... La encore c'est très limité.



La palette de 15 couleurs pour les sprites étant commune aux 16 sprites, tu restes à 15 couleurs quoi qu'il arrive... a moins de rasteriser les sprites... Ca reste hyper limité.

Who Dare Wins II , je me rapelle qu'il y avait eu un listing illustrant la technique sur un ACPC mais je ne pourrais plus dire lequel.

Bah oui mais c'est notre habituel conflit entre occupation CPU/occupation RAM/rendu , toute l'histoire de la programmation des jeux vidéos....

Tu n'as pas de technique ultime, chacune a ses avantages et ses inconvénients, pour celle ci dans les avantages , on peut aussi mettre l'occupation de RAM.

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

pas 21 couleurs, c'était une fote de frape...

je pensais à 2 couleurs ou plutôt 1 couleur+transparence par exemple...

Le MSX2 me semble t'"il possèdait des sprites en 1 seul couleur, mais hard...
Bien sur c'est super limité mais pouyr des shchmuup...pourquoi pas, comme je le rapelle, Xénon2 en 16 bit, les tirs n'ont pas de texture...

Bah oui , si tu utilise la technique en mode 1 mais bon c'est pire du speccy porc là

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

Cela dit ya de l'idée... Je reflechissais un peu entre deux coding d'effets (j'viens d'en faire un qui déchire mémé)... n'utiliser que quelques couleurs peut permettre effectivement d'avoir plus de gfx dispo dans un seul sprite... La contrainte c'est justement de ne pas utiliser l'encre transparente qui à moins d'être commune à tous les gfxs du sprite ne causera que des soucis... Reste après à multiplier les sprites en les deplaçants (en hard ou soft selon le cas). Bon bein j'vais me faire un p'tit gfx moi

Bin pour être honnète j'ai pas tout compris à la technique...
J'ai besoin d'exemples graphiques pour comprendre, lol...

mais je vais y réfléchir, et logiquement pour des trucs comme les tirs bin il y a bien moyen de mettre de la transparence tout le temps...

Enfin, en quoi on ne peut pas faire de même en 2 couleurs en 16 couleurs ? il manque des couleurs pour "filtrer" ?
Euh, arf oui, je crois que je comprend un peu en fait, quoique...

Bon, sinon esque l'on peut mixer les techniques ? genre utiliser ça pour certains sprites et mettre d'autres en normal ?
Après avoir 2 routines de gestion des sprites peut apporter plus de lourdeur que de gains, arf...

L'intéret c'est juste de placer 2 sprites en 1 donc de gagner de la Ram, sachant que l'on extirpe le bon sprite simplement en changeant d'encres ?

Quoi qu'il en soit, si un petit malin peut cracker ghouls and ghost, je veux bien retoucher les Graphix, même en gardant les mêmes limitations du moteur...
Une simple repixélisation me semble suffisante...
Après si il reste de la ressource CPU, bin pourquoi pas des petits plus...
Arthur en sprite Hard, ça devrait déchirer, lol...

Idem pour Ghost and goblin, lui donner le véritable gameplay donc le passage en calbute (plusieurs points de vie donc) et les armes optionnelles mieux fournies...
Voir aussi un peu de retouche graphix...

Il me semble que ces jeux ne chargent que en une seule fois non ? (464 ?)


En tout cas cette méthode me semble mitigée.

Oui on gagne de la ressource Ram sans doute, mais au pris de graphismes euh...
Après GhoulsNghost est l'un des rare jeux de type plateforme en Overscan sur CPC (avec euh...donkey Kong ?)
et quand on sais ce que pompe l'overscan/fullscreen...quand même.
Il ne manque que de meilleurs graphismes encore qu'un petit masquage des sprites...
Mais c'est sinon assez jouable je trouve, malgré le "demi-scrolling" si classique sur Amstrad.

Mais fin du HS, revenons au bin's : un moteur original en Plus.

Il me semble qu'il est de bon ton de se limiter en globale sur le plus, car déjà qu'un moteur efficace et super jouable c'est pas si courant en Old..certe trop souvent auto limité par les speccy ports et le format 464...).

En tout cas rien que de multiplier les Chargements suffit à faire rentrer bien mieux les données.
les Programmeurs pros se limitaient trop au format 464 (voire Speccy 48k avec Kassette) pour des raison bassement merchantiles..
Cercle vicieux.

"oh, le 464 est le plus vendu de la gamme, on ne peut pas se passer de ce marché"
"bin alors on ne vendra pas plus de 6128 ?"
"vous ne vendrez pas plus de 6128 ? alors on a bien fait de ne faire que des jeux 464..." lol.
Et ça a fait un peu pareil avec la gamme plus qui fut non seulement limité par le Old, mais aussi par le 64Ko...

(Ah, on peut rêver d'un GX4000 avec des caretouches de 512Ko et 128Ko de Ram, là il y aurait eut des truc sympatiques...)

LA force d'un CPC, c'est bien le 6128.
Soient D7 et 128Ko.
c'est le seul moyen d'avoir des truc trouducutant le C64 car ça offre du confort relatif compensant un peu le manque de support Hard en sprites /scrolls (pour le old) et le manque de ressources système (car lourdement graphique niveau Ram).

LA Ram supérieur offre de la souplesse pour les Datas et le lecteur D7 assez rapide et fiable de la souplesse pour le chargement multiple.

Hélas, ça implique plus de temps de programation...déjà que ça leur faisait souvent chier de devoir même légèrement retoucher les Graphix depuis un speccy...

Floudeur for life.

Ca sent le G&G 128+... naaaaaan j'déconne

C'est assez simple quand on considère les choses au niveau binaire mais si tu veux je te ferai une petite illustration

Sinon , une GX4000 avec 128K de Ram , c'est pas très utile sauf à vouloir porter facilement du 6128+ format disk vers le format cartouche.En lecture, il n'y a aucune difference entre la RAM et la ROM sauf que l'emplacement en mémoire des pages ROM (0 ou #C000) en même temps que l'ASIC est super avantageux.

Après , je vais surement en fâcher certains mais , ayant eu un 6128 en premier, j'ai toujours considéré le 464 et le 664 (bien que j'adore son look avec ses fleches bleue) commes des 6128 downgradés.Mais promis , j'essayerai un de ces 4 de faire kkch qui tourne sur les trois...

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