[Xav] Sonic the Hedgehog

[Laucops]

Miam, miam...

Si ça arrive à terme, ce sera quand même le homebrew le plus énorme de la pce... Y a certains dèvs mégalos qui vont en prendre pour leur amour-propre là...

J'ai hâte de voir la suite !

[touko]

EHEH cool

[shubibiman]

Que j'aimerais que ce titre bénéficie d'une sortie "officielle" sur une vraie galette. Il le mériterait largement.

[Arm]

Bravo vivement que cela aboutisse.

[shubibiman]

Xav, je me demandais si tu connaissais ce site :

http://opensnc.sourceforge.net/home/index.php

[xav]

Bien sur, ils ont fait un sacré bon boulot.
Qu'en a m'en inspirer c'est autre chose, Open sonic est écrit en C avec des opérations 32 bits et des virgules, sonic SCD en small C avec le stricte minimum d'entier en 16 bits.
Appliquer les algos de l'Open sur le mien transformerais Sonic the hedgehog en Sonic the arthrotic turtle

[citylab2]

je viens de voir tout ton boulot et franchement un grand BRAVO pour tout ça! Vivement que le jeu soit finit! ça fait plaisir de voir des fans assidus de la nec à ce point.

[Kaminari]

DIMPS devrait en prendre de la graine...

[xav]

Avis au pro de l'asm, J'aurais besoin d'un petit coup de main s'il vous plait.
Les collisions avec le décor sont gérer par une map secondaire qui code sur 4 bits l'attribut d'un tile quelconque de la vrai map.
Voila comment ça marche en C:

#incbin(collision_map, "GHZ//ghz1.bin");
.
.
.
map_get_coll( x, y)
char x, y;
{
int adr;
char data;

adr=(y*map_width)+x;
adr=adr>>1;
adr+=2;
data = collision_map[adr];

if(x & 1) data=data >> 4;
else data=data & 0x0F;
return data;
}

Ça marche parfaitement tout en restant simple, mais ce n'est pas super rapide, surtout au niveau de l'accès au tableau/pointeur.
Comme cette fonction et appelé TRÈS souvent, y aurais il moyen de la réécrire complétement en asm?

NB: collison_map ne fait jamais plus de 8Ko, de même x, y et map_width ne dépasse jamais 255.

[Tanuki]

Le truc serait d'éviter la multiplication, mais map_width n'est pas constant ...

Il faut d'abord un morceau de code qui fasse une multiplication 8-bit => 16bit:

Je propose ça en pseudo-asm (si je me suis pas planté):

Code : Tout sélectionner

;==============================================================================

; ** A_op et B_op sont altérés pendant le traitement **

A_op:         EQU  $2000      ; 8-bit  (multiplicande)
B_op:         EQU  $2001      ; 8-bit  (multiplicateur)

result:       EQU  $2002      ; 16-bit (résultat)

A_op_msb:     EQU  $2004      ; 8-bit  (variable privée du code)

;==============================================================================

factor_start:

              STZ result      ; initialise le résultat à zéro
              STZ result+1

              STZ A_op_msb    ; initialise la partie supérieur du ...
                              ; multiplicande

loop:         LDA B_op
              BEQ finish      ; termine si le multiplicateur est nul

              LSR A           ; divise le multiplicateur par 2
              STA B_op
              BCC next_step

              CLC             ; additionne le multiplicande au résultat si ...
              LDA A_op        ; ... il y a un reste
              ADC result
              STA result      ; résultat (lsb)
              LDA A_op_msb
              ADC result+1
              STA result+1    ; résultat (msb)

next_step:    ASL A_op        ; multiplie par 2 le multiplicande
              ROL A_op_msb

              BRA loop        ; retour au début de boucle

finish:

;==============================================================================

/* principe en C */

unsigned short factor (unsigned char A_op, unsigned char B_op)
{
  unsigned short result=  0;
  unsigned short tempory= A_op;

  while(B_op)
   {
    if(B_op & 1)
     result+= tempory;

    B_op>>= 1;
    tempory<<= 1;
   }

  return result;
}

;==============================================================================

[xav]

Merci Tanuki, mais à priori quelque chose cloche: Sonic chute

Faut que j'essaye de voir les résultats avec un printf

Le truc serait d'éviter la multiplication, mais map_width n'est pas constant ...

J'avoue que j'ai été tenté de fixé une fois pour toute la largeur des niveaux à 256 tiles, parce que ça permet des tonnes d'optimisation, mais c'est pas super souple.

A moins de partir sur un choix simple de largeur en puissance de 2: 32 ( ça c'est pour une tour) ,64,128, ou 256 ( là pour une plaine )

[Tanuki]

... mais à priori quelque chose cloche: Sonic chute

Pauvre Sonic, ne lui dis pas que c'est de ma faute !!!

En fait j'ai voulu poster trop rapidement et voilà le super résultat.
J'ai modifié mon post précédent et je pense que c'est bon maintenant (prions pour Sonic).

[touko]

A mon avis il n'y a pas grand chose à passer en asm ..

Tu devrais mettre tes variables en global.
Utiliser l'ASM pour ton tableau ..

Si tu passes toute ta fonction en asm, il te faudrait surement la mettre en fastcall ..
Mais bon je pense pas que t'y gagne bcp car pour les reste je crois pas que huc te pénalise (multiplications, décalage, etc ..)

[whathells]

Qu'est-ce que j'aimerais y comprendre quelque chose à ce que vous racontez...

[MooZ]

Si la largeur max de ton tableau est 256, tu peux stocker ta map avec un "padding" de 256. C'est à dire que si ta map fait 256 de largeur, tu auras un padding de 0. Si ta map fait 94, ton padding sera de 162. Comme ça ton accès au tableau sera simplifié. Et rien ne t'empeche de stocker d'autres trucs dans la partie non utilisée de ta map.

Code : Tout sélectionner

	.zp
map_x     .ds 1
map_y     .ds 1
map_width .ds 1
map_ptr   .ds 2

	.code
map_get_coll:
	lda    #low(collision_map)
	clc
	adc    <map_x
	tax
	lda    #high(collision_map)
	adc    <map_y
	lsr    A
	tay
	txa
	ror    A
	
	bcc    .even
.odd:
		clc
		adc    #2
		sta    <map_ptr
		tya
		adc    #0
		sta    <map_ptr+1
		
		lda    [map_ptr]
		lsr    A
		lsr    A
		lsr    A
		lsr    A
		rts
.even:
	adc    #2
	sta    <map_ptr
	tya
	adc    #0
	sta    <map_ptr+1
	
	lda    [map_ptr]
	and    #$0f
	rts