Página 2 de 2

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Mie Abr 30, 2014 2:28 pm
por wilco2009
Por supuesto es evidente que no es lo mismo que tener 512Kb de forma simultánea. Pero con una ordenación adecuada puede accederse de una forma relativamente rápida al valor deseado simplemente con un out y un acceso a memoria. Entiendo que eso tiene que ser más rápido, a la fuerza, que un cálculo trigonométrico.

De todas formas era solo una posible idea de zup que no me parece tan descabellada.

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Mie Abr 30, 2014 6:34 pm
por zup
Respondo por partes:

Parte 1: Troceado inteligente.
En ningún momento se me ha ocurrido que debas cargar por pantalla, sino por niveles. Un nivel puede estar compuesto de un montón de pantallas, y pasar al siguiente solo después de haber completado las tareas. Si piensas en juegos como Freddy Hardest, los mapeados no eran pequeños y cabían en 48k.

Si le aplicas los 128k a Freddy Hardest, puedes meterle más enemigos (aparte de los 3 o 4 que tenía), más tiles, música y quizás alguna animación extra... y te seguirán sobrando bastante memoria.

Parte 2: Animaladas en 512k.
Lo de las tablas lookup son una serie de burradas que se me han ocurrido. Las tablas tendrían como mucho un límite de 16k (eso en un 128k normal, no sé como va la paginación de un clón ruso), pero eso da para tener muchas cosas precalculadas. ¿Que hacer un OUT, consultar y hacer otro OUT lleva tiempo? Seguro, pero me da en la nariz que lleva menos tiempo que intentar hacer el cálculo a mano.

Otra animalada con ejemplo práctico: tener objetos precalculados. Cojamos el ejemplo de Top Gun (vale, no era un gran juego) que lo único que puedes tener en el cielo es otro F14 (con mucha imaginación, eso sí). Con esa cantidad de memoria podrías tener ya precalculados los vectores del avión apuntando en diferentes direcciones; luego solo tendrías que calcular a dónde apunta el otro avión y coger los vectores ya precalculados. A cambio de unos pocos OUT, ahorras unas cuantas multiplicaciones (aunque no todas).

O, yendo algo más lejos... ¿qué tal si se sustituyen directamente esos vectores precalculados por sprites? No estoy seguro de si Wing Commander lo hacía así. Das mejor aspecto al juego con esa memoria extra, a un coste (relativamente) bajo.

Parte 3: El lado oscuro.
Y, lo más importante de todo (no sé si lo he mencionado), ¿realmente se necesitan esos 512k? Una preocupación sería caer en usarlos porque si, sin justificación. Para explicarme un poco mejor: pensad en la mayoría (ojo, no todos) de juegos de MegaCD o los primeros CDs de PC. Muchas veces el juego en sí podría caber en pocos diskettes, pero se le añadían intros y secuencias FMV (a veces, de baja calidad) que parecía que estaban ahí simplemente para llenar el CD.

¿Habrá quién caiga al lado oscuro y meterá cosas solamente porque se puede? Acordaos que un juego no es mejor por ser más largo.

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Mie Abr 30, 2014 8:07 pm
por wilco2009
zup escribió:Respondo por partes:

Parte 1: Troceado inteligente.
En ningún momento se me ha ocurrido que debas cargar por pantalla, sino por niveles. Un nivel puede estar compuesto de un montón de pantallas, y pasar al siguiente solo después de haber completado las tareas. Si piensas en juegos como Freddy Hardest, los mapeados no eran pequeños y cabían en 48k.

Si le aplicas los 128k a Freddy Hardest, puedes meterle más enemigos (aparte de los 3 o 4 que tenía), más tiles, música y quizás alguna animación extra... y te seguirán sobrando bastante memoria.


Te había entendido perfectamente, solo decía que de esta manera se pueden hacer niveles más grandes, o incluso un solo escenario enorme para varios niveles. La utilidad de esto puede ser discutible lo sé, pero es una opción para el programador.

