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:
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:
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 :)
No comments:
Post a Comment