Supongo que alguna vez habréis oído eso de que lo que más aterra a un pintor, es un lienzo en blanco. Bueno, quizás no sea exactamente así, pero indudablemente (creo O_o), el peor momento de la realización de una pintura es el de empezarla.

Quien dice pintor, dice dibujante. El momento de comenzar el dibujo es incómodo, porque es el comienzo lo que guiará el desarrollo posterior.

Quien dice dibujante, puede querer decir (esto no lo veo tan claro) escritor (particularmente, novelista). No es lo mismo el momento en el que toca empezar a escribir, que un momento en el que ya se lleva encauzada la creación del texto y se tienen las ideas desarrolladas. Todo esto lo digo desde la perspectiva de alguien que no ha profundizado en la escritura, como (supongo) la mayoría de los que lean esto.

Pues quien dice escritor, dice programador... desde que acabé la carrera con la defensa del proyecto me he abandonado a la más absoluta de las vagancias, a la más absoluta desgana ante la idea de programar algo. Supongo que es normal tras tirarme tantos meses programando como loco día y noche y ante la ausencia de presión de la que gozo ahora.

No es ya sólo el no tener nada empezado para continuar, sino el hecho de que lo primero que debo hacer en estos momentos es documentarme, y programar con herramientas que no había usado hasta ahora. Más desgana aún.



Ante esto, cualquiera puede pensar que al título del blog le falta algo así como "of the engineering", o bien "of the career". De eso nada.

Me encanta programar. Como ya dije en la entrada que puse sobre mi finalización de la carrera, es algo importante de cara a ser informático. Sí, me encanta. Pero incluso ante algo que te encanta de vez en cuando puede haber algo de desgana, ¿no?

Otra cosa que podríais pensar: mentira, no te gusta tanto la programación, lo has hecho hasta ahora porque es tu obligación, pero nunca lo has hecho simplemente por placer. Pues ni hablar, aquí tengo una muestra. Vale que es una muestra de hace más de 4 años, pero... al menos tengo varios proyectillos pensados para mi tiempo libre (y el de algún colega). Por el momento no pasan de proyectillos, eso sí... nada, dentro de unos días estaré así:

Os imagináis que ese soy yo, y que estoy programando con fruición en lugar de estar escribiendo en el blog.

Ya veréis, ya...

Hoy he tenido la defensa del proyecto fin de carrera, con la cual, acabo definitivamente la Ingeniería Informática. La carrera ha sido muy dura, pero por fin se acabó.

Recuerdo cuando una compañera de instituto me decía que unos amigos suyos, grandes estudiantes, estaban pasándolo fatal y suspendiendo asignaturas en esta carrera, con lo que debía ser extremadamente difícil. Cierto es que la carrera es difícil (en realidad, no creo que haya carrera fácil), pero es cuestión de empeñarse. En este empeño, hay dos claves: 1- hay que tener fuerza de voluntad para estudiar cuando apetece hacer otra cosa, y 2- te debe gustar la informática.

Por informática, no entiendo encender el ordenador y entenderse con el güindous, ver páginas web y hasta hacer un documento en Guord. No. Por informática entiendo, lo que son tareas por debajo de eso. El desarrollo del software, el funcionamiento del hardware, la metodología de diseño. Tienes que disfrutar con, o por lo menos no te debe desagradar, la programación. Uno no puede llamarse informático sin saber programar. No olvidemos aquel anuncio de televisión, de cursos de programación Borland: Informático... ¡Si no sabes programar!

Y programar puede ser el peor de los infiernos si no te gusta. Tenedlo en cuenta los que estéis pensando en hacer una carrera de informática. Repito: el peor de los infiernos, si no te gusta. Aún gustándote, te puede sacar de quicio en alguna ocasión...

... Pero, la recompensa (el software obtenido) lo puede merecer. Ver cómo funciona a veces no tiene precio. Digo a veces, porque depende del programa que hagas. Por ejemplo, si es un juego que haces en tus ratos libres por amor al arte, realmente disfrutas con los resultados. Si es un programa que haces para una práctica de una asignatura porque no tienes más remedio, posiblemente veas el programa resultado y escupas sobre él... o lo harías si fuese posible escupir sobre un programa.

