1

Voilà, j'ai vu un topic crée par Orion_ qui disait que GpSurfaceFlip() est assez lent.
Alors je voulais savoir si vous avez d'autres méthodes plus rapides de double buffering qui fonctionnent tout aussi bien ?
www.wikio.fr/user1921&info=comments

2

[edit] erf je lit bc trop vite happy

pour repondre a ta question, je vois pas comment ca pourrais etre plus rapide, le gpsurface flip est synchro ac l'ecran,
donc son temps est compris entre 0 et 20 ms, pour faire 53fps

pour que ton jeux tourne + vite, il faudrais separrer l'affichage du reste, en le mettant ds un thread
et la le mec il le pécho par le bras et il lui dit '

3

pour repondre a ta question, je vois pas comment ca pourrais etre plus rapide, le gpsurface flip est synchro ac l'ecran

Ok. smile
donc son temps est compris entre 0 et 20 ms, pour faire 53fps

Pourquoi 53 FPS ?
pour que ton jeux tourne + vite, il faudrais separrer l'affichage du reste, en le mettant ds un thread

Et il y a des programmeurs qui le font ?!
www.wikio.fr/user1921&info=comments

4

-

5

> Pourquoi 53 FPS ?

parseque l'ecran se rafraichi 53 fois par secondes, tu as donc 20 milisecondes pour faire ce que tu doit faire,
si tu depasse le flip attend un rafraichissement de plus et le fps est divisé par 2

> Et il y a des programmeurs qui le font ?!

pas a ma connaissance mais je m'y interesse, marre de pas pouvoir regler les temps de mes anim exactement comme je veut ^^
et la le mec il le pécho par le bras et il lui dit '

6

-

7

si tu depasse le flip attend un rafraichissement de plus et le fps est divisé par 2

Ah ouais d'accord ! Mais pourquoi c'est pas plus rapide ? C'est long 20 ms !

Sur TI il ne me semble pas que ce soit si lent... je n'y comprends plus rien là sad
www.wikio.fr/user1921&info=comments

8

J'ai commencé un bout de moteur 2D et j'ai en effet (je copie en partie le sprite du dessus pour simuler une réflexion sur de l'eau) un peu gourmand et je suis tantôt à 30 FPS et tantôt à 60 ! Il n'y a pas e moment ou j'obtiens un FPS constant entre !
Pffff, c'est vraiment mal foutu !
www.wikio.fr/user1921&info=comments

9

tu teste sur quoi ?
car sur l'emu ça tourne a 60 fps smile
avatar
pixel and 3D graphics: www.madpxl.com

seeking iPhone developer, contact me !


10

gp1.PNG
gp2.PNG

Je teste avec un émulateur parce-que je n'ai plus ma gp32.

Le code n'est pas très optimisé vu que je me suis basé sur une routine de putpixel mais c'est pas excessif au point de vue de diviser en un seul coup le FPS par deux !

www.wikio.fr/user1921&info=comments

11

si c pas constant, c que des fois tu depasse, des fois non
ou bien c parseque tu utilise un gprectfill pour effacer l'ecran

si tu as 60fps, c que tu tourne sur geepee comme le dis mad
pour certain truc geepee tourne plus vite que la gp, pour d'autre non, mais l'ecran simulé tourne a 60fps
ton jeux est peu etre stable sur vrai gp
et la le mec il le pécho par le bras et il lui dit '

12

t images passe pas ^^
et la le mec il le pécho par le bras et il lui dit '

13

En plus oui je n'efface même pas l'écran ! J'en ai pas besoin pour le moment vu que tout est redessiné.
Et puis ce mode de double buffering est bien un swap et non pas une copie d'écran ?
En tout cas c'est bizare ces 20 ms, sur Ti il n'y a pas ce problème alors que c'est pas une console de jeu !
www.wikio.fr/user1921&info=comments

14

tres simpa l'effet sur l'eau smile

> ce mode de double buffering est bien un swap
je c pas, surement

sinon, tu peut faire du simple buffer en mattant a quelle ligne en est le rafraichissement de l'ecran tongue

> Le code n'est pas très optimisé vu que je me suis basé sur une routine de putpixel mais c'est pas excessif au point de diviser en un seul coup le FPS par deux !

peut etre que sans ton effet sur l'eau, tu est juste a la limite, et le petit peu que ca prend te fait depasser le temps max d'une frame.
en tout cas si le fps est stable et /2, c que tu depasse a tt les frames ^^

> En tout cas c'est bizare ces 20 ms, sur Ti il n'y a pas ce problème alors que c'est pas une console de jeu !
ué mais les Ti ca poutre tongue
et la le mec il le pécho par le bras et il lui dit '

15

Orion_ :
le gros probleme c la synchro, tu ne controle pas le flip, il est fait automatiquement a interval regulier

Ok, donc la gp32 permute bien les buffers vidéo sans qu'on le demande ?
Je comprends mieux le résultat que j'ai obtenu hier.
Je ne comprenais pas pourquoi mon affichage clignotait à mort alors que je voulais seulement afficher 2-3 trucs. Pb que j'ai résolu en dupliquant l'affichage dans le second buffer.
avatar

16

Sur ti on utilise le triple buffering.

17

non, la gp ne fait rien sans que tu le demande

elle flippe l'ecran si tu apelle le surfaceflip (c lui qui synchro ton prog ac l'ecran)
si tu l'appelle pas, le buffer affiché a l'ecran sera tj le mm,
ca ce vois qt tu ecrit dedans, mais de la a clignotter ^^ reessai ce que tu fesais hier, sans le surfaceflip
et la le mec il le pécho par le bras et il lui dit '