zup escribió:Parte 2: Animaladas en 512k.
Lo de las tablas lookup son una serie de burradas que se me han ocurrido. Las tablas tendrían como mucho un límite de 16k (eso en un 128k normal, no sé como va la paginación de un clón ruso), pero eso da para tener muchas cosas precalculadas. ¿Que hacer un OUT, consultar y hacer otro OUT lleva tiempo? Seguro, pero me da en la nariz que lleva menos tiempo que intentar hacer el cálculo a mano.

Otra animalada con ejemplo práctico: tener objetos precalculados. Cojamos el ejemplo de Top Gun (vale, no era un gran juego) que lo único que puedes tener en el cielo es otro F14 (con mucha imaginación, eso sí). Con esa cantidad de memoria podrías tener ya precalculados los vectores del avión apuntando en diferentes direcciones; luego solo tendrías que calcular a dónde apunta el otro avión y coger los vectores ya precalculados. A cambio de unos pocos OUT, ahorras unas cuantas multiplicaciones (aunque no todas).

O, yendo algo más lejos... ¿qué tal si se sustituyen directamente esos vectores precalculados por sprites? No estoy seguro de si Wing Commander lo hacía así. Das mejor aspecto al juego con esa memoria extra, a un coste (relativamente) bajo.


Estamos de acuerdo entonces en que esto es una utilidad, ¿no?

zup escribió:Parte 3: El lado oscuro.
Y, lo más importante de todo (no sé si lo he mencionado), ¿realmente se necesitan esos 512k? Una preocupación sería caer en usarlos porque si, sin justificación. Para explicarme un poco mejor: pensad en la mayoría (ojo, no todos) de juegos de MegaCD o los primeros CDs de PC. Muchas veces el juego en sí podría caber en pocos diskettes, pero se le añadían intros y secuencias FMV (a veces, de baja calidad) que parecía que estaban ahí simplemente para llenar el CD.

¿Habrá quién caiga al lado oscuro y meterá cosas solamente porque se puede? Acordaos que un juego no es mejor por ser más largo.


En eso estoy de acuerdo, puedes caer en el lado oscuro como se cayó cuando apareció el PC, pero a cambio se consiguieron cosas que de otra manera hubieran sido imposibles.
Se podrían incluir distintos escenarios digitalizados como fondo de la pantalla de algunos juegos agilizando el cambio entre pantallas. Quizás esto no parece muy apropiado para un Spectrum, pero quizás no se ha planteado nunca simplemente por falta de memoria.
Si tuvieras que cargarlos de disco el lag entre pantallas sería mayor.
Estoy de acuerdo en que esto es caer en cierta manera en el lado oscuro, pero porqué tenemos que flagelarnos nosotros mismos y prohibirnos hacer cosas que podemos hacer.
Son solo ideas, pero seguro que a la gente se le ocurren otras cosas con el uso.

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Jue May 01, 2014 11:31 am
por zup
Bueno, yo no he dicho que no pueda tener utilidad. Mi planteamiento es que casi todo puede hacerse con 128k y que hay que ser un poco rebuscado para necesitar los 512k.

En cuanto a lo de llenar por llenar... ¿cuántas pantallas de arkanoid se podrían meter en 512k?

En tiempos de los 486 también hubo juegos de CD muy buenos que por sí solos justificaban comprar una unidad. El problema es que como el CD era lo más de lo más, también hubo editores que los usaron porque si. Como ejemplos de uso de tecnología porque si, tendríamos Rise of the Robots... que usó gráficos 3D (¿pre-renderizados?) porque eran lo último y era injugable. ¿Habrá gente que use esos 512k solo porque están ahí aunque pudieran usar solo 128k? Aunque siempre existe la tentación de hacer las cosas de una manera simplemente porque se puede...

La otra cosa que me asusta es tener que cargar 512k desde cinta...

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Jue May 01, 2014 2:31 pm
por wilco2009
Si, por supuesto eso puede ser intratable. La idea sería utilizar un dispositivo de almacenamiento masivo como el interface IDE o el divIDE.

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Jue May 01, 2014 10:31 pm
por mcleod_ideafix
Una cosa para la que podrían venir muy bien los 512KB es para crear sprites compilados. Es decir, usar la técnica en la que los sprites no se pintan en pantalla, sino que el "pintor" de sprites lo que hace es generar código en cierta parte de la memoria, que a su vez se encarga de escribir en la pantalla en las posiciones ya calculadas, para pintar los sprites. La tarea de pintar sprites consiste unicamente en llamar a la rutina creada (compilada) por este sistema. Con varias páginas puedes generar código compilado de hasta 16KB, suficiente para pintar unos cuantos sprites :)

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Jue May 01, 2014 11:04 pm
por antoniovillena
¿Te refieres a sprites prerrotados? Vamos lo que usa el juego "Cobra"

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Jue May 01, 2014 11:46 pm
por wilco2009
Mmm, eso sería una buena idea como aplicación.

