Friday, June 16, 2006

Dejando de molar

Como siempre, hace ya tiempo desde la ultima entrada...

Despues de la excursión de 3 dias con mi padre, se ve que volví nuevo, y me dediqué a programar bastante orientado a la scene. En cuestion de 45 dias, hice tres 4k y dos ports a windows. Un mes despues, terminé un tercer port, y desde entonces poca cosa he hecho. Para referencia, las 4k son, en orden cronologico:

- Ifparty'06 invitation / Collapse + Necrostudios
- Extasik / Collapse + Necrostudios
- e-fill / Collapse + Necrostudios

Y los ports:

- Fulcrum / Matrix
- G-Cube / Matrix
- Luxo / Matrix

Estoy especialmente contento con las dos primeras 4k (ifparty'06 invit y la extasik), la primera por el diseño general (que despues se convirtió en la imagen de la party :O) y la otra por ser tecnicamente bastante más potente que cualquiera que hubiera hecho hasta la fecha. Sobre los ports, el de la Fulcrum fué genial hacerlo, siempre me encantó.

Ahora mismo, estoy algo off de la demoscene. Los motivos son varios, y no creo necesario discutirlo aqui, pero simplemente necesito centrarme en otras cosas más interesantes que hackear graficos dentro de una 4k. Almenos ese es mi punto de vista ahora mismo.

Como no quiero (ni puedo) dejar de programar en casa, estoy liado con un engine 3D, centrado en soportar ciertas cosas que hace meses que queria probar. Siento ser parco en detalles, pero de momento poco hay que contar.

Como apunte final, me da la impresión que este verano no asistiré a muchas partys, no me he preocupado de inscribirme decentemente a la euskal, y los billetes a la Buenzli y la evoke estan demasiado caros. UPDATE: se ve que no han enviado aun las invitaciones de la PMP, sino que simplemente soy gilipollas y me creo mis opiniones demasiado rapidamente, por supuesto siempre basadas en humo :P

Ah, y ademas, ahora curro de programador.

Nada más, divertíos.

Sunday, February 26, 2006

Excursión

Ya se sabe, una imagen vale mas que mil palabras:



Resumiendo mucho, me he pasado 3 dias cruzando montañas, y ahora que ya he vuelto a Barcelona, la verdad es que añoro el cansancio, dolor de piernas y sudor de esos dias...

Wednesday, February 15, 2006

Emulación

Como algunos sabran, ultimamente, para despejarme de proyectos mas grandes y complejos, he recuperado mi emulador de gameboy que escribí por alli el 1999-2000.

Llamarlo emulador seria uno de los peores eufemismos que uno se puede imaginar, pues:

- No emulaba la pantalla
- El emulador de la cpu, tenia mas errores que lineas de codigo
- Todo el timing estaba hecho a ojo

Resumidamente, que era solo un core del z80 modificado que trae la gameboy.

El dia 2 de enero, cuando la xmo'06 de collapse estaba parada esperando a algunos graficos, y que yo corrigiera mil bugs del engine, decidi darle un toque, a ver si lo conseguia. Porque? Hacer un GUI en windows forms me hacia mucha gracia, pero necesitaba algun proyecto, y el emulador era perfecto: necesitaba un debugger decente para la cpu, integrar graficos en la pantalla principal, un visor de sprites... Era la oportunidad perfecta!

Resumiendo las 3 semanas que siguieron, hice mil versiones del debugger, cada una mas usable, un visor de sprites, integré opengl en la ventana principal, para poder ver lo que veria en una gameboy, un visor de "hardware", como lo llamo yo, que no es mas que todas las direcciones de gameboy que controlan la pantalla, y la cpu.

Sobre la parte mas tecnica del emulador, comentaré como lo hice, y quizas, que cosas haria diferente ahora mismo:

1o) Consigue roms libres con codigo. El debugger ayuda mucho para todo lo que no tengas codigo original, pero unos buenos comentarios son mano de santo. A parte, siempre son mas simples que un juego comercial, y ayudan a corregir detalles que de otra manera se te escaparian. Las hay para todas las consolas/maquinas, asi que no hay excusa.

