30

tu peux âpas précalculer tes rotations (vu qu'il n'y as pas bcp de tiles)?

31

Pollux> Je comprends pas tout ce que tu fais (où est-ce que tu fais le OR?), mais respect pour avoir vu qu'on peut virer le cas où (a2) = -1 en changeant la structure des données.

Et du coup ça m'a fait remarqué qu'on peut aussi changés la structure pour carrement se passer d'additions. En écrivant le code en C on obtient:
short yDest,shift;
for (yDest=16;yDest--; ) {
	shift = 1;
	do {
		if (src[*xySrc])
		*dest |= shift;
		xySrc+=1;
	} while (shift+=shift);
dest++;
}	


démo avec 20 tiles rotatés par frame: http://fpgforce.dyndns.org/~jyaif/Public-files/Kartingz_test1.zip
Avant, pour arriver à cette fluidité je ne pouvais pas avoir plus de 10 tiles simultanément smile


JackosKing-VNR> Il y a 50 tiles de 16x16 pixels dans 128 directions à précalculer => 204800 octets à précalculer sad


32

Jyaif :
Pollux> Je comprends pas tout ce que tu fais (où est-ce que tu fais le OR?), mais respect pour avoir vu qu'on peut virer le cas où (a2) = -1 en changeant la structure des données.

Je ne fais pas de OR, parce que de toute façon tu écrases tout le contenu de *dst ; donc je recopie bêtement le pixel au lieu de faire un test et ORer si le test est vrai ^^

Si tu veux rester en C pur, le plus efficace risque d'être :
short yDest,shift; 
for (yDest=16;yDest--; ) { 
#define PIX(n) vDest |= src[*xySrc++] & (1<<(n))
#define PIX4(n) PIX(n),PIX(n+1),PIX(n+2),PIX(n+3)
#define PIX16(n) PIX4(n),PIX4(n+4),PIX4(n+8),PIX4(n+12)
	short vDest = 0;
	PIX16(0);
	*dest++ = vDest; 
#undef PIX
#undef PIX4
#undef PIX16
}

33

ah purée, t'es bon grin

Il y a un petit bug dans le code mais je vais surement trouver comment le corriger.

34

il y a un or et une affectation en trop non? (Mode chieur)

35

Jyaif :
Il y a un petit bug dans le code

Le mien ? Effectivement si chez toi src est un unsigned char *, ça va poser des problèmes... Le plus efficace serait de considérer dest non pas comme un short * mais simplement comme un char *, et de travailler uniquement avec des char ^^

36

Je me suis débrouillé en transformant src en short *

37

oui enfin si src est un short * ça va imposer une pénalité de performance assez importante, il vaudrait mieux que tu changes dest en char * et que tu fasses la boucle 32 fois au lieu de 16...

38

Tiens je suis étonné de ça... la RAM est reliée par un bus 16 bits non? Donc j'aurais tendance à penser que travailler en 16 bits est plus rapide... confus
avatarHighway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

39

Oui mais l'accès à un tableau de char est bien plus rapide que l'accès à un tableau de short... Ca pourrait se résoudre en multipliant par deux les xySrc, mais :
- si le compilo est bon, x & 0x12 est plus rapide que x & 0x1200, donc les calculs seront plus rapides en 8 bits smile
- même si ça n'était pas le cas, le gain de performances en passant de 8 à 16 bits serait complètement négligeable par rapport au gain de performances qu'on pourrait avoir par exemple en faisant de l'assembleur automodifiant ^^ (on doit pouvoir traiter un pixel en 16 cycles et des poussières, i.e. 2x plus rapide que ce que j'ai proposé en C love)

40

Mais il faut que (x & 0x12) soit plus que 2 fois plus rapide que (x & 0x1200) pour que le traitement en 8 bits soit plus rapide non ?

A part ça, voilà le nouveau gameplay/graphismes qui ma pris bcp de temps mais qui est censé régler le problème de la visibilité. J'ai décidé de diminuer la taille de la voiture, la vitesse et la largeur de la piste smile
Aussi, la voiture dérappe beaucoup plus, c'est plus marrant comme ça wink
KARTINGZ00.GIF
http://fpgforce.dyndns.org/~jyaif/Public-files/Karintgz%20v01.zip

41

Jyaif :
Mais il faut que (x & 0x12) soit plus que 2 fois plus rapide que (x & 0x1200) pour que le traitement en 8 bits soit plus rapide non ?

Pas du tout, la différence 8 bits / 16 bits n'a une influence qu'au moment de l'écriture de vData, qui prend un temps négligeable devant le calcul lui-même de vData... En revanche, si tu utilises un tableau de short, tu subiras une grosse pénalité en 16 bits parce qu'il faudra faire une multiplication par deux à chaque pixel ^^

42

la "grosse pénalité" (la multiplication par deux), c'est pas une addition ? Tu propose de faire 2x plus de calculs pour éviter de faire une addition ?

43

(ou un décalage si la multiplication est obligatoire, ça doit prendre 4 cycles)
avatarHighway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

44

mais y a aucuns calculs en plus en faisant du 8 bits, justement...
En supposant qu'il n'y a pas la multiplication par deux en question, 16 bits :
  move.w *xySrc++,d1
  move.w 0(src,d1.w),d1
  and.w #1234,d1
  or.w d1,d0
  ... idem x16 ...


  move.w d0,(dest)+
 
8 bits :
  move.w *xySrc++,d1
  move.b 0(src,d1.w),d1
  and.b #1234,d1
  or.b d1,d0
  ... idem x8 ...
  ... idem x8 en stockant dans d2 au lieu de d0 ...

  move.b d0,(dest)+
  move.b d2,(dest)+


Donc on perd en tout et pour tout 8 cycles sur une routine de 552 cycles, ça ne change pas gd-chose ^^ Alors que si on rajoute la multiplication par deux dans la routine 16 bits, on perd 64 cycles, c'est déjà moins négligeable (et idem pour les and qui font gagner 32 cycles en 8 bits)

45

Hm... ok hehe
avatarHighway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

46

(et en fait la différence est seulement de 4 cycles et pas 8, parce qu'on a un OR en moins en 8 bits ^^)

47

La version quasi-définitive du jeu:
http://www.mirari.info/get.php?c=T4fJ

Au programme, il y a 4 circuits et la sauvegarde de ghost et des temps réalisés.