Re: [SMS] CIMMERIAN - a Barbarian tribute

[theWave]

Joli travail, c'est vraiment super ce portage.

[Invité]

vraiment incroyable ... <3 bravo ! la suite :)

[Atlantis]

Très beau travail, félicitation et bon courage pour la suite !

Je veux une version boite avec le poster de Maria !!!

Il va falloir la contacter pour lui demander son accord.

Je ne doute pas qu'elle ait bien vieilli mais... et si on demandait plutôt à sa fille maintenant ?

Je connais pas sa fille, je suis resté bloqué sur le poster de la mère !
Mais je suis sûr qu'elle a encore de magnifiques "restes".

[drfloyd]

11 ans apres la publication, mon article est toujours tres consulté sur le web :

http://gamopat.com/article-455473.html

je me demande pourquoi............

[Ricco59_59]

Waooouuhhhh, BRAVO

Etant donné le nbre de projets en route, 2016 est un grand cru

Vivement la suite

[Invité]

http://mag.mo5.com/actu/87826/barbarian-porte-sur-master-system/

C'est bon, tu la sens désormais, la pression ? :)

[ichigobankai]

nop, j'aime pas la bière 

[Invité]

2016 va être une excellente année pour le Homebrew Français !

[ShiningBZH]

Yep , ça promet ! 

Au fait copain Vetea dans une semaine on est en Mars

[Invité]

Yep , ça promet ! 

Au fait copain Vetea dans une semaine on est en Mars

Oui oui je sais ... Mais je ne veux pas polluer le topic d'Ichigo. Rdv sur le post officiel pour de futures bonnes nouvelles !

[CPC6128]

Mon premier jeu de combat, mes premières têtes coupées
Superbe projet

[ichigobankai]

Merci

J'ai commencé à implémenter le système de collision.
J'ai activé le 2ème player (pour faire des tests de collision c'est mieux...)

Les collisions sont gérées au pixel près ^^

J'utilise une fonction cablée en hard qui est très rarement utilisée dans les jeux car celle ci met un flag lorsque 2 sprites se superposent (en prenant en compte uniquement les pixels "opaques", cad qui ne sont pas en index 0 pour la transparence), mais ce flag n'indique pas quel sprite à été touché....

C'est donc peu utilisé/non pertinent dans de "vrais" jeux avec bcp de sprites, hors dans un jeu de combat avec seulement 2 gros métasprites on peut facilement savoir qui a donné un coup et qui a reçu ^^
Exit donc les test par bounding box & cie.

J'ai codé une extraordinaire fonction en ASM de 5 lignes, wahou 

petit copié/collé de SMSpower, in english...sorry guys !
http://www.smspower.org/Development/CollisionDetection

How it works

During screen display, the VDP will set an internal flag if any two sprites are drawn such that one or more of their opaque pixels overlap.
This flag can be read from the control port; bit 5 of the byte read contains the contents of the collision flag (1 if a collision has occurred, 0 otherwise); as soon as it is read, it is reset to 0.

