Gandulf escribió:Bufff, eso es rapidísimo, pero la memoria que ocupa lo hace un poco inviable. Yo programo para 48K siempre (almenos de momento seguiré así) y si usara pre-rotados no me cabrían los sprites en el spectrum. Pero si lo tienes que aplicar a un par de sprites o a unos cuantos y tienes memoria para ello, pues sí, es la opción.
Claro. El problema es que incluso con 128K voy apuradísimo de memoria (ahora mismo no me caben, he tenido que hacer algunas perrerías que no me gustan nada), por eso estoy pensando en adoptar alguna técnica alternativa.
Cuando me dices eso de enchufar un raster me dejas como el del chiste del taller de coches al que le dicen que le han cambiado la "junta de trócolo". Me imagino la funcionalidad de lo que comentas, pero es una aplicación?. ¿un aparato? ?¿
Es una forma rápida de "ver" cuánto tarda en ejecutarse una rutina. Pones un color en el borde en la entrada y otro color diferente a la salida. Al ejecutar la franja resultante te dice el número de líneas que ha consumido, con lo que dividiendo se obtienen los t-states aproximados. Seguramente tiene otros nombres, pero yo siempre le he llamado medir con rasters. Lo utilizo constantemente con todas las rutinas importantes.. así sé cuánto margen tengo antes de pasarme de frame y dónde es prioritario optimizar.
De todas formas te puedo decir exactamente los t-states que consume la impresión de un sprite del tamaño que me dijiste, sin el raster., luego te lo miro
Ok, perfecto. No olvides medirlo con el tamaño máximo (no alineado) y si utiliza máscaras, fondos y esas cosas, dímelo también. Gracias.
J
) pues la gente hacía lo que se lo ocurría así de primeras.
¡¡¡ A ni MÉN !!!
, vaya tela. Aquello sí que tenía tela, que había que recompilar en kernel cada vez que modificabas algo, y tardaba 8 horas en recompilarse, por el reloj, era acojonante aquella filosofía del "pasa de tecnología microsoft" 