< Retour vers Bidouille & Développement Informatique

Agrandir

Articles

Médias 33 33

Tutoriels

Forums 326 326

Sujet Le pub des programmeurs

1 925 réponses
117 participants
123 074 vues
130 followers

Anonyme

521410

Sujet de la discussion Posté le 25/08/2005 à 17:21:03

Salut

y a des programeurs sur AF si oui vous bossez sous quoi ?

Afficher le sujet de la discussion

Anonyme

521410

291 Posté le 01/09/2006 à 12:07:22

Jujupauty> tu bosse dans un studio de developpement de jeu, ou en "indépendant" ?

jujupauty

1150

AFicionado·a

Membre depuis 21 ans

292 Posté le 01/09/2006 à 12:38:24

Nan je faisais pour mes loisirs. Mais le pb, c'est que lorsque t'as l'impression d'avoir coder 90% tu te rends qu'il reste encore 90% du boulot à faire, dessin, niveau, scénario, musique... J'ai donc décider de me consacrer à la programmation musicale pour me reposer uniquement sur mes compétences. Pour l'instant je découvre encore la prog audio et tout et tout, mais quand je vois tout les soft libre qui existent, je me dis qu'il doit y avoir moyen de faire des truc sympa. J'ai vraiment envie de réutiliser un max désormais. Quand c'est pas possible parce que les sources de certain soft c'est :eek2:

Par l'autre jour j'ai trouvé ce bouquin d'occaz par hazard : https://www.amazon.com/Digital-Signal-Processing-Alan-Oppenheim/dp/0132146355/sr=1-3/qid=1157106945/ref=sr_1_3/002-8263639-8464829?ie=UTF8&s=books

C'est un vieux bouquin, mais très complet et pour 8 euros on va pas se plaindre...

Jul

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 22 ans

293 Posté le 01/09/2006 à 13:25:39

Oppenheim, j'ai eu la chance de voir un speech de lui il y a quelques jours justement. Le mec, c'est presque le dieu vivant du traitement du signal numerique. Pas mal de truc sinteressants sur le sampling non uniforme

Bref, sinon, je reviens la dessus:

Citation :
Mon expérience de programmation de jeux video me dit qu'il est par exemple plutôt lent d'aller tester la couleur d'un point dans la mémoire vidéo. Autre exemple, quand on programme un jeux soit on crée chaque frame en mémoire centrale et on la copie une fois terminée dans la mémoire vidéo. Soit on à toute les données nécessaire dnas la mémoire vidéo et on construit l'image en local (OPEN GL & co). Par contre si on copie les sprites ou triangles un par un en mémoire vidéo là c'est la mort des perf... Après l'explication du point de vue architecture, là ??? Peut être, y a-t-il des problèmes d'accès au bus concurents. IL y a sûremet des sémaphores à acquérir pour les accès concurrents à la mémoire vidéo ça c'est presque sûr.

C'est ca que je comprends pas. Dis moi si me trompe, parce que je connais vraiment rien en video, j'ai du avoir 3 heures de cours d'OpenGL dans ma vie: tu as de l'audio a traiter dans un plug, disons 44.1 khz, 32 bits flottants. Si tu veux par exemple faire de la fft dessus, tu peux passer pas mal de parametres en un coup (typiquement, les tables de cos/sin), et apres, tu as juste a passer les donnees frames par frames (disons de 1024 samples, par exemple). Passer 1024 samples de la memoire video a la memoire centrale, ca prend beaucoup de temps ? Comment ils font ceux qui font du calcul sur GPU. Il y a forcement besoin de relire les donnes a un moment ou un autre. Si tu calcules des inverses de matrice 1000x1000, c'est des Mo que tu as besoin de rapatrier de la memoire vive...

Remarque, c'est vrai que de la fft, pour que ca vaille le coup, faut que tu puisse en faire un sacre paquet de fois par seconde, disons au moins 10000 de 1024 sur le GPU, ce qui fait finalement beaucoup de donnees a rappatrier (100 Mo/s).