Además de la inmediata de tener más de todo (tiles, sprites, musica, animaciones), ya tenemos dos posibles aplicaciones de esa memoria extra:

- Tablas lookup para acelerar, por ejemplo, graficos 3D.
- Sprites compilados.

Van saliendo cosillas......

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Vie May 02, 2014 2:51 pm
por mcleod_ideafix
antoniovillena escribió:¿Te refieres a sprites prerrotados? Vamos lo que usa el juego "Cobra"

No, no. Sprites compilados. La idea es la siguiente: tus rutinas de sprites parten de unas coordenadas X,Y y la dirección de un sprite que se ha de pintar sobre el fondo. Pues bien, en lugar de hacer eso (pintarlo en pantalla), la rutina lo que hace es generar un trozo de código máquina que a su vez es el que se encargaría de pintar el sprite.

Esta generación se puede hacer "off-screen", mientras se está viendo el frame actual. La idea es, si quieres sprites animados a 50fps, que todo el proceso de compilación de sprites no dure más de un frame (20ms).

Cuando ocurre una interrupción, lo que se hace es llamar a la rutina que se generó en el frame anterior. Esta rutina consistirá en un montón de instrucciones seguidas del tipo:

Código: Seleccionar todo
LD A,valor
LD (direccion),A

Quizás mezcladas con otras como:

Código: Seleccionar todo
LD HL,valor16
LD (direccion),HL


O bien mezcladas con secuencias desenrrolladas de bucles tales como:

Código: Seleccionar todo
LD HL,direccioninicial
LD (HL),valor1
INC H
LD (HL),valor2
INC H
LD (HL),valor3
etc...

Que tu compilador de sprites use una u otra forma depende de lo que quieras pintar. El valor que se pokea en pantalla ya estaría prerrotado y pre-combinado con lo que hubiese en pantalla en ese momento.

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Vie May 02, 2014 3:41 pm
por mcleod_ideafix
Una pequeña demo que escribí hace tiempo. Muestra 70 sprites de 2x2 píxeles en pantalla, y los anima a 50fps.

http://www.zxprojects.com/atc/prueba_sp ... ilados.zip

Imagen

Cada sprite es una pequeña bolita cuadrada de 2x2 píxeles que se va moviendo por la pantalla en diagonal y rebotando en los bordes de la misma.

El color del borde indica el tiempo en líneas ráster que se gasta en cada operación:
- AZUL: el tiempo que se tarda en borrar la pantalla (no la borra entera, simplemente dibuja con OVER 1 los sprites en sus posiciones antiguas)

- ROJO: el tiempo que se tarda en pintar la pantalla con los sprites en sus nuevas posiciones.
(para una animación a 50 fps sin parpadeo, los tiempos de estas dos operaciones deben ser tales que no se llegue a tocar la linea superior de "paper". Como podeis ver, esto no sucede salvo que aumenteis el número de "bolitas" a 120)

Como los sprites se pintan con XOR, el mismo código que los pinta los puede borrar. Aprovecho esto para, en este punto, hacer que el código que acaba de pintar los sprites en la fase ROJA del presente frame se convierta en el código que los borra en la fase AZUL del siguiente frame.

- MAGENTA: el tiempo que se tarda en reposicionar los sprites, es decir, calcular su nueva posición, ver si han llegado a un borde de la pantalla para invertir el sentido de la marcha y así generar el "rebote", etc.

- VERDE: el tiempo que se tarda en generar de nuevo el código que pinta los sprites en su ubicación actualizada en el paso anterior.

