Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
 

Autor Hilo: ZX Frogger (Leído 78700 veces)

Ivanzx

  • T-7T
  • Mensajes: 480
    • El rincon del Spectrum
Buenas Bubu! Me gustaria ayudarte tambien, pero de programacion cero patatero :fuuu:

Quizas puedas preguntar a alguno de los gurus (computer emuzone, mojon twins...)

Un saludo!

Bubu

  • T-600
  • Mensajes: 2 598
Pues calculemos esto de los ciclos: resulta que mi rutina tiene una copia de los gráficos en memoria. Así que el número de instrucciones de desplazamiento es:

32 caracteres * 2 filas de caracteres * 8 scanlines cada caracter * 256 píxeles de extremo a extremo = 131.072 instrucciones RR(HL)

Entonces, 25 millones / 131.072 = 190

Por tanto cada píxel desplazado cuesta 190 ciclos (cálculos y otras cosas). No lo veo descabellao.
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

Bubu

  • T-600
  • Mensajes: 2 598
Quizás lo que tenga que hacer es ejecutar los RR(HL) directamente sobre la VRAM, pero recuerdo cuando era chico y pogramaba en C/M que leía siempre que era mejor no escribir direstamente sobre la VRAM puesto que si se hacía seguramente parpadearían los gráficos...
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

mentalthink

  • T-500
  • Mensajes: 870
Está super chulo, la ultima imagen es realmente guapa guapa, mas que recordarme al spectrum me ha venido de golpe la nostangia... y a la mente me ha venido una máquina de aquellas \"chungueras\", del joystick con la pelota Roja, usease de las que valian 5 ptas... que creo que he jugado alguna por 5 pelas...

doragasu

  • T-600
  • Mensajes: 2 314
  • Si no está roto, ¡yo lo arreglo!
    • Kernel Hacks
190 ciclos por pixel me parece una pasada (teniendo en cuenta sobretodo que escribes en ASM). No tengo ni idea del número de ciclos por instrucción del Z80, pero suponiendo una media de 4 ciclos por instrucción, son 45 instrucciones para desplazar un pixel... como digo, me parece una pasada.

Cita de: \"Bubu\" post=20093
Quizás lo que tenga que hacer es ejecutar los RR(HL) directamente sobre la VRAM, pero recuerdo cuando era chico y pogramaba en C/M que leía siempre que era mejor no escribir direstamente sobre la VRAM puesto que si se hacía seguramente parpadearían los gráficos...


En máquinas con más memoria y potencia, en efecto es mejor usar una técnica de doble (o triple) buffer, pero visto lo visto, y suponiendo que la lectura/escritura en VRAM es igual de rápida al menos que en RAM normal, creo que tu mejor opción es escribir directamente sobre esta memoria.

Bubu

  • T-600
  • Mensajes: 2 598
OK, doragasu, cataré a escribir direstamente en la VRAM, a ver qué pasa. La teoría dice que irá el doble de rápido, uséase, que el cocodrilo tardará unos 4 segundos en recorrerse el río, jiji.

¡Hey, Ivanzx! De momento me gustaría no molestar en otros foros, y además esto es una especie de reto, jiji. Ya cuando me quede sin absoluta idea pediré socorro al mundo :-) Gracias por el consejo.

mentalthink, ¿te refieres a las máquinas en blanco y negro pero con un papel de celofán de color pa que pareciera que la máquina era a color? A esas he jugado yo. Pero ¿qué edad tiés tú? Yo tengo ya 40 tacos.
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

doragasu

  • T-600
  • Mensajes: 2 314
  • Si no está roto, ¡yo lo arreglo!
    • Kernel Hacks
Acabo de echar un vistazo rápido al set de instrucciones del Z80, y el RR[HL] se come la friolera de 15 ciclos, con lo que serían 12 instrucciones de este tipo por píxel. La verdad que no sabía que el Z80 fuera tan lento. El 6502 que llevaban las NES y el C64 si no recuerdo mal tenía una media de 2 ciclos por instrucción.

En cualquier caso, 12 instrucciones para desplazar un píxel siguen siendo unas cuantas...