Anonyme

521410

294 Posté le 01/09/2006 à 14:35:22

Ca mérite un essais? :D:

j'ai pas les compétences pour tester ca cela dit...

jujupauty

1150

AFicionado·a

Membre depuis 21 ans

295 Posté le 01/09/2006 à 14:36:39

La bande passante du bus c'est (ou c'était) clairement une limitation. Par exemple 800x600x32bitx60fps = 109 Mo/s. D'ou l'intérêt de construire l'image en mémoire vidéo, sinon ton cpu passe son temps à transférer des données.

Pour l'audio je ne vois pas trop le problème non plus, si les calculs utilisent des données locales. Mon message précédent était plus pour expliquer qu'il peut y avoir des problèmes en programmant des jeux. Même si la lecture dans la mémoire vidéo est lente, il ne doit vraiment pas y avoir de problème pour y lire un flux audio et même plusieurs. Par si tu veux traité des flux provenant de la mémoire centrale, là à mon avis c'est plus le nombre de flux qui posera une limitation. Après tout du 24bit 96kHz, si on aligne les sample sur des mots de 32bit ça ne fait que 375ko/sec.

Pourquoi c'est lent de lire depuis la mémoire vidéo? J'ai trouvé ça: http://groups.google.fr/group/alt.games.programming/browse_frm/thread/e41764b6b384d6e0/d8bc1c5a5643a478?lnk=st&q=%22reading+from+the+video+memory%22+&rnum=1&hl=fr#d8bc1c5a5643a478

En gros pour l'écriture ne mémoire vidéo (le plus courant) l'architecture permet des écritures groupées. Pour la lecture ton processeur doit attendre que la donnée traverse le chipset du bus, le controleur mémoire, soit stockée en mémoire.

Jul

Pov Gabou

19553

Drogué·e à l’AFéine

Membre depuis 22 ans

296 Posté le 02/09/2006 à 16:11:43

Bon, je me suis motive pour faire un hote VST en python. C'est encore tres primaire, mais je peux loader un plug vst et l'instancier, prendre quelques meta parametres, et avoir une liste des parametres et de leurs valeurs:

si on prend le adelay.dll en exemple de la sdk VST, mon truc permet de faire sous python:

Citation :



adelay  = PlugLoader("./adelay.dll")



print "vendor of plug %s is %s" % (adelay.effect_name,

        adelay.vendor)



print "plug %s has %d param(s)" % (adelay.effect_name,

        adelay.nparam)



print "Params are " + str(adelay.param)

et ca donne

Citation :



vendor of plug Delay is Steinberg Media Technologies

plug Delay has 3 param(s)

Params are {'Delay': 0.5, 'Volume': 0.75, 'FeedBack': 0.5}

Il y a quelque trucs qui sont pas tres jolis:
- le callback pour la com plug->host, je vois pas comment le rendre customisable en python pour l'instant, sans compter que je comprends pas tres bien dans quels cas il est utilise)
- je me suis pas trop casser le cul a faire la difference dans le wrapper c++ entre la classe AEffect et le VST (faut dire que je comprends pas encore tres bien le detail a ce niveau la).

Mais grosso modo, ca m'a pris que 300 lignes de code c++, plus une 10ne en python, et je suis content du resultat. En plus, je crois qu'il y a pas meilleur moyen pour comprendre comment marche la comm plug <-> hote en VST.

Avec une ou deux heures de boulot en plus, je devrais pouvoir exposer la fonction process, et envoyer/recevoir des donnees entre python et le plug (ce qui est quand meme le but au depart).

Si jamais ca interesse qqn, je peux foutre les sources qqpart (c'est que pour linux, mais la partie non portable, a savoir charger une libraire, est encapsulee dans une petite classe, et ca demande 3 lignes a changer a tout casser).