tamapolis

Today I wanted to add the scrolling feature to my canvas, so I can have a canvas larger than the window.

To implement the feature was easy, but then I realized that when I did the “save” function I only made a dump of the screen, not the whole texture, and now the texture was bigger than the screen, so I needed a save method on the RT class.

It wasnt hard to code it, but the problem came when I tryed to save the RGB16F RT, it just didnt work, the pixels in the resulting image looked like it was taking one byte per pixel and channel instead of reading it as a Float, somehow it was obvious, you cant pass an array of bytes to a function and expect it will know how to handle it, but the documentation of PIL (the library used to handle images in python) is crap, they don’t explain well how to specify the pixel format when is 16 or 32 bits and has more than one channel.

I have been searching info all day long and nothing was found, I just end up thinking PIL doesnt support to read images in RGB with channels of more than 8 bits. They say something about a “F” format if you use the fromBuffer function, but the encoder looks like it only allows one channel images. Silly.

Then I had an idea, if I take every pixel and divide it by 256 (when a short is used) I will have a 8 bits precission, indeed I don’t need to save a 16bits image, mainly because not a lot of file formats supports it (and right now Im using JPG).

I tried to do so, to divide every pixel read from the buffer by 256 and store it using 8bits per channel. First, it wasnt easy, because the image is stored using numpy, which I understand, but the documentation of numpy is crap, they don’t tell you some basic things like how to convert from one data type to another, or how to apply a function to every value of the matrix. So finally I discovered how, but it didnt work, it appear like some values where out of bounds.

So after wasting a whole day just to save a image I came up with the simplest idea, to create a temporary RGB image with 8 bits precission and render a quad using the other texture. I’m wasting some memory and performance but it works and it is easy.

No screenshots today or resources today.

I’m three days behind, I know, but I’ve been coding hard last days, but I never found time to write in the blog about it, and also I wanted to have a nice version without bugs before I share it here.

So what I’ve been coding these days? Well, I pushed away the old code about cubes and cellular automatas, and started something new from scratch, but first I refactor a little bit my code to create a classic class in almost every interactive application, the Application class.

This class encapsulates the ugly and boring code common to all Applications, like creating the window, the main loop, reading the input, calculating the elapsed time, quitting the app in a clean way, and some minor stuff.

When refactoring I tryed to use as much python tricks as I could, not just the regular C++ syntax, I followed some nice tutorials were they explain how to take advantage of the python features to reduce the amount of code, this particularly was preaty useful: Python Tips, Tricks, and Hacks

This translates to a better use of lists, parameters in funcions, and iterations in general.

I even added some exceptions to avoid leaving the window open if the application crashes, that was anoying.

So I refactor my old code to make it really simple to create an application from scratch, here is one example:

#!/usr/local/bin/python

from OpenGL.GL import *
from OpenGL.GLU import *
from GLTools import *
from shaders import *
from Application import *

WINDOW_SIZE = [800,600,False]

class MyApp(Application):

 def init(self):
     glDisable( GL_CULL_FACE )        
     self.logo_tex = Texture()
     self.logo_tex.load("data/tmt-logo.png")

 def render(self):
     glClearColor(0.0, 0.0, 0.0, 1.0)
     glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT)

     glBlendFunc(GL_SRC_ALPHA,GL_ONE)
     glEnable(GL_BLEND)
     glColor3f(1.0,1.0,1.0)
     self.logo_tex.render([-1,1],[2,-2])

 def update(self, time_in_ms):
      pass

app = MyApp()
app.createWindow("My App", WINDOW_SIZE, WINDOW_SIZE[2] )
app.start()

The formating here is a little bit messed up but you can download the file from the sourcode file at the end of this entry.

Then I decided to create an application in 2D, I’m a little bit tired of 3D cubes and I don’t plan to create a mesh loader for the moment, for now I want to focus in other ideas, more headed to pictures and basic shapes.

I remembered and old idea about creating something similar to a canvas where to draw in a Photoshop way. I like to use Photoshop to do illustration but sometimes I have ideas of brushes that can’t be done with the features of photoshop (maybe in the latest versions they have added them).

