Todas las entradas de: César León

Nací en el mes de mayo. En 2014 empecé a estudiar sobre el desarrollo de vídeojuegos, un conflicto de mi vida fue descargar software privado sin pagar licencias. Godot formó un puente entre mi y el Software Libre, probé GNU/Linux y termine aceptando el sentimiento ético de la FSF. Feliz de desarrollar juegos Indie con Software Libre :').

Disminuir ruido de fondo con Audacity

Al momento de empezar con la producción de vídeos para Youtube, me enfrenté con un problema muy común: el micrófono captaba el viento y toda clase de sonidos del ambiente. Para solucionar esto pensé que sería necesario otro micrófono, por un tiempo tuve que mantenerme con unos vídeos que de fondo sonaban muy mal.

Resulta que hay una solución muy sencilla, sin necesidad de cambiar el micrófono. El audio lo capturo desde el software de Audacity, lo único que hacía era exportar en un formato estándar (como .ogg), el audio que capturaba con el micrófono. Era seguro que algún efecto solucionaría el problema de sonido en el fondo, pero no tenía tiempo para experimentar.

Después de googlear me encontré con que Audacity dispone del efecto: “Noise Reduction” (Reducción de reuido). Su funcionamiento es muy sencillo:

En la imagen anterior se muestra como seleccioné la parte del audio que tiene el ruido de fondo, sólo tienen que seleccionar una parte pequeña, no todo. Después buscamos la opción de “Reducción de Ruido” o “Noise Reduction” en la sección de “Efecto”.

Veremos dos pasos para conseguir el efecto: primero hay que obtener el perfil de ruido. Es la parte que seleccionamos hace un momento, así que podemos hacer clic en el botón.

El perfil de ruido se ajustará con la parte que seleccionamos anteriormente, ahora tenemos que seleccionar todo el audio.

Para cumplir con la segunda parte del efecto de “Reducción de Ruido”, una vez seleccionado todo el audio, volvemos a la ventana del efecto y hacemos clic en “Ok”. Ustedes pueden cambiar los parámetros que se muestran ahí (Reducción, Sensibilidad, Suavizado), yo lo dejo con los valores por defecto, porque así me es suficiente.

Sí todavía queda un sonido mínimo, pueden repetir los mismos pasos. Espero que esto les sea útil en algún momento.

Este tutorial se realizo desde Canaima GNU/Linux 6.0. El programa de Audacity viene por defecto en el sistema.

Por ser Open Source no es Software Libre – Historia del Open Source Initiative

Es común que una persona confunda al Software de Código Abierto con el Software Libre, es una diferencia sutil. Dos caminos que prácticamente llegan al mismo lugar.

En este artículo vamos a repasar la historia de la Open Source Initiative (OSI) para que conozcan su punto de vista sobre el Software. El próximo jueves escribiré un artículo con la historia de la Free Software Foundation (FSF) y sacaremos las diferencias del Software Libre y el Software de Código abierto u Open Source.

Open Source Initiative – OSI

Fundada conjuntamente por Eric Raymond y Bruce Perens en 1998, la OSI inicia con la misión de defender el uso de código abierto en los Estados Unidos, motivados por todo el movimiento que generó el kernel Linux al ser liberado y reconocido en todo el mundo, sumando, además, la liberación del navegador Netscape.

Inmediatamente se contó con el apoyo de grandes figuras en la informática, personas como: Linus Torvalds y los representantes de Perl, Python y Apache le dieron el visto bueno a la iniciativa.

La etiqueta de «código abierto» se creó en una conferencia celebrada el 3 de febrero de 1998 en Palo Alto, California. La junta estaba creciendo debido al impacto de la liberación del navegador Netscape, mucha gente vio la oportunidad de educar y trabajar para un futuro de desarrollo abierto.

Los miembros de dicha conferencia creían que las razones pragmáticas por las que Netscape liberó su código eran valiosas para interactuar con nuevos usuarios y desarrolladores, ofreciendo la perfección del software trabajando junto a una comunidad que se comprometa unicamente al desarrollo del programa.

Su punto de vista se centra en el desarrollo del software y los beneficios que, como usuario o desarrollador, puedes obtener liberando el código y trabajando libremente con otras personas. Para ellos resulta importante resaltar que el Open Source hace referencia a la eficiencia durante el desarrollo de software, por eso decidieron diferenciarse del termino «Software Libre», ya que este tiene un punto de vista más «filosófico» y «político».

La OSI fue concebida como una organización educativa y de defensa general con respecto al Open Source. En enero de 1999 participaron en una petición para que el gobierno de los Estados Unidos se pasara al código abierto.

Cabe destacar que su defensa es discreta. En lugar de ser activistas públicos, trabajan de forma más «silenciosa». Proporcionan antecedentes a periodistas o casos de negocios a los ejecutivos. En el pasado también trabajó con la Free Software Foundation (FSF) «para convencer a las entidades antimonopolio de que exigieran licencias de código abierto para las patentes de CPTN«.

