Bienvenidos al blog de FactorSIM.

Hoy he estado creando un sprite para el nuevo curso que estamos desarrollando. Bueno, en realidad yo he hecho un script y el script ha hecho el sprite, porque no tenía yo ganas de crear 100 imágenes a mano. Este es el resultado:

Las imágenes PNG individuales ocupan unos 950 bytes cada una. Parece poco, pero juntando las 100 salen 94.989 bytes. El sprite con las 100 imágenes dispuestas en una cuadrícula de 10×10 ocupa 14.384 bytes: un 15% del tamaño total de las imágenes individuales. Y de cara al navegador, en lugar de ser 100 peticiones es sólo una única carga (evitando latencia de cada imagen, su overhead, el hecho de que ningún navegador en su sano juicio lanzaría 100 peticiones en paralelo contra el mismo servidor, etc, etc…) .

Tal vez este sea un caso un poco extremo y habitualmente no nos encontremos con cosas tan evidentes, pero creo que esto explica por qué todos “los grandes” (google, yahoo, etc…) recomiendan el uso de sprites.

El resultado? Un linda pelotita que rueda y rueda cuando javascript le sopla…
Cómo se hace? En mi caso, con este script tan bonito:

1
2
3
4
5
6
7
8
9
10
11
12
13

#! /bin/sh
 
mkdir -p imgs
for i in `seq 1 100`; do
	sed -e s/##ENDANGLE##/`echo "scale=20; ( $i - 25 ) * 2 * 3.1415926535897932384626433832795 / 100" | bc`/g < drawing.svg > drawing_t.svg
	echo "$i..."
	"/cygdrive/c/Archivos de programa/Inkscape/inkscape.exe" -e 'C:\Documents and Settings\DaniM\Escritorio\sprites\imgs\'$i'.png' 'C:\Documents and Settings\DaniM\Escritorio\sprites\drawing_t.svg'
done
 
echo "Final sprite..."
sq=`seq 1 100`
names=`for i in $sq; do ( echo imgs/$i.png ) done`
/cygdrive/c/Archivos\ de\ programa/ImageMagick-6.4.0-Q8/montage.exe -background transparent -tile 10x10 -geometry +0+0 $names progress_sprite.png

El funcionamiento es sencillo: uso inkscape para crear un archivo vectorial SVG con el gráfico, utilizo sed para modificarle el ángulo final del arco y lo convierto a PNG invocando inkscape desde la linea de comandos. Una vez tengo las 100 imágenes, utilizo montage (parte de ImageMagick) para juntarlas en un sprite.

Como podeis ver, utilicé cygwin. Si hubiera usado un sistema operativo de verdad, no tendría que haber puesto toda esa marabunta de rutas en dos formatos diferentes.

Una opción interesante hubiera sido procesar el fichero SVG mediante xsltproc en lugar de mediante sed. Para casos más complejos seguramente sería una muy buena opción. Pero eso… lo dejo como ejercicio para el lector.

Cuando aparecieron las primeras WebApps nos reimos de ellas y nos negamos a llamar aplicación a “eso”. Pero dicen que quien rie el último rie mejor. Mediante ingenio, tecnología y nuevos estándares han superado sus limitaciones iniciales y ya hace tiempo que todos somos conscientes de que las aplicaciones web son aplicaciones de pleno derecho.

El más reciente gran paso es WebGL: un API OpenGL ES 2.0 para JavaScript. Es decir: gráficos 3D acelerados por hardware en el navegador. Estamos hablando del mismo tipo de tecnología con la que se desarrollan los juegos normales y corrientes. Y si bien JavaScript es más lento que el lenguaje C/C++ que utilizan los juegos, el hecho de que cada vez se haga más proceso en la GPU y menos en la CPU es una tendencia muy conveniente para hacer WebApps 3D competitivas.

WebGL no es un proyecto de especificación que algún dia verá la luz. Ya está aquí. Las últimas versiones de los principales navegadores ya lo implementan (lo que pone de manifiesto que Internet Explorer cada vez cumple menos su labor como navegador, ya que és la única excepción). Y las aplicaciones web que lo utilizan también están ya aquí. Por ejemplo:

Google Body Browser (http://bodybrowser.googlelabs.com/): un atlas anatómico completo en 3D.

Quake WebGL: por si teníamos alguna duda de si esto iba a servir para juegos. Hay una versión completa de Quake 2 (http://playwebgl.com/games/quake-2-webgl/) y visores de niveles de Quake 3 (http://media.tojicode.com/q3bsp/). Seguramente WebGL diera para portar juegos más modernos, si el código de estos estuviera disponible, claro.

Y otros muchos ejemplos de todo tipo: http://www.chromeexperiments.com/webgl

Hay veces que ves un portfolio de un artista y te quedas en estado de shock. Fascinado por la visión, por la capacidad creativa y de conceptualización que tiene. Y lleno de envidia por la gran cantidad de talento que desprende. Es el caso del Portfolio de Tiago Hoisel.

Sencillamente impresionante.

(Via el IMPRESCINDIBLE Criterion).

Cada vez más se consolida la presencia de Drupal como una de las herramientas líderes para la creación de entornos web complejos. En Barcelona aparte de nosotros, destacaría el trabajo de agencias como Neurotic y de Atenea Tech, sin olvidar el trabajo de freelance como Robert Garrigos…

Fuera de Barcelona, sólo conocemos el excelente trabajo de Carmel Hassan y seguimos muy de cerca el trabajo de Investic (que además son de Pamplona, mi tierra natal).

Sin embargo, todavía hay clientes que dudan de la utilización de Drupal porque ven limitaciones en el tipo de páginas a crear y en el diseño que se puede aplicar a las mismas.

Para ellos, qué mejor que ver los siguientes ejemplos de webs hechas en Drupal:

1.- Berliner.de/

http://www.berliner.de/

2.- The White House

Read the rest of this entry »

El Ministerio de Educación a través del Cnice, hoy ITE, ha puesto a disposición de los profesores, unos “simuladores” de la actividad profesional. Algunos de ellos se pueden acceder directamente desde esta dirección.

En un principio pensaba que sería un desarrollo serio, simuladores realmente interactivos, que permitan probar y cometer errores y que pudiesen mostrarte un aprendizaje de aprendizaje mediante la práctica.

La realidad, es que son simuladores más bien pobres (los que he podido probar, ya que algunos son .exe o requieren de Internet Explorer). De los que se hacían hace 10 años, con un arbol de decisiones en muchos casos de una sóla rama, lineales, con una interacción  baja, un uso de vídeo poco adecuado y unas animaciones muy poco elaboradas. No entro en diseño gráfico ni en usabilidad, que creo que son realmente un punto a mejorar. Hay partes del desarrollo que ni se leen correctamente, ya que están en flash, en blanco sobre fondo negro y en letra pequeñita.

En algunos simuladores, hacen un uso muy poco profesional del croma y del 3D, y en otros, para locutar, utilizan Loquendo. Supongo que ambas opciones son para ahorrar coste, aunque me gustaría ver la partida presupuestaria.

Pero hay una sorpresa. Por ejemplo, los Socioculturales. Estos simuladores tienen un diseño mucho más interesante, una usabilidad mejorable aunque razonable y una dinámica real de juego y simulación. Además, usan el 3D para mostrar objetos y escenarios, pero de forma muy correcta. Las dinámicas son clásicas, pero al menos no se ven anticuados nada más nacer.

Visto en El blog de Celestino Arteta