Re: [SMS] CIMMERIAN - a Barbarian tribute

par **drfloyd** Sam 11 Fév 2017 - 10:26

ah oui le fond scrolle !!!!! Shocked

C'est du pixel perfect, c'est du retro 100% maitrisé.

Chapeau

par **Tryphon** Sam 11 Fév 2017 - 10:43

Qh non c'est pas du pixel perfect. C'est beaucoup plus beau que l'original !

par **drfloyd** Sam 11 Fév 2017 - 11:57

Tryphon a écrit:Qh non c'est pas du pixel perfect. C'est beaucoup plus beau que l'original !

je ne comparais pas à l'original en disant ça.

C'est un pixel perfect pour cette console, c'est la perfection visuelle.

par **Tryphon** Sam 11 Fév 2017 - 12:20

Pixel perfect c'est quand tu fais un portage en tout point identique à l'original Very Happy

par **philip** Sam 11 Fév 2017 - 23:42

La mise en couleur est excellente !

par **drfloyd** Dim 12 Fév 2017 - 0:23

Tryphon a écrit:Pixel perfect c'est quand tu fais un portage en tout point identique à l'original

oui mais moi je disais ca dans le sens que c'est de l'art graphique "perfect" pour la SMS !

par kawickboy Dim 12 Fév 2017 - 12:23

Tu as prévu des trucs cachés genre perso comiques alternatifs, ou cheat qui se débloquerait avec le lightgun...?

par ichigobankai Dim 12 Fév 2017 - 15:28

si je disais tout, tout de suite ca ne serait pas drôle Wink

par Alucardark Dim 12 Fév 2017 - 18:25

Très beau boulot, le jeu est joli jusqu'au debug mode (et ça, c'est vraiment le genre de détail que j'apprécie). Chapeau!
Question toute bête, et peut-être déjà posée ici, mais est-ce qu'il y aura une compatibilité avec le module FM de la SMS?

par ichigobankai Dim 12 Fév 2017 - 20:52

Avec Vingazole on y a pensé, mais pas encore tranché la question.

par ichigobankai Mar 14 Fév 2017 - 12:19

Allez pour le fun,
hier j'ai commencé à convertir certaines fonctions originellement en C en full ASM (en assembleur inline, cad directement au milieu du code en C)
[SMS] CIMMERIAN - a Barbarian tribute - Page 15 Sdcc_a10

[SMS] CIMMERIAN - a Barbarian tribute - Page 15 Sdcc_a10

J'ai juste gagné +60% sur l'affichage actif, lol.
(en ré-écrivant seulement 3 fonctions)
Et ca fait bien exactement la même chose, je vous rassure.

par **F.L** Mar 14 Fév 2017 - 13:32

les lignes colorés sur les cotés representent l'affichage actif ? c'est ça ?
60% c'est enorme. c'est du à quoi ? à des tiles similaires ou qq chose comme ça ?

par **Tryphon** Mar 14 Fév 2017 - 13:39

Non. Juste du code assembleur mieux foutu qu'un code compilé.

par ichigobankai Mar 14 Fév 2017 - 13:41

Surtout des calculs/transferts de données des positions des elements de metasprites,
et oui c'est pendant l'affichage actif

en C ce sont des memcopy, normalement un truc plutot tres rapide une fois en asm.
Sauf que parfois SDCC perd les pédales à la compilation et fait (vraiment) n'importe quoi sur certains memcopy... alors que d'autres sont impec.
Doit y avoir trop de param / variables à un moment et il en peut plus de la vie ^^
Du coup j'ai tout réecrit à la main.

par Stef Mar 14 Fév 2017 - 23:34

Le gain est quand meme très impressionnant ! Sur la partie rose tu as gagné un facteur 3 ou 4, sur les parties jaunes et orange c'est un facteur 5 ! SDCC fait vraiment un travail de sagouin :-/ J'ai l'impression qu'il est pire que GCC sur MD MDR

Enfin je ne doute pas que ton code est particulièrement bon également Wink

par **drfloyd** Mar 14 Fév 2017 - 23:36

ichigobankai a écrit:Allez pour le fun,
hier j'ai commencé à convertir certaines fonctions originellement en C en full ASM (en assembleur inline, cad directement au milieu du code en C)

J'ai juste gagné +60% sur l'affichage actif, lol.
(en ré-écrivant seulement 3 fonctions)
Et ca fait bien exactement la même chose, je vous rassure.

ENORME

Je te tire mon chapeau moi que ne pige que dalle en assembleur !!! Mais alors que dalle...

par Invité Mer 15 Fév 2017 - 0:48

* se met à genoux *
Respect.

par ichigobankai Mer 15 Fév 2017 - 9:30

Merci les gars !

Concernant SDCC, je regarde assez régulièrement le fichier asm généré et en général c'est "plutôt" bien fait.
Mais pour une raison que j'ignore les fois ou j'ai mis pas mal de calculs & conditions dans de grosses fonctions il a perdu un peu les pédales...

par Invité Mer 15 Fév 2017 - 12:41

Faut pas que vous zieutez le code généré de Huc le compilo C pour la PCE alors Mr. Green

.
Le passage des variables dans une fonction est génial Cool

par grostonton Mer 15 Fév 2017 - 15:33

C'est vraiment très maîtrisé graphiquement, je m'incline, chapeau ! thumleft