2o) El debugger lo mas simple posible. En las primeras versiones, tenia un debugger super-cutre, sin ni soporte para breakpoints, pero con mucha información sobre los registros especiales. Al final, he sacado esos registros especiales (que no son mas que ciertas direcciones de memoria) a otra ventana, y he dejado el debugger asi:



Mis recomendaciones en concreto, serian: añade soporte para breakpoints lo mas pronto posible, haz que el viewer del desensamblado sea scrollable, y haz que el comando run corra igual que correria el emulador sin debugger. Son detalles simples, pero yo no los tenia al principio, y me he demostrado que son muy utiles.

3o) Debuggea, debuggea, y debuggea. En mi caso, el interpretador, es un switch gigantesco, y tengo que todas las instrucciones que no soporto, salga un error y salga. Antes de emular/jugar a ningun juego, probé mil roms de juegos, solo para asegurarme que el interpretador esta completo, ya habra tiempo para implementar graficos. Puedo decir que me sé gran parte del codigo tanto el Dr. Mario como el Tetris. Si no te gusta debuggear, un emulador te aburrira soberanamente.

Me dejo mil cosas, pero es realmente complejo explicarlo todo en solo un post. Ahora ya emulo el 90% de los juegos de la gameboy mono perfectamente. Otro dia pondré shots :)



Cambiando de tema...

Hablando con diversas personas del IRC y messenger, me comentaron que seria interesante que hablara de emuladores de diversas maquinas, y de joyas que he visto para gameboy/gameboy color. Empezaré por las joyas de gameboy, explicando un poco como es la maquina, para que se entienda un poquito lo que podeis ver.

La gameboy mono solo puede mostrar 4 tonalidades de ocre en un LCD de 160x144 pixeles, su cpu va a 4mhz, y la pantalla funciona con un puntero a tiles de 8x8 pixeles o de 8x16 pixeles. Se pueden mostrar 40 sprites en pantalla, con una limitación de 10 por linea, pudiendo cada sprite estar girado respecto la X, la Y. A parte, tiene un background de 256x256 pixeles, scrolleable en X e Y, que funciona de manera que cuando una parte sale por un lado, aparece en el otro (scrolleable en loop, vaya, pero asi se entiende mejor). También se puede activar, la llamada "window" que es otro background que se pinta encima del background, este no loopea como el background, y tiene una resolución de 256x256. Para mas efectos, los sprites pueden tener prioridades sobre ciertos colores del background y la window, pudiendo crear asi diversos efectos (como un personaje pasando por detras de arboles, o cosas parecidas). La cpu solo puede direccionar 16bits, es decir, 64kb de datos, pero esta limitación se pasa con banking, que no es mas que tener cierto rango de memoria que se puede cambiar por otro al escribir en ciertos registros del cartucho. Con esto, se puede conseguir hasta 8kb de ram, o 2mb de rom. Hasta aqui la explicación rapida de como funciona una gameboy mono de toda la vida.

La gameboy color, funciona a 4 o 8mhz, dependiendo del modo en el que este la cpu, puede mostrar hasta 64 colores en pantalla, de 32768 posibles, pero esto se puede superar cambiando la paleta por scanline. A parte, tiene varias clases de dma, para copiar memoria mas rapido.

Asi pues, tenemos una consola en la que no tenemos acceso directo a pantalla, que todo lo debemos pintar en la tabla de tiles, con una cpu lenta, ademas de tener muy limitados los periodos de escritura en esa ram de tiles.

El mejor emulador actualmente es el kigb, si quereis ver alguna de las roms abajo reseñadas, usadlo!

Demos/juegos impresionantes:

- Stun Race FX: posiblemente lo mas impresionante que he visto nunca. Solo usa la gameboy mono, pero muestra 3D, buena velocidad, y muchas de las cosas que hacia el chip FX de la SuperNintedo, que era una cuantas generaciones mas avanzado. Simplemente impresionante.

- Mental respirator: 3D, buenos efectos y buenos graficos, quien necesita mas?

- Demotronic: Scroll vertical durante el scanline, algo que segun nintendo no se podia hacer. Vale la pena verla solo si sabeis como funcionan las maquinas por tiles.

