30 de Julio, 2014

»Desmovilizándome · He estado pensando seriamente en actualizar mi equipo de casa (un portátil Dell normalito), pero no sé si quiero comprar otro portátil. Ahora mismo tengo un escritorio, con lo que trabajo con una pantalla de 22", ratón y teclado (un KBT Pure Pro compacto, y mecánico), más un Chromebook de 11.6" para llevar de paseo y a conferencias. En estos casos el portátil ocupa mucho espacio en la mesa, y no lo muevo para nada.

Estoy pensando en un Gigabyte Brix (el GB-BXI3-4010, que trae un Intel Core i3 de cuarta generación con una tarjeta de vídeo Intel 4400 HD; con 120 GB SSD y 8 GB de memoria se queda en unos 420 EUR). Ocupa poco espacio, es muy silencioso, y tiene todo lo que necesito (hasta WLAN). No es la máquina más potente, pero tampoco es mi prioridad. ¿Alguien tiene experiencia con este tipo de barebones?

Hay 2 comentarios

27 de Julio, 2014

Compositing y rendimiento

Alex llevaba tiempo quejándose de que su portátil no movía Minecraft con suficiente suavidad y la verdad es que, calidad de drivers aparte, no es que la máquina fuera corta de recursos (la GPU no es una pasada, pero la máquina tiene 4GB de RAM y... ¡es solo Minecraft!).

Se me ocurrió que podría probar con Openbox en lugar de Unity, y hay una gran diferencia (ella trabaja con Ubuntu Precise, que ya va siendo viejo... es verdad). Había leído por ahí que correr un gestor de ventanas minimalista puede mejorar los FPS que se consiguen en Linux en juegos 3D más o menos exigentes.

En mis experimentos con pyglet he notado que hay un problema similar en GNOME, y está relacionado con gestores de ventanas que implementan compositing (en inglés).

La idea básica es que en lugar de dibujar en el display, el gestor de ventanas que hace composición (traducción libre) proporciona un buffer para cada ventana a donde se redirigen las operaciones de dibujado de una forma transparente para la aplicación.

Una vez se tiene ese buffer listo, el gestor de ventanas enviará la información al display, realizando muchas veces un post-proceso para proporcionar todos los effectos a los que nos han ido acostumbrando los escritorios modernos.

Esto ni que decir tiene que tienen un coste, especialmente alto con tarjetas gráficas poco potentes o en las que el driver para Linux no es especialmente bueno.

En el caso de Alex, el gestor de ventanas Openbox no realiza composición, con lo que Minecraft se ejecuta mucho más suave al eliminar el trabajo extra que realiza Unity y que cuando ella juega al juego es completamente innecesario.

Aunque esos efectos que esperamos en un escritorio moderno son importantes (si los Mac y Windows lo hacen, hay una presión importante en el mercado para que las distribuciones Linux siguan la tendencia), es frecuente que causen problemas si quremos jugar ocasionalmente en Linux sin invertir en el hardware específico que nos daría el rendimiento necesario.

Es bastante habitual desactivar la redirección en juegos que se ejecutan en pantalla completa, con varios hacks que no terminan de funcionar en todas partes, y con el nuevo y prometedor _NET_WM_BYPASS_COMPOSITOR, que nos permitirá informar al gestor de ventanas que no queremos su buffer ni la redirección.