The idea is to create a RenderTexture and to use it as a canvas, then to draw texturized quads on the RT when painting, they can be paint using blending to achive cool overlay effects, and I have complete freedom to resize, rotate or do other tricks on the brush. Creating a canvas was easy and that was done two days ago pretty quickly once I had the Application class to handle the mouse and keyboard events.

But I thought it didn’t had too much interest, mostly because the tool barely had any feature that couldnt be done in photoshop.

The next day I spend some time playing with the app and adding some common features like saving the image to disk, the Undo option, having different brushes, controling the alpha and the repetition, etc.

I have some ideas in mind for the future, for starters, I want to create special brushes, that behave like they have their own life (auto-brushes in advance), then I want to create a big canvas, not just the one I have now, something bigger composed  by several RTs, and leave the auto-brushes wandering around, drawing strange shapes.

I also have more features that I would like to add, like having layers ‘a la photoshop’, sharing the canvas online like in webcanvas, or having a small class to do on-the-fly coding for the brushes.

Lot’s of ideas in this field to explore…

Problems found

During the refactoring I found some anoying problems related to python and OOP, mostly because some internal behaviours. For instance, all the brush instances where sharing the same list instance for the textures, instead of having their own due to have initialized the list on the body of the class, not in the constructor.

Other issues where related to openGL. Dealing with RTs based in FrameBuffer Objects is simple in concept but tricky in practice, mostly because it can behave erratic under some systems. My friend Miguel Angel is having some issues with the openGL code in his machine, and I’m having some in mine.

Also, I had a pixel resolution problem when doing the canvas. If the brush paints too much quads in the same region it is easy to overdraw the same zone quickly which doesnt looks nice, then the solution is to draw quads with a small alpha so the color increases slowly, but this has a problem, if the brush alpha is too small and the texture has also alpha or values closer to zero, when both values are multiplied and stored in the RT, there is not enough pixel resolution and they are clamped to the closest value, creating ugly artifacts.

The solution is obvious, increase the resolution for the RT, instead of having 8bits per channel (the usual) I changed the RT code to support more formats, like 16bits or 32. This was tricky because I don’t know how they behave in different cards, and my first surprise was when I tested in my home computer, it was running at 2 frames per second, just because my GForce 6600 doesnt like too much the RGB32F format. I made some fixes to use 16bits but I got dissapointed that drawing a quad in a 32bits texture could reduce the performance to 2 fps.

I had more problems but now I don’t remember, probably because they weren’t too much important.

Screenshots

Here are some of my artistic results, I created some brushes in photoshop but I enjoy playing more with the plain ones.

Code

There are lots of keys so here is a list:

• 1-5 to change between brushes
• Control Z to Undo
• Control S to save to disk
• Keypad / and * to control flow
• Keypad + and – to control preassure
• Keypad . to change between white and rainbow color
• C to clearthe buffer
• Mouse Wheel to control the brush size
• Shift Mouse Wheel to control brush rotation

You can download it from here: hackpact day 6

Today I was a little bit short of ideas, and having the latest Alone In The Dark game didn’t helped.

So I decided to give a better look to the conway shader I coded yesterday, so instead of using it as a PostFX I used it as a texture for the cube. It was easy, I only had to add the texture coordinates to the cube and activate the result texture from the conway code when rendering the cube.

I can’t say the results are very good but for those who love the cellular automatas it is fun to see.

I tryed to improved a little bit the conway shader but I ran out of ideas. I end up putting a different world in every color channel, so what you see is three boards at the same time (red, green and blue). I start the world using a texture which is in grayscale so more or less all channels start being almost the same.

All the faces in the cube use the same texture, and when I coded the conway I forced the textures to repeat on the edges, so it gives the look and feel that every face behaves diferent, but they are all the same.

I also tryed to render the cube several times with diferent sizes to give the feel that the pixels have volume, but it didnt worked. So at the end I just took advantage of the posibilities of the graphics card and use a texture big enough to have a huge conway world, and it looks fun when you see so many cells in action.

Now screenshots and source code:

Here you can download the source code: hackpact day 5