Como se puede ver en la demo, las fases MAGENTA y VERDE duran bastante tiempo. El sprite no está prerrotado. Me da igual porque estas fases no pintan a pantalla. Es más: si no te importa que la animación sea a 25 fps en lugar de a 50 fps, puedes aumentar el número de "bolitas" hasta unas 150. Más allá de eso hay problemas de memoria, y es aquí donde disponer de un banco completo de 16KB sólamente para almacenar el código compilado puede ser de ayuda.

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Vie May 02, 2014 4:21 pm
por wilco2009
Impresionante mcleod, creo que podría estar muy bien aplicarlo en algún juego.

Otra gamberrada que se me ha ocurrido es la oportunidad de utilizar el paginado para implementar abstracción y polimorfismo. Es decir, implementar las mismas rutinas pero con un comportamiento diferente en cada página. Cada página contendría el comportamiento de una serie de objetos diferentes.
El programa llamaría a sus "metodos" (subrutinas) de la misma forma y sin preocuparse de como hará este para ejecutar el mismo.
Sólo cambiando la página activa se modificará el comportamiento.

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Vie May 02, 2014 6:32 pm
por antoniovillena
Ahora lo he comprendido. Supongo que compilar+pintar sprites de este tipo es más lento que por ejemplo pintar directamente mediante sprites prerrotados, pero que el pintado en sí es muy rápido y se puede hacer durante los primeros 14000 ciclos y se podrían pintar más sprites sin parpadeo.

Sería cuestión de hacer una demo comparativa entre sprites prerrotados y sprites compilados. Si los compilados suponen una ventaja, desde luego modificaría mi engine FASE para tenerlos en cuenta.

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Vie May 02, 2014 8:44 pm
por SpeedXP
Es una pasada estar en este foro, juas!!! :mrgreen:

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Sab May 03, 2014 1:42 am
por mcleod_ideafix
antoniovillena escribió:Ahora lo he comprendido. Supongo que compilar+pintar sprites de este tipo es más lento que por ejemplo pintar directamente mediante sprites prerrotados, pero que el pintado en sí es muy rápido y se puede hacer durante los primeros 14000 ciclos y se podrían pintar más sprites sin parpadeo.

Sería cuestión de hacer una demo comparativa entre sprites prerrotados y sprites compilados. Si los compilados suponen una ventaja, desde luego modificaría mi engine FASE para tenerlos en cuenta.


Si lo piensas un poco verás que este método es lo más parecido a usar una pantalla shadow. De hecho probablemente pintar sprites de la forma tradicional en pantalla shadow sea más rápido que usar sprites compilados, pero aquí aunque tenemos ingentes cantidades de memoria, no tenemos pantalla shadow, así que es, creo, la opción más rápida.

Re: Próximo concurso de juegos de 512Kb para Spectrum

NotaPublicado: Dom May 04, 2014 11:57 pm
por flopping
Ya veo que se le van buscando aplicaciones a esos 512K, con ideas bastante buenas, y seguro que aun hay mas posibilidades por descubrir, aunque como dice zup, gastar memoria por gastar no es lo que se busca, pero podriamos hacer juegos estilo brunilda, mucho mas largos, con mas trama, graficos, mapeados, sonidos etc....al igual que juegos conversacionales con pantallas estaticas o dinamicas, no pensemos solo en juegos tipo arkanoid, donde tendriamos tropecientasmil pantallas sin aparente variacion entre ellas, solo los enemigos y poco mas, no es esa la utilidad que se busca, yo creo que se le puede sacar mucho jugo a esos 512k, es evidente que la paginacion es un handicap, pero tambien lo es en un juego de 128k y se hacian y se siguen haciendo, asi que tampoco creo que sea una excusa para no aprovechar esa memoria de mas, imaginemosnos un Brunilda 2 en 512k, vamos seria la repanocha, jajajaja.

Respecto a las cargas, si que es cierto que en cinta seria infumable, pero como ha comentado wilco2009, se puede usar el divide para ello o la rom de cargando leches o comprimir el fichero y descomprimirlo en memoria, para que cargara en menos tiempo y demas cosas que se podrian estudiar, aunque lo dicho, lo primero es tener un proyecto interesante y poder plasmarlo, salu2.