18

ca conciste en koi du triple buffering ?

le 1 est a l'ecran, tu affiche ds le 2 et la moitié du 3 ?
tu flippe le 2 a l'ecran, tu fini d'afficher le 3 et affiche ds le 1 ?
ect .. ??
et la le mec il le pécho par le bras et il lui dit '

19

Bah justement, sans le surface flip, ca clignote.
Je vais refaire des expériences ce soir pour être plus précis que dire "ça marche pas !" wink
avatar

20

?!!

> Je ne comprenais pas pourquoi mon affichage clignotait à mort alors que je voulais seulement afficher 2-3 trucs. Pb que j'ai résolu en dupliquant l'affichage dans le second buffer.

ca ct sans surfaceflip ??
qt tu dis seulement afficher 2 3 truc, c style un msg d'erreur ou c une map animée ac des truc qui bouge ?


par exemple, ds Gmod, j'affiche un msg a l'ecran pendans que ca liste le contenu du rar

GpTextOut(NULL, &gpDraw[!nflip],10,215,"Gmod 0.5 - use chn modlib and unrarlib",0x2A) ;
GpTextOut(NULL, &gpDraw[!nflip],30,110,"scanning archive ... please wait",15) ;

je l'affiche direct sur le buffer affiché a l'ecran, puis je fait ce que g a faire ds l'archive, mais je ne m'ocupe pas de flip d'ecran ou autre, mon message restera affiché, sans clignotter tant que g pas reflippé l'ecran.
et la le mec il le pécho par le bras et il lui dit '

21

Alors, première version du programme :
je définis les surfaces d'affichage, j'affiche le premier buffer (qui ne contient rien)
puis, je génére 256 rectangles dans le second buffer (pour voir à quoi ressemble la palette).
Je fais ensuite un flip des buffers pour voir ce que j'ai mis dans le 2nd buffer.
Je lance ensuite une boucle infinie.

Verdict : l'écran semble m'afficher en alternance mes rectangles une frame sur 2 et un écran blanc.

avatar

22

c pas normal tongue

moi je viens de tester ac ca :

#include "./Gdl/Gdl.h"

void GpMain(void * arg)
{
initScreen();

clrScr() ;
nflip ^= 1 ;
clrScr() ;
nflip ^= 1 ;
GpTextOut(NULL, &gpDraw[nflip],30,30,"hello world ! grin",0x2A) ;
flipScreen() ;
while(1)
{
refreshKey() ;
if(keyUp(kL)) GpAppExit() ;
};
}

et ca m'affiche mon hello world, sans afficher un ecran vide une frame sur 2 smile
et la le mec il le pécho par le bras et il lui dit '

23

Je recode le source foireux pour voir où j'ai loupé une marche.
avatar

24

ben tu doit faire un flip d'ecran ds ta boucle ^^
et la le mec il le pécho par le bras et il lui dit '

25

Une petite question (toute mes confuses si ça a déjà été évoqué ailleurs) :
on peut définir jusqu'à 4 pages de buffer pour l'affichage. 4 pages, c'est largement plus qu'il ne m'en faut. Est-il possible d'utiliser l'espace des 2 buffers en trop pour avoir 2 buffers écran de + de 320x240 ?
(Ca semble à priori possible vu le contenu de la structure GPDRAWSURFACE mais ce n'est pas explicité dans la documentation que j'ai sur le SDK).

avatar

26

je savais pas qu'on etait limité a 4 ^^

> Est-il possible d'utiliser l'espace des 2 buffers en trop pour avoir 2 buffers écran de + de 320x240 ?
bah ui ^^ vu que tu choisi toi au moment du flip le buffer que tu va afficher

rien ne t'empeche aussi d'alouer une zone memoire de 320*240 et de l'utiliser comme un buffer video temporaire (bien sur pas ac les fct de blit de gp ^^)
et la le mec il le pécho par le bras et il lui dit '

27

rov :
je savais pas qu'on etait limité a 4 ^^

Je sens comme une pointe de sarcasme smile

Voilà de quoi cause la doc :
. The firmware generates four surface buffers in 8-bit mode and two surface buffers in 16-bit mode

Il est aussi écrit que le programmeur peut allouer lui même des buffers mais qu'ils ne pourront pas être utilisés en tant que buffer primaire.... mouais, faut vraiment que j'étudie ça de près moi.
avatar

28

justement en 16 bits comment on fait car ça bug, personne n'a la boucle de rafraichissement ?

29

c'est bon j'ai recup la routine de fliscreen du gdl et ça marche parfaitement merci rov ^^ ( et anata pour l'info ^^ )

30

Sur ti on utilise le triple buffering.

Sur GP32 c'est bien possible. On peut copier ou faire pointer les images terminé vers la mémoire qui va à l'écran sans attendre quoique ce soit ?!
C'est vraiment pas normal d'attendre pour des clous. Sur les consoles de salon (on va dire avec un rafraichissement de 50 Hz ou 60 Hz pour la télé) la console n'attend pas l'écran pour afficher !?
En tout cas c'est bien la première fois que je vois ça.
www.wikio.fr/user1921&info=comments