Para que un programa sea considerado Open Source, debe cumplir con las siguientes normas (las he copiado exactas, omitiendo su justificación):

  1. Redistribución gratuita: La licencia no debe restringir a ninguna parte de vender o regalar el software como un componente de una distribución agregada de software que contiene programas de varias fuentes diferentes. La licencia no requerirá un canon u otra tarifa por tal venta.
  2. Código fuente: El programa debe incluir el código fuente. Cuando alguna forma de producto no se distribuye con el código fuente, debe haber un medio bien publicitado para obtener el código fuente por un costo de reproducción no superior a lo razonable, preferiblemente descargando a través de Internet sin cargo. El código fuente debe ser la forma preferida en que un programador modificará el programa. Código fuente deliberadamente ofuscado no está permitido. No se permiten formularios intermedios, como la salida de un preprocesador o un traductor.
  3. Trabajos derivados: La licencia debe permitir modificaciones y trabajos derivados, y debe permitir que se distribuyan bajo los mismos términos que la licencia del software original.
  4. Integridad del código fuente del autor: La licencia puede restringir la distribución del código fuente en forma modificada solo si la licencia permite la distribución de «archivos de parche» con el código fuente con el fin de modificar el programa en tiempo de compilación. La licencia debe permitir explícitamente la distribución de software creado a partir de código fuente modificado. La licencia puede requerir trabajos derivados para llevar un nombre o número de versión diferente del software original.
  5. No discriminación contra personas o grupos: La licencia no debe discriminar a ninguna persona o grupo de personas.
  6. No discriminación contra campos de esfuerzo: La licencia no debe restringir a nadie el uso del programa en un campo específico de esfuerzo. Por ejemplo, puede no restringir el uso del programa en un negocio, o ser utilizado para investigación genética.
  7. Distribución de la licencia: Los derechos adjuntos al programa deben aplicarse a todos aquellos a los que se redistribuye el programa sin la necesidad de la ejecución de una licencia adicional por esas partes.
  8. La licencia no debe ser específica de un producto: Los derechos adjuntos al programa no deben depender de que el programa sea parte de una distribución de software en particular. Si el programa se extrae de esa distribución y se usa o distribuye dentro de los términos de la licencia del programa, todas las partes a quienes se redistribuye el programa deben tener los mismos derechos que los otorgados junto con la distribución de software original.
  9. La licencia no debe restringir otro software: La licencia no debe imponer restricciones sobre otro software que se distribuye junto con el software licenciado. Por ejemplo, la licencia no debe insistir en que todos los demás programas distribuidos en el mismo medio deben ser software de código abierto.
  10. La licencia debe ser neutra desde el punto de vista tecnológico: Ninguna disposición de la licencia puede basarse en ninguna tecnología individual o estilo de interfaz.

A diferencia de las normas básicas en las que se basa la FSF (hablaré de ellas el jueves), el Open Source busca un orden para el Software de código abierto, así evitan conflictos y son claros con sus licencias. El próximo jueves sacamos conclusiones 😉 .

Instanciar balas de nave espacial en Godot Engine

Una buena parte de los desarolladores indie han realizado un “Space Shooter” en su vida. Si quieres aprender a realizar los “disparos” con una nave espacial desde Godot, pasemos al artículo.

Nodos para la nave del jugador

Doy por hecho que su nave ya esta preparada: es un nodo KinematicBody2D y tiene su imagen. Además de eso, vamos a crear un nuevo nodo llamado “Position2D”, seguro adivinarán que se trata de una posición que podemos asignar en cualquier parte de la escena. La colocamos por encima del jugador, a cierta distancia.

Escena de la bala

La bala se creará por separado. Al igual que el jugador, su nodo principal es un KinematicBody2D que llamaremos “Bala”. Dentro de ella crearemos su Sprite y el CollisionShape2D, la guardamos con Control+S y añadimos un nuevo Script.

Script de la bala

Tienen permiso para eliminar todas las líneas de comentario. En el principio vamos a añadir dos variables:

var dir = -1
var speed = 500

La variable “dir” define la dirección que debe tomar la bala cuando es instanciada en la escena. Si es -1 subirá y en 1 bajará.

Activamos la función “_process()” y dentro de ella ponemos lo siguiente:

func _process(delta):
	var move = move_and_collide(Vector2(0,dir*speed*delta))
	if move != null:
		if move.collider.is_in_group("Enemigos"):
			move.collider.queue_free()
		elif move.collider.is_in_group("Jugador"):
			move.collider.queue_free()
		
		self.queue_free()
	
	if global_position.y > 720 || global_position.y < 0:
		self.queue_free()

La variable “move” sólo se puede usar dentro de la función _process(), es una variable local. Le ponemos un “move and collide” de valor, ya que esa función se usa para mover cuerpos Kinematic y consume menos recursos que un “move_and slide”. Al ser una función de movimiento, le vamos a pasar un parámetro de Vector2().

Dentro del Vector2() vamos a colocar nuestra formula de movimiento para que la bala se mueva. Su segundo parámetro corresponde al eje “Y” (el vertical). Como nuestra bala se moverá hacía arriba, sólo usaremos el eje vertical. La operación “dir*speed*delta” hará que cada segundo se aplique la aceleración en la bala, así veremos como se mueve en la escena. Cuando “dir” es negativo hace que la aceleración también sea negativa, pero cuando “dir” es positivo la aceleración queda positiva y la bala se mueve para abajo.