La carrera está rodeada de algunos mitos. Hay quien cree que aquí se bombardea con matemáticas y física. Eso es cierto (hasta cierto punto)... el primer año (y de todos modos en ese curso también hay asignaturas más "informáticas" ), al menos en mi universidad. Después de eso, se pasa a otros asuntos, como es hardware de bajo nivel, programación, metodologías, ingeniería del software, etc. Si eres de ciencias, y has obtenido nota para entrar, no deberían suponer un problema tan grave las matemáticas y la física. Además, hay que pensar que es solamente un obstáculo que hay que superar para llegar a lo que interesa. Aunque...

... no faltan las asignaturas coñazo, que son esas que no interesan a nadie, que son aburridas a más no poder, cuyo estudio representa una auténtica tortura china, y que no sirven para nada, diga lo que diga el profesor de turno. No, no faltan esas asignaturas, pero son baches que hay que superar... para llegar a lo que interesa. Me repito, pero la idea es esta.

Con lo dicho, puede parecer que entre matemáticas, física, y asignaturas truño no queda nada interesante. Falso, hay muchas otras asignaturas que sí son realmente interesantes para cualquiera, habiendo además muchas optativas diferentes. En cualquier caso, la verdadera informática te debe gustar.

Otro malentendido surge porque hay gente que cree que en la Ingeniería Informática le van a enseñar a hackear webs como un monstruo. No, eso no se enseña, desde luego, aunque lo aprendido a lo largo de la carrera puede servir para entender esas "tareas". Es más, un auténtico hacker es un experto en seguridad informática. No se enseña mucho de esto último en la carrera, pero se pueden hacer cursos para completar la formación de la carrera, que lo ponen a uno en situación. Pero eso sí... tienen que gustarte realmente las redes y los entresijos de la seguridad para seguirlo, porque si no se convierte en otro infierno.

Concluiré diciendo, que lo verdaderamente interesante de la carrera, es que lo convierte a uno en un resolvedor de problemas, porque se ejercita la mente para ello, y se aprenden, sobre todo, metodologías que posteriormente permitirán aprender con mayor facilidad cosas más concretas, como algún lenguaje de programación determinado.

Por último, dado que mi proyecto de fin de carrera está terminado, subiré cuando pueda algún vídeo de demostración.

Hasta aquí mi despedida del estudio de la Ingeniería Informática... ¡hola, Master en Desarrollo de Software!

Estaba yo programando, en lo que es la etapa final de la implementación del simulador de conducción para mi proyecto de fin de carrera, cuando tras unos pocos cambios tras la última compilación, decido recompilarlo todo para ver que marcha bien. Algo totalmente rutinario: lo hago a cada rato. A eso que me sale una lista inmensa de mensajes de error de compilación que no había visto nunca. Errores tan absurdos como "Símbolo inesperado: namespace". Al principio uno no sabe qué pensar: el compilador parece no reconocer súbitamente palabras que forman parte del lenguaje.

Se me ocurrió que la configuración del entorno había cambiado espontáneamente a compilar como C en lugar de C++ o algo por el estilo (con lo cual algunos símbolos dejan de reconocerse), pero comprobé que no era el caso. Siguiente idea: en mi código uso continuamente comprobaciones del preprocesador para descartar o incluir trozos de código selectivamente según una condición. Pensé que me habría dejado algún par "ifdef-endif" o "ifndef-endif" sin cerrar, así que a buscar.

Rebusqué en todo el código y no había manera, todos los ifdef/ifndef estaban bien cerraditos. Empecé a ponerme nervioso porque la lista de errores no me daba información alguna sobre dónde se encontraba el verdadero error. Siguiente idea: reiniciar el IDE pensando "se le ha ido la olla".

Pensé en reiniciar el IDE, pero no me decidí porque entonces se pierde la secuencia de deshacer de todo lo último que he hecho, y si no funcionaba el reinicio perdería toda posibilidad de deshacer los cambios hasta quitar el error de en medio. Así que, opté por deshacer todo lo hecho hoy aprovechando que siempre tengo abiertos todos los ficheros que modifico.

Ctrl+Z a saco en unos cuantos archivos, y la compilación seguía fallando. Continué deshaciendo en otros archivos, hasta que... ¡premio! Al deshacer los cambios en uno en particular, los siniestros mensajes de error desaparecieron. Ergo el único fallo que desencadenaba esa ristra de mensajes estaba aquí. Miré con recelo el trozo de código que provocaba el error pensando "pero si es un código de lo más normal y parece estar bien". Seguí mirando y... ¡sorpresa! Me encontré una llave '{' que sobraba. La eliminé y todo volvió a la normalidad.