Thus, a game may continuously poll this flag. It seems that line-accurate emulation (changing the flag's value after each line is drawn) is sufficient for all known software to work correctly; software that relies on more accurate timing is unlikely to work on most emulators.

It is up to the game engine to determine which two (or more) sprites have overlapped, considering that there are probably more than two sprites on-screen at the time. Because they have to do this software sprite-sprite collision detection anyway, and sprite-background collision detection is also useful, most games of any complexity do not bother to use this flag and instead run their software collision detection routines once per frame.

Les sprites ont également un peu avancés, ils sont refait à ~50%.

D'après mes petits calculs, les sprites (joueurs) devraient prendre 4 banks de 16ko en tout + 2 banks de 16ko pour les versions "touchées".
Les données sont non compressées (c'est à dire que chaque tile/sprite de 8x8 pixels prends 32 bytes (ou octets) en rom) et ceci pour gagner en rapidité de chargement ! Pas de temps de décompresser des datas en temps réel, ce nous ferait perdre un temps ô combien précieux.

[drfloyd]

c'est énorme

Le gestion des collision est surement l'aspect le plus crucial pour le gameplay.

[ichigobankai]

J'ai une fonction de transfert de meta sprites > VDP a corriger/modifier + 2/3 petits trucs a mettre à jour et je ferais une petite vidéo pour montrer que l'on touche bien l'adversaire au pixel près

Ces derniers jours j'ai aussi changé mon poste de travail, en temps normal je code pour la SMS sur mon PC, SDCC étant plus simple a installer dessus (avec tout un tas d'autres soft).
Là j'ai compilé SDCC sur mon MAC, compilé WLA-DX & d'autres petit prog et du coup je peux compiler mes roms direct sur ma machine où je passe 99% de mon temps...nettement plus pratique.

[ichigobankai]

Ma fonction de transfert metasprites > VDP est enfin finie ^^

Une jolie prise de tête

En gros, ca alterne à chaque frame (cad 60 fois par seconde) l'ordre des persos dans la SAT (sprite attribute table) comme comme ca au moment où il y aura un clignotement du au dépassement des 8 sprites sur une ligne, ca clignotera en alternance les sprites en "trop" sur joueur 1 puis sur joueur 2...

Je vais tâcher de remettre quelques sprites que j'ai fait et le décor à jour avant de faire une petite vidéo (car là c'est un truc de dev ± en brut)

[drfloyd]

Enorme

Une vidéo ! Oui je veux voir ça en vidéo

PS : au final tu veux en faire une version boite ?

[ichigobankai]

oui le but serait d'en produire qq uns.

Surtout que j'ai déjà fait les pcb

et j'ai aussi un stock de coques de cartouches compatible SMS, le patron de la boite en full carton est déjà fait...donc y'a plus qu'à.

[F.L]

magnifique projet
je suis heureux de voir que ça avance bien et si je t'ai inspiré à te lancer dans cette aventure, je suis flatté.
j'adore le titre CIMMERIAN, ça rend hommage au film conan le barbare, dont etait inspiré le jeu barbarian, la boucle est bouclée...
quand je te vois en train de decouper les sprites, ça me rapelle il y a deux ans , quand j'etais en plein là dedans aussi, ça rapelle de bon souvenirs mais aussi beaucoup de travail !
j'adore le decor wasteland, plus beau que la version amiga, un challenge pour cette petite console !
je vois sur les screenshots, qu' à gauche ce sont mes decors amiga en 16 couleurs   . j'en avais bavé pour trouver les bonnes palettes
parti comme c'est, cette version sera la plus belle version, toutes machines confondues
j'espere que tu feras super attention au gameplay, car c'est le plus important de ce jeu 
va tu te servir de mes routines pour le gerer ??

j'attends avec impatience la suite !!!

[ichigobankai]

Merci !
Et oui tes portages en sont quand même un peu à l'origine

La découpe des sprites/génération des metasprites est "automatisée" au travers de scripts de mon cru.
Car la mise en place des coordonnées de chaque bloc de 8x8 serait sinon soumis a un taux d'erreurs énorme.
Quand tout sera calé, je gagnerai meme encore un peu de temps sur la gestion car je virerai les offsets que j'ai mis pour caler mes positions de métasprites, j'integrerai ces offsets directement dans les valeurs des metasprites (plus de calcul intermédiaire)

j'ai passé quelques heures hier à compiler/installer quelques petites applis, petites maj de certains de mes scripts python, créer un fichier bash (unix) pour automatiser pas mal de choses...

Dès que j'ai remis quelques trucs en place je pourrais faire une petite vidéo.

Concernant le gameplay, je ne regarde pas le code de tes barbarians car ca doit bien faire 25 ans que je n'ai pas regardé du basic... pis bon le truc fun c'est quand même de chercher comment faire un truc "compliqué" en X trucs ultra simples ^^
J'ai déjà mis à plat une bonne partie des cas de collisions, donc y'a plus qu'à.

Pour infos, j'ai quand même tester sur le hard et pour le moment c'est exactement comme sur emu

[F.L]

ça rend bien !

si jamais ça peux te servir, j'ai "traduit" ma boucle principale (sans affichage ni son) en C . tout y est à l'interieur
ça compile 0 erreur avec codeblocks.
l'année derniere je souhaitais faire un barbarian en C avec la sdl, mais depuis le debut de l'année j'ai completement laissé tomber le code...
mais je comprendrais si tu souhaite partir sur des bases "saines" car ma manière de coder est peu conventionnelle et c'est souvent compliqué de lire les codes d'un autre
@+

