Página 5 de 6

Re: Pintando sprites de 16x16 en ensamblador

Publicado: Mar, 10 Dic 2013, 10:29
por na_th_an
$this->bbcode_second_pass_quote('radastan', 'E')s que mi idea es muy sencilla: un par de funciones para recoger y restaurar el fondo. Es decir, algo en plan:

get_background_x16 (x,y,puntero);
put_background_x16 (x,y,puntero);

Sólo tienes que definir un espacio de memoria para cada sprite que quieras mover, donde se almacenará el fondo, y usar esas dos funciones entre la que imprime el sprite. Tendré que hacer subversiones para cada tamaño, al igual que las rutinas de sprites, pero es que la librería va a ocupar una "mierda" en tamaño gracias a que es en ensamblador y no hay dependencias.


Esta era la idea inicial, por ejemplo, en Subacolib (la que lleva el Maritrini tipo Saimazoom), pero no funciona. Hacer todo el proceso de almacenado y restaurado de fondo desde el lenguaje "host" (C o Basic, me refiero) es mucho más costoso computacionalmente y apenas te da tiempo de gestionar un sprite antes de que se te acabe el tiempo de borde (que es el que tienes para que no haya parpadeos sin tener que hacer cosas raras). Por eso tuve que añadir el gestionado automático de sprites a la biblioteca, porque si no, no había forma de hacer un juego en condiciones.

Re: Pintando sprites de 16x16 en ensamblador

Publicado: Mar, 10 Dic 2013, 10:33
por radastan
Pues tengo que intentarlo, es más, en las interrupciones está la clave. No me importa alguna cosas rara en pantalla en movimiento, lo que me importa ahora mismo es poder mover cosas de forma muy simple.

Re: Pintando sprites de 16x16 en ensamblador

Publicado: Mar, 10 Dic 2013, 23:19
por radastan
$this->bbcode_second_pass_quote('antoniovillena', '
')Por cierto hay instrucciones en el código que no hacen nada, te las marco con asterisco.


He tenido que volver a meter esas instrucciones porque cuando un sprite se imprime en dos tercios de la pantalla (es decir si cada línea está en un tercio) pasan cosas divertidas. Pero es que aún así siguen pasando más cosas.

Os dejo un ejemplo.

Re: Pintando sprites de 16x16 en ensamblador

Publicado: Mar, 10 Dic 2013, 23:21
por radastan
Ahora os dejo el ejemplo añadiendo las instrucciones que parecían que sobraban, además de todo el paquete para compilar y ver el código fuente.

Notad que se arregla parte del problema, pero no todo.

PD: Vaya pedazo de mierda el Z88DK, no optimiza el código NADA. Si no usas una función la deja ahí.

Re: Pintando sprites de 16x16 en ensamblador

Publicado: Mié, 11 Dic 2013, 09:01
por D_Skywalk
Hace un par de flickeos, pero mola, que cantidad de bichos! XD
¿si ya has salido del splib por que no usas sdcc?

Motor.h deberías compilarlo como librería si quieres que no incluya las funciones sin usar...

Un Saludo tiu :D

Re: Pintando sprites de 16x16 en ensamblador

Publicado: Mié, 11 Dic 2013, 09:09
por na_th_an
Eso es. No es que z88dk sea una mierda, es que C no funciona así.

Re: Pintando sprites de 16x16 en ensamblador

Publicado: Mié, 11 Dic 2013, 09:47
por radastan
$this->bbcode_second_pass_quote('na_th_an', 'E')so es. No es que z88dk sea una mierda, es que C no funciona así.


Ilústreme, su ilustrísima. :mrgreen:

Fuera coñas, dime como convierto esto en una librería para que no incluya aquello que no uses.

Ya que estoy haciendo un tutorial, que sea completito.

Re: Pintando sprites de 16x16 en ensamblador

Publicado: Mié, 11 Dic 2013, 10:06
por na_th_an
El que se encarga de ver qué código tiene que incluir es el linker. Normalmente hace una lista de las funciones que necesitas de las bibliotecas estáticas (.lib) e incluye el código objeto (.o) de las funciones que necesites. En un archivo de biblioteca estática (.lib) van un montón de códigos objeto (.o). Cada uno se genera a partir de un fuente C o ASM con varias funciones y estructuras locales, normalmente relacionadas e indivisibles, por eso se suele añadir una función principal y funciones auxiliares necesitadas por esta en cada archivo fuente. Por eso el enlazador incluye un .o COMPLETO si se necesita algo de dentro de él: simplemente porque se entiende que el programador ha incluido dentro del .o sólo lo necesario.

En realidad nosotros lo hacemos mal. Meter código ejecutable en un .h e incluirlo a pelo en el .c es una burrada gordihima. Supuestamente en los .h sólo debería haber declaraciones. El código debería ir en archivos .c que se compilasen en .o y luego se linkasen todos juntos. Idealmente, el código incluido en cada archivo .c debería ser indivisible y autocontenido, de forma que el enlazador pudiese descartar un archivo objeto completo si no se utiliza nada de él.

En nuestro caso sólo tenemos un archivo C que incluye mucho código, y que genera un único archivo .o. El enlazador no tiene que hacer nada, sólo coge ese archivo objeto para crear el binario. No es su trabajo meterse dentro del archivo .o para optimizarlo y eliminar cosas que no se utilicen. Ni en z88dk ni en ningún compilador de ningún lenguaje.

Re: Pintando sprites de 16x16 en ensamblador

Publicado: Mié, 11 Dic 2013, 10:11
por na_th_an
Si quieres beneficiarte de esto, lo suyo es que hicieses un archivo de fuente con cada función y sus auxiliares, compilases todo a .o y luego lo empaquetases en una biblioteca .lib, con todas las declaraciones de funciones en su correspondiente archivo .h. z88dk te permite hacer esto, aunque no te puedo ayudar porque nunca lo he hecho. Sin embargo, si te bajas el paquete de fuentes de splib2 y miras make.bat verás como se hace. Splib2 son un montón de funciones, cada una en su archivo .asm o .c, que son ensambladas/compiladas y luego empaquetadas juntas en una biblioteca.

Haciéndolo así, tendrías tu .lib gordote, pero el linker sólo incluiría las funciones que se utilizan desde el juego, y no toda la biblioteca.

Re: Pintando sprites de 16x16 en ensamblador

Publicado: Mié, 11 Dic 2013, 11:38
por radastan
¡Grrrrrrrrr! :evil:

Sigo peleándome con la rutina, y creo que ya se cual es el problema... está mal de base.

No se puede sumar 32 y ya está para pasar a la siguiente línea. Eso sirve si estás trabajando dentro del mismo tercio, pero si la siguiente línea no está allí se te monta todo en el mismo tercio (que es lo que pasa). Es decir, hay que recalcular por cada línea la dirección de pantalla, sin trucos.

Vuelta a empezar. :cheer: