1

Bonjour, bonjour,

Avant tout, je m'excuse par avance si la question a déjà été posée mais
le module de recherche n'étant pas à la pointe de la techique, je n'ai
pas trouvé mon bonheur. Bref...

Quid des performances du sdk de gamepark ?
Est-il bon ? moyen ? tout juste passable ou carrément miteux ?

Oui, je sais que je pourrais faire les tests moi même. Mais comme beaucoup
de monde, je suis un peu débordé.

Alors ? il est capable d'encaisser 2 layers et 200 sprites ou bien il met la gp32
par terre dès qu'on affiche un fond d'écran et 3 pauvres sprites ?


a+

EDIT: je parle des routines 256 couleurs
avatar

2

teste les demo faites ac gdl1 tongue

le sdk gp est potable mais les fct de blit transparentes sont vraiment lentes
enfin bon, en utilisant les possibilité des fct au max (limite de blit) tu peut mettre 1 layer de fond + 1 layer transparent, en tournant a 53fps
apres les 200 sprites en plus, je penses pas tongue surtt si ils sont transparent (mais tu peut qt mm faire des truc simpa -> lapinou)

3

Les 200 sprites, c'est bien plus que ce dont j'ai besoin.

Merci pour la réponse smile
avatar

4

pour ma par je dirais ca depend de comment tu codes l'affichage de tes 2 layers.

Sont ils fixes ou avec scrolls ?

Pour le nb de sprites, c'est surtout leurs tailles en pix qui va influencer la quantité max!

Test CA

Le BEAST est un enorme sprite c'est lui qui m'a obligé a passé a 80MHz smile, mais ce n'est pas optimisé car je l'affiche d'un bloc, pour optimiser il aurai fallu que je decompose en tile et zap les tiles vides.

D apres moi un layer BG + un layer avec transparence + 50taines de sprites 16*16 avec transparence + un musique mod = 99MHz sans trop forcer.

5

Oh, Shadow of the beast smile

Je voyais les 2 couches avec scroll.

Ta démo, elle est faite avec le sdk ??? Hum, il est donc possible de faire des choses avec, cool !
avatar

6

Est-il facile de programmer des routines de sprites plus rapides que celles du sdk ?
Je ferais peut-être mieux d'essayer et puis de vous dire après grin ... mais je serais curieux de savoir ce qu'il en est si quelqu'un a déjà essayé.
Surtout qu'il faut encore les clipper... celles du sdk sont bien clippées, non ?

7