Today I have been playing around with python for eight straight hours and the results are not very impressive, too much time wasted in stupid problems. Mostly because I keep thinking in C++ and some of the simple tasks I usually do when coding graphics under C++ are a pain in the ass in Python.

For example, to create a multidimensional array in an efficient way, impossible, you need to use Numpy, which is a module specially designed for this purpose, but even though through numpy I took me lot of time to figure out how to apply an action to every cell.

Or for example trying to refactor my RenderTexture class I created the Texture class that allows to load textures from disc, but then I wanted to make RT inherit from texture and I like to have several constructors, but in Python you can’t distinguish two constructors by the type of the parameters (mainly because there is no specified types) so I had to use a different approach (dictionaries for the trivial parameters).

Also I had to deal with the classical OpenGL problems when creating the Texture class, they didn’t render correctly due to the pixel packing (I always forget that!), and some other issues.

So to do something cool I created a PostFX using Conway’s Game of Life idea, which turn out not to be so fanzy and I don’t think it deserves an screenshot here. Because if you apply it to every frame it looks more like an edge detection algorithm.

I’m just a little bit upset that I wasted so much time with things that didn’t translate to anything interesting. And everyday I become more and more worried that I’m wasting precious time in re-coding my old framework under a different language, which would be a stupidity because I could have keep using the old one under C++.

The reason to move to python is to explore new fields in graphics, not to do the same but in an slow and rusty way.

For the next episode I have some ideas, first I want to test Numpy in depth, second a friend told me about a python module specially designed to the mathmatics involved in graphics (vectors, matrices, etc), something I really need If I pretend to create something over Python. And for the ending I want to do some test about reloading the code without restarting the application.

And now some screenshots and the source code:

It is just a conway game of life executed in a shader, nothing impressive at all. Miguel Angel helped me with the automata rules.

Here is the source code: hackpact day 4 and if you want to use it, when you hold LeftControl key it renders the Game of Life, and if you hold LeftShift it takes the boxes image as input, so tap LeftShift once while you hold LeftControl, also with the keypad Divide and Multiply you change a threshold I added to the automata and it makes some funny worlds.

First a little comment about RenderToTexture. My RTs are based in FBOs (Frame Buffer Objects), thats a feature relatively new on OpenGL and not well supported by all the graphics card.

Yesterday I was testing my app under OSX where I have everything installed (I used Macport to install python and all the libraries) and it crashed because the FBOs were not supported. Thats impossible because it is a MacBook and I know the card supports it, but for some reason the OpenGL functions relative to FBOs are not pointing to the right place on the driver, I don’t know what to do to solve it.

I also tested it in my other computer which runs Windows 7, and pygame crashes due to a problem with MSVCR71.dll, I guess is a SDL problem and Visual Studio, the funny part is that it works when I run the script from python IDLE. Weird. So at the end using python and opengl is not as cross platform as I thought.

My friend Miguel Angel pointed out also something curious, he had the same problem as Bastiaan when calling one of the OpenGL function, but that problem didn’t occour to me, it has to be something with the versions we are using, so I guess the Pyopengl API is not so solid and it is changing between versions more than what I would like, that could be a problem in the future, we will see…

PostFX

Today I’m gonna try to code a simple PostFX shader to see if I’ve got the basics.

The wrapper I did for the shaders is too simple right now, it doesnt support to upload textures to the shader, and that is mandatory, so thats my first enhacement. Also I haven’t test loading and showing a texture, indeed I coded the RT class without having a Texture class first (usually RT inherits from Texture).

I was expecting to find a class that encapsulates all the boring part of a texture, like texture formats, filters, etc, but I wasnt so lucky.

I’m worried about something, I don’t want end up doing the same I do everytime I start coding in a new language/platform. I always start wrapping the things I need, and keep doing it till I have been doing technical stuff so long that I get bored, instead of creating the application I create the tools, and the application never comes… It is a death spiral where I always fell. In game development there is a saying: “those who code game engines never code a game”, and it is true, as soon as you start coding your own engine you are always chasing a new feature instead of trying to create something with the features you already have.