Ya seguiré comentando segun me pique, a parte, me dijeron a ver si podia comentar emus de diversas consolas, mas en general:

- Gameboy Mono/Color: Kigb. Testeado con todas las roms conocidas de gameboy, 100% compatible, simplemente perfecto. Portado a varios OS, y aun en desarrollo.

- MasterSystem/Gamegear: Meka. Un buen gui, herramientas para desarrollar, y jugar comodamente. Portado a varios OS, con source disponible y aun en desarrollo.

- Megadrive/MegaCD/32x: Gens. Muy rapido y compatible, como pega, que te cambie el escritorio a 16bits. Portado a varios OS, con codigo disponible, algo abandonado.

- Super Nintendo: ZSnes. Muy rapido y compatible, ademas de tener opciones para "mejorar" los graficos como para tirar un tren. Portado a varios OS, con codigo disponible, y en desarrollo.

- Sega Saturn: SSF. El mejor emulador de esta autentica bestia dificil de emulador (tiene 8+ chips que se tienen que sincronizar). Aun en desarrollo, bastante compatible, aunque necesitareis un pc con windows y SSE2.

- Playstation: EPSXE. 100% compatible, rapido, uno de los coders es de por aqui, tiene version windows y linux, y soporta plugins. Algo abandona pero no creo que necesite mas updates.

- Nintendo 64: Project64 (El site a veces esta down). Utiliza emulación de las principales librerias graficas que se usaban en para la n64, asi que pierde compatibilidad en pro de la velocidad. El mas compatible, muy rapido, y aun sigue en desarrollo. Solo para windows, pero el codigo de la 1.4 es libre, asi que se podria "portar".

- Dreamcast: Chankast. Muy rapido, practicamente abandonado, desarrollado por conocidos demosceners. Solo para windows :)

- XBox: CXbx. Un hack de las llamadas a las librerias/hard de xbox, para que rulen en windows, debido al parecido de la XBox a un pc. De momento solo furula el Turok y esta abandonado, pero hay source disponible.

- Playstation 2: pcsx2. Promete ser el mejor, no puedo hablar sobre su rendimiento, a pesar que por los shots promete ir lentillo en la generación actual de CPUs. Sera/es una buena plataforma barata para desarrollar.

- GameCube: Dolphin. Muy lento en nuestra generación de CPUs, pero bastante compatible, y muy impresionante como demostración del "se puede hacer". Sin codigo disponible, pero hay otro emulador hecho por los genios Duddie y Tratax, con source disponible, que dara que hablar cuando sea mas compatible, aqui.

- Nintendo DS: Dualis o DeSmuME. No funcionan juegos comerciales, pero son geniales para desarrollar para DS sin tener que comprar una DS o un cartucho grabable. Tambien es interesante el iDeaS, que hace funcionar alguna rom comercial hasta cierto punto.

Y esto es todo, me he dejado la NES pq nunca me ha interesado mucho, pero diria que el JNes es el mejor.

Buff, 2 posts en un dia, de aqui a 3 meses ya volveré a escribir algo...

Port de la mayhem a Windows (2/2)

Sigo... (algo tarde, pero esto NO es un ego-blog)

Viernes, 25 de Noviembre del 2005
-------------------------------------------
Asi pues, con el codigo de las librerias, a pesar que no era del todo compatible, parcheo mi carga de ficheros (sorprendentemente, no me habia equivocado mucho con mi cargador hecho a base de ingenieria inversa).

En las siguientes 12h lo unico que hice es conseguir que todos los efectos funcionaran, ni comí ni bebí nada, solo codee sin parar. Tuve que corregir algunos bugs de coloreado, y, posiblemente lo que me llevo mas tiempo, imaginar como era el codigo de "emulación" de 32bits que usaba la original en segun que partes. Y porque usaba esto? Muy simple, el loader de imagenes, usaba el bitdepth teorico actual, y suponia que el bitdepth de la imagen era igual. Ningun problema para la mayoria de imagenes, pero habia algunas imagenes a 32bits, y claro, ponian un modo de 32bits fake (solo engañando a la estructura de control, imagino), para cargarlas bien. La razón porque estaba diseñado asi, algo "mal", se me escapa, pero lo atribuiré a codigo rapido y pre-deadline. Para corregirlo, estuve probando con diferentes valores en la estructura de control, hasta que di con el correcto.