[65c02]

La vache ?!
Mais c'est un magnifique boulot !

[Invité]

Les données sont non compressées (c'est à dire que chaque tile/sprite de 8x8 pixels prends 32 bytes (ou octets) en rom) et ceci pour gagner en rapidité de chargement ! Pas de temps de décompresser des datas en temps réel, ce nous ferait perdre un temps ô combien précieux.

Tu as raison, et si la taille de la rom n'est pas un problème, la compression est à éviter,car franchement inutile en plus du CPU que tu perds .

[ichigobankai]

Merci

et oui pas de souci de "place", avant d'atteindre le 1Mo... j'ai un peu de marge ^^

[drfloyd]

Bordel, le screenshot, il déchire du slip

[Invité]

Merci

et oui pas de souci de "place", avant d'atteindre le 1Mo... j'ai un peu de marge ^^

Surtout que que quelque chose me dit que faire des grosses cartouches n'est pas un problème pour toi !! 

[Invité]

C'est beau.

Et es PCB aussi !

[ichigobankai]

Merci les gars !

J'ai pris le temps de vous faire un petit explicatif de la transformation des images du player 1 (qui regarde vers la droite) vers les autres variantes.

les parties indiquées (python) étant des scripts que j'ai fait.

le plus complexe étant le GENP2, celui-ci démontant les bitplanes des fichiers bin pour en modifier les offsets de palettes attribuées aux pixels.
en gros au lieu qu'un pixel soit à l'index de couleur X il est modifié en index Y
pour ceux que ca interesse, je vous renvoie lire la très belle explication (en anglais) de Maxim, un des gourous de SMSpower :
http://www.smspower.org/maxim/HowToProgram/Tiles

Autre petite chose, lors de cas de collision, le sprite qui est touché est modifié en version "blanche" car il n'est pas possible d'ajouter de sprite pour simuler un impact/gerbe de sang.
"Pas possible" dans le sens ou l'on dépasserait toujours le nombre maximum de sprite par ligne et ca moi je veux l'éviter au max !



*Gif générés via les captures de l'emulateur MEKA, normalement l'anim est en boucle, mais au cas où le lien direct :
https://i.servimg.com/u/f84/16/36/24/79/cimmer12.gif

[Invité]

C'est bien foutu, j'adore, encore plus avec les torches animées 

[F.L]

pour la gerbe de sang, tu pourrais transformer la tile du bout d'epee en tache de sang, ça t'evitera de créer un nouveau sprite
un amstrad cpc pouvait le faire, un master system le fera aisement
à chaque probleme sa solution

[ichigobankai]

et non pour le "juste un tile", le moteur des players charge le metasprite & les tiles de facon complete, pas seulement 1 morceau (à chaque frame pour les coordonnées meta et 1 fois sur 2 pour les tiles).
Mais sur CPC, c'est un sprite la gerbe de sang au bout de l'épée si je ne m'abuse...

On pourrait s'amuser a faire pour chaque type de coup, un perso avec les impacts aux endroits associés, mais honnêtement là au moins on sait que l'on a touché.

En trucs que j'ai pas encore dit :

- Exit le timer en VS car rien à foutre & inutile, ca bouffe des cycles et c'est ultra archaïque.
Si je veux laisser le jeux tourner 10h sans toucher à la manette, sans foutre une put*** de pause...pour aller pisser.

- bloquer une attaque via une protection amènera des points (et pas seulement les attaques, non mais !)

- je pense ajouter un "death mode", 1 barre de vie et tu niques autant d'ennemis que possible avec = course au hi-score à la con

et surtout correction d'une énorme bourde de toutes les versions de Barbarian que j'ai pu voir :
quand on décapitera un gars sa barre de vie sera directement à 0 ^^

[Invité]

et surtout correction d'une énorme bourde de toutes les versions de Barbarian que j'ai pu voir : 
quand on décapitera un gars sa barre de vie sera directement à 0 ^^

LOL, détail complètement inutile, donc forcement indispensable