par airdream Mer 15 Fév 2017 - 23:09

on croirait presque a de la MD

par **Tryphon** Jeu 16 Fév 2017 - 1:44

ichigobankai a écrit:

Ça correspond à quoi les bandes de couleurs à l'extérieur ? C'est une feature de l'ému ?

par ichigobankai Jeu 16 Fév 2017 - 9:55

c'est une fonction set border que l'on a ajouté à notre lib avec Vingazole.

Ca prend une couleur de la 2eme palette (celle des sprites) et la met en index 0 (overscan) de cette meme palette.
Juste a mettre autant de set_border(xx) dans/autour des fonctions dont je veux voir la charge (avec plusieurs valeurs pour voir plusieurs couleurs)

En temps normal y'a que sur le hardware que tu pourrais voir ces couleurs, mais Emilicious un emu multiplateformes (et tres fidèle pour la SMS) permet aussi d'activer l'overscan (et donc de voir ces bandes)

par **Tryphon** Jeu 16 Fév 2017 - 13:17

Ah pas con. Ça te permet de voir ce qu'il se passe pendant le vblank ? Super ingénieux !

par ichigobankai Jeu 16 Fév 2017 - 14:31

pendant les hblank Wink

ca fonctionne pour l'affichage actif et le vblank.

par **F.L** Jeu 16 Fév 2017 - 18:17

tu programmes de façon tres pro, ça fait plaisir à voir !
j'aimerais savoir faire comme toi mais il me manque des bases Embarassed

par ichigobankai Jeu 16 Fév 2017 - 19:39

Si je codais de façon "tres pro" je ferais ça 100% en asm et y'aurais 0 debug du 1er coup , mais j'en suis bien incapable ^^

Mais le compliment me fait plaisir Embarassed

par Invité Jeu 16 Fév 2017 - 20:39

Les "Pros" font aussi des erreurs et leurs projets n'échappent pas aux bugs ! Wink

Mais ce qui est chouette dans ta démarche, c'est d'aller dans le très bas niveau pour améliorer le projet ou d'arriver à ce que tu veux. amoureux

par bfg Ven 17 Fév 2017 - 22:01

ichigobankai a écrit:Merci les gars !

Concernant SDCC, je regarde assez régulièrement le fichier asm généré et en général c'est "plutôt" bien fait.
Mais pour une raison que j'ignore les fois ou j'ai mis pas mal de calculs & conditions dans de grosses fonctions il a perdu un peu les pédales...

Toi aussi, il fait n'importe quoi dès qu'on fait des calculs mathématiques "complexe" ?

J'en suis à faire des merdes de ce genre quelquefois :

unsigned int foutu_bug(unsigned int v1,unsigned int v2)
{
return v1+v2;
}

unsigned int rand_a_b(unsigned int a, unsigned int b){
unsigned int r;

/* Putain de bug à la con de compilo qui me force à faire ça !! */
r = manual_rand();
r = r % (b-a);

return foutu_bug(r,a);
}

Ou alors c'est moi qui est très fatigué et que je dois me mettre à l'élevage de chèvre ...

par ichigobankai Sam 18 Fév 2017 - 9:38

Non j'ai pas encore eu a faire ce genre de tour de passe passe Wink

j'ai modifié des bouts de code comme ca :

le truc originel en C, rien de transcendant :

Code:: ;rom.c:1354: memcpy( (unsigned char *)bkg_anim_pos, (unsigned char *)bkg_anim_infos[1], (is_bkg_anim*7)); //en bloc

L'ASM généré légèrement caca... surtout que je ne connais pas le cout en cycles/la tronche du code de la fonction memcpy de la lib SDCC (issue du string.c/h) - j'ai pas spécialement cherché non plus ^^

Code:: ld de, (#_bkg_anim_infos + 2) ld bc,(_is_bkg_anim) ld b,#0x00 ld l, c ld h, b add hl, hl add hl, bc add hl, hl add hl, bc push hl push de ld hl,#_bkg_anim_pos push hl call _memcpy ld hl,#6 add hl,sp ld sp,hl

[/code]

Là la même chose, codée par mes soins, à la main.
avec un truc "normal" à base de ldir pour copier en blocs.

Code:: __asm ld hl, (#_is_bkg_anim) ld a, l ; l max = 6, a max = 42 rlca ; rlca ; rlca ; sub a, l ld c, a ld b, #0 ; bc = nb ld hl, (#_bkg_anim_infos +2) ;from ld de, #_bkg_anim_pos ;to ldir __endasm;

c'est avec ce genre de bout de code à la noix que j'ai gagné un facteur de quasi 5 sur les couleurs orange & jaune.

par nemokantio Sam 18 Fév 2017 - 13:47

Ne soyez pas trop dur avec sdcc, après tout le processeur cible n'est qu'un Z80...
Par contre je confirme aussi qu'il peut péter les plombs, j'ai eu ça.

Ichigo dans ton code originel en c, tu appelais memcpy (et du coup il utilisait la pile pour les paramètres), dans ta version asm tu fait directement le ldir donc ce n'est plus pareil.
Et pour la multiplication par 7, en c il faisait ça en 16 bits (et en faisant *2+1*2+1), là toi tu l'as optimisé en 8 bits (et en faisant *8-1)...

Très intéressant !
thumleft