So my plan now is to create the ultrabasic needs, which will be to have textures, shaders, RTs, maybe meshes (something simple) and a tiny graph editor, but I will talk about this when the time comes.

Ok, so I made a PostFX shader, I added the function to upload a texture to a shader and for my first test I rendered the same scene but reversing the colors and it worked.

gl_FragColor = vec4(1,1,1,1) – texture2D(texture,gl_TexCoord[0].st);

I was thinking of leaving that as an example of PostFX but that was too simple so I thought about something more complex.

Where you are coding a PostFX shader you read the pixel you are going to write from a texture, then you apply a function using the color of the pixel as the input and the output is returned from the pixel shader to be written in the same position of that pixel.

But sometime ago I realized that when it comes to PostFX you usually want to read not only that pixel, also the average of the pixels around that one, or in other words, you want to blur the pixel. To do that there are several options, one is to read all the pixels around your pixel from the texture and calculate the average, but for prototyping that is tedious, other solution is to blur the texture before passing it to the shader, but then if you want the original one you need two textures.

So I found a trick, to use the Mipmaps. Textures have mipmaps which are versions of the same texture but in lower resolution, and OpenGL allows you to create on-the-fly mipmaps of  a RenderTexture. It is kind of slow because it has to calcule all the mipmaps piramid even when you only want two or three levels, but the good thing is that it is only one line of code, so I added the option to the RenderTexture class.

I have used this trick in the past to create lens effect, motion blur, depth of field, etc. Obviously the results are not perfect in comparison with a good gaussian blur, but it does the task.

For this example I read the channels of the pixel separatly, with a little offset in X and I also add some blur to the red and blue component. Here are the results:

And here is the source code: hackpact day 3

For today I expected to clean a little bit more my code, it is growing fast from the skeleton I started and I don’t want to have to refactorice everything in a couple of days, but damn, I always end up wrapping stuff instead of using it so for this project I will focus on having the essential features.

First I wanted to add a simple wrapper to RenderToTexture features of OpenGL. The reason is that once you  have shaders and RenderToTexture you can achieve lots of cool algorithms, specially the postFX algorithms.

To do PostFX you want to be able to apply an algorithm to every pixel on the screen after you have rendered the scene, but OpenGL was thought more to render primitives on the screen (lines, triangles, and so). Then the old way to do PostFX to the final image was to download from the Video Memory the frame to the RAM, then using the CPU apply the algorithm, then upload it again, but that was far too slow and CPU consuming (and using Python thats MADNESS!!)

The cool way is using shaders and RenderToTexture combined. How? Well, Shaders allow to execute an algorithm for every pixel of the primitives we draw, not enough, because we want to read the previous pixel, apply the algorithm and store it in the same place. So the trick goes like this, we render the whole scene in a texture, then we render that texture in a quad filling the whole screen but with a shader with our PostFX algorithm activated.

So the shader is going to be executed for every pixel on the screen, and we can have the pixel in that position as an input to the shader. The result will be store it in the same pixel. Easy!

We can achieve nice effects like color balance, combine different images, blurs, edge detecting, etc.

So let’s start wrap a Render To Texture in a class, the interface should be simple, something like this:

• constructor where you choose Width, Height, Depth (and in my case some other flags)
• enable which redirects the rendering to our texture instead of the screen
• disable to restore the rendering to the screen
• bind to bind the resulting texture
• render to render the resulting texture as a quad to the screen

So after some work I managed to have everything working. Some interesting thoughts about it:

• Working with OpenGL in Python is easy, even some old OpenGL API functions have been wrapped in a more helpful way, for instance glGenFramebuffers in C++ you have to pass the reference to the variable where you want to store the Id of the FBO, but in Python it just returns it, thats nice.
• I had some problems when it comes to passing to OpenGL memory address, for instance if you create a texture and you want to initialize it with something. I don’t know how to do it, I have seen examples using Numpy but I just skipped that part.
• OpenGL usually never crashes, but those functions that expect a pointer… you better take care of them, because if you miss the address they will crass the application, no Python exception will catch that.

