Re: [SMS] CIMMERIAN - a Barbarian tribute

[ichigobankai]

Le CPC n'est pas du tout comme une SMS.
D'après ce que ma expliqué Vingazole (et si j'ai bien compris) sur CPC ca calcul l'affichage au complet (car pas de sprite hard) c'est pour ca que tu peux mettre n'importe quoi, mais que par contre c'est bcp plus lent à l'affichage vu que ca doit rafraîchir tout l'écran.
Sur Spectrum aucune idée, je ne connais pas la machine (mais c'est peut etre la même avec moins de couleurs).
Perso c'est cette version là (spectrum) que je trouve la plus intéressante graphiquement.

Et comme je l'ai dit, je PEUX mettre le sang sans problème (je suis loin des 64 sprites qui est le max), le souci est le clipping des sprites quand on dépasse les 8 par ligne, et ca moi j'en veux pas. Avec Vingazole on se prend la tête sur chacun de nos devs pour justement l'éviter.
Si j'avais laissé les persos avec leur taille d'origine, ca aurait marché aussi....mais ca aurait clignoté comme un sapin de noël.

Les persos faisant déjà 4 sprites/tiles de large en temps normal (et à 90% du temps) je suis quasi tout le temps à 8, donc le sang en sprite "à part" c'est non. 
Je peux - par contre - faire une version alternative du metasprites avec le sang sur l'épée car je ne charge pas juste "1 sprite", mais un metasprite complet (tiles & coordonnées), la boucle en ASM étant faite avec des instructions OUTI pour aller le plus vite possible pour le transfert de données). 
Là en l'état j'ai (vraiment) pas le temps de le faire pour la fin du concours qui est dimanche prochain. 
Au risque de me répéter, je ne fais pas un "portage de Barbarian" bête et méchant, ca ne m'intéresse absolument pas.
J'y rajoute des trus que me plaisent et modifie des trucs que je trouve complètement con. Qui a parlé de double décapitation ?

Pour le gnome pas trop un souci, j'ai déjà tout pensé/solutionné en amont (et il ne fait que 2 tiles de large soit 16 pixels), 
meme souci/réponse que pour le perso qui tombe au sol, faut penser jouer avec l'axe Y. 
Ca rajoute un peu de profondeur de champ et surtout m'évite cette saleté de clipping.
Je ne me suis pas lancé dans ce truc sans y avoir réfléchi un peu avant

- j'espère ne pas avoir répondu de façon trop abrupte ! -
(perso le tact j'ai plutôt tendance à garder ca plutot pour mes enfants)

@Rod, lol ^^
Sur NES y'a que 2 choses "vraiment" bien (pour moi) :
- les boutons start/select sur la manette (manque cruellement à la MS, même si on peut feinter avec la manette MD et coder pour que les boutons soient pris en compte)
- le proc audio 

Bon, vu qu'il me reste encore des tiles de dispo en VRAM, je ferais peut etre réagir le méchant en arrière plan (selon les attaques avec un petit % aléatoire par dessus, histoire que ce ne soit pas toujours effectif)

[Invité]

bah le jeu qui va prouver que la SMS > NES (une fois encore) :)

T'aime bien lancer des trolls ?
Elle sont très équivalente , si la nes a des défauts je dirait que j'en trouve 3 par rapport a la SMS:
-la Nes a moins de couleurs possible que la SMS (pas énorme 53 contre 64), et pas les mieux choisi (mais c'est subjective).
-La Nes fonctionne avec un système de Mapper qui d’après moi limite grandement le rendu visuel (surtout pour les animations) , je préfère la SMS avec sa possibilité d'écrire en VRAM (comme toute les autre consoles par la suite).
-La SMS a plus de RAM que la Nes , mais cela est pas très important tout dépend tu type de jeu qu'on veut faire cette différence peut être nul (ou alors on considère qu'une SNES est plus puissante qu'une Neo Geo si on ne prend que ce critère la...).

Après comme le dit ichigobankai la nes a un bon proc audio et la manette est un vrai plus d'ailleurs pour cela que je me suis pas lancé dessus sur la SMS (me suis arrêter a une démo technique) , je trouve le manque de bouton trop limitant malgré son architecture simple (Je l'avais deja dit mais la SMS est pour moi la console la plus facile a programmé dans l'ere du 8/16 bits).

[Invité]

bah si tu veux faire agir le méchant, fais le sur la décapitation, ca serait énorme ! :)

[ichigobankai]

Pour que F.L soit content, voilà à quoi les impacts pourraient ressembler 

(uniquement les frames "touchantes", les autres ne sont pas testée et/ou valide au niveau collision)
le coup de boules et le coup de pied peut être à mettre en blanc plutôt que rouge (j'ai les 2 couleurs dispo dans la palette)

[Invité]

Sur NES y'a que 2 choses "vraiment" bien (pour moi) :
- les boutons start/select sur la manette (manque cruellement à la MS, même si on peut feinter avec la manette MD et coder pour que les boutons soient pris en compte)
- le proc audio 

Tu peux aussi rajouter un DMA pour le transfert RAM/SAT, et le système de CHR-ROM comme sur NG qui est une bonne idée .
La nes est aussi de conception plus vieille que la SMS, 2 ans les séparent et je pense que finalement la nes s'en tire pas trop mal fasse à la SMS, chacune ayant ses points forts,le shoot blade buster sur nes est très impressionnant je trouve  .

Sinon pour en revenir au topic, j'aime bcp ta planche ichigo 

[Invité]

"La nes est aussi de conception plus vieille que la SMS, 2 ans les séparent et je pense que finalement la nes s'en tire pas trop mal fasse à la SMS, chacune ayant ses points forts ."

Je réutiliserai cet argument dans Super Nintendo VS Megadrive : Fight :)

[Invité]

Je réutiliserai cet argument dans Super Nintendo VS Megadrive : Fight :)