Bubu

  • T-600
  • Mensajes: 2 598
Bueno, he descubierto el error. Aunque no es un error de programación. Es un error en los cálculos que hice del tiempo y eso. Resulta que 7 segundos no es lo que tarda en mover toda una fila, sino en ¡¡mover las 5 filas!! Lo que pasa es que para las otras 4 no le había asignado aún los gráficos, y estaba desplazando ceros todo el rato, jiji.

Ahora sí, ya tengo todo el río desplazándose, y lo más rápido que puedo hacer es que un objeto atraviese en 7 segundos la pantalla horizontalmente. Voy a ver en el Frogger original esto cómo va, jiji.

A ver si puedo colgar en el YT un vidrio del Frogger tal y como lo llevo para que veais el tema del río ;.)


Salu2
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

doragasu

  • T-600
  • Mensajes: 2 314
  • Si no está roto, ¡yo lo arreglo!
    • Kernel Hacks
¡Eso ya es otra cosa!

Sigue siendo lento, pero después de echar los cálculos, ya parece bastante más razonable (sale a unas 2 instrucciones por pixel).

Por cierto que no se si lo habrás hecho ya, pero tal vez te convendría echar un vistazo a los ciclos de CPU de cada instrucción, y darle una pensada a ver si hay algún modo de hacer las rotaciones más rápidas que con el RR(HL), aunque sea usando más instrucciones. Mientras un RR(HL) se come 15 ciclos de reloj, un RRA o RRCA se come sólo 4 (aunque evidentemente habrá que meter algún LD por ahí que sume ciclos).

Si pones el código de la parte que hace el desplazamiento, tal vez pueda echarle un vistazo, a ver si se me ocurre algo. Especular sin ver el código es complicado...

EDITO: Acabo de caer en la cuenta de que cada desplazamiento RR(HL) no desplaza 1 pixel, sino 8, con lo que... ¡me sigue pareciendo demasiado lento!. Además acabo de echar un vistazo a tu cálculo de ciclos y hay un factor 256 no entiendo de dónde sale. Tu fórmula es:

32 caracteres * 2 filas de caracteres * 8 scanlines cada caracter * 256

Pero el factor 256 si no he entendido mal, ya lo estás metiendo implícitamente con el \"32 caracteres * 8 scanlines cada caracter\", con lo que para mí la fórmula del número de píxels a desplazar para una fila sería simplemente:

32 caracteres * 2 filas de caracteres * 8 scanlines cada caracter = 512 píxels

Si además tenemos en cuenta que cada RR(HL) desplaza no 1 sino 8 píxels, el número de desplazamientos para una fila sería:
32 caracteres * 2 filas de caracteres * 8 scanlines cada caracter / 8 pixels por desplazamiento = 64 instrucciones

¡De 64 a 131072 hay una diferencia un pelín abultada!, así que viendo que tus cálculos más o menos cuadran (a diferencia de los míos), sospecho que me he debido equivocar en algún lado.

mentalthink

  • T-500
  • Mensajes: 870
@Bubu, no me refiero , vamos creo recordar que el algun chiringuito, o en la iglesia de mi barrio, que el curilla era muy espabilao, tenia un Pinball y una maquinilla, y las ponia a 5 ptas, para que nos dejaramos los gardufos... fijate si era listo el tio que se montaba un cine el fin de semana con 4 sillas y te cobraba 100 pelas... eso sí, eran las peliculas que acaban de salir en el Videoclub... jaja , lo tenian que haber trincao ahora los de la Sgae... joder , si es que hacerse cura o politico al final es lo mejor...

Pues eso, hombre yo tengo tambien mis tacos, unos pocos menos que tú, pero que andamos por la misma cuerda...

Por cierto aunque no tengo ni idea de lo que comentáis arriba de los ciclos de Reloj, como sabéis ese dato... que lo ponen en los Datasheets de los micros... y por lo tanto ni gastan el mismo numero de ciclos dependiendo de la instrucción, no?¿... Una cosilla, si se sabe programar en ASM un CPC, es relativamente sencillo hacerlo con un Spectrum o MSX... los 3 llevan un Z80, pero lo poco que he tocado de ASM con el CPC y se pueden hacer llamadas al Firmware y tal... cambia mucho de un sistema a otro?¿...