Cuando quieran comprobar una colisión con la bala, usan lo siguiente:

if move != null:
		if move.collider.is_in_group("Enemigos"):
			move.collider.queue_free()
		elif move.collider.is_in_group("Jugador"):
			move.collider.queue_free()

En caso de que la variable “move” no valga “null”, significa que chocamos con algo. Para saberlo usamos “move.collider” eso indica con que nodo chocamos. Ustedes se pueden inventar muchas cosas a partir de eso, yo pondré esto:

Si el “collider” sea quien sea, se encuentra en el grupo de “Enemigos” o “Jugador”, entonces elimina al collider.

Además, cada vez que la variable “move” sea verdadera eliminamos a la bala con self.queue_free().

Por último en el script de la “bala”, vamos a decir que si la posición en el eje «Y» es mayor que “720” (El 720 lo pueden cambiar por el tamaño de pantalla en “altura” que tengan en la configuración de ventana), entonces se autodestruye. En caso de que sea menor que 0, también la autodestruyes. Cuando sea menor que 0 es porque salió de la pantalla y esta muy alto.

Aquí cambiamos el 720 de altura por el numero que quieran…

Script del jugador

Ya que tenemos una bala para instanciar, vamos con el script del jugador. Primero vamos a añadir esta variable:

var bala = load("res://Bala/Bala.tscn")

Con el «load» estamos cargando un recurso de nuestra carpeta de proyecto. La ruta de la escena que contiene la bala la podemos obtener así:

Clic derecho en el recurso que queramos y después «Copiar ruta»

En la función _process() del jugador añadimos lo siguiente:

if Input.is_action_just_pressed("disparar"):
		_disparar()

El «Input.is_action_just_pressed()» va a ser verdadero cada vez que se presione una vez la acción que indiquemos como parámetro, en este caso estoy usando una acción llamada «disparar». La podemos crear de la siguiente manera:

La función _disparar() tampoco esta creada, la vamos a definir para poner el siguiente código:

func _disparar():
	var newBala = bala.instance()
	get_parent().add_child(newBala)
	newBala.global_position = $pos_bala.global_position
	newBala.dir = -1

Cada vez que hagamos clic en el botón de espacio (se active la acción disparar), una nueva variable «newBala» creará una instancia de la variable bala que creamos arriba.

Esa nueva instancia se volverá hija del padre del jugador. Con get_parent estamos accediendo al nodo que sea padre de la escena portadora del script, en nuestro caso, el jugador es el que esta usando el «get_parent». Ya con el add_child estamos colocando a la nueva instancia como hija del padre (hermana del jugador :p).

Recuerden que para acceder a las propiedades de un nodo sólo tienen que poner el «.» después de una variable que contenga la instancia del nodo. newBala contiene al nodo de la bala, si usamos un «.» vamos a poder acceder a sus propiedades. Colocamos su posición global igual a la posición global del nodo «pos_bala» que fue el nodo que añadimos junto con entrar en el tutorial.

Con el signo de dólar ($) podemos acceder a los nodos que sean hijos del portador del script. En nuestro caso desde el jugador podemos acceder al pos_bala, el Sprite y el CollisionShape.

Ya con esto hemos terminado el tutorial. Espero que sea de su agrado y aprendan algo :).

Puedes acceder al código del proyecto buscando «SpaceShip» en la Biblioteca De demos: https://gitlab.com/indielibre/bdd/

¿No conoces Debian GNU/Linux? – Aquí un resumen de sus ramas

Si entraste al mundo de GNU/Linux por la distribución de Ubuntu, seguro que todavía no conoces a la madre Debian. Usada por cientos de desarrolladores, Debian es la base para una gran cantidad de distribuciones, incluyendo Ubuntu.

Su nombre es una combinación del nombre de su creador Ian Murdock, con el de su esposa Debra. Todo comenzó en 1993 con la presentación de una distribución que se realizaría de forma abierta con los nacientes GNU y Linux kernel. Tres años después, y para nuestra sorpresa, la primera versión estable del sistema (Debian 1.1) sale con el nombre clave de «Buzz», un personaje de la película Toy Story. Desde ese momento, las versiones importantes de Debian tienen el nombre de un personaje de dicha película.

Ramas de Debian

Al momento de querer instalar Debian, vamos tener que elegir una de sus tres ramas. Son las ediciones que caracterizan al sistema:

  • Rama estable. Es recomendada oficialmente. Cuenta con un software estrictamente probado y es difícil que encuentres problemas en esta edición. Muchos programadores, productores y diseñadores la eligen porque es solida como ninguna.
  • Rama de pruebas (testing). En esta rama van a parar los paquetes que formaran parte de la futura versión estable. Aquí se probaran hasta que sean completamente seguros y quede demostrado que sirven para producción.
  • Rama inestable (unstable). Aquí se desarrolla Debian. Es la rama que usan los desarrolladores y algunos usuarios valientes para tener todo el software actualizado a su ultima versión, ya que en la rama estable y la de testing, el software tiene versiones que pueden distar mucho de las actuales. La rama inestable se llama «Sid» el malo de la película.

