Topics

16

H.S / Sociabilité informatique et différence sexuelle

« on: 10 January 2011 à 22:28:44  »

 Quel bonheur !
 En recherchant des trucs sur mes vieux disque durs, j'ai retrouvé la thèse de sociologie de Nicolas Auray sur les démomakers et les gonzesses  ! Ca n'était plus en ligne du tout. Lecture très intéressante, le sociologue à du aller en party nous étudier à l'époque !

Sociabilité informatique et différence sexuelle - AurayTHTF2002.pdf

 ... et puis ya des passages qui me MDR très fort.

La rivalité agonistique et les rites de masculinité violente :
La “ démo ” offre l’occasion d’une démonstration d’agressivité entre les usagers.
L’usage inclut alors un rapport à la violence. Cependant, ce recours à des formes de
violence s’accompagne d’un degré de contrôle extrêmement fort de celle-ci, et
notamment de self-control. C’est précisément à partir de l’apprentissage de normes
particulières de self-control en ce qui concerne les pulsions de violence, le “ sang
froid ”, que se distingue l’excellent programmeur de “ démos ”.

 (edit) ... ben en fait, j'ai retrouvé son site et le doc est toujours en ligne en fait, .. d'ailleurs, ya ça aussi:
La place des hackers dans l'innovation informatique : une comparaison des cas hollandais, français et américain

 Aussi de lui ya:
Le prophétisme hacker et son contenu politique

17

Code / Android NDK r5

« on: 07 January 2011 à 15:25:00  »

Android NDK, Revision 5 (December 2010)

This release of the NDK includes many new APIs, most of which are introduced to support the development of games and similar applications that make extensive use of native code. Using the APIs, developers have direct native access to events, audio, graphics and window management, assets, and storage. Developers can also implement the Android application lifecycle in native code with help from the new NativeActivity class. [...]

General notes:

        * Adds support for native activities, which allows you to implement the Android application lifecycle in native code.
        * Adds native support for the following:
              o Input subsystem (such as the keyboard and touch screen)
              o Access to sensor data (accelerometer, compass, gyroscope, etc).
              o Event loop APIs to wait for things such as input and sensor events.
              o Window and surface subsystem
              o Audio APIs based on the OpenSL ES standard that support playback and recording as well as control over platform audio effects
              o Access to assets packaged in an .apk file.
        * Includes a new toolchain (based on GCC 4.4.3), which generates better code, and can also now be used as a standalone cross-compiler, for people who want to build their stuff with ./configure && make. See docs/STANDALONE-TOOLCHAIN.html for the details. The binaries for GCC 4.4.0 are still provided, but the 4.2.1 binaries were removed.
        * Adds support for prebuilt static and shared libraries (docs/PREBUILTS.html) and module exports and imports to make sharing and reuse of third-party modules much easier (docs/IMPORT-MODULE.html explains why).
        * Provides a default C++ STL implementation (based on STLport) as a helper module. It can be used either as a static or shared library (details and usage examples are in sources/android/stlport/README). Prebuilt binaries for STLport (static or shared) and GNU libstdc++ (static only) are also provided if you choose to compile against those libraries instead of the default C++ STL implementation. C++ Exceptions and RTTI are not supported in the default STL implementation. For more information, see docs/CPLUSPLUS-SUPPORT.HTML.
        * Includes improvements to the cpufeatures helper library that improves reporting of the CPU type (some devices previously reported ARMv7 CPU when the device really was an ARMv6). We recommend developers that use this library to rebuild their applications then upload to Market to benefit from the improvements.
        * Adds an EGL library that lets you create and manage OpenGL ES textures and services.
        * Adds new sample applications, native-plasma and native-activity, to demonstrate how to write a native activity.
        * Includes many bugfixes and other small improvements; see docs/CHANGES.html for a more detailed list of changes.

Hourra ! J'en révais !

18

Code / OpenGL 2.x: Pyramides/Mipmap temps réel ?