The best way to test if your Render To Texture works fine is to render the whole scene to a low resolution texture and show it to a full screen quad. You should get some pixelated results (if you disable filtering), here is my proof:

Once I have the Render To Texture results I could create a PostFX shader but I will do that tomorrow. For today I better play a little bit more with the scene I’d got from Bastiaan adding some input and cool effects like changing the size of the cubes depending on the distance to the light source.

If you want to test the application (I won’t suggest it in the early stages because there is not too much interesting stuff unless you want to know more about Python and OpenGL) here are the keys:

• 1 to 4: enables different effects (blend, rotate cubes, sphere shaped, edges and RenderToTexture)
• Space and Backspace: to move the camera back and forth
• Keypad + and – reduce the dimensions of the voxel
• ESC to close it

It is nice to use pygame underneath because it is a wrapper of SDL and I have been using SDL for years so most of the features of SDL are exposed with similar names and interface but in python. For instance, I wanted to use the time increment to move the objects instead of the frame number, this is important to have a constant movement, otherwise it moves faster when the scene is emptier (when the framerate is higher).

I also added a small bar at the botton to show the framerate, I don’t know how to render text (I probably will need to use another module…) so I just draw a line from left to right, where right means 60fps and left means 0fps.

I also made some small optimizations to the Bastiaan code, nothing to be ashamed for, just ensure all the faces of the cubes were clockwise so I can enable back face culling.

If you want to test it the files are zipped here: hackpact day 2

Real-time graphics is a field ruled by C++, not by imposition, just because the idiosyncracy of the task. We need to do a lot of things and we need them to be done as fast as possible, otherwise we have a drop of the framerate and we loose the feeling that the world is moving.

So C++ works perfect in that field, in the field of real-time standalone graphics applications. But sometimes we want more, we want other things, like flexibility, like on-the-fly coding, like portability, and then we start looking C++ like and old man looks at his wife, yeah, she was adorable, but a thousand years ago.

I like coding graphics, it reminds me drawing and I like drawing. Somehow it is the same in my mind, but with the difference that coding I can make iterative things a lot faster and easier. I am part of a small set of people in the world who know how to draw and how to code graphics, and I want to take advantage of that. I want to explore both fields till the point where they merge in a new form of expression.

So today I’m gonna park my C++ compiler and start with something new, I need a language powerful (but not too much), where I can use my knowledge of graphics but with the flexibility of a playground, a sandbox, where I can add and remove in a simple way, within a keystroke. The idea? To create an application where I can code graphics meanwhile they are renderer, similiar to fluxus but using OpenGL paradigm.

And the awarded platform is… Python!. I know enough of this language to know it fits my needs, there are modules for almost everything and it is made to be confortable to code, but the setting up is going to be a pain in the ass.

So my first task today (and the one I’m going to document) is how to render some stuff in OpenGL using Python,

The setting up

First I have to download a thousand of packages:

• Python compiler (I choose 2.6 because 3.x version still don’t have a good support for most of the libraries)
• PyOpenGL all the binds needed to use OpenGL
• OpenGLContext which is a library wrapping the common stuff in all OpenGL applications, helpful, but this have depencencies too…
• PyDispatcher a library to send messages between elements
• PIL to load images
• Numpy to numerical actions along arrays (important to process meshes… I guess)
• PyGame more or less like OpenGLContext but with more stuff about games
• PyVRML97 this sounds kind of cheesy because who uses VRML now… but OpenGLContext asks for it

To install this libraries is easy, you just need to unzip them and execute from the command line “python setup.py install” inside the folder, and they do the rest.

I needed to test that everything was working so I end up in the website of Bastiaan Zapf: Complete Python OpenGL examples. Lot’s of useful examples of python mixed with OpenGL and with shaders!.

It took me some time to have all the libraries used by him, but it is a nice way to start, to take other person’s work instead of starting from scratch (and giving full credit!).

The first test

But after reading some of the examples propose by Bastiaan I better backup up a little, I mean, I need the basics of the aplication flow inside Python, things like creating a window, reading the keyboard input, rendering the frame, so I will follow the pygame tutorials to see what they suggest… No, too basic. They can be useful but I don’t want to waste time reading them. I just grabbed information to create and destroy the window and to check the keyboard input, for now I don’t need anything else.

