Desarrollando Náyade he prestado mucha antención a los accesos a memoria, para minimizarlos lo máximo posible en operaciones que se repiten mucho, como la colisión de cada disparo con cada enemigo, nave con cada enemigo, etc. Se trata de encontrar un buen balance entre velocidad y espacio: usar funciones con sus parámetros y sus accesos a RAM o si esas funciones son cortas, duplicarlas con los parámetros fijos y convertirlas en macros. Bueno, no descubro nada nuevo.

Pero veo situaciones como al escribir a VRAM en que no se puede asumir que los puertos 98 y 99 sean para todos los MSX, en que se podría consultar el valor, modificar la rutina al inicio y así ya no hay que consultarlo cada vez. Y a partir de aquí se me ocurren un montón de "bizarradas" para rascar algún acceso a memoria.

Mi pregunta es: ¿Es una práctica habitual? Konami por ejemplo, ¿lo solía hacer? A cada uno nos atrae un motivo para programar para MSX. A mi me hace gracia hacerlo dentro de las limitaciones/costumbres de la época (con todas las comillas que queráis, porque ahora tengo emulador, debugger, etc).

Es obvio que debería copiar a RAM la rutina.

Pues eso, ¿es una prática habitual? ¿Lo usáis los developers? ¿Se usaba?

Edición: Sí, he quitado el offtopic 

Ok, así lo hago. Respecto al diseño, pues seguro que es mejorable. Pero me refiero a que si con "el diseño perfecto" muevo n elementos en pantalla, y haciendo tres apaños así consigo mover n+x elementos, pues mejor, independientemente del diseño 

Pero no me he puesto a medir exactamente el tiempo que ocupo entre interrupciones y el que me queda libre (porque no se hacerlo con exactitud básicamente). Entonces no se si estos apaños tampoco darían para mucho. Por eso preguntaba si es una práctica habitual, en cuyo caso supongo que sí se gana, o no lo es tanto por lo que creo entender.

Como te dice Mortimer, es poca cosa, asi que X quiza sea = 1, como mucho. Dependerá del caso. Para eso, generalmente, no hace falta molestarse. Ahora si, como también te dice, ya lo tienes en RAM y no te supone molestia ponerlo asi, pues tampoco pierdes nada. Y, vaya, de nuevo según el caso, si por meter 1 elemento más el juego (o lo que sea) va a ganar bastante, o te es crucial, adelante. Como he dicho, no pierdes nada tampoco, si acaso un poco de RAM, pero si te es asumible esa pequeña pérdida, pues bien. Cada caso es diferente, no hay que hacerlo así o asá siempre, unas veces te convendrá una cosa y otras lo contrario. Y, como ambas formas son correctas, no es problema el pasar de una otra.

Lo de las lineas del borde va realmente bien y es muy visual, así no tienes que ir contando ciclos. Y además, que queda bonito
Eso sí, procura siempre probarlo en 60hz. Si te va bien así en 50hz no tendrás problemas. Pero si te va bien a 50hz, a menos que ya veas que tienes mucho margen, luego a 60hz puede haber sorpresa. Imagino que no te digo nada que no sepas, pero por si acaso.

Gracias por las respuestas. Veo que la ganancia no es muy significativa entonces.


Me parece superinteresante. Es algo que había oído pero no me había puesto. Así que he hecho unas pruebas y veo que el tiempo que me ocupa una rutina parece fijo porque el rectángulo que se dibuja en pantalla es siempre del mismo tamaño. Pero noto que a veces me sale más arriba y a veces más abajo... Todo esto en un emulador.

Hago:



En el VBLANK el VDP va dibujando el fondo. Entonces en el momento que le digo que cambie el fondo, ¿lo sirve al momento? Porque entonces no entiendo bien porqué no me sale siempre el rectángulo en la misma posición. Sí que sale siempre en la misma zona (inferior o superior según las pruebas) pero no siempre exactamente en la misma línea.   (Todo esto partiendo de que he comentado casi todo el código y lo que calculo a cada pasada en teoría es siempre lo mismo.)

Edito: Perdón, perdón, como lo estaba probando sin sonido tenía el pequeño detalle que estaba el player funcionando de fondo 

Sale perfecto, igual tamaño y mismo posición. Genial.

¿Podrías mandar un par de pantallazos?

De todas formas es normal que no aparezca exactamente en el mismo punto. Supongo que estás enganchado a la interrupción con el BIOS, y esta hace varias cosas antes de pasarle el control a tu rutina, como explorar el teclado. Y alguna debe ser de tardar más o menos cada vez.

Además creo recordar que incluso poniendo directamente tu propio gestor de interrupciones sin BIOS, el punto de comienzo también baila un poco, imagino que porque el VDP tendrá algún margen y/o el Z80 según el ciclo máquina en el que le llegue la INT tarda más o menos en responder...

Okk. Lo que sí veo es que siempre ocupa el mismo ancho, que sí que es de esperar. Gracias.