Cada rama tiene un propósito. En la estable se busca la formación de un sistema operativo completo, solido y con todo su software probado. Esta estabilidad tiene un precio, al lanzar esta versión se hace un congelamiento de todo el software y no recibe más actualizaciones hasta la próxima versión estable… que sale en un par de años.

En la rama de pruebas se identifican los errores que puedan dañar a la futura versión estable, es en ella donde un usuario puede colaborar probando cada programa y informando sobre su funcionamiento. Cuando la rama de pruebas esta desarrollada en su totalidad, puede convertirse en la versión estable. Después de eso, la rama de pruebas se queda «sola» y recibe todos los paquetes de la rama «Sid» la inestable, para que sean probados y puedan formar parte, en un par de años, a la versión estable.

A estas alturas ya tendrán una idea de la rama inestable, en ella se desarrolla Debian. Obtienen las últimas versiones de software y las preparan para que puedan pasar a la rama de pruebas.

Si algo nos queda claro, es que el desarrollo de Debian es muy organizado. Todo un ciclo que cumple perfectamente su objetivo.

Fuentes que he consultado para escribir el artículo:

Ramas de Debian: https://exdebian.org/wiki/ramas-de-desarrollo-de-debian

Historia de Debian: https://maslinux.es/razones-por-la-cual-debian-es-crucial-en-la-historia-de-gnu-linux/

Dev snapshot: Godot 3.1 alpha 1

Lo que todos estábamos esperando: Godot 3.1 alpha 1 es nuestro primer hito hacia el lanzamiento estable de Godot 3.1, con unos 7 meses de desarrollo desde Godot 3.0 (¡más de 3.500 commits!).

Contrariamente a nuestras versiones de mantenimiento de 3.0.x, que incluyen solo correcciones de errores revisadas a fondo y compatibles con versiones anteriores, la versión 3.1 incluye todas las nuevas características fusionadas en la rama principal desde enero de 2018, y especialmente todas las mostradas en nuestros devblogs pasados.

La etapa alfa corresponde a nosotros como un congelamiento de características, como se anunció en GitHub hace unos días, lo que significa que ya no consideraremos las solicitudes de extracción con nuevas características para la fusión en la rama maestra, y eso hasta que se libere Godot 3.1. De esta forma, podemos enfocarnos en lo que ya tenemos, finalizar y pulir las principales características que aún están en progreso (por ejemplo, el soporte OpenGL ES 2.0) y corregir muchos de los errores antiguos y nuevos informados por la comunidad.

Las versiones instantáneas alfa se lanzarán regularmente durante esta fase, para probar continuamente la rama principal y asegurarse de que se vuelva más estable, confiable y esté lista para la producción.

Renuncia

IMPORTANTE: esta es una compilación alfa, lo que significa que no es adecuada para su uso en producción, ni para revisiones de prensa de lo que Godot 3.1 sería en su lanzamiento.

Todavía hay un largo camino de reparación de errores y mejora de la usabilidad hasta que podamos lanzar la versión estable. Este lanzamiento es exclusivo para probadores que ya están familiarizados con Godot y pueden informar los problemas que experimentan en GitHub.

Tampoco hay garantía de que los proyectos iniciados con la compilación alfa 1 sigan funcionando en versiones alfa 2 o posteriores, ya que nos reservamos el derecho a realizar los ajustes necesarios hasta la fase beta (aunque los cambios de compatibilidad en esta etapa deben ser mínimos).

Las características

Las notas de la versión aún no se han escrito, pero puede consultar el registro de cambios detallado en el que está trabajando nuestro colaborador Hugo Locurcio.

Como se mencionó anteriormente, nuestros devblogs pasados también deberían darle una idea de los aspectos más destacados del próximo lanzamiento.

Los escritores de documentación están trabajando arduamente para ponerse al día con las nuevas funciones, y la última rama ya debería incluir detalles sobre muchas de las nuevas características 3.1.

Descargas

Los enlaces de descarga no aparecen en la página de descarga oficial por el momento. Esto para evitar confusiones para los nuevos usuarios. En su lugar, navegue por uno de nuestros repositorios de descarga y busque el editor binario que coincida con su plataforma:

Debido a algunos problemas del sistema de compilación, alpha1 no tiene plantillas de exportación de trabajo para el objetivo UWP ARM. Además, las características upp y websockets faltan por completo en las plantillas de exportación de UWP.

Importante: realice copias de seguridad de sus proyectos Godot 3.0 antes de abrirlos en cualquier versión de desarrollo 3.1. Una vez que se haya abierto un proyecto en 3.1, su archivo project.godot se actualizará a un nuevo formato para mapeos de entrada que no es compatible con Godot 3.0; este último se negará a abrir un proyecto 3.1. Además, el uso de nuevas características 3.1 en su proyecto significa que no puede volver a 3.0, a menos que haga el trabajo necesario para eliminar el uso de esas características. Así que pruebe 3.1-alpha1 en una copia de sus proyectos 3.0 o inicie nuevos proyectos con él.

Informe de errores

Todavía hay cientos de informes de errores abiertos para el hito 3.1, lo que significa que ya conocemos muchos errores. Sin embargo, muchos de estos problemas pueden no ser críticos para la versión 3.1 y pueden ser redirigidos a una versión posterior para permitir la liberación de Godot 3.1 en un par de meses.