"Joder" es la primera palabra que se viene a la cabeza en esta situación. Una llavecita y mira la que liamos. El problema está relacionado, con que ese trozo de código está dentro de una secuencia ifdef-endif, ya que en una situación normal, por una llave de más saldrían mensajes de error mucho más intuitivos que me permitirían encontrar fácilmente el fallo.

Dado que los mensajes no me informaban en absoluto de dónde estaba el error, aparecían en un lugar bastante alejado de éste, y tengo muchos archivos que se compilan por separado, jamás en la vida habría localizado el error si no llega a ser por mi querido amigo el Deshacer. En todas sus formas, ya sea con Ctrl+Z, a través del menú Edición, o pinchando con el ratón en la lista de Deshacer del editor, el Deshacer, siempre acompañado de su correspondiente Rehacer, se muestra como un regalo del cielo, de valor incalculable, capaz de sacarnos de auténticos aprietos. Bendigo al señor que inventó esta maravillosa opción.

Benditos Deshacer y Rehacer, os declaro mi más sincero amor, eterno e incondicional.

Dado que me lo pidieron hace tiempo en la entrada sobre mi particular versión del juego de Snake (no confundir con Metal Gear ), que hice tras mi primer año de carrera, pondré un sencillo tutorial para entenderse un poco con la gestión de las teclas en un programa C simple. No es nada complejo ni es la mejor forma de hacer las cosas, pero para quien está empezando o tenga dudas de cómo hacerlo, puede ser útil. Eso sí, debo aclarar que los ejemplos que vamos a ver, son para MS-DOS / Windows. En Linux alguna cosa puede ser diferente.

El punto de partida es: estamos haciendo un programa o juego sencillo con C/C++, y queremos capturar teclas que el usuario pulse. En principio uno pensaría en scanf o cin>>, que sirven para entrada de datos, pero no sirven, dado que éstos, esperan que se escriba algún dato para luego pulsar Enter. Aquí lo que nos interesa es que el programa sepa de inmediato que se ha pulsado una tecla (como puede ser una tecla de dirección), e identificar cuál.

Para casos como este, hay que tener el código ASCII a mano:

Pincha sobre la imagen para verla más grande

Recordad que el código ASCII tiene algunas variantes, por lo que no todos los códigos ASCII que encontréis serán iguales. Pero para usar unos pocos caracteres no suele dar problemas. Los 32 primeros caracteres son no imprimibles... en según qué casos. Se usan como caracteres de control (por ejemplo, salto de línea), aunque también tienen dibujitos asociados y dependiendo del lugar donde se usen, se pintará el dibujo o se realizará la acción asociada.

Otra particularidad es que hay teclas que comparten el código... como es el caso de las teclas de dirección. Éstas no están señaladas en ninguna tabla ASCII que haya visto. Hay que averiguar cómo referirse a estas teclas (para las teclas imprimibles, como la letra a, basta con usar la propia letra con comillas simples: 'a').

Trabajando con una buena librería o herramienta de gestión de eventos, no sería necesario preocuparse por el código ASCII, porque en esos casos normalmente toda tecla o carácter tiene su correspondiente etiqueta asociada (por ejemplo, KEY_LEFT para referirse a la tecla de dirección izquierda). Suponiendo que no es así, que estamos con C/C++ "a pelo" y sin ningún tipo de ayuda como la comentada, tendremos que definir nosotros mismos esas etiquetas. Pasamos a la acción.

1- Cómo averiguar empíricamente el código de una tecla

Para ello podemos hacer un programa sencillo que nos permita averiguarlo:

------------------------------------------------

#include <conio.h> //Para getch
#include <stdio.h> //Para printf

int main(){
char tecla;

printf("Pulsa la tecla de la que quieres conocer su codigo: ");
tecla = getch();

printf("\nEl codigo de la tecla pulsada es: %d\n",tecla);

return 0;
}

------------------------------------------------

Explicación: getch captura una tecla y la devuelve, pudiendo almacenar el código en una variable, como hacemos en este programa. Después, interpretamos como una variable entera a tecla usando el código %d para imprimirla, de modo que vemos su código numérico que es lo que nos interesa.

A continuación lo compilamos. Si el archivo es ascii.c, podemos hacer:

gcc -Wall ascii.c -o ascii.exe

si tenemos gcc, o del modo que sea si usamos otra herramienta.

