Página 2 de 4
Re: Experimentos pintado de sprites en ensamblador
Publicado: Sab, 07 Dic 2013, 17:52
por antoniovillena
Bueno ya he terminado la demo de 48k, al final se ha quedado en 13 sprites, 12 enemigos que rebotan y el protagonista que se mueve con las teclas OPSA (sí, he cambiado la Q por la S para simplificar el código, disculpen el inconveniente).
Me pondré con la versión 128K, en la que podré mover más sprites simultáneamente y tener una ventana mayor, concretamente voy a usar la misma que la churrera (15x10 tiles).
Estos motores de tiles/sprites en principio no tienen ningún objetivo, sólo es por experimentar. Pero no me importaría colaborar con D_Skywalk con el objetivo de ir completando el engine de 128K con rutinas de la Churrera, y así superar los 48 tiles de límite que tiene la Churrera actualmente.
Re: Experimentos pintado de sprites en ensamblador
Publicado: Dom, 15 Dic 2013, 13:53
por antoniovillena
He actualizado la demo en el hilo de WOS. Ahora el engina borra individualmente los sprites, hay un límite de 8 sprites a la vez y sobra la mayor parte del tiempo de frame para hacer otras cosas.
http://www.worldofspectrum.org/forums/s ... post740885
Re: Experimentos pintado de sprites en ensamblador
Publicado: Dom, 15 Dic 2013, 18:31
por radastan
De tus experimentos preveo el nacimiento de una nueva biblioteca de sprites que nos va a dar muchas alegrías.
Re: Experimentos pintado de sprites en ensamblador
Publicado: Dom, 15 Dic 2013, 22:47
por D_Skywalk
A mi lo que mas me mola de todo esto es quitarme el z88dk de encima XDD
Re: Experimentos pintado de sprites en ensamblador
Publicado: Dom, 15 Dic 2013, 23:44
por radastan
Ni que Z88DK fuese una castaña pilonga, con un poco de ayuda es más sencillo que el BASIC. Y si tienes una buena biblioteca escrita en ensamblador detrás tienes la potencia del ensamblador y la sencillez del C.
Re: Experimentos pintado de sprites en ensamblador
Publicado: Lun, 16 Dic 2013, 09:58
por D_Skywalk
No lo digo por escribir en C, lo digo por el compilador, mucho mejor si usáramos sdcc.
Re: Experimentos pintado de sprites en ensamblador
Publicado: Lun, 16 Dic 2013, 11:06
por radastan
$this->bbcode_second_pass_quote('D_Skywalk', 'N')o lo digo por escribir en C, lo digo por el compilador, mucho mejor si usáramos sdcc.
Pues no. SDCC limita las rutinas en ensamblador bastante más que el Z88DK, fíjate que mis rutinas o las de A. Villena ya no sabría decirte si funcionan tal cual, ya que en SDCC habría que realizar push/pop de algunos registros antes de empezar.
SDCC es más eficiente en la compilación, pero ya se ha demostrado que no es del todo así. Todo fue a raíz de una comparativa en una página de CPC, que luego se ha visto que sucedía por ciertas condiciones. Al final el código es casi igual de eficiente en la mayoría de los casos, vamos que no es la panacea que parecía.
Es más, Z88DK está empezando a fusionarse con el proyecto SDCC y los compiladores cada vez se parecen más, por lo que realmente no vas a notar diferencia en poco tiempo.
Re: Experimentos pintado de sprites en ensamblador
Publicado: Lun, 16 Dic 2013, 11:54
por D_Skywalk
dices que sdcc no tiene fastcall?
Yo es que después de las coñas que tenía con ++i, i+=1, i++, ... le había puesto el sanbenito XD
Pero si dices que no están tan alejados, te creo compa :_)
Re: Experimentos pintado de sprites en ensamblador
Publicado: Lun, 16 Dic 2013, 12:05
por radastan
Tengo entendido que hay un par de registros de la CPU reservados en SDCC, y que las comparativas que hay por ahí entre ambos compiladores no son tan certeras como parece (sobre todo con las últimas versiones de Z88DK).
Re: Experimentos pintado de sprites en ensamblador
Publicado: Lun, 16 Dic 2013, 12:42
por na_th_an
Antes que anda hay que decir que z88dk en sí no es un compilador. El compilador en el que se basa por defecto es ZCC. En las últimas betas de z88dk puedes, si quieres, generar código con SDCC.
Cada uno tendrá sus fuertes. Según los super tacañones del C para 8 bits, y siempre según lo que se explicó en una extensísima discusión en WOS llena de tochoposts, por lo visto esa aparente mejor generación de código lo era únicamente con los ejemplos cortos, pero en un programa largo no sería tal. Por lo visto SDCC genera mejor código inline, pero ZCC aprovecha mejor las llamadas a subrutinas, así que depende bastante de cómo sea tu programa y de la longitud del mismo. Aparte de lo que dice radas, ZCC tiene mejor soporte para bibliotecas (un enlazador en condiciones) y no hay restricción sobre el uso de registros y otras paranoias.