Como probador, se le anima a abrir informes de errores si tiene problemas con 3.1 alfa. Compruebe primero los problemas existentes, utilizando la función de búsqueda con palabras clave relevantes, para asegurarse de que la falla que experimenta no se conoce aún.

The illustration picture is a 3D scene designed by John Watson. Source: Twitter post by @yafd.

Este artículo es una traducción de la página oficial: https://godotengine.org/article/dev-snapshot-godot-3-1-alpha-1

Probando Manjaro Linux

Manjaro es una distribución basada en un desarrollo independiente de Arch Linux, así como Canaima se basa en Debian. Ambos padres son conocidos en el mundo de GNU/Linux por su antigüedad, estabilidad y comunidad.

Cambiar a la familia de Arch Linux supone aprender algo nuevo. La instalación de paquetes tiene otros métodos y resulta más rápida que en la familia Debian, por lo menos para mi.

Hace ya un par de semanas que he instalado la versión estable de Manjaro junto con Canaima, con este tiempo conseguí producir algunos vídeos y adelantar mis proyectos. Para algunas cosas Manjaro me es más eficiente, mientras que para otras he sacado problemas. 

En esta entrada hablaré de Manjaro y lo compararé con Canaima desde el punto de vista de un desarrollador de vídeojuegos y productor multimedia, aunque sólo sea un aficionado ;). Como dato interesante puedo decir que Manjaro y Canaima son distribuciones Rolling Release, se pueden actualizar sin necesidad de instalar una nueva versión estable.

¿Por qué Manjaro Linux?

Manjaro no me es una distribución desconocida, tiempo atrás fue uno de mis sistemas principales. También he probado distros como: Chakra y KaOs, esta última se considera completamente independiente de Arch Linux, pero usa su sistema de gestión de paquetes: Pacman.

Si desinstalé Manjaro en el pasado, fue por una serie de dificultades donde no encontré solución. Problemas que hoy en día, con la nueva versión, están erradicados. Siempre me gustó Manjaro por su comunidad y estabilidad en el escritorio de Plasma. Proporciona una comodidad que sólo puedo comparar con Chakra.

Al principio instalé Manjaro para probar la cantidad de recursos que se consumen durante la producción de un vídeo, el desarrollo de vídeojuegos mediante Godot y la navegación en internet. Mis resultados me han convencido para hacer la transición de mis proyectos a Manjaro, sin embargo Canaima seguirá instalada en la computadora como precaución ;).

Manjaro tiene versiones oficiales y mantenidas por su comunidad, cada versión se diferencia por el escritorio del sistema: las versiones oficiales tienen Plasma, GNOME y XFCE. Las versiones mantenidas por la comunidad tienen muchos otros escritorios. Yo soy partidario de Plasma, consume pocos recursos y es un escritorio hermoso, nada que ver con GNOME. En Manjaro Plasma es muy estable, eso me ha encantado.

Producción de vídeos

KdenLive en Manjaro

Al momento de elegir una distribución de GNU/Linux tengo que pensar en el rendimiento para producción multimedia, si bien mis vídeos no requieren de tanto trabajo en la edición, me tengo que fijar en la velocidad para procesar un archivo y el peso resultante. Así como también mi rendimiento personal para manejar los programas y el escritorio del sistema.

Los problemas que he encontrado al momento de producir vídeos en Manjaro son:

  • Parpadeo del escritorio mientras se captura la pantalla con Vokoscreen o SimpleScreenRecorder. Al principio pensé que era un problema sin solución, resultaba muy molesto ver un vídeo así, la ventana desaparecía y dejaba el fondo de pantalla por unas fracciones de segundo. Lo arreglé bajando los fps en la configuración de Vokoscreen a 15.
  • Voz duplicada durante edición en KdenLive. Este era un problema decisivo: durante la edición del vídeo la voz sonaba duplicada en la previsualización pero se acomodaba cuando el vídeo era producido. Resulta que cambiando el modo de previsualización de «Alta calidad» por «Ninguno» solucionaba el problema… vaya calidad.
Solución al segundo problema de KdenLive

Eso fueron todos mis problemas en cuanto a producción de vídeos. Por fortuna encontré solución.

El archivo resultante al procesar un vídeo tiene un peso similar a un archivo producido desde la versión de Canaima, con la diferencia de que en Manjaro el procesamiento tarda unos minutos más y se reduce un aproximadamente un mega.

En Manjaro tengo las últimas versiones de Software, esto me da más funciones que en Canaima. Sin embargo debemos tener en cuenta que Canaima se basa en la rama estable de Debian y que encontrar problemas es complicado, mientras que con las últimas versiones de Software corro riesgo.

Desarrollo de vídeojuegos

Godot va de maravilla, pero eso lo he notado en prácticamente todas las distribuciones que he probado. Con Manjaro puedo trabajar consumiendo menos recursos de mi hardware, pero eso tiene que ver ya con el escritorio del sistema: mientras que en Canaima GNOME puede consumir 1.2gb sin tener aplicaciones abiertas, en Manjaro Plasma llegas a 500mb con lo mismo…