Cuando lo ejecutemos, y pulsemos por ejemplo la tecla de dirección izquierda, es posible que obtengamos esta salida:

Pulsa la tecla de la que quieres conocer su codigo:
El codigo de la tecla pulsada es: 0

Eso NO quiere decir que el código de la tecla sea 0. El problema es que getch coge caracteres del buffer de teclado y a veces (particularmente cuando la tecla pulsada es una de dirección), se cuela alguno que no debe, por decirlo de forma más o menos sencilla . Pero si lo volvemos a ejecutar obtenemos la salida correcta. Tras algunas ejecuciones, vemos que los códigos son como sigue:

- Tecla de dirección arriba: 72
- Tecla de dirección izquierda: 75
- Tecla de dirección derecha: 77
- Tecla de dirección abajo: 80

Con lo que en el programa que estamos haciendo, podemos añadir al principio estas líneas:

#define KEY_UP 72
#define KEY_LEFT 75
#define KEY_RIGHT 77
#define KEY_DOWN 80

Y ya podemos usar estas etiquetas en lugar de los códigos ASCII en el resto del programa.

2- Captura de teclas en programas dinámicos

Ya hemos visto cómo capturar una tecla en un caso en el que el programa espera a que se pulse alguna, pero ¿y si queremos que el programa esté procesando o haciendo cualquier actividad aunque no se pulsen teclas? Por ejemplo en el juego de la serpiente: las serpientes se mueven aunque ningún usuario pulse ninguna tecla. Necesitamos algo que nos diga cuándo se pulsa una tecla. No se puede ejecutar getch() salvo que sepamos que el usuario ha pulsado una tecla y por lo tanto el programa no va a quedarse bloqueado. La solución (en MS-DOS / Windows) es la función kbhit(), también incluida en conio.h. Esta función se usa del siguiente modo:

------------------------------------------------

...

#define KEY_ESC 27
...

tecla = KEY_RIGHT; //Inicializamos

do{

...
//Procesamos
...

if(kbhit())
tecla = getch();
} while(tecla != KEY_ESC);

------------------------------------------------

Explicación: se suponen definidas las etiquetas para las teclas. En este código, se inicializa la tecla a "derecha", como si el usuario hubiese pulsado ya "derecha". A continuación itera en función de esa variable y posiblemente otros datos hasta que el usuario pulse Esc (el código de la tecla Esc es 27, lo podéis comprobar con el programa que vimos antes). La función kbhit devuelve true si el usuario ha pulsado una tecla, o false en caso contrario. Lo que quiere decir, que el programa seguirá iterando sin ejecutar getch hasta que el usuario pulse alguna tecla, que será capturada de inmediato (cuando termine la iteración en curso).

Debo indicar que kbhit en según qué implementaciones (compilador usado) puede no funcionar del todo bien y, por ejemplo, provocar un ligero parón, haciendo que se ralentice el programa por un instante en el momento en que el usuario ha pulsado una tecla. Como digo, depende del compilador usado.

En cualquier caso, esta forma de implementar no es la más elegante ni la más recomendable. Por ejemplo, no funcionará bien si se pulsan varias teclas a la vez, o se mantiene pulsada alguna. Es más recomendable disponer de algún mecanismo de gestión de eventos, de forma que el programa trabaje "a su bola" y cuando se pulse alguna tecla, simplemente se le avise para que atienda la pulsación, sin tener que hacer continuas comprobaciones. Pero en casos sencillos (como el juego que puse aquí), puede valer.

Quien tenga alguna duda sobre lo expuesto o cualquier otra cosa, que me lo haga saber con un comentario .

Me encuentro peleándome con Lib3ds, una librería para carga de modelos 3DS, cuya documentación, si es que se puede llamar así, es una puñetera basura (no explica nada, es solamente un listado, y ni siquiera un listado donde sea fácil encontrar algo), y además no encuentro ejemplos en condiciones (y eso que es bastante famosa la librería por lo que he podido ver, entre los programadores que se han metido en este tema...). No es culpa solamente de la librería, sino del propio formato, que se monta unos chanchullos tremendos para representar los modelos, pero eso es algo que la librería debería abstraer. De modo que no hay excusa: tal vez sea la mejor librería existente para carga de modelos 3DS desde C, pero su documentación y ejemplos son una puñetera castaña, lo que me está haciendo perder tiempo al no dar con la tecla para ciertos modelos.

¡He dicho, joder!
Powered by Objection!