Non les arguments qui arrangent doivent rester dans leur topic respectif  .
C'est écrit dans la convention de Genève .

[F.L]

Pour que F.L soit content, voilà à quoi les impacts pourraient ressembler 

(uniquement les frames "touchantes", les autres ne sont pas testée et/ou valide au niveau collision)
le coup de boules et le coup de pied peut être à mettre en blanc plutôt que rouge (j'ai les 2 couleurs dispo dans la palette)

oh joie
le diable est dans le détail. c'est nickel
par contre, pas la peine pour le coup de tete et coupdepied, puisqu'il n'y a pas de contact avec l'épée

pour revenir à la précédete page, je suis ravi que tu ai prévu la place pour le gnome et la tete, tu as tout ce qu'il faut pour finir le jeu. c'est cool.
tes expliquations sont claires, et tu as du tact, t''inquiete . j'ai remarqué que tu programmes d'une manière très académique et ordonnée, felicitations, tout l'inverse de moi

d'ailleurs de te voir faire ce jeu sur sms, ça me donnerait presque envie de m'y mettre.j'imagine qu'il y a des ressemblances de programmation avec la megadrive ?
as tu un site à me conseiller qui explique comment faire un hello word sur sms et les outils necessaires ? on peut avec codeblocks ?
bon courage poour la suite
@+

[ichigobankai]

je savais que ca te plairait ^^

Effectivement pour les coups de boules et pieds ne devraient logiquement pas avoir (trop) de sang, mais je pense qu'il faut quand même signaler "l'impact" étant donné que ca enlève quand même de la vie...

Si tu veux essayer de coder sur MS, y'a la lib C de sverx qui est dispo/public : http://www.smspower.org/forums/15228-DevkitSMSDevelopYourHomebrewInC
https://github.com/sverx/devkitSMS
et Sverx a fait un petit tuto d'utilisation : http://www.smspower.org/forums/15888-DevkitSMSTutorial
Normalement ca doit ressembler à notre lib (vingazole & moi), vu qu'a l'époque Sverx nous avais demandé d'y jeter un oeil pour créer la sienne.
Sinon y'a WLA-DX pour s'y essayer en ASM Z80.

Je code avec un 'pov soft type notepad (enfin un équivalent sur mac)
Difficile de te dire si je code de façon "académique"  / ordonnée ou non...je fais comme je pense que ca doit être fait (et c'est pas forcément le bon choix, mais tant que ca fonctionne bien). 
Je suis encore loin d'être un crack en C, je me fais toujours un peu chié sur les pointeurs 
SDCC est un bon prof, car pas franchement permissif et à la moindre merde il à plutôt tendance à t'éjecter de la compilation.

Te dire les équivalents entre MS et MD a mon avis y'en a pas des masses... 
Les grosses différence étant que l'on travaille uniquement en tiles 8x8 et que le VDP est un gros goulot d'étranglement (on ne peut pas envoyer bcp de tiles par vblank et tu le satures tres vite ce vblank) et que forcément le Z80 de la SMS et plus lent que le 68000 de la MD ^^
Coder sur MS n'est pas tres compliqué je pense, mais il y a quand même pas mal d'infos à assimiler.
Avec vingazole on a passé bcp de temps en tests divers & variés...et on en fait encore.
Perso j'ai un Master Everdrive version USB (gagné a un concours SMSpower d'ailleurs) et c'est top pour tester sur le hard, une ligne de commande dos (ou un batch) et ca envoie direct la rom.

Au final c'est comme dans n'importe quel langage, faut faire "assez" simple et surtout efficace (savoir manier les bytes/octets & bits est -a mon sens- obligatoire)

[Stef]

Peut être que certains l'ont vu (ou pas), mais sur ma version quand un player est touché par un coup "violent", le perso tombe au sol plus bas que dans les versions "normales" de barbarian.
...
Cela n'est pas anodin, c'est pour éviter le dépassement des 8 sprites par ligne 
(qui est à l'origine du bien connu "clignotement de sprites")

J'avais remarqué ce détail et je me demandais pourquoi... maintenant j'ai compris, bien vu
D'ailleurs tu as extrêmement bien géré cette contrainte de sprite, je n'ai pas vu un seul clignotement malgré la taille conséquente des sprites (pour de la MS) :)

[Invité]

Je code avec un 'pov soft type notepad (enfin un équivalent sur mac)
Difficile de te dire si je code de façon "académique"  / ordonnée ou non...je fais comme je pense que ca doit être fait (et c'est pas forcément le bon choix, mais tant que ca fonctionne bien). 
Je suis encore loin d'être un crack en C, je me fais toujours un peu chié sur les pointeurs 
SDCC est un bon prof, car pas franchement permissif et à la moindre merde il à plutôt tendance à t'éjecter de la compilation.

Je te félicite , franchement j’aimerai pas coder a un équivalent de notepad  , (et pk ne pas utiliser un IDE c'est pas ce qui manque pour le C ? ).
Faire un jeu sans maîtrisé les pointeurs , bravo ,, mais je pense que c'est a double tranchant , un pointeur qui dépasse sus SMS , le jeu continuera a 'marcher' (tout dépend ou tu écris), sur PC les bug seront plus aléatoire voire un plantage de ton programme , et cela aucun compilateur peut t'aider (il faut utiliser un debugger pour ce genre de cas).

Te dire les équivalents entre MS et MD a mon avis y'en a pas des masses... 
Les grosses différence étant que l'on travaille uniquement en tiles 8x8 et que le VDP est un gros goulot d'étranglement (on ne peut pas envoyer bcp de tiles par vblank et tu le satures tres vite ce vblank) et que forcément le Z80 de la SMS et plus lent que le 68000 de la MD ^^
Coder sur MS n'est pas tres compliqué je pense, mais il y a quand même pas mal d'infos à assimiler.

le Vblank est limité pour n'importe quelle machine , je suis limité aussi sur SNES , et sur MD aussi elle est limité , je me fixe 4ko d’envois dans le VBlank grand max (et c'est pas énorme pour ce que je veux en faire).
Par contre je suis moins d'accord sur les info a assimilé , j'ai appris la prog sur SMS en 2-3 jours , ya vraiment pas grand chose a voir et on fait le tour assez vite , sauf si tu parle du Vblanlk/nmi/irq , 2/4bpp ect mais ça ce sont des info d'ordre général (qu'on retrouve sur toutes les machines 8/16 bits).

[pckid]

Je pense que l'on peut feliciter Ichigo, juste le fait d'aller jusqu'au bout de ses projets, ils poussent toujours à la qualité, et cela est fort appréciable.

Je sais pas si sur gamopat il a parlé de son bomberman Sms , avec création d'un quadrupleur sur SMS.
il passe du dev à la création de hard.
Bravo à lui, d'aller jusqu'au bout et de nous faire vivre la sms.

[ichigobankai]

lol ^^
J'ai failli écrire un pavé en mode connard, mais vu je suis un peu naze (dormi 3h) je m'abstiendrais de dire n'importe quoi.

Je ne maîtrise peut être pas parfaitement les pointeurs, mais j'arrive à me démerder un peu en elec.
(et pour vérifier les pointeurs y'a quand même les debuggers sur emu, c'est pas freestyle non plus, hein)

4 ko pendant un vbl, ca perso, ca me laisse rêveur, de mon coté c'est plutôt ~7/800 octets...arghh
de mémoire je dois bouffer ~400 octets de ram (sur 8192) pendant le jeu (surtout le pré-calcul des éléments de la SAT et sa copie qui prennent de la place).

J'ai remis l'IA et du code autour et je me fais bien latter la gueule...
j'ai l'impression d'être devant un des derniers ennemis du jeu, lol.
J'ai mis en place le lecteur audio (musique & sfx), bon faut pondre une track ou 2 et ca c'est moins simple et surtout chronophage, surtout si je veux pas faire un truc merdique avec 4 notes style "piou piou 8bits"

pour le Bomberman, alias NEKO BLASTERS de son vrai nom, Vingazole ouvrira un thread quand il le voudra, vu que c'est lui qui code le jeu en full ASM.

[Invité]

C'est très beau graphiquement, chapeau 

Sinon perso pour le moment je code avec notepad++ qui est très bien .
J'ai du mal à voir l'intérêt d'un code blocks pour ce genre de projet 

[pckid]

Oui ça fait très moderne, dans l'air du temps, à l'époque de la Sms vs Nes , cela aurait fait mal au proc graphique de la nes !

[philip]

je savais que ca te plairait ^^

Effectivement pour les coups de boules et pieds ne devraient logiquement pas avoir (trop) de sang, mais je pense qu'il faut quand même signaler "l'impact" étant donné que ca enlève quand même de la vie...

Dans ce cas peut être un flash blanc à la place du sang.

Chapeau bas pour les graphismes !... et la prog aussi.

[ichigobankai]

Merci

J'ai ré-activé / modifié  l'IA, elle est encore perfectible (et pour l'instant ne change pas en fonction du level) mais c'est déjà sympa en l'état.

Pour la démo de dimanche il y aura :
- mode story avec 3 arènes (1p + 1 bot alétoire)
- mode versus (2 players - persos aléatoires)
le jeu reboot après 3 combats, histoire de voir les 3 arènes.

La décapitation arrivera après, je préfère intégrer/finir les 2 arènes restantes et peaufiner 2/3 choses du gameplay. Je choisi de laisser la mort de coté car je ne pense pas avoir le temps de la coder + finir le gnome et tout animer. Et j'ai pas envie de bâcler cette partie qui est quand même un peu ± la meilleur chose du jeu (avec la babe à gros boobs )

Pour terminer ce petit post, Vingazole me disait que ce serait sympa de montrer/expliquer un peu une partie du pixelart.



Voilà donc une capture après / avant, de la partie serpents enroulés autour des colonnes.
J'ai rajouté un petit effet de rétro-éclairage, une astuce que j'utilisais à l'époque où je faisais de l'image de synthèse pour faire ressortir les volumes. (3DSmax pour les intéressés)

[F.L]

bien vu pour l'effet sur les serpents. il etait présent sur la version cpc (la plus travaillée graphiqement) regarde les eclairages du decor "trone", sublime


je me posais une question : est il possible sur sms d'afficher tout simplement des tiles avec une couleur transparente ? (sans etre déclaré en tant que sprite)
je me disais ça car quand le gnome va tirer le cadavre tu va vite arriver aux 8 tiles horizontales :
joueur1 présent+joueur2 allongé+gnome+tete decapitée suivant le cas (!!)
si c'etait possible , tu pourrait contourner la limitation des sprites. pas con, non ?

[pckid]

Je voudrais demander un truc à ichigo, et désolé d'avance pour les fans de Barbarian.

J'ai toujours trouvé ce jeu à l’époque lent et lourd , ou plutôt un temps de réaction lourd avant que le joueur saute, donne un coup . Cela m'a toujours déçu quand je jouais au cpc chez un pote, alors je préférais un boulder dash , ou renegade, ou gauntlet.

Peut on profiter de la SMS pour dynamiser l'action des players avec une rapidité plus Babarian sur Amiga, ou une fluidité StreetFighter 2, enfin moins CPC ?

Vraiment sorry, mais cela est un retour d'un joueur.

Version Ichigo


Version cpc


Version Amiga

[Invité]

tout simplement des tiles avec une couleur transparente ? 

Bah oui, on appelle ça un sprite hard   .
Plus sérieusement,non pas avec 1 seul plan hard, donc si tu veux gérer ce genre de chose faut passer sur du sprite soft ici .

Au fait ichigo, je sais pas si tu en as parlé, mais es ce que tu gères(ou va gérer) du z-order pour les combattants ??

[Stef]

Y'a seulement 2 combattants, pourquoi gérer du Z-order ?

[Invité]

Y'a seulement 2 combattants, pourquoi gérer du Z-order ?

Pour que quand celui de faible priorité frappe ,il ne soit pas masqué par l'autre sprite,tu vas avoir des rendus à l'écran bizarres entre les 2 sinon .

Mais c'est peut être plus une simple gestion de priorité que du z-order pur et dur  ..

[ichigobankai]

Pour l'ordre il est changé une frame sur 2 (modifié à chaque vblank) :
P1 > P2
P2 > P1
P1 > P2
etc..
ceci pour éviter que lors du dépassement des 8 sprites par ligne, le player en 2ème position de la SAT ne soit pas "effacé" au niveau sprites.
En gros ca fait un effet de transparence (clignote à 60fps) quand les persos se chevauchent.
J'ai opté pour du "sang" blanc pour les impacts car le rouge ne ressort pas du tout (mais alors pas du tout).
sauf peut etre dans certains futurs background mais bon faut faire des choix de façon global.

D'ici quelque jours vous pourrez tester vous même de toute façon

@FL le barbarian que tu as posté une une maj récente faite par des fans.
A l'origine c'est quand même bien moins "joli". Pis bon, y'a pas de rétro éclairage sur les serpents ^^
Et je crois avoir déjà expliqué que le cadavre ne sera pas sur le même axe Y, donc faux souci.

J'ai fait un bout de vidéo, j'ai encore quelques bugs/glitchs à régler (là c'est du brut, j'ai pas testé sur le hard la rom depuis plusieurs jours) mais ca donne un aperçu de la "vitesse". bon par contre jouer avec une seule main...c'est franchement imbranlable !


Evidemment sur une vidéo filmée n'importe comment ca donne un rendu...de merde.

[Invité]

Rien à dire c'est très beau, chapeau pour les petites anims dans les niveaux,je sais que je me répète mais bon quand on est fan . 

[Stef]

Y'a seulement 2 combattants, pourquoi gérer du Z-order ?

Pour que quand celui de faible priorité frappe ,il ne soit pas masqué par l'autre sprite,tu vas avoir des rendus à l'écran bizarres entre les 2 sinon .

Mais c'est peut être plus une simple gestion de priorité que du z-order pur et dur  ..

Ah oui effectivement, celui qui frappe devrait donc toujours se trouver devant ? Mais effectivement c'est le terme Z-Order qui m'avait étonné, ici il s'agit de donner la priorité à 1 joueur ou l'autre selon la situation.

Pour l'ordre il est changé une frame sur 2 (modifié à chaque vblank) :
P1 > P2
P2 > P1
P1 > P2
etc..
ceci pour éviter que lors du dépassement des 8 sprites par ligne, le player en 2ème position de la SAT ne soit pas "effacé" au niveau sprites.
En gros ca fait un effet de transparence (clignote à 60fps) quand les persos se chevauchent.

Ca ne fait pas un peu bizarre quand les joueurs se chevauchent cette alternance de priorité ?
Sinon vraiment félicitations, c'est du très bon boulot ! Tu gères parfaitement les contraintes de la machine, que ce soit au niveau du choix des couleurs, la gestion de sprites pour éviter les clignotements... j'adore quand on est face à un jeu et qu'on ne ressent pas du tout les contraintes techniques du support, et là c'est le cas =) Certes Barbarian n'est pas un jeu très demandeur en ressource mais rien que pour les graphismes et les sprites c'est vraiment bien géré =)