Lo mejor de todo es la configuración del sistema, esto gracias a Plasma. Muy bello será el día en que Canaima tenga ese «sabor» disponible.

Conclusión

Estoy satisfecho del rendimiento con Manjaro y su escritorio Plasma. La apariencia le gana a GNOME y puedo hacer lo mismo que en Canaima. Sin embargo, Manjaro corre el riesgo de colgarse por alguna actualización, que el Software me mande errores recién fabricados, etc. Por esa razón, la rama estable de Debian, la vieja confiable de Canaima, seguirá en mi computadora en caso de emergencia.

Enlace a la web de Manjaro Linux: https://manjaro.org/

Disfruten de GNU/Linux, hay distribuciones diferentes por todos lados y lo mejor es que podemos probarlas casi todas libremente ;). 

Curso sobre los fundamentos de GDScript disponible en Udemy

Puede que Godot no sea el motor para desarrollo de vídeojuegos mas usado, antes de su versión 3.0 la mayoría de sus seguidores estaban ubicados en Estados Unidos y el proyecto se mantenía con donaciones como cualquier otro proyecto de código abierto.

Hoy tenemos un nuevo motor con una base económica sólida y sus usuarios en crecimiento, mejorando día a día las funcionalidades para desarrollo 2D y 3D y trabajando con una gran cantidad de colaboradores por la estabilidad y optimización de Godot.

Mes tras mes, decenas de usuarios se interesan por Godot y en la comunidad hispana se hace notar el crecimiento. Sin embargo, no contamos con el nivel de tutoriales que la comunidad anglosajona ha reunido. Matías Muñoz, mediante su canal de YouTube: FuryCode, fue de los primeros en producir material educativo sobre Godot y hoy se ha publicado su primer curso en Udemy: «Aprende a programar para desarrollar vídeojuegos en Godot«. En su curso encontraras los fundamentos del GDScript, el lenguaje de programación que se realizó unicamente para Godot y que esta basado en Python.

Si nos ponemos a repasar los cursos sobre Godot que tenemos disponibles en Udemy, nos encontraremos con poco menos de diez. Dos de ellos en español, Matías a producido el primer curso que abarca los fundamentos de GDScript y garantiza el buen camino del estudiante para iniciar en Godot.

Aprovecha para trabajar con Godot, no puedes perderte el curso: https://www.udemy.com/aprender-a-programar-para-desarrollar-videojuegos-con-godot/

Ventajas de Canaima GNU/Linux frente a Windows

Para complementar mi artículo sobre el “Por qué” se puede usar Canaima, voy a escribir sobre sus ventajas y desventajas comparándolo con Windows.

Ventajas:

  • Software instalado por defecto. Canaima viene con suficientes programas para trabajar producción de vídeo y diseño gráfico, así como también la suite completa de LibreOfiice para la oficina. El usuario común generalmente no necesita instalar más programas.
  • Fácil instalación de Software. Esto se debe a la tienda de aplicaciones de Canaima (proveniente del sistema Debian), puedes buscar y actualizar los programas que necesites fácilmente.
  • Más rápido. Si bien Canaima cuenta con el entorno de escritorio Gnome, el que mas consume recursos en el mundo de GNU/Linux, resulta todavía más rápido que Windows 7 o Windows 10.
  • Atajos. En Canaima puedes dividir tus programas en espacios de trabajo, por ejemplo: dejas los navegadores en un espacio y la oficina en otro. Con acercar el cursor a la esquina superior izquierda de la pantalla ya puedes mostrar un espejo de todas las aplicaciones abiertas y los espacios de trabajo.
  • Configuración de escritorio. Puedes cambiar cada detalle del escritorio de Canaima, sus temas, iconos, fuentes… así como también puedes añadir extensiones para mejorar el funcionamiento. Todo esto es mucho mas fácil que en Windows.
  • Buena adaptación con el escritorio. Si no sabes cómo hacer algo en Canaima, puedes buscar en el navegador la palabra “Ayuda”, encontraras tutoriales escritos y en vídeo sobre la navegación por el sistema y atajos de teclado que te pueden ser de utilidad.
  • Versión “Live”. Como muchas otras distribuciones GNU/Linux, Canaima puede ejecutarse desde un pendrive o memoria USB sin necesidad de ser instalado en la computadora. Con esto pueden comprobar que el sistema funcione correctamente sin necesidad de instalarlo y arrepentirse.

Desventajas:

  • Problema con la terminal. Si después de instalar Canaima te sientes emocionado por usar la terminal, vas a experimentar un problema con el comando “sudo”. Esto es un problema común en Debian.
  • Falla en repositorios de software. Es probable que tengas otro problema para actualizar el software de Canaima mediante la terminal, esto se debe a sus repositorios.
  • Problema con TouchPad de algunas laptops. Me han afirmado que no pasa en todas las laptops, pero el problema consiste en que el hardware del touchpad no es detectado. Si tienen una laptop y no poseen un ratón externo, recomiendo no instalar Canaima.

No he experimentado otra desventaja con respecto a Windows. Uso Canaima para el desarrollo de vídeojuegos y la producción de vídeo y todo va bien. Cabe destacar que al producir vídeos en Canaima, el archivo resultante pesa menos que en otros sistemas, lo he comprobado.