Bubu

  • T-600
  • Mensajes: 2 598
doragasu, yohe calculado así el número de RR(HL) que hacen falta:

- Hay 2 filas que mover
- Cada fila son 32 caracteres
- Cada carácter son 8 scanlines

Bien, con esto tendríamos 2 * 32 * 8 = 512 instrucciones RR(HL)

Y con esto lo que hemos conseguido es desplazar 1 PIXEL nada más, que es lo que hace las instrucción RR(HL). Lo que hace es el bit 0 lo pasa al flag carry, el bit 1 lo pasa al 0, el 2 al 1, el 3 al 2... el 7 al 6, y en el 7 mete el flag carry anterior.

Ahora bien, estoy contando el número de instrucciones necesarias para que el cocodrilo atraviese a lo ancho la pantalla, es decir, que se desplace 256 píxeles, por lo que ese es el factor que no ves. Hay que multiplicar 512 * 256 y sale un total de 131.072 instrucciones RR(HL)

La verdad es que es un tema megafriky éste, pero meeencaaannntaaaa ;-)
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

doragasu

  • T-600
  • Mensajes: 2 314
  • Si no está roto, ¡yo lo arreglo!
    • Kernel Hacks
Ah, OK, te había entendido mal, pensaba que te referías a que tardaba 7 segundos en desplazar al cocodrilo 1 pixel, no toda la pantalla entera.

Lo que sospecho que se tiene que poder hacer es que cada RR desplace 8 píxels, pero como no se cómo se organiza la memoria del Spectrum, no me voy a atrever a afirmarlo.

Bubu

  • T-600
  • Mensajes: 2 598
jJJAJAjAjAA, mentalthink, me voy a tener que meter a religioso a estas alturas :-D

Respecto a la similitud entre ordenadores con el Z80, no tienen nada que ver entre sí. Lo único que hace el Z80 es hacer operaciones aritméticas (sumar, restar) y escribir y leer de la memoria. Eso sí es común en todos los ordenadores con Z80. La diferencia, y gorda, viene en los chips de apoyo a la CPU. En Spectrum la ULA se encarga de dibujar la pantalla, emitir el sonido, leer el teclado, etc. Y el Spectrum NO TIENE GESTIÓN DE SPRITES. Hay que fabricárselos manualmente.

Tú en un Commodore 64 p.ej. metes en memoria un dibujo de 16x16 píxeles, y con una única instrucción le dices al ordenador que mueva ese sprite. Pero en Spectrum hay que fabricarse los desplazamientos píxel a píxel, y esto sin hablar del problema del color...
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

Bubu

  • T-600
  • Mensajes: 2 598
Es así, doragasu, un único RR desplaza 1 píxel los 8 píxeles de un byte. JAjajaja, suena a trabalenguas, pero es así. Imagínate eso en pantalla:

11110000 - 11001100

pues bien, si aplicas un RR a cada byte (es decir, dos RR\'s):

01111000 - 01100110



De todas formas sé que estoy desperdiciando RR\'s porque desplazo toooda la fila, haya o no sprites ahí. Si sólo desplazara las zonas donde hay cocodrilos, troncos, etc, quizás se acelerara la cosa, pero la gestión de eso sería muy compleja y al final el tiempo se lo llevaría la gestión en sí.
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

doragasu

  • T-600
  • Mensajes: 2 314
  • Si no está roto, ¡yo lo arreglo!
    • Kernel Hacks
Ah, entendido ;). Si en el fondo estamos de acuerdo, pero yo llamo a las cosas a mi manera, y así me va. De acuerdo también en tus cálculos para mover un cocodrilo por toda la pantalla: 2*32*8*256 rotaciones.

Si implementas el desplazamiento sobre la memoria de video, ya nos contarás qué tal va. Puede que no vaya mucho mejor, por el tema de que la ULA puede meter esperas, pero aún así supongo que algo ma? rápido irá.