[Invité]

Ah oui effectivement, celui qui frappe devrait donc toujours se trouver devant ? 

Doit, je sais pas, mais j'ai toujours eu une impression bizarre en tant que coder, ça m'a toujours gêné visuellement, mais c'est peut être moi qui fait une fixette .
Par exemple tu vas avoir un joueur dont le coup de pied va être au dessus, et celui de l'autre derrière, moi ça me dérange un peu ..

Mais effectivement c'est le terme Z-Order qui m'avait étonné, ici il s'agit de donner la priorité à 1 joueur ou l'autre selon la situation.

Oui le terme était un peut fort là ..

[pckid]

Mais effectivement c'est le terme Z-Order qui m'avait étonné, ici il s'agit de donner la priorité à 1 joueur ou l'autre selon la situation.
Oui le terme était un peut fort là ..

C'est un terme explicite , je reconnais ce terme, car ichigo, fait du dev Web ! comme moi d'ailleurs.

[ichigobankai]

Ca ne fait pas un peu bizarre quand les joueurs se chevauchent cette alternance de priorité ?

Sinon vraiment félicitations, c'est du très bon boulot ! Tu gères parfaitement les contraintes de la machine, que ce soit au niveau du choix des couleurs, la gestion de sprites pour éviter les clignotements... j'adore quand on est face à un jeu et qu'on ne ressent pas du tout les contraintes techniques du support, et là c'est le cas =)
Certes Barbarian n'est pas un jeu très demandeur en ressource mais rien que pour les graphismes et les sprites c'est vraiment bien géré =)