I have an idea to start, I’m going to pack most of the import stuff I need to code graphics in some classes, stuff like Shaders and RenderToTexture, that is something common when you start coding in OpenGL, the API is boring and confusing, so the best thing to do is to encapsulate the API in simple calls closer to your mind paradign. I have the code in Bastian examples to compile a shader, so time to take it.

Here is my first “module”, just a small source file that will help me as a guide to future modules, I put there the shader compiler and how to create a box in a call list: GLTools

And then I clean up the Bastiaan file to use my tools and add some small features: Hackpact_dat1

And here are the results:

Cubes and blending

Main changes are to render two cubes instead of one (one in wireframe and one normal) and to use additive blending. I like when you overdraw the scene, it looks “hackerish”.

Conclusion

Hey, programming in python with OpenGL looks easier than what I thought. I don’t have to say the types and the API is totally exposed so I can do most of the regular stuff without thinking too much. The performance is good enough and it blends perfectly with Python.

Tomorrow, more test

My friend Graham is a good link to the productivity path of the sourcecoder. He always surprise me with his good use of the spare time, and he make me remember the golden years when I enjoyed spending hours trying to figure out the secrets of the ancestral art of developing for your own pleassure.

So sometimes we talk about metadevelopment (how to develop your skills to develop better). He told me about meetings he arranged back in the days with other people in the same situation, just to talk about their own projects, in an effort to push each other in the hard way to complete their ideas and to prevent them of parking the projects when things get hard.

And yesterday he told me about a Hackpact arranged by a friend. As far as I understood the Hackpact is a pact between a bunch of people with ideas where everybody undertakes to develop and document a small idea every single day for a month.

Sounds a lot of work to me, but hey, that’s what I need now, a virtual pact with some foreign people I don’t know for a greater purpose, in my case, the glorious exploration of the real-time rendering using scripting languages.

So here is my pact, but don’t blame me if I only last for a week, it was enough effort to recover this blog!

And then I realized how much time wasted, how many ideas got lost, and how far I was getting from the right path I draw during my bright years. And then I remembered, that I had a blog, somewhere over the internet.

So from now and on, it doesnt matter that I think I don’t have nothing to say, from now and on I will do things, and I will document them, here, and I will use this blog as a proof of existence.

And yes, it is time to switch to english.

But be aware, not more emo-stuff (I hope), from now only technical words I barely understand.

Me han pasado hoy el enlace a la web donde se pueden ver las valoraciones que los alumnos han hecho de mi labor como profesor de prácticas de los últimos años. Sabía que existía tal web pero nunca me había parado a buscarla, y lo cierto es que me dejan bastante fino.

Como profesor novato que soy aprecio las críticas y veo que en gran parte tienen razón, muchos de los errores que apuntan son fallos que me constan ya de tiempo atras, pero que no se solventan de un año para el otro. Tambien los hay que se toman mis reproches como algo personal y aprovechan las evaluaciones anónimas para desahogarse, pero yo tambien he sido alumno así que es comprensible.

Os dejo aquí el listado de los comentarios que me han hecho los alumnos en los últimos años para escarnio público mio.

Infografía 2007 mi primer año como profesor, traté de repetir lo que se había hecho en años anteriores aunque no me convenciera del todo, aun así ese año figuré en la lista de profesores que estaban por encima de la media en valoraciones, la nota media fué de 8.09

