<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comentarios en: Accediendo a los subpixels con Pygame mediante SubPixelSurface</title>
	<atom:link href="http://www.elchiguireliterario.com/2007/06/11/pygame-subpixels-subpixelsurface/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.elchiguireliterario.com/2007/06/11/pygame-subpixels-subpixelsurface/</link>
	<description>Videojuegos independientes y programación en español</description>
	<pubDate>Sat, 22 Nov 2008 23:34:28 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>Por: Ciro</title>
		<link>http://www.elchiguireliterario.com/2007/06/11/pygame-subpixels-subpixelsurface/#comment-408</link>
		<dc:creator>Ciro</dc:creator>
		<pubDate>Wed, 13 Jun 2007 16:30:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.ciroduran.com/blog/2007/06/11/pygame-subpixels-subpixelsurface/#comment-408</guid>
		<description>Hola Luis,

Tu pregunta es muy buena. Hasta ahora en CuteGodChigüire he hecho los bloques del terreno como una extensión de Sprite, pero no he utilizado para nada su funcionalidad ni la de los grupos.

Los bloques de terreno son particulares en este juego en el sentido de que: a) No precisan de ninguna actualización de movimiento por sí mismas sino hasta que los muevo con el mouse, b) La información de su ubicación depende de World, la clase que representa el mundo. Debido a que los bloques se pueden mover, me parece que tiene más sentido mantener la información de su ubicación en World en vez de adentro.

Es por esas dos razones que hasta ahora no he utilizado grupos ni sprites para representar los objetos del terreno, sino que he programado las cosas a un estilo personal: esto me ha permitido aplicar una o dos técnicas que ya conocía para dibujar y hacer detección del mouse.

Sin embargo, puede que otros objetos como los personajes sí los haga como Sprites, de ser necesario. Es algo que no tengo planificado por ahora. Esta tarde debería salir el artículo de la segunda revisión del juego, y allí aclaro más detalles de lo que voy a hacer. Quizás si tenga que aplicar algunas movimientos suavizados del terreno pueda utilizar las funciones que ofrece Sprite. Esta es la ventaja de lenguajes como Python, que puedo cambiar las cosas sin tanto esfuerzo.

Ah, Numpy... Estuve entre este fin de semana y el lunes averiguando cómo utilizarlo, y me conseguí con el rollo gigantesco del cambio de nombre entre Numeric y Numpy, junto con varios problemas, como no conseguir funciones que están en Numeric pero no en Numpy. Esto se traduce en que instalé al principio Numpy, y estuve enredadísimo con problemas como que no reconocía que había una función matrixmultiply, y otras cosas. Al final tuve que resolver instalando Numeric, contra toda recomendación de actualizarme a Numpy, y todos contentos.

Igualmente necesito esta librería para poder realizar operaciones fundamentales sobre las imágenes que no puedo hacer de otra manera sin tener que echar el código yo mismo. Así que no me queda otra que seguir adelante con Numeric.

Espero haber respondido tus preguntas. Gracias y está pendiente otros artículos más con respecto al prototipo.

Saludos!</description>
		<content:encoded><![CDATA[<p>Hola Luis,</p>
<p>Tu pregunta es muy buena. Hasta ahora en CuteGodChigüire he hecho los bloques del terreno como una extensión de Sprite, pero no he utilizado para nada su funcionalidad ni la de los grupos.</p>
<p>Los bloques de terreno son particulares en este juego en el sentido de que: a) No precisan de ninguna actualización de movimiento por sí mismas sino hasta que los muevo con el mouse, b) La información de su ubicación depende de World, la clase que representa el mundo. Debido a que los bloques se pueden mover, me parece que tiene más sentido mantener la información de su ubicación en World en vez de adentro.</p>
<p>Es por esas dos razones que hasta ahora no he utilizado grupos ni sprites para representar los objetos del terreno, sino que he programado las cosas a un estilo personal: esto me ha permitido aplicar una o dos técnicas que ya conocía para dibujar y hacer detección del mouse.</p>
<p>Sin embargo, puede que otros objetos como los personajes sí los haga como Sprites, de ser necesario. Es algo que no tengo planificado por ahora. Esta tarde debería salir el artículo de la segunda revisión del juego, y allí aclaro más detalles de lo que voy a hacer. Quizás si tenga que aplicar algunas movimientos suavizados del terreno pueda utilizar las funciones que ofrece Sprite. Esta es la ventaja de lenguajes como Python, que puedo cambiar las cosas sin tanto esfuerzo.</p>
<p>Ah, Numpy&#8230; Estuve entre este fin de semana y el lunes averiguando cómo utilizarlo, y me conseguí con el rollo gigantesco del cambio de nombre entre Numeric y Numpy, junto con varios problemas, como no conseguir funciones que están en Numeric pero no en Numpy. Esto se traduce en que instalé al principio Numpy, y estuve enredadísimo con problemas como que no reconocía que había una función matrixmultiply, y otras cosas. Al final tuve que resolver instalando Numeric, contra toda recomendación de actualizarme a Numpy, y todos contentos.</p>
<p>Igualmente necesito esta librería para poder realizar operaciones fundamentales sobre las imágenes que no puedo hacer de otra manera sin tener que echar el código yo mismo. Así que no me queda otra que seguir adelante con Numeric.</p>
<p>Espero haber respondido tus preguntas. Gracias y está pendiente otros artículos más con respecto al prototipo.</p>
<p>Saludos!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Luis Antón</title>
		<link>http://www.elchiguireliterario.com/2007/06/11/pygame-subpixels-subpixelsurface/#comment-406</link>
		<dc:creator>Luis Antón</dc:creator>
		<pubDate>Wed, 13 Jun 2007 07:14:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.ciroduran.com/blog/2007/06/11/pygame-subpixels-subpixelsurface/#comment-406</guid>
		<description>Vaya con lo de los subpixels, interesante.  De todas formas, veo que estás hablando mucho de las Surfaces pero no comentas nada de la clase Sprites y para el cuteGod podría venir bien. La principal ventaja es el bucle de actualización, que puede llamar a todo un grupo de sprites de vez si utilizan la misma función de actualizado (y seguramente el terreno del cuteGod cumpla esta condición). ¿O ya conoces los sprites y te decidiste por las surfaces (que vienen directamente de las SDL)? Si es así, ¿por qué?

En  cuanto a la NumPy, me "fastidia" tener que usar terceras librerías para que las cosas vayan rápidas. Precisamente alguno de los juegos que participó en la última pyWeek no me funcionó porque no tenía instalada Numerical, la versión anterior de Numpy. Le cogí algo de manía : )</description>
		<content:encoded><![CDATA[<p>Vaya con lo de los subpixels, interesante.  De todas formas, veo que estás hablando mucho de las Surfaces pero no comentas nada de la clase Sprites y para el cuteGod podría venir bien. La principal ventaja es el bucle de actualización, que puede llamar a todo un grupo de sprites de vez si utilizan la misma función de actualizado (y seguramente el terreno del cuteGod cumpla esta condición). ¿O ya conoces los sprites y te decidiste por las surfaces (que vienen directamente de las SDL)? Si es así, ¿por qué?</p>
<p>En  cuanto a la NumPy, me &#8220;fastidia&#8221; tener que usar terceras librerías para que las cosas vayan rápidas. Precisamente alguno de los juegos que participó en la última pyWeek no me funcionó porque no tenía instalada Numerical, la versión anterior de Numpy. Le cogí algo de manía : )</p>
]]></content:encoded>
	</item>
</channel>
</rss>