En fait ca ne gène pas vraiment (le coup des sprites 1 sur 2 ) car le chevauchement n'intervient que sur certains cas très spécifiques.

Merci pour les compliments en tout cas, venant de gens que j'estime "très bons" ca me fait particulièrement plaisir

Bon là faut rester les pieds sur terre ca reste un "petit" dev sans vraie grande prétention technique.
Quand je vois ce que code / peut coder Vingazole...c'est franchement pas comparable.
En temps normal c'est d'ailleurs Vingazole qui se farci la partie code et moi la partie graphique, on se complète plutôt bien ^^
Mais pour une fois j'avais envie de faire un truc 100% solo...histoire de montrer que l'on peut coder un petit jeu en C -pas trop merdique- et qu'il tourne sur le vrai hard.

Lol, le fameux Z-ordering, on devrait plutot appeler ca du Y-ORDER sur nos vieilles machines 2D...y'a pas la 3ème dimension ^^

[Invité]

Non non je maintiens pour le z-order , juste que effectivement le rendu 2D rend le z et y dans le même axe , mais je considère que c'est un z order vu que on manipule une profondeur (donc une nouvelle coordonné) c''est plus flagrant avec un beat them all , on peut se déplacer en haut/bas , droite /gauche et sauter (donc une hauteur).
Mais on général (que cela  soit en 2D ou 3D) je considéré le Y comme une hauteur , donc on général sur un jeux 3D si tu te déplace tu te déplace sur X et Z et si tu saute tu te déplace en Y.

[Invité]

Je suis un peu d accord avec kannagi, techniquement c est du y, mais dans la pensé il y a une notion de profondeur derrière .
Enfin on s en fou, l essentiel c est de se comprendre .

[ichigobankai]

Clair qu'on s'en branle de la dénomination.