Pour le moment, il y a moi.
Jeudi et vendredi dernier, j'ai appris l'asm arm vite fait et j'ai fait une routine d'affichage (sans transparence pour l'instant).
La fonction marche, son p'tit nom c'est void GpBitBltASM(GPDRAWSURFACE * screen, int startX, int startY, unsigned char* sprite, int sprite_width, int sprite_height); comme la fonction de l'API mais sans selection de zone dans le sprite a copier. Ca copie betement toute l'image. Pas terrible pour une fonte ou un sprite anime par exemple.
C'est rien du tout optimise (je lis les pixels 1 par 1. Il doit etre facile de les lire 4 par 4) et a l'interieur, elle est un peu retournee (l'ecran de la gp32 balaye en ligne verticales en partant du coin inferieur gauche. J'ai tape mon premier code pour un balayage horizontal a partir du coin superieur gauche).
Ca tient en 100 lignes et la plus grosse partie du code, c'est pour empecher que le sprite ne deborde de l'ecran.

Je mets de l'ordre dans tout ca et je vous le balance. Ca peut servir, au moins pour voir a quoi ressemble de l'assembleur ARM.

P.S: le but principal n'etait pas de recoder une fonction d'affichage mais de pouvoir dire que j'ai deja fait de l'assembleur arm a un entretien d'embauche. C'est la raison pour laquelle j'ai choisi de faire une fonction qui marche bien plutot qu'une fonction bien optimisee mais qui n'aurait pas ete finie le jour de l'entretien.

8

Ah d'accord. Ca m'intéresserais de savoir comment les copier 4 par 4 car j'ai programmé une routine qui recopie partiellement un sprite en le déformant pour faire un effets d'eau. En l'optimisant à fond en C, j'obtiens un résulat correct.
Je ne sais si je peux copier les pixels 4 par 4 parce-que j'en saute un sur deux dans le sens de la longueur.
Et il faut faire comment pour les copier 4 par 4 ? Sur Ti un long contenait 32 pixels mais là, là ça doit être pareil sauf qu'un long en fait 4 ?

9

Le 4 par 4, ca ne marchera que pour des colonnes de 4 pixels. C'est du au balayage exotique de l'ecran.
Ou alors tu tournes ta GP et ca te fait des lignes de 4 pixels wink
En fait, il doit meme y avoir moyen de faire des copies par 8, 16, 24, 32, 36, 40 en utilisant plusieurs registre. La fonction ASM existe (je crois) mais c'est pas demain que je vais l'utiliser.

10

Le 4 par 4, ca ne marchera que pour des colonnes de 4 pixels.

Des multiples de 4 tu veux dire ?! Mais il faut faire des colones au lieu de faire des lignes ?
Pour faire ma routine, je suis partit d'un putpixel que j'ai trouvé et je l'ai fais sans réfléchir. grin
Et pour faire des copies par 8,16,24,32,36,40 il faut bien charger les registres quand même et cela se fait en plusieurs fois. Tandis qu'en une seule fois il est possible d'en faire 4 maximum.
En tout cas c'est intéressant de copier 32 pixels d'un coup ! smile

11

1- pour charger 10 registres, ca se fait en une commande. Apres savoir combien il y a de cycle d'horloge derriere, il faut se plonger dans la doc.
Au debut de chaque fonction t'as un ligne type STMFD r13!,{r4-r10} qui sauvegarde les registres r4 a r10 a partir de l'adresse memoire pointee par r13. Rien ne t'empeche de faire un STMFD r12!,{r1-r10} pour sauvegarder 10x4octets soit 40 pixels.
2- Le coup des colonnes, je me suis mal exprime. L'effet de ton eau, je suppose que c'est une sorte d'offset pour chaque ligne horizontale. Les optimisations violentes sur gp32 se font pour chaque colonne. Bref ca va pas etre le grand amour entre le balayage vertical de la GP32 et ton effet "horizontal"

12

moi aussi g crée ma fonction smile
elle ne marche qu'avec une couleur de transparence pour l'instant, pour des sprites plus petit en hauteur que 240 pixels
en fait je scanne au prealable l'image, a la recherches de bout de colonnes non transparentes, et des espaces entres ces colonnes
apres pour afficher, je n'ai qu'a aller ds l'ecran ou je veut blitter, puis afficher une colone, jumper ds l'ecran de la taille de l'espace, blitter une autre collone ... ^^

ca marche assez bien mais il va me falloir une fonction de tracé de colonne rapide

13

yaouank c quant que tu nous fait un tuto pour debutter en asm ? ^^'

14

rov :
ca marche assez bien mais il va me falloir une fonction de tracé de colonne rapide

Compte pas trop sur moi. J'en suis a, pour chaque pixel du sprite "lit pixel sprite, ecrit pixel sur ecran"

15

rov :
yaouank c quant que tu nous fait un tuto pour debutter en asm ? ^^'

J'etais en train de nettoyer mon code quand un monsieur de arm m'a appele grin (30 minutes en anglais au telephone. J'adore !).
Je m'y remets.

P.S: c'etait pour un entretien d'embauche. La phase d'apres c'est l'entretien sans telephone et apres c'est l'embauche si j'ai de la chance.

16

arf bonne chance ^^
moi y a personne qui m'apelle lol mais mon 33k prend la ligne ca doit etre pour ca happy

> Compte pas trop sur moi. J'en suis a, pour chaque pixel du sprite "lit pixel sprite, ecrit pixel sur ecran"
c déjà bien moi l'asm j'en suis a .. ah bah j suis pas lol
pour ma fonction, il faut que je trouve comment faire marcher ces %$^**ù££ de dma, y a que le 0 qui veut marcher ^^

17

Voilà une routine de sprite qui semble fonctionner comme le sdk (ça afficahe correctement un sprite) mais elle n'est pas clipée.
Ca serait carrément plus rapide avec des longs mais pour le moment je n'y arrive pas : je me retrouve avec des sprites énormes affichés à l'écran.
void Draw_Sprite_32(unsigned char *sprite, unsigned short x, unsigned short y)
{
		short i,j;
		if(x<0 || x+32 >320 || y<0 || y+32>240)
		return;
		unsigned char *video_mem = (unsigned char *) (gpDraw[nflip].ptbuffer + 239-y-31);
		unsigned char *dest =  (video_mem + (x<<8)-(x<<4));

		for(i=x;i<x+32;i++)
		{
	               j=32;
		      while(j--)
                     {
		          *dest++ = *sprite++;
		     }	
                    dest = dest + 240-32;
		}
						
}

18

Bon ben moi aussi j'ai fais une routine qui traitait des blocs de pixels transparent ou pleins.

Le pb c'est que gpconverter convertit les images pour les fonctions du SDK GP et donc je me retrouvais avec une image tres buggée.

Sinon ma routine etait prevu pour un gros sprite avec transparence et elle marchait ainsi, dans un tableau (a calculer avant utilisation) je comptais les pixels transparent a sauter d'un coup ensuite je comptais les pixels existant etc etc , tout ca de gauche a droite ligne par ligne de haut en bas. le tableau me servait a zapper X pixels tranparents d'un coup pour arriver directement sur un existant et copier directement un bloque (enfin une suite) de pixels existant sans avoir besoin de comparer si le pixel=transp ou pas.

Hum je sais pas si j'ai été clair smile

Bon en theorie ca va plus vite qu'un traitement pixel / pixel puisque qu'on copie des bloques de pixels.
Inconveniant qui dit tableau dit besoin de RAM, et en plus il faudrait un convertisseur d'image qui convertisse ligne / ligne dans un tableau

19

@requiem :
Ta démo, elle est faite avec le sdk ??? Hum, il est donc possible de faire des choses avec, cool !


Oui avec minigp32 v1, donc le SDK GP off la lib mod de CHN et le vieux compilo GCC 3.04 smile

20

Jycet, c a peu pres ma methode smile

je n'utilise pas l'image pour afficher (g regroupé ds une structure le tableau des pixels pleins, des jump et des taille de colonnes), donc ca prend a peu pres la mm place en ram que l'image originale

g aussi eu des gros problemes ac gpconverter, maintenant je charge un pcx ou je sauve l'image en raw ac paintshop et je l'inclu ds un rar lui mm inclu au fxe par un .h ^^

21

Jycet, ça ne serait pas plus simple que tu manipules un sprite compressé en RLE ? le résultat serait à peu près le même mais pour un coût en même moindre car tu n'aurais pas à utiliser deux tableaux (un pour les données, un pour dire si tu as un bloc transparent ou non).
avatar

22

Quelqu'un a le courage de pondre un code tout bete qui affiche plein de fois un sprite et le framerate dans un coin ?

P.S: Jycet, pareil ! J'ai commence avec minigp32 v1, tant que ca marche, je change pas. Je serais bien passe a celui de MrMirko (et son gcc tout neuf qui va vite) mais il manque plein de fonctions a son SDK officieux (le minimum aurait quand meme ete de refaire un max des fonctions du SDK. Au moins l'affichage 8bits, le chargement des 256 couleurs de la palette en un coup, etc.).

23

Au fait, moi et gp converter on n'est pas faches. Faut arreter de dire que tout est de sa faute.
Vos images ne sont pas buggees, elles sont stockees par colonne et completees par des lignes noires pour avoir un nombre multiple de 4 de lignes.

24

ben justement il fait ca donc c de sa faute smile
on va pas adapter nos fonctions aux convertisseurs qt mm ^^

moi je ne trouve pas qu'il manque des fonctions ds le sdk de mirko, au contraire, juste les fonctions de buffer d'ecran et d'io aurais été suffisante

> Quelqu'un a le courage de pondre un code tout bete qui affiche plein de fois un sprite et le framerate dans un coin ?
bof je suis pas motivé, par contre je peut te proposer le code pour afficher les fps (attention, marche seulement a 66mhz)

void showfps(void)
{
	static long time=0 ;
	static short fps=0,fps_count=0 ;
	char buffer[20] ;
	static long last_time ;
	long tick = GpTickCountGet() ;
	short frame_time = tick - last_time ;

	last_time = tick ;
	fps++ ;
	if(tick > (time + 1000)) { time=tick ; fps_count=fps; fps=0 ; }

	sprintf(buffer,"%i|%i",fps_count,frame_time) ;
	GpTextOut(NULL, &gpDraw[nflip],10,10,buffer,0x2A);
}

25

@yaouank :
Quelqu'un a le courage de pondre un code tout bete qui affiche plein de fois un sprite et le framerate dans un coin ?


Vas voir --ICI-- et prends la "JYCET DEMO 1.1" il y a plus que ce que tu ne veux mais bon FXE et SRC dispo pour qui qui n'en veut ! smile

a+