Hay otros factores que pueden afectar al rendimiento de los juegos en Linux (drivers, la versión de Mesa 3D), pero el compositing es el que más dolores de cabeza me ha dado, y no podemos esperar que todos los usuarios de nuestros juegos utilizen un gestor de ventanas minimalista :(.

Hay 0 comentarios, anotación clasificada en: programming, linux.

20 de Julio, 2014

El Makefile perfecto

Igual el título es un poco efectista, pero dado que me ha costado un poco dar con el Makefile para mis proyectos C++ con SFML, lo pongo por aquí por si le es útil a alguien más.

BIN=main
CXX=g++
# debug
CXXFLAGS=-fPIC -I. -c -Wall -ggdb -DDEBUG
LDFLAGS=
# release
#CXXFLAGS=-fPIC -O2 -I. -c -Wall
#LDFLAGS=-s
LIBS=-lsfml-system -lsfml-graphics -lsfml-window
 
SOURCES=$(wildcard *.cc)
OBJECTS=$(SOURCES:.cc=.o)
 
all: $(SOURCES) $(BIN)
 
clean:
    rm -f $(BIN) *.o *.orig Makefile.deps
 
Makefile.deps:
    $(CXX) $(CXXFLAGS) -MM $(SOURCES) > Makefile.deps
 
$(BIN): $(OBJECTS)
    $(CXX) $(LDFLAGS) $(OBJECTS) $(LIBS) -o $@
 
.cc.o:
    $(CXX) $(CXXFLAGS) $< -o $@
 
include Makefile.deps

Asumo GNU Make, aunque la verdad es que no sé si funcionaría con otras implementaciones.

Lo más destacable es que busca las dependencias automáticamente (usando el flag -MM del compilador), de forma que cuando modificamos un fichero solo recompilamos los objetos que se ven afectados. Además asume que todos los ficheros .cc del directortio forman parte del proyecto y que los includes locales están en el mismo directorio (es un proyecto prequeño).

La verdad es que probé CMake, que es lo que usa SFML para configurar y compilar; pero entre que no tengo necesidad real de configurar (por ahora no distribuyo fuentes) y al final CMake genera Makefiles, decidí investigar un poco más lo que ya sabía en lugar de dedicar tiempo a una herramienta nueva que por ahora no necesito.

Al final lo que más tiempo me llevó fue dar con el orden en el que hay que enlazar las librerías, por tema de dependencias entre ellas, y todo porque no leí correctamente la entrada en el FAQ :(.

Hay 0 comentarios, anotación clasificada en: programming, cpp, sfml.

19 de Julio, 2014

»El día después · Hace un par de días me di cuenta de un detalle que se me había pasado completamente desapecibido: ya no consumo feeds. Cuando actualicé a Fedora 20, olvidé que estaba usando Liferea y no restauré mi lista de feeds desde la última copia de seguridad. La verdad es que no lo he echado mucho de menos, pero me doy cuenta de que ahora estoy mucho menos informado. Hace algo más de un año que pronosticaba un apocalípsis de los blogs con el cierre de Google Reader; ¿alguien más lo ha notado?

Hay 5 comentarios, anotación clasificada en: blog.

6 de Julio, 2014

Zooooop!

Ayer publiqué Zooooop!, mi juego de Junio para one game a month.

Se trata de un juego tipo match-3 (la mecánica básica es agrupar tres piezas o más del mismo color), en el tenemos el clásico tablero continuo en el que podemos hacer click y desplazar una fila (o columna) para hacer los grupos, que una vez hechos desaparecen dejando huecos que se rellenan con piezas que caen desde la parte superior de la pantalla.

La pantalla de juego

Es un juego sencillo y no muy excitante, pero ha sido ideal para probar nuevas herramientas, en este caso SFML (el juego lo he hecho en C++).

Hacía años que no programaba nada en C++ y estoy intentando refrescar conocimientos y volver a aprender el lenguaje con todas las novedades que han ido apareciendo desde que hiciera un par de aplicaciones a finales de los 90.

Por una parte no me ha disgustado trabajar con el lenguaje (imagino que después de programar en Javascript, C++ no es tan malo :D), sobretodo tirando de STL (std::vector principalmente), y no me ha costado demasiado montar una estructura escenas/estados como la que suelo montar en Python. Por otra parte es cierto que el ciclo programa → compila → ejecuta es más lento, y algunos errores son más complicados de corregir (menos mal que tengo gdb).

En cuanto a SFML, estoy todavía bastante verde, pero más o menos lo que voy pillando me parece bastante bien diseñado. Proporciona un nivel de abstracción sobre OpenGL que me ha gustado mucho (por ejemplo, usar su clase View es más sencillo que trabajar directamente con glViewport). Para juegos eminentemente 2D me parece una buena elección; para temas 3D en los que desarrollemos nuestro propio motor, creo que también.

Empecé con el juego bastante tarde, con lo que habrán sido unos 10 días (y solo unos ratos en esos días, recordemos que esto no es a tiempo completo :P), y lo que más problemas me ha causado han sido las decisiones de desarrollo de la propia librería.

Por ejemplo: la versión que hay para bajar en la web como estable es la 2.1 (publicada hace cosa de un año), y tiene un par de bugs que han resultado muy graves en mi projecto (uno de ellos relacionado con la gestión del ratón en windows); con lo que he tenido que usar el código del repositorio y compilar mi propia versión.

SFML trabaja con cmake, y la verdad es que ha sido bastante lioso para hacer cross-compiling en Linux para Windows; especialmente porque he tenído que aprender muchas cosas en poco tiempo (difrentes versiones de compilador introducen diferencias en el ABI y las librerías no enlazan, MingGW tiene dos gestores diferentes para las excepciones y resulta que Fedora usa el otro, etc).

Al final he conseguido generar el binario perfecto para Windows, que ejecuta en Wine y en un Windows de verdad también ;). Porque resulta irónico que desarrollando en Linux sea más sencillo distribuir tu juego con SFML para Windows que para tu sistema de desarollo. ¿Por qué? Por las dependencias.

El juego para Windows son unos 1.1 MB comprimidos que incluyen el juego, datos y un par de DLL (que puedo distribuir, son Open Source), pero conseguir el mismo efecto en Linux es bastante más complicado si no quieres recurrir a empaquetar para cada distribución (eso si distribuyen SFML 2.1, que es bastante reciente). Así que para mi es bastante más fácil ahora mismo compilar binarios para Windows que empaquetar para Ubuntu desde Fedora :(.

Es curioso que siendo la distribución uno de los puntos más criticados de Python me resultó bastante fácil empaquetar Grid Runners para Linux, Windows y Mac (¡y no tengo un Mac!), que por ahora distribuir Zooooop!.

Tampoco es que sea un problema. Aparte de que nadie va a jugar al juego, según las estadísticas de mi página en GameJolt, Mac es una minoría, y Linux... casi inexistente :(.

Me ha gustado SFML, y creo que volveré a repetir en el futuro. Por una vez ha sido genial no tener problemas de rendimiento (¡qué rápido y suave va todo!), tras trabajar tan duro para ser lo suficientemente rápido en mis proyectos usando Python o Javascript.

Actualización: he publicado paquetes para Ubuntu 14.04 en la página del juego. Además he hecho un backport de SFML 2.1 a Precise, que se puede bajar desde este PPA (que mi madre todavía usa Precise :P).

Hay 0 comentarios, anotación clasificada en: 1gam, programming, sfml, cpp.

29 de Junio, 2014

»Google-- · Hace dos años que comentaba que estaba usando Google+ y que me gustaba, y en los últimos meses la verdad es que ya ni me acuerdo de él. Igual todo empezó cuando estuve probando Firefox OS, porque la web de Google+ me obligaba a introducir la contraseña con demasiada frecuencia (aunque era problema de Firefox OS, que al final dejé de usar). Ahora vuelvo a tener móvil Android, pero me parece que Google+ ha pivotado ya demasiadas veces (la app cambia cada poco, y en general creo que a peor), y no va a despegar. El caso es que como red social en general no está mal y me sirve para seguir a gente interesante, pero al final suena demasiado a monólogo porque no hay nadie (y para eso ya tengo esta bitácora :P).

Hay 0 comentarios, anotación clasificada en: google.

11 de Junio, 2014

»Probando SFML · Estoy empezando (algo tarde) mi juego de Junio y esta vez he decidido usar SFML y C++. La librería está muy bien, por ahora lo que me estoy encontrando en la versión 2.1 es bastante pontente (¡y rápido! después de usar Python y Javascript para programar juegos, C++ es una pasada). Además aprovecho para ponerme al día con C++ porque mi experiencia con el lenguaje es de finales de los 90 y la cosa ha cambiado un poco desde entonces. Por ahora estoy usando dos recursos: esta referencia on line y Accelerated C++ en la mesita de noche.

Hay 0 comentarios, anotación clasificada en: programming, cpp, sfml.

1 de Junio, 2014

»Resultados de PyWeek 18 · Ya están los resultados de la PyWeek 18. He quedado tercero, con 3.79 en total (mi mejor marca desde que empecé a participar en la competición); 3.41 en diversión, 3.59 en innovación y 4.36 en producción, siendo el primero en esa categoría. El ganador en individuales ha sido The Eight Bit Passage, en grupos ha sido Goodnight, Mr President (que, por cierto, no soporta Linux; ¡ha ganado con solo 8 votos! Mi favorito era Idle). He repetido posición, aunque esta es la primera vez que he entregado un juego que podría haber ganado ;).

Hay 0 comentarios, anotación clasificada en: pyweek.

27 de Mayo, 2014

»Grid Runners en indiegames.com · Estoy muy contento con que Grid Runners haya sido mencionado en indiegames.com. Además me gusta bastante la descripción que John Polson hace del juego:

Grid Runners involves hacking all the terminals in each stage, but the real challenges are in resource management and environment manipulation. You can hack each PC in one of four ways: to grant access to nearby doors, to disable nearby lasers, to recover your link (health), or to get you extra time on the grid. Enemies can shoot at you to deplete your health, and lasers will reduce your time allowed on the grid.

Yo no lo hubiera explicado mejor :).

Hay 0 comentarios, anotación clasificada en: pyweek.

21 de Mayo, 2014

Commits durante la PyWeek 18

Esta es mi punch card para Grid Runners, que nos da una referencia visual de cuándo y cuántos commits hice a lo largo de la semana.

Commits

Comparado con la edición anterior, creo que se nota que he tenido más trabajo ;). Además acabé bastante más tarde el último día añadiendo los 10 niveles (el sábado, porque el domingo en la gráfica corresponde con el inicio de la competición).

Hay 0 comentarios, anotación clasificada en: pyweek.

Entradas antiguasEntradas nuevas