• excelente, explica muy bien y si tienes alguna duda, te atiende muy aducademente. (este debía ser el alumno al que le aprobé con un cuatro)
• mes exercicis y practiques i menys teoria abstracta. (parece eslogan de campaña)
• És poc eficient haver de posar a la pràctica allò que encara no s’ha explicat a teoria.
• Explicaciones muy claras y ademas incluye posibles errores tipicos que se han cometido a lo largo de los cursos, que quieras o no, son muy utiles porque hacen que vayas con mas atencion a la horade programar.
• M’agrada molt la forma d’explicar. Fa que les practiques siguin molt entenedores i amenes. La unica cosa es que es podria deixar una mica mes de temps per a l’ntrega de les practiques, ja que tot i que es poden fer parcialment a classe, per acabar-les al mateix dia no es possible moltes vegades, creant retrassos en l’entrega – retrassos acceptats, pero que no agraden ni a professors ni a alumnes
• Que parli més a poc a poc. No és que s’expliqui malament, és que a la velocitat que ho explica no tenim temps de processar tota l’informació. A part d’això molt bé tot, està molt predisposat a ajudar.
• Explica bé i sempre está disposat a ajudar.
• Que no parli tant depressa.
• Es un tiu una mica borde i va del pal amb els alumnes, es creu un ser superior als alumnes, personalment, el professor més estúpid que m’he trobat en tota la carrera….  (este llevaba odio contenido durante semanas)

Infografía 2008, este año intenté rehacer las practicas para hacerlas menos teóricas y más utiles para los alumnos, aunque eso las hizo algo caoticas. Reconozco que se me fué un poco de las manos y eso se notó en las valoraciones. La nota media fué de 6.16:

• En general todo esta bien. ¡enhorabuena!
• Al fer-se-li una pregunta, o dir-li que una cosa no et funciona, si mira la teva pràctica, sol dir que ‘esto es una chorrada, imaginate tener que trabajar con operaciones de matrices como yo’, despreciant el que els alumnes a vegades no sapiguem una resposta. Tot i així, sempre acaba resolent la qüestió. (jurl, a este mis críticas no le sentaron muy bien)
• no és que expliqui malament, si no que ho fa massa rapid. parla extremadament rapid dels conceptes que segurament ell sap de sobres i deu considerar banals xo molts de nosaltres ni coneixem i és molt dificil seguir que diu quan encara estas pensant en el que ha dit abans.
• Una semana es poco plazo de entrega para la gran mayoria de las practicas.
• Parla tan depressa que no s’enten res del que diu i a part utilitza documents en PDF que son d’altres anys i que tenen poca relació o serveixen de poca ajuda a l’hora de fer les pràctiques. Si el vas a veure el despatx perque no t’ha quedat clara alguna cosa, no t’ajuda a entendre-ho sino que encara posa traves preguntant si no escoltàvem a classe… No m’ha agradat gens la docència rebuda (i se que no soc la unica persona) (parte de razón lleva pero me quedo con la última frase, habla por los demas porque sabe que ellos no tendran valor de hacerlo)
• Parla molt ràpid. La classe on s’impartia la classe era un forn (la 231 crec). Amb tanta calor un no es pot concentrar. (no se si me culpa a mi de que la clase se caliente tanto)
• Hi han massa pràctiques a fer durant el trimestre, ja que tenim més assignatures d’aquest estil de fer pràctiques i seminaris i encara més amb Bolonya… El professor a vegades s’explica amb massa pressa a les pràctiques i no s’acaba d’entendre tot el que s’ha de fer.

Taller de Jocs 2008, primer año dando juegos, en general estoy contento pero faltó algo de planificación y los recursos que daba a veces no habian pasado un testeo adecuado, pero traté de suplirlo dedicandoles más horas de las que figuraban por contrato. La nota media que me dieron fué de 8.23

• Agenjo for president (este debe ser presidente de mi club de fans)
• parla més a poc a poc
• Cuidado con los bugs en los frameworks, los alumnos nos podemos volver bastante locos! A parte de eso, buen trabajo. (es lo que pasa cuando no reaprovechas el trabajo de los profesores anteriores)

En fin, creo que queda claro que tengo que ponerme serio con mi problema de hablar rápido, pero joder, hablar más lento implica pensar más lento y eso no se como se hace. Y por otra parte debería advertirles de que tengo una actitud un poco agresiva cuando se trata de comentar sus errores, pero no hay maldad ninguna, es la manera como a mi me habría gustado que me dijeran las cosas.

Bueno, me queda mucho trabajo que hacer para mejorar mi labor docente, me esforzaré para que no me vean tan ‘evil’ cuando pierda la paciencia.