Para terminar es importante saber que Canaima es un sistema basado en la ultima versión estable de Debian (9.4). Por lo tanto puedes encontrar soluciones a errores de Canaima buscando como si de Debian se tratara, ejemplo: “Falla con sudo en la terminal de Debian – error 30”, si aplicas lo que encuentres de Debian en Canaima, es muy probable que resuelvas el problema.

Espero que te animes con Canaima y me cuentes la experiencia.

¿Por qué Canaima GNU/Linux?

Historia y problemas en torno a Canaima

El 18 de octubre del año 2007 se inició en Venezuela un sistema operativo basado en GNU/Linux, o como decimos comúnmente: “Linux”. Bautizado como Canaima, Canaima GNU/Linux.

En ese tiempo Venezuela estaba atravesando una etapa de fuertes inversiones sociales, Canaima pasaría a ser un elemento clave en la educación dentro de todas las escuelas públicas del país y ayudaría, con su enfoque de libertad y Software Libre, a desviar el interés y la dependencia por el software privativo propio de Microsoft y su Windows. Durante poco más de una década a millones de estudiantes se les otorgó una computadora portátil (Laptop) con el sistema de Canaima.

Muchos años tuvieron que pasar para que el sistema obtuviera una versión estable, esto le costó muchas desinstalaciones y disgustos por parte de los usuarios, quienes, al no tener soluciones con algunas cosas, desinstalaron el sistema y descargaron (ilegalmente) una versión de Windows. Puedo sugerir tres problemas clave que influyeron en la decisión del usuario en el pasado y nos pasan factura ahora:

  1. Influencia de Windows y su software privativo en centros informáticos, lugares donde los estudiantes pueden imprimir trabajos o estudiar con internet.
  2. Problemas con el sistema de Canaima que sus profesores o la falta de interés del propio estudiante no pudieron resolver y restan puntos a la experiencia del usuario.
  3. Falta de información, mal promoción y poco ejemplo en el uso de Canaima. En la internet se encuentra muy poca información sobre Canaima, con decir que la mayoría de sitios web en torno al proyecto no se actualizan desde el 2012. Recomiendan Canaima sin explicar sus virtudes, sin demostrar que puede ser usada por el usuario común o el trabajador. Inclusive, podemos encontrar en oficinas relacionadas con el propio gobierno (fundador de Canaima) otros sistemas operativos como MacOs y Windows.

Eso era el pasado: un proyecto poco estable y una nueva Era de la Información naciendo en Venezuela. Hoy tenemos una pequeña cantidad de estudiantes con Canaima y el objetivo de recuperar la confianza de todos esos usuarios que se alejaron por la mala fama de una versión inmadura.

De los problemas que planteé arriba ya sólo queda uno: falta de información. Si el marco fuera el mismo ya disfrutaríamos de una comunidad gigantesca con poco menos de tres millones de usuarios. Ahora quedan nuevos problemas, los más difíciles y que encontramos como síntomas de los ya pasados:

  1. Ignorancia sobre ética en la informática o de los objetivos que persiguen empresas como Microsoft en la sociedad. Eso genera una incapacidad en la persona para entender el camino propuesto por el Software Libre y el Software Privativo y sus consecuencias en la sociedad.
  2. Dependencia del software privativo.
  3. “Odio Canaima”. Esta es una respuesta nacida en Venezuela, propia de una persona que puede verse con dos perspectivas: Primero, Canaima en el pasado pudo resultar frustrante por la falta de compatibilidad con el hardware y problemas de software que estropeaban su uso y pudieron servir de tortura a personas sensibles, por lo que, aunque “odio” sea extremo, es válido. Segundo, un único factor que para algunos, (generalmente extremistas, o meramente ignorantes) es determinante: Canaima es mantenido por el Estado venezolano que, para algunos sectores influyentes en la opinión pública cuenta con “mala fama”. Lo peor es que se “odie” Canaima sin siquiera ser probada por el usuario, simplemente porque es promovida por un gobierno.

Por fortuna no son problemas sin solución. Sin embargo, la rama de usuarios partidaria del tercer problema es muy inflexible. Hay que abundar en razones o, a largo plazo, hacer que Canaima sea muy usada pues estas personas generalmente se guían por modas.

Para colaborar, ahora escribiré un resumen sobre el “Por qué” Canaima puede ser usado por usuarios comunes. Mas adelante, dedicaré unas notas sobre las “Ventajas y Desventajas” comparándolo con Windows.

Detente a pensar: ¿Qué haces día a día en Windows?

Muchas personas sólo necesitan una computadora para navegar en internet, entrar en redes sociales y, en caso de estudiantes, copiar información de Wikipedia. En Canaima puedes tener las últimas versiones de Software en cuanto a navegadores de internet. Incluso teniendo en cuenta que Firefox es código abierto y Google Chrome una copia googleada del navegador Chrorium, osea Software Libre. No hay limitantes en ese aspecto.

Me parece que no te limitas a la navegación, también puedes tener fama de escritor. En Canaima tienes todo el paquete de oficina de LibreOffice en español y con diccionario, osea el resaltado de palabras que te corrigen al escribir. Si no hacías cosas sobrenaturales no notarás diferencia con el uso de Microsoft Office y, por ende, no habrá problema con pasarte a Canaima para redacción.