« on: 18 December 2010 à 20:09:55  »

 
 Pour relancer un sujet dans le droit fil de ce forum, voilà une question de code qu'elle est intéressante:
 Pour du MIPmapping ou d'autres trucs en GLSL, il peut être utile de construire les "autres niveaux de mimap" d'une image dynamique, ou le niveau 0 correspondrait à un FBO, redessiné en temps réel.
 J'ai une routine qui construit un niveau a partir du niveau du dessus avec des shaders, mais les niveaux de la pyramide sont des textures indépendantes, pas "une seule texture" avec plusieurs levels: en effet: il est possible d'attacher un FBO a chaque level d'une texture, mais si on fait ça j'imagine que c'est pas légal, parce que tu te retrouves à écrire la même texture que tu lis, même si le niveau écris n'est en théorie pas lu, un texture2d() est susceptible de lire ce qui est écrit.
 Flairant ce problème, Je m'en suis tenu à garder autant de textures que de niveaux, puis de finasser avec le shader qui va ensuite utiliser la pyramide (en faisant un mip maison avec 2 texture2d(), pas très élégant tout ça) .

 Dans les docs de gl"ES"2, j'avais cru voir une méthode GL pour re-construire  automatiquement tout les niveaux >0 d'une texture. Il me semble l'avoir testé sous la petite implémentation qui la proposait (une beta du tegra sdk) et avoir constaté des perfs de daube.

 Une telle méthode est elle dispo sur les implémentations courantes (la dernière fois ou j'ai vraiment fait du GL c'était en 2002/2004, à l'époque il fallait créer tout ses niveaux au cpu ). Quelqu'un connait-il une autre bidouille pour construire une pyramide en temps réel ? ou un truc genre faire du ping-pong entre 2 pyramides puis recopier un des niveaux sur 2 vers l'autre ?
 Merci les mecs, c'est puissant !

19

Groupes / Alcatraz

« on: 10 December 2010 à 10:18:34  »

 Suite à un Thread de Crown sur AmigaImpact, et comme PGCS^Alcatraz est suisse francophone, je mets ici les liens pour le légendaire groupe Amiga alcatraz ! De retour sur PC depuis 2007.
(il y a pas beaucoup de fr dans le groupe sinon)

http://alcatraz.untergrund.net/
Le site en français du graphiste de Odissey/Ilyad: PGCS
http://www.pgcs.info/
http://www.pouet.net/groups.php?which=195&order=release

20

Code / GL2.x / GLSL1.x Particules avec GL_POINTS et coords sur textures

« on: 06 December 2010 à 12:21:24  »

  Hop ! Quelques petites questions comme ça avant de me lancer dans un petit moteur de particules en GL2.x / GLSL1.2 pour montrer des trucs à mon frangin prof.

 J'ai encore jamais utilisé de VBO pour les vertex, mais d'après ce que je lis de vos posts,
faut quand même gérer les positions de vertex au CPU, et rebalancer des tables.

 Je pensais plutôt dessiner la dernière passe de dessin avec des GL_POINTS, mais passer non pas des positions x,y,z aux .vert mais des index de points (0,1,2,3,...), et mettre les position dans une texture que je lirais depuis le vertex shader.

... dans les premières passes, j'utiliserais d'autres shaders pour appliquer les calculs des mouvements de particules depuis des .frag, sur une série de textures 2D/FBO.
 J'aime bien: comme ça, ya aucun calcul CPU, tout dans le GPU (en plusieurs passes).

Est-ce que c'est une bonne idée, est-ce ça peut être efficient ? (peu d'expériences en "texture2D() depuis un .vert", certaines implé GL ES 2 ne le permettent pas par exemple. ) Est-ce qu'il y aurait pas des problèmes quelconques ? Est-ce qu'il y a des alternatives de ce genre avec des VBO ? Est-ce que des VBO c'est mieux ou pas mieux que des textures pour stocker des coords de vertex ?