Y ahora lo interesante: partes en ensamblador puro y codigo automodificable. Como he comentado, habia partes del codigo original de la libreria que no tenia, ya que los Incognita solo tenian la versión de la libreria de windows, que a pesar ser casi 100% compatible con la de MS-DOS, carecia de ciertas definiciones. La que dió algo de trabajo fue la de control del modo grafico, ya que a base de leer los .asm acabé imaginando en que orden y de que tamaño eran todos los valores que se referenciaban tanto en los .asm como en los .cpp. Muchas pruebas despues, di con la estructura correcta, pero costó lo suyo. El otro problema, es que se usaba codigo automodificable, que a pesar que en ms-dos seguro que era util, en windows no queria usarlo, asi que reescribi partes del codigo, mas que nada unos cuantos inner-loops.

Hacia las 9 de la tarde del viernes, tenia todos los efectos corriendo, menos el jarron con bump-mapping del principio, y el karateka tenia el mapeado mal, y petaba a veces. Decidí cerrar el dia, y dejarlo asi de momento.


Domingo, 27 de Noviembre del 2005
-------------------------------------------
Una vez pasado el fin de semana, decidi que ya era hora de terminarlo, asi que me puse a debuggear a piñon los 2 efectos q no iban bien, lease el karateka, y el jarron. Para haceros una idea, el karateka tenia esta pinta:



A pesar que primero pensaba en algun problema unsigned/signed (con la eunectex/anaconda ya habia tenido algun problema parecido), despues de añadir/invertir/etc los valores de mapeado, nada, que petaba de vez en cuando, y se veia fatal.

Al final, vi 2 detalles "idiotas" que se nos escapan a todos despues de releer el mismo codigo mil veces: me habia dejado cierto inner con codigo automodificable (en el jarron), y lo peor, tenia los valores de proporcion X/Y mal, ademas de una colada "menor" en la estructura de control de pantalla. Resumidamente, varios bugs menores, pero, que como siempre, juntos producian que el karateka se viera mal, y el jarron petara con su mejor "Segmentation fault".

Finalizar la prod
-------------------------------
Esto no me acuerdo cuando lo hice, pero bueno, es igual.
Le mandé la prod "terminada" a reboot/incognita y a ent/incognita, y ambos me dijeron que estaba mal el timing. Por lo visto, el player de windows daba valores MUY distintos para el control de que escena se debia ver en cada momento.

Posiblemente esta fue la parte mas pesada de hacer, ya que casi no recordaba la original, y tuve que ver mi versión portada unos cuantos centenares de veces, haciendo el timing que creia era 100% fiel. Para aquellos que hayan tenido que sincronizar una prod asi, entendaran lo desesperante, cansado, y aburrido que es.

Unas horas mas tarde, conseguí corregir el timing de la demo y acelerar la parte final de las particulas: la mandé a los coders originales, y solo ent, me comentó que le gustaria que le pusiera un control de velocidad, para que fuera al mismo framerate que la original (para que fuera mas lenta, vaya). Asi que un vsync que esperaba a la 4a vez que se iba a actualizar el monitor, y le puse un comando de consola para deshabilitar el vsync "bestia", para aquellos con pcs mas viejos, o con ganas de saber como se veria hoy en dia.

Antes de empaquetar, programé un efectillo, le añadi un grafico incrustado al ejecutable, y ya teniamos parte secreta. Despues empaqueté la release, escribí el .nfo, y saque el port, mucho mas contento de poder ver la mayhem cuando me apeteciera! Para terminar este post, un link a una imagen de mi parte preferida:



Solo dejaros con el port ya finalizado: Mayhem win32, y comentar, para los escrupulosos, que los bajos framerates de los shots linkados, son debido a que los hacia con la versión debug, que petaba menos veces en la parte del karateka :)