Otra limitante puede ser el uso de Adobe Photoshop y bueno: casi todo el software de Adobe. Pero no tienes derecho a quejarte por cosa semejante, porque sin temor a equivocarme estoy seguro que nunca has pagado un céntimo por la licencia de ese software. Puedes hacer cosas avanzadas y sencillas aprendiendo sobre el manejo de Gimp (Alternativa a Photoshop), lo mismo con InkScape (Alternativa a Illustrator). Ambas herramientas están instaladas por defecto en Canaima, pero también puedes instalar nuevas.

Si haces vídeos inocentes con Windows Movie Maker encontrarás decenas de alternativas mil veces mejores en GNU/Linux, Canaima. Pero quizás usabas Cantasia o Sony Vegas, obviamente sin pagar licencia… pierdes nuevamente el derecho de protestar su ausencia. Sin embargo, Canaima viene con Kdenlive una herramienta de producción de vídeo que, en mi opinión, lo he comparado con Cantasia y me parece mejor. Kdenlive viene instalada en Canaima por defecto, pero también hay decenas de programas en Software Libre para producción de vídeos.

Canaima tiene mucho más software listo para ser usado justo después de instalar el sistema y tú mismo puedes descargar algo nuevo. Sólo he mencionado los casos más comunes desde mi punto de vista, si tienes otro diferente, coméntalo.

¿Por qué debo usar Canaima GNU/Linux si estoy cómodo/a en Windows?

Es muy simple: tienes que unirte a las personas que trabajan día a día por el desarrollo libre del software porque así mejoraremos nuestra sociedad, porque avanzaremos en el desarrollo de software y hardware a nivel mundial.

Te voy a plantear un resumen, en mi opinión muy breve: el Software Libre defiende la libertad del usuario para compartir y cambiar un programa. Si quieres cambiar un programa necesitas saber su código fuente, son las líneas que decenas de personas han construido con sus conocimientos para dar vida al programa. Los desarrolladores de Software Libre ponen a disposición de cualquier persona el código fuente que hayan trabajado, le permiten cambiarlo y sacar versiones diferentes del programa, para así mejorarlo, limitarlo o hacer lo que se quiera, esto es libertad para el usuario. Lo cual es muy ventajoso, los estudiantes de informática pueden saber cual camino seguir, aprenderán sobre la formación de software mucho más rápido y, en consecuencia, evitarán errores en sus programas y enriquecerán de funcionalidades nuevas su propia obra. El Software Privativo hace de su código fuente algo privado, sin acceso a los usuarios y, además, sin permiso (al menos legal) para compartir el software con tus amigos o compañeros. Un estudiante no puede aprender sobre la creación de Adobe Photoshop, se las tiene que arreglar para hacer algo semejante, pero será muchísimo mas lento.

Todo esto sin contar con la tendencia de los crackers por producir virus en los programas de Windows, que pueden resultar en desventaja para cualquiera. Teniendo en cuenta que si usas Windows, no pagaste por el antivirus…

Si todos siguieran el camino de Microsoft Windows a la larga terminaríamos como esclavos del dinero y la privación. Si valoras tu libertad y la de tus compañeros, usa GNU/Linux. En este caso, hoy te he recomendado Canaima GNU/Linux.

Puedes descargar este sistema operativo desde su página oficial: https://canaima.softwarelibre.gob.ve/

Plataformas 2D – Nuevo curso para la Biblioteca De Demos

Entre los proyectos de agosto que fueron publicados en la Biblioteca De Demos se encontraban: Naves 2D y Plataformas 2D. Sobre este ultimo he estado trabajando una serie de vídeos para su desarrollo y ya esta todo listo para publicar.

Durante el primer curso, que era Tappy Plane, todavía estaba decidiendo el formato que usaría en cada vídeo. Se ve claramente que mientras los primeros capítulos eran muy cortos, los últimos resultaron largos y con más «detalle». Las pruebas con ese curso me dieron una base para continuar con los nuevos y, ahora con el Plataformas 2D, todos los vídeos serán «largos» y en mi opinión: con más calidad.

Para complementar el curso voy a producir vídeos relacionados con los nodos y las «funciones» usadas. Me parece que esto fortalecerá la información y garantizará el entendimiento de todos.

Entre las cosas que aprenderán y me parece importante destacar están:

  • Capacidad del personaje para hablar mediante globos de diálogo (Con textos indicados por el jugador).
  • Puntos intermedios al morir que devuelven al centro del nivel.
  • Botones para abrir puertas.
  • Cajas de monedas animadas. 

Dentro del curso encontraran más contenido, pero para algunos puede resultar repetitivo. Voy a dejar el enlace de la lista de reproducción donde se publicaran nuevos capítulos. Probablemente no se extenderá más de 15 vídeos.

Descarga el código y colabora desde GitLab: https://gitlab.com/indielibre/bdd/platformer2D

Sigue la lista de reproducción con los capítulos: https://www.youtube.com/watch?v=EUF1iwGsNqY

Si quieres ayudarme con el mantenimiento de Indie Libre puedes unirte a mi Patreon: http://patreon.com/indielibre