🚀 go-pugleaf

Y el allegro tira sobre bajo nivel o sobre X? Es decir, si en Allegro
pides una "pantalla a 640x480" te pone la VGA as� o detecta si
est�s en X y te abre una ventana del tama�o solicitado.

Porque para videojuegos en MS-DOS muy bien, pero parte de la gracia
del Linux es que yo est� en un PC con Windows, ponga un servidor X
o un VNC y pueda ver esas demos o juegos, (l�gicamnte a costa de
un framerate patatero), pero al menos verlas.

Yo estoy muy escarmentado de la �spoca de demoscenero de Amiga, en
la que hac�as una demo para Amiga 500 y (como no ibas legal
por el sistema operativo pidiendo pantallitas, sino que
ibas a saco al hard a buscar los registros) en un A1200 no tiraba
ni p'atr�s.

Tengo "mono" de hacer alg�n d�a alguna cosa para Linux y estaba
pensando que quiz�s ser�a incluso razonable mentar una demo
"autocontenida en un CD". Por ejemplo, montar un iso-fs con sus
cositas, poner un arranque autom�tico y asegurarse que en es CD
hay todo lo necesario para "ver" esa demo donde sea (incluso
donde no haya Linux instalado).

Eso es bastante viable para sistemas de Consola y ataque a
bajo nivel, para tirar con un framerate razonable.

Es m�s, hasta se puede tener en el lilo un entry-point para
las demos con un kernel que est� comunmente aceptado
como "m�nimo" para que funcionen y toda una distro (peque�a,
por supuesto) con las librer�as necesarias para que todo
funcione. Si esa mini-distro orientada a demos ocupa *muy*
poco y est� autocontenida (por ejemplo, en nuestra debian/redhat
/mandrake, etc creamos un direcotorio /usr/local/demodistro/
y all� hay todo lo necesario para ejecutar esas demos, juegos,
emuladores y dem�s, evitas, por un lado complicadas instalaciones
de paquestes sueltos para hacer que tu distro actual tire con
las demos y por otro lado que al correr con un chroot a ese
directorio, por ejemplo, aseguras que nada pueda estropearse
por accidente.

Esto puede facilitar el "probar" las demos, juegos, y tal. Pero
por otro lado ser�a _muy_ (y digo _muy-mucho_) interesante
que la librer�a que se use soporte (por ejemplo en funci�n
de un fichero lo-que-sea.rc) que vaya por bajo nivel (hard)
o por alto nivel (X), al estilo DirectX, que si la tarjeta
tiene alpha lo hace por hard y si no, lo calcula la CPU.

Esa combinaci�n es la permitir�a mayor compatibilidad con el
p�blico masivo y, en definitiva, es la que aportar�a un mayor
n�mero de "espectadores" de las demos y tal, lo que generar�a
un mayor volumen de creaci�n de producciones, lo que a la vez
aumentar�a el uso de susodicha librer�a (sea cual fuere) y a la
vez cada vez m�s estar�a m�s soportada.

As� que resumiendo, mi (modesta) opini�n desde un punto de vista
externo (no he programado en allegro ni en SDL en Linux, aunque
s� videojuegos en Allegro para MS-DOS) se plantea desde 2 puntos
de vista:

Punto de vista de "programador que tiene "mono"":
- Si la librer�a soporta X y consola, programar� m�s, porque
a veces estoy en lugares que no tengo consola Linux (s�lo
un treiste Win), pero con acceso a mi shell de mi servidor.
Si ah� lanzo mi demo y la puedo ver por X, fant�stico.
Ser�, por supuesto, consciente de que cuando la tire en modo
consola ir� cien veces m�s r�pido.
- Si la librer�a soporta X y consola, programar� m�s, porque
mi trabajo lo ver� decenas de veces m�s gente que si lo hago
s�lo por hard. Quien tenga inter�s en verlo r�pido, ya lo tirar�
en modo consola.

Punto de vista de "espectador pasivo":
- Si la librer�a soporta X y consola, me atrever� m�s a 
ejecutar una demo, porque tiro las X en un usuario sin
privilegios y si la demo no se cuelga entender� que el
programador no ha metido la gamba, as� que quiz�s me atreva
a tirarla contra la consola.
- Si la librer�a s�lo soporta consola, ser� dif�cil que me atreva
a tirar un programa que toque el hard, pq seguramente deber�
correr en root o con una plataforma lanzada en root que accede
a ese bajo nivel y corro el riesgo de congelar el sistema, con
lo que debo apagar a saco. �Y si estaba haciendo un maravilloso
download, o un amigo hab�a entrado por telnet para compilar su
s�per-cr�tico-programa que tocaba miles de peque�os archivos
y el disco deber�a apagarse bien? (Ya seeeeee, las copias
de seguridad, es por poner un ejemplo, ya se entiende, no?).

A esto se suma que, como espectador, si tengo un sistema
f�cil de instalar (por ejemplo todo .rpm o .deb que _no_
haya que compilar y tal) ser� m�s probable que ejecute esas
demos, por ello propongo la mini-distro orientada a demos
"autocontenida" precompilada para intel i586 (se puede
preparar un script que precompile para otras CPUs)
en .rpm y .deb de forma que deje "todo", inclu�do su
kernelito y sus libreri�tas metido en un �nico directorio
tal que en el lilo ponga otra entrada (por ejemplo
titulada "demos") y que al arrancar ya sepa yo que eso me
va a respetar el resto del sistema.

Adem�s, por comodidad del espectador, sugiero que _todos_
usen esa distro sin cambiarle cosas para evitar cosas
del palo "es que con la mini-distro-demos v1.23 pero
con el Kernel 2.4.3, y sin opci�n de no-se-qu� no funciona".
Simplemente, si con la versi�n del desarrollador funciona,
tiene que ir y punto.

A la vez, si se puede hacer que el juego/demo/emulador
compilado "no requiera" de haber arrancado en esta distro
para tirar en X, mil veces mejor, por si en ese momento no
se puede reiniciar el sistema (yo que se, hacer un
/etc/distro-demo.rc con el path adecuado y si el programa
detecta que no ha arrancado en modo "demo" nativo, tenga
los directorios a los que referirse para ir a buscar las
libreri�s de acceso al modo gr�fico, as� sin rebotar
se podr�a llegar a ejecutar, s�lo que s�lo podr�a ser en
X o en consola si garant�a de que funcione.

Bueno, es mi modesta opini�n vista desde el punto de vista,
como he dicho antes, externo y como potencial espectador
+ developer, no como actual programador en ninguna de las
dos librer�as que se proponen.

Saludos.
xim/compumax