/* Topic des codeurs couche-tard [5] */

The Uploader · Le 21/07/2011, à 18:50

non, c'est juste ultra lent (upload à 86%). edit: fait! Attention pour les données, c'est une forced update (un seul commit pour les données, toujours modifié par la suite, histoire de pas ralentir encore plus l'upload, et de pas versionner du binaire, ce qui ne sert à rien). Un pull (fetch+merge) donnera un conflit. Vaut mieux refaire un clone. ^^

De toute façons, il va falloir que je nettoie tout ça (mais un autre jour. ).

Bon un menu et de la zik on a dit... \o/
edit: woohoo, faire bouger la souris un peu vite en rond prend 13% du CPU selon htop. C't'un Core2Duo T5800... O_o
@screen est pourtant "HWSURFACE" (dans la mémoire vidéo) et "DOUBLEBUF".. (c'est peut-être le double buffer ? non c'est pareil).
Ben heureusement que je fais pas un shoot them up ultra nerveux.. O_o

Dernière modification par The Uploader (Le 21/07/2011, à 19:07)

tshirtman · Le 21/07/2011, à 19:52

je sais pas pour ruby-game, mais pour pygame HWSURFACE apporte plus de complexité au code que de perf, peu d'intérêt… ce qui fait mal ou bien au perf, c'est le format de pixel de l'image (nb couleur, profondeur…), pour qu'un blit se fasse avec des performances décentes, il faut que les deux surfaces aient le même format, on utilise la fonction convert_alpha() sur une image après l'avoir chargé, on récupère le résultat et on blit ça sur l'écran, et pouf, on gagne environ 80% de perfs…

Dernière modification par tshirtman (Le 21/07/2011, à 19:52)

grim7reaper · Le 21/07/2011, à 20:18

tshirtman a écrit :

je sais pas pour ruby-game, mais pour pygame HWSURFACE apporte plus de complexité au code que de perf, peu d'intérêt…

Bah ça apporte rien en complexité, sauf si tu veux bosser direct sur les pixels (là ok : faut locker l'image, la ramener en RAM, faire ta bidouille, la delocker et la renvoyer en VRAM).
Y'a d'autres complications avec pygame ?

Par contre si, ça boost les perf vu que tu utilises la VRAM au lieu de la RAM. Si tu choisis bien les images à caler en VRAM y'a moyen de sentir la différence.
Du moins en théorie, car je sais que pendant longtemps Xorg ne permettait pas d'utiliser HWSURFACE et la SDL faisait donc un fallback silencieux sur SWSURFACE, je ne sais pas ce qu'il en est aujourd'hui

tshirtman a écrit :

ce qui fait mal ou bien au perf, c'est le format de pixel de l'image (nb couleur, profondeur…), pour qu'un blit se fasse avec des performances décentes, il faut que les deux surfaces aient le même format, on utilise la fonction convert_alpha() sur une image après l'avoir chargé, on récupère le résultat et on blit ça sur l'écran, et pouf, on gagne environ 80% de perfs…

Là par contre tu as totalement raison, ce truc là joue vraiment pas mal (donc faut convertir une bonne fois pour toute au moment de charger l'image comme tu le dis). Parce que sinon on se bouffe une conversion à chaque blit et ça peut pourrir violemment les perf'.

Par contre je trouve le nom de la fonction convert_alpha mal choisi pour cette tâche O_o".
Ça doit être spécifique à pygame, en C c'est plutôt la fonction SDL_DisplayFormat (ou SDL_DisplayFormatAlpha si canal alpha il y a) qu'on utilise.
Mais bon ça c'est l'un des premiers trucs que t'apprends en SDL normalement (même sur le Site du Zéro y'en a qui le savent, c'est dire ).

Tiens, tant que tu passes par là j'ai une requête : tu pourrais me faire disparaître des scores du TdCT stp ? Ça fait un moment que je n'y passe plus et, après avoir réfléchi, je ne compte pas y revenir. Donc disparaître des scores serait une manière pour moi « d'officialiser » cette décision ^^"
Merci d'avance

Dernière modification par grim7reaper (Le 21/07/2011, à 20:24)

tshirtman · Le 21/07/2011, à 20:24

en fait, la fonction de base s'appelle "convert" et la version pour les images avec canal alpha s'appelle convert_alpha… oui, du coup c'est pas tout à fait évident…

pour HWSURFACE j'avoue que je pas personnellement vérifié, mais dans l'un des tutos que j'avais lu au début, quand les perfs d'USF étaient juste inexploitable, il expliquait à la fois le coup des convert, et le peu d'intérêt des HW. Bon sinon, faudrait que je vérifie, je fais pas mal de traitement d'images au vol, mais pas au pixel (enfin, pas moi, le C oui par contre) donc je ne sais pas si ça marcherait ou pas… je regarderais… (mais c'est loin d'être les perfs graphique, mon problème le plus important à ce jour).

edit: et oui je m'en occupe

Dernière modification par tshirtman (Le 21/07/2011, à 20:24)

grim7reaper · Le 21/07/2011, à 20:28

tshirtman a écrit :

en fait, la fonction de base s'appelle "convert" et la version pour les images avec canal alpha s'appelle convert_alpha… oui, du coup c'est pas tout à fait évident…

Ouais, une fois n'est pas coutume je trouve le C plus explicite sur ce coup.

tshirtman a écrit :

pour HWSURFACE j'avoue que je pas personnellement vérifié, mais dans l'un des tutos que j'avais lu au début, quand les perfs d'USF étaient juste inexploitable, il expliquait à la fois le coup des convert, et le peu d'intérêt des HW.

Si t'as le lien du tuto, je ne serais pas contre y jeter un œil

The Uploader · Le 21/07/2011, à 20:45

grim' a écrit :

Mais bon ça c'est l'un des premiers trucs que t'apprends en SDL normalement

Ben de fait ça va l'être (j'ai regardé MicroMachines, y'a bien des MapRGB, mais pas de DisplayFormatAlpha), car 13% d'un Core2Duo pour bouger la souris c'est juste ignoble! ^^'

Sinon dans Rubygame c'est Rubygame::Surface.convert, semble-t-il :

(gem-server)-http://0.0.0.0:8808/doc_root/rubygame-2.6.4/rdoc/Rubygame/Surface.html#method-i-convert a écrit :

convert( other=nil, flags=nil )
Copies the Surface to a new Surface with the pixel format of another Surface, for fast blitting. May raise SDLError if a problem occurs.
This method takes these arguments:
other
The Surface to match pixel format against. If nil, the display surface (i.e. Screen) is used, if available; if no display surface is available, raises SDLError.
flags
An array of flags to pass when the new Surface is created. See Surface#new.

Bon y'a aussi to_display et to_display_alpha.

grim' a écrit :

Bah ça apporte rien en complexité, sauf si tu veux bosser direct sur les pixels (là ok : faut locker l'image, la ramener en RAM, faire ta bidouille, la delocker et la renvoyer en VRAM).

Je crois qu'heureusement je n'aurais pas à faire ça. Empiler deux/trois surfaces (genre une roquette au dessus d'un soldat + l'anim quand il se la prend, et ne pas oublier le terrain en dessous de tout ça) suffira, j'pense..

Dernière modification par The Uploader (Le 21/07/2011, à 21:04)

The Uploader · Le 21/07/2011, à 21:25

Bon, to_display/to_convert n'avait pas l'air de faire effet (sans faire d'erreurs, génial). Passé par GIMP.

tshirtman · Le 21/07/2011, à 21:39

@grim: c'était là
file:///usr/share/doc/python-pygame/tut … guide.html

edit: on le trouve ici aussi
http://pygame.org/docs/tut/newbieguide.html

Dernière modification par tshirtman (Le 21/07/2011, à 21:46)

grim7reaper · Le 21/07/2011, à 21:41

@The Uploader : Ouais d'ailleur en regardant le code source, c'est plus les méthodes to_display* (et non pas to_convert, enfin ça peut le faire aussi mais c'est plus chiant) qu'il faut appeler.
Après ton problème de perf vient peut‑être d'autre chose (ça va mieux après le coup de Gimp ou pas ?).

@tshirtman : c'est le même ça ?

le tuto a écrit :

It only works on some platforms. Windows machines can usually get hardware surfaces if you ask for them. Most other platforms can't. Linux, for example, may be able to provide a hardware surface if X4 is installed, if DGA2 is working properly, and if the moons are aligned correctly. If a hardware surface is unavailable, sdl will silently give you a software surface instead.

Ça ça rejoint malheureusement mes observations, faudrait vraiment voir si c'est encore d'actualité.

le tuto a écrit :

It only works fullscreen.

Ça je savais pas, faudra que je me renseigne là dessus.

le tuto a écrit :

It complicates per-pixel access. If you have a hardware surface, you need to Lock the surface before writing or reading individual pixel values on it. If you don't, Bad Things Happen. Then you need to quickly Unlock the surface again, before the OS gets all confused and starts to panic. Most of this process is automated for you in pygame, but it's something else to take into account.

Ouais, là aussi on est d'accord

le tuto a écrit :

You lose the mouse pointer. If you specify HWSURFACE (and actually get it), your pointer will usually just vanish (or worse, hang around in a half-there, half-not flickery state). You'll need to create a sprite to act as a manual mouse pointer, and you'll need to worry about pointer acceleration and sensitivity. What a pain.

J'ai jamais observé ce comportement, mais c'est peut-être parce que X11 n'a jamais voulu me donner une surface HW ^^"
Et puis aussi parce j'utilisais rarement la souris dans les jeux que je développais.
M'enfin, faudra que je teste un jour.

le tuto a écrit :

It might be slower anyway. Many drivers are not accelerated for the types of drawing that we do, and since everything has to be blitted across the video bus (unless you can cram your source surface into video memory as well), it might end up being slower than software access anyway.

Bah stun peu le but en même temps, mettre l'écran et les sprites/tiles souvent affichés dans la VRAM.
Sinon c'est sûr que si on met juste l'écran l'intérêt est pas fameux.

M'enfin c'est vrai que si X11 continue encore aujourd'hui de faire chier pour les HWSURFACE bah vaut mieux rester sur les SWSURFACE.

Dernière modification par grim7reaper (Le 21/07/2011, à 21:53)

tshirtman · Le 21/07/2011, à 21:47

oui, j'ai fait édit sans refresh, c'est le même…

The Uploader · Le 21/07/2011, à 21:49

Après ton problème de perf vient peut‑être d'autre chose (ça va mieux après le coup de Gimp ou pas ?).

Moui, je suis à 3% (au lieu de 4%) quand il ne se passe rien ('fin quand je bouge pas la souris, donc ), à 13% quand je commence à bouger la souris comme un fou, puis 12/11/10% ensuite (au lieu de 13%/14% en permanence lors des mouvements).

J'crois surtout qu'il faudrait que j'évite de faire des draw/undraw quand il ne se passe rien. Mais faut bien définir le "il ne se passe rien" pour pas tout casser la logique undraw/update/draw. ^^'

Dernière modification par The Uploader (Le 21/07/2011, à 21:53)

grim7reaper · Le 21/07/2011, à 21:56

Bah alors peut-être que le gouffre à ressources est ailleurs.
Ptetr un FPS trop rapide ?

The Uploader a écrit :

J'crois surtout qu'il faudrait que j'évite de faire des draw/undraw quand il ne se passe rien. Mais faut bien définir le "il ne se passe rien" pour pas tout casser la logique undraw/update/draw. ^^'

Ouais, ou ça aussi ^^

Dernière modification par grim7reaper (Le 21/07/2011, à 21:58)

tshirtman · Le 21/07/2011, à 21:59

ah oui, moi j'ai un framelimiter sur USF…

The Uploader · Le 21/07/2011, à 21:59

Il est à 10 :

@clock.target_framerate=10

Après, faudrait peut-être vérifier le FPS effectif..

tshirtman · Le 21/07/2011, à 22:01

ouch avec seulement 10?

c'est peut être un peu foireux le concept des undraw perso je préfère tout dessiner à chaque fois que nécessaire
edit: hum, usf bouffe 19% dans les menus, que la souris bouge ou pas (mais il se passe des choses tout le temps dans les menus, y'a des sprites qui bougent derrière et tout), et dans les 90% en jeu .

Dernière modification par tshirtman (Le 21/07/2011, à 22:04)

grim7reaper · Le 21/07/2011, à 22:04

Oui, faut faire gaffe à undraw c'est pas toujours utile.
Mais là pour un curseur ça me semble assez logique : t'effaces l'ancien et t'affiches le nouveau, ça me choque pas.

Après si t'as trouzmille sprites, bah là faut pas se faire chier à undraw : tu reblittes le background un gros coup sur tout l'écran et tu refais l'affichage des sprites avec leurs nouvelles coordonnées.

Édit : BN World! (à partir de demain soir je suis en congé pour 3 semaines \o/)
Et up

/me sur la page précédente a écrit :

Édit : Πυλάδης, si tu pouvais me blacklister ça serait cool

(au cas ou tu ne lises pas la page précédente ^^)

Dernière modification par grim7reaper (Le 21/07/2011, à 22:13)

The Uploader · Le 21/07/2011, à 22:20

c'est peut être un peu foireux le concept des undraw perso je préfère tout dessiner à chaque fois que nécessaire

Ben sans utilise Rubygame::Sprites::Group.undraw, j'ai des trainées.
Puis bon ce sera pareil pour tous les sprites qui bougent. Tu fais comment sans undraw d'abord ? Oo

Puis la souris a besoin de changer de forme (notamment quand on donne un ordre à une unité d'attaquer/d'aller à) à, s'pour ça qu'il lui faut un sprite. ^^'

edit :

grim' a écrit :

Après si t'as trouzmille sprites, bah là faut pas se faire chier à undraw : tu reblittes le background un gros coup sur tout l'écran et tu refais l'affichage des sprites avec leurs nouvelles coordonnées.

ah, pas con! >_<
edit : vu les paramètres de Rubygame::Sprites::Group.undraw(@screen, @background), je crois que c'est exactement ce qu'il fait.

Dernière modification par The Uploader (Le 21/07/2011, à 22:24)

Pylades · Le 21/07/2011, à 22:23

grim7reaper a écrit :

Et up
/me sur la page précédente a écrit :
Édit : Πυλάδης, si tu pouvais me blacklister ça serait cool
(au cas ou tu ne lises pas la page précédente ^^)

Ah oui, je l’avais déjà fait ; j’ai oublié de le signaler. ^^

Dernière modification par Πυλάδης (Le 22/07/2011, à 02:04)

The Uploader · Le 21/07/2011, à 22:46

Bon ben j'appelle undraw juste quand la souris bouge, ben c'est encore pire! O_o (3% idle, 17% quand je fais bouger).
Et un peu d'autres manières, ça fait plein de bugs. >_<, genre :

def mousemoved
  if @rect.topleft!=@event.pos
    @game.undraw
    @rect.toplef=@event.pos
    @game.draw
  end
end

(bon ce code fait spaghetti j'trouve... Un sprite qui appelle le undraw/draw du groupe de sprites du jeu.. heureusement qu'il ne marche pas!)
scregneugeu.. è_é
edit: rajouté la zik (UNE ligne! \o/ UNE, 1, one line! \o/ ), mise à jour des sprites faite... Bon ben le menu avec des polices sera pour demain...
Bonne nuit!

edit: ah non demain je fais des PDFs qui font ce qu'ils veulent! nannnnnnnnnnnnnnnnnn! >_<

Dernière modification par The Uploader (Le 21/07/2011, à 23:15)

cm-t · Le 22/07/2011, à 00:09

'Nuit;

HP · Le 22/07/2011, à 00:37

plop += 1

tshirtman · Le 22/07/2011, à 00:40

bonne nuit…

Sir Na Kraïou · Le 22/07/2011, à 01:02

Æ ?!

nesthib · Le 22/07/2011, à 02:02

plop

samυncle · Le 22/07/2011, à 02:22

HP a écrit :

plop += 1

plop += 10

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1201 Le 21/07/2011, à 18:50

Re : /* Topic des codeurs couche-tard [5] */

#1202 Le 21/07/2011, à 19:52

Re : /* Topic des codeurs couche-tard [5] */

#1203 Le 21/07/2011, à 20:18

Re : /* Topic des codeurs couche-tard [5] */

#1204 Le 21/07/2011, à 20:24

Re : /* Topic des codeurs couche-tard [5] */

#1205 Le 21/07/2011, à 20:28

Re : /* Topic des codeurs couche-tard [5] */

#1206 Le 21/07/2011, à 20:45

Re : /* Topic des codeurs couche-tard [5] */

#1207 Le 21/07/2011, à 21:25

Re : /* Topic des codeurs couche-tard [5] */

#1208 Le 21/07/2011, à 21:39

Re : /* Topic des codeurs couche-tard [5] */

#1209 Le 21/07/2011, à 21:41

Re : /* Topic des codeurs couche-tard [5] */

#1210 Le 21/07/2011, à 21:47

Re : /* Topic des codeurs couche-tard [5] */

#1211 Le 21/07/2011, à 21:49

Re : /* Topic des codeurs couche-tard [5] */

#1212 Le 21/07/2011, à 21:56

Re : /* Topic des codeurs couche-tard [5] */

#1213 Le 21/07/2011, à 21:59

Re : /* Topic des codeurs couche-tard [5] */

#1214 Le 21/07/2011, à 21:59

Re : /* Topic des codeurs couche-tard [5] */

#1215 Le 21/07/2011, à 22:01

Re : /* Topic des codeurs couche-tard [5] */

#1216 Le 21/07/2011, à 22:04

Re : /* Topic des codeurs couche-tard [5] */

#1217 Le 21/07/2011, à 22:20

Re : /* Topic des codeurs couche-tard [5] */

#1218 Le 21/07/2011, à 22:23

Re : /* Topic des codeurs couche-tard [5] */

#1219 Le 21/07/2011, à 22:46

Re : /* Topic des codeurs couche-tard [5] */

#1220 Le 22/07/2011, à 00:09

Re : /* Topic des codeurs couche-tard [5] */

#1221 Le 22/07/2011, à 00:37

Re : /* Topic des codeurs couche-tard [5] */

#1222 Le 22/07/2011, à 00:40

Re : /* Topic des codeurs couche-tard [5] */

#1223 Le 22/07/2011, à 01:02

Re : /* Topic des codeurs couche-tard [5] */

#1224 Le 22/07/2011, à 02:02

Re : /* Topic des codeurs couche-tard [5] */

#1225 Le 22/07/2011, à 02:22

Re : /* Topic des codeurs couche-tard [5] */

Pied de page des forums