Recherche testeur... - Page 1

J'ai fait un petit truc pour gp32, et j'aimerais qu'une bonne ame se devoue pour le tester sur gp32 C'est une demo au format gxb.
Ca fait juste qu'afficher quelques sprites. C'est en gros pour tester mes routines de sprites, et les comparer a celles de GamePark.
Un volontaire ? (Envoye par email).

Oui je suis volontaire !!!
nico3@gp32news.fr.st

C'est envoye.

je t'ai envoyé un mail et j'ai rien recu

Je t'ai envoye sur perier_s@epita.fr. Mais peut etre en plusieurs exemplaires

si tu veux, je peus la mettre sur mon site

c zarb j'ai rien recu, doit yavoir un pb, ils sont en train de modifier des param sur la ls de l'ecole.

pphd tu peux me mailer ca a sperier@kappa-systemes.fr stp?

Ce truc la ? C'est mal ecrit, pas beau, et ca ne sert a rien a part pour moi
Non, je veux pas. Attends que je fasse quelque chose de bien beau

>Yenaphe: Reenvoyez.

Resultats chez yenaphe :

test1: 55444 ms
test2: 29875 ms
test3: 10848 ms

Cool, c'est bien ce que je pensez
Sachant que ca affiche, si mes souvenirs sont bons, 280x144 = 40320 sprites de taille 40x96, ca nous fait donc

Routine Game Park : 727.22 spr 40x96 /s
Routine PpHd basique: 1349.62 spr 40x96 /s
Routine PpHd evoluee: 3716.81 spr 40x96 /s

L'ecran est totalement rempli avec 20 sprites 40x96.
Et ca c'est avec la frequence originelle.

Triple scroll differentiel a 30 Hz : 1800 sprites. Cool y'a encore plein de marge
Et on peut faire monter plus haut, ou plus subtil :
Faire afficher a toutes allure et pour la syncho baisser la vitesse du proc

On peut conjecturer qu'a 133 Mhz (laissez moi rever), ca fasse :
7433.62 sprite 40x96 /s, soit 28 000 000 pixel /s

Et en plus : ca marche !!!

hmm... bon fo ke je my mette... comment j'affiche un pixel a l'écran? (en C, asm, verrai après)?

typedef unsigned short pixel;
pixel lcd[320][240];

lcd[i][j] = 0xF456;

trop dur (En pratique c'ést legerement plus complique puisque l'ecrna ne peut etre allourer que par le systeme, mais bon le principe est la).

lol, pa ça

un ex de prog ki marche sur la gp32 et ki allume 1 pixel
c mon pt de départ obligé ça
v voir tes sources...

Faut que je fasse un tutorial sur comment developper sur gp32 sans les libs de game park. Je sais fxman, je dois le faire Chose promise, chose due.

il est fort ce PpHd, faut faire gaffe, GamePark va finir par nous le prendre.... tellement il optimise le code....

lol

bah, si c'est bien paye. Mais je gagne en faisant des compromis differents.
Et au fait, yenaphe, ca fait quoi apres la fin du dernier test ?
Sur l'emu ca recommence au premier, et toi ?

PpHd a écrit :
Faut que je fasse un tutorial sur comment developper sur gp32 sans les libs de game park. Je sais fxman, je dois le faire Chose promise, chose due.

ben si tu le fais......

PpHdfx-man

bah j'ai attendu queslques seconde et ca reste sur le dernier test.

Est ce que je peux essayer moi aussi sur ma GP32 ?

jycet@caramail.com

merci

putain c koa ces routines de merdes de chez gamepark !!!! c carrement l'equivalent de la tigcclib sur TI ou koa ?

Bon heureusement y a pas de prob kernel/nostub sur GP32 donc je pourrais taxer les routines GFX de pphd

Sinon pkoi 40x96 ??? pkoi pas un truc plus normalisé (32x32 serait mieux car c le tiles de base sur GP32 vu la taille de l'ecran )

Ah nan je viens de capter : 240/32 c vrai ca tombe pas juste et vu k tu veux remplir tout l'ecran ca marche mieux (240/96=4)

Aghnar
a écrit : putain c koa ces routines de merdes de chez gamepark !!!! c carrement l'equivalent de la tigcclib sur TI ou koa ?

Ce ne sont pas nos routines qui sont lentes, mais celles de AMS!!!

Euh ouais je pale exclusivement des routines gfx, et celles de tigcclib et celles d'extgraph sont lentes et ce sont pas celle de l'AMS mais de "vous" (TN,ZJ...la tigcclib team koa)

Elles sont très rapides par rapport à celles d'AMS (BitmapPut)!

Autant comparer une deux chevaux a un escargot.
Non celles de Game Park ne sont pas lentes. Mais tres completes.
Moi, dans ma grande tradition de la simplification, c'est
DrawSprite(x,y, sprite*)

Et pkoi 40x96 : parce que c'est la taille du sprite : spr de taille variable evidememnt (la j code le clipping).

sympa tout ca, surtout le triple scroll différentiel, ca va aider pour lémulation GBA ?