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 74938 veces)

Bubu

  • T-600
  • Mensajes: 2 598
¡¡Opciones multicolores traigo, oigan!!

A ver que sus parece:


[ Guests cannot view attachments ] 06.PNG[/attachment]
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

mentalthink

  • T-500
  • Mensajes: 870
Sobre el tronco lo que te han comentado, yo me quedo con el primero, aunque los colores no peguén, pero es curioso que es el que mejor queda...

Sobre la última imgen, se me ha caido el álma al suelo, que guapo... esto lo tienes que acabar si o si.

Una consulta sobre los colores... no hace mucho conecte el divide al 48Kb, se que será una tonteria, porque si ninguna empresa lo hacia o es que no me fije mucho en ese juego o fue programado de una forma muy rara... porque cuando lo enchufé, pensé coño!!! estoy con el CPC o con el Spectrum... tenia un monton de colores... y se movia super rapido, y nada de trasnparencias raras, ni nada...  Bueno el movimiento parece por caracter... pero yo personalmente nunca he visto algo en spectrum con esos colores y calidad grafica...

http://www.youtube.com/watch?v=xo_0JDLqgw0

Raiders

  • T-7T
  • Mensajes: 468
Pues a mi me gusta más de la última captura la opción del tronco amarillo :P

Bubu

  • T-600
  • Mensajes: 2 598
AJjajaaja, ¡¡bieeeen!! A mí también me gusta la 2ª opción, porque es más fiel al original.
El único poblema que le veo es cuando la rana se suba a un tronco amarillo, siendo la rana verde, quedará poco contrastada... De cualquier manera pondré el color de los troncos, de las tortugas y de la rana parametrizable en el código fuente para que sea variar el valor y a correr, jiji. De momento, troncos amarillos + tortugas rojas : 2, troncos rojos + tortugas rosas : 1
Cuantas más opiniones haya, mejor, que yo para tema de arte y colores soy bastante malo.

Por cierto, aquí os dejo un vidrio de la parte de la carretera, para que lo veais en acción:

http://www.youtube.com/watch?v=c3x67H5m2lY&feature=related
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

Deka Black

  • T-600
  • Mensajes: 9 150
A straight line may be the shortest distance between two points, but it is by no means the most interesting. - (Third Doctor in The Time Warrior)

Raiders

  • T-7T
  • Mensajes: 468
Trampa! Trampa! Usa vida infinita! xD

doragasu

  • T-600
  • Mensajes: 2 314
  • Si no está roto, ¡yo lo arreglo!
    • Kernel Hacks
Soy un ignorante del Spectrum, así que seguramente esto que voy a decir es un disparate, pero por si acaso lo suelto. El caso es que más de una vez he oído comentar que el Spectrum tenía 8 colores, pero tiene un bit de brillo que permite pintar esos 8 colores más brillantes y así tener 16. La pregunta es: ¿No se podría usar eso para tener 2 tonos de rojo distintos, uno para el tronco y otro para las tortugas?

En cuanto al tema de optimización y C vs lenguaje de ensamble, a día de hoy lo más recomendable es escribir en C el grueso de los programas y optimizar únicamente en lenguaje de ensamble las rutinas que más tiempo de CPU consumen. Por ejemplo, no tiene mucho sentido invertir el tiempo extra que requiere programar los menús en lenguaje de ensamble, ya que no habrá diferencias apreciables de rendimiento y además los menús son un elemento en los que no pasaremos casi tiempo.

Por otro lado, como decía el gurú de la optimización Michael Abrash en su libro \"Zen of Code Optimization: The Ultimate Guide to Writing Software That Pushes PCs to the Limit\", más importante que programar en lenguaje de ensamble es diseñar (o re-diseñar) inteligentemente los algoritmos. Michael Abrash afirma que mientras que pasar una rutina de C a lenguaje de ensamble puede conseguir factores de mejora como mucho de 10 (lo cuál está muy bien), un rediseño inteligente de un algoritmo puede conseguir mejoras en un factor de 100 o más. Un ejemplo perfecto es lo que comentas Bubu de cómo vas a hacer el scroll al pixel de los troncos, evitando andar trasteando con desplazamientos y más instrucciones. Rediseñando de manera inteligente el algoritmo (independientemente de en qué lenguaje programes) has logrado una mejora que seguro es mayor que si pasases de C a ASM una rutina con desplazamientos.

Después de este tocho, en cualquier caso, el proyecto es relativamente sencillo, lo suficiente como para hacerlo por entero en ASM, así que si el tiempo no es un factor que te escasee, pues tampoco hay problema en hacerlo en este lenguaje.

Bubu

  • T-600
  • Mensajes: 2 598
¡¡Gracias, Deka Black, 3 vs 1!!

JAjaJAA, Raiders, quien hace el pograma, hace la trampa :-DDDDD
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

Bubu

  • T-600
  • Mensajes: 2 598
Cita de: \"doragasu\" post=19744
Soy un ignorante del Spectrum, así que seguramente esto que voy a decir es un disparate, pero por si acaso lo suelto. El caso es que más de una vez he oído comentar que el Spectrum tenía 8 colores, pero tiene un bit de brillo que permite pintar esos 8 colores más brillantes y así tener 16. La pregunta es: ¿No se podría usar eso para tener 2 tonos de rojo distintos, uno para el tronco y otro para las tortugas?


La diferencia entre brillo sí y no es demasiado sutil como para que destaque uno sobre otro. Los 16 colores (15, porque el negro no presenta brillo) por hardware pueden convertirse en 255 colores por sofware, ya que si pones píxeles 1 y 0 muy cercanos entre sí, y los 1 los colores con rojo p.ej. y los 0 con amarillo, obtienes un naranja virtual.
Voy a intentar hacer así los troncos a ver si consigo un color marrón más o menos guay.

Cita de: \"doragasu\" post=19744

En cuanto al tema de optimización y C vs lenguaje de ensamble, a día de hoy lo más recomendable es escribir en C el grueso de los programas y optimizar únicamente en lenguaje de ensamble las rutinas que más tiempo de CPU consumen. Por ejemplo, no tiene mucho sentido invertir el tiempo extra que requiere programar los menús en lenguaje de ensamble, ya que no habrá diferencias apreciables de rendimiento y además los menús son un elemento en los que no pasaremos casi tiempo.


Tienes razón, lo que pasa es que al principio esto lo utilicé para crearme mis librerías en ASM personalizadas, y una de ellas es la de hacer menús. Yo sólo tengo que enviar posiciones, textos y colores, y los menús se hacen en 20 segundos. Sí, a lo mejor C también y así no tendría ni que haberme hecho mis librerías, pero entonces no aprendo, no sé cómo van las tripas de todo esto. El proyecto es sobre todo para aprender yo a hacer un juego. ;-)

Cita de: \"doragasu\" post=19744

Por otro lado, como decía el gurú de la optimización Michael Abrash en su libro \"Zen of Code Optimization: The Ultimate Guide to Writing Software That Pushes PCs to the Limit\", más importante que programar en lenguaje de ensamble es diseñar (o re-diseñar) inteligentemente los algoritmos. Michael Abrash afirma que mientras que pasar una rutina de C a lenguaje de ensamble puede conseguir factores de mejora como mucho de 10 (lo cuál está muy bien), un rediseño inteligente de un algoritmo puede conseguir mejoras en un factor de 100 o más. Un ejemplo perfecto es lo que comentas Bubu de cómo vas a hacer el scroll al pixel de los troncos, evitando andar trasteando con desplazamientos y más instrucciones. Rediseñando de manera inteligente el algoritmo (independientemente de en qué lenguaje programes) has logrado una mejora que seguro es mayor que si pasases de C a ASM una rutina con desplazamientos.


Y aquí viene mi principal poblema del frogger. Actualmente tengo implementado el algoritmo \"preshifted\", es decir, los gráficos los almaceno en memoria desplazados uno a uno los píxeles, porque en su momento vi que 48KB daban para esto, y como hay demasiadas figuras que desplazar (muchos coches en la carretera, muchos troncos y tortugas en el río), pues este algoritmo es el más rápido para ello.
Pero cuando la rana se suba a un tronco, tendré un sprite sobre otro, y por tanto van a parpadear (murrápido).
Por eso quiero probar (por probar) otro algoritmo aunque sólo sea para el río, el de ir shifteando online.


Cita de: \"doragasu\" post=19744

Después de este tocho, en cualquier caso, el proyecto es relativamente sencillo, lo suficiente como para hacerlo por entero en ASM, así que si el tiempo no es un factor que te escasee, pues tampoco hay problema en hacerlo en este lenguaje.


Uy, ahí está el tema. Tengo hijos, trabajo inteso y de muchas horas, etc, y tiempo es de lo que menos tengo. De hecho me pongo sólo a partir de las 12 de la noche, y suelo acabar entre la 1 y las 2 de la noche, porque a las 6.50 estoy en planta todos los días.
De todas formas no me parece tan sencillo, máxime cuando el Spectrum tiene una velocidad que te puede limitar el desplazamiento de los sprites. Ahí es donde reside el mayor handicap. Fíjate que la mayoría de los juegos comerciales tienen muy muy pocos sprites simultáneos desplazándose de pixel en pixel.

Salu2, y gracias por tus comments, nunca considero disparates cosas así :-)
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

Bubu

  • T-600
  • Mensajes: 2 598
PREGUNTA: ¿Permite algún C para Spectrum manejar sprites?

Parece que Z88DK pué tener algo, pero en unos sitios leo que es un mojón, que está incompleto... y entros laos no dice nada. Si alguien sabe algo, plís tellme, es pa no andar descargándome cosas y probando

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

Deka Black

  • T-600
  • Mensajes: 9 150
A straight line may be the shortest distance between two points, but it is by no means the most interesting. - (Third Doctor in The Time Warrior)

doragasu

  • T-600
  • Mensajes: 2 314
  • Si no está roto, ¡yo lo arreglo!
    • Kernel Hacks
Cita de: \"Bubu\" post=19748
Pero cuando la rana se suba a un tronco, tendré un sprite sobre otro, y por tanto van a parpadear (murrápido).
Por eso quiero probar (por probar) otro algoritmo aunque sólo sea para el río, el de ir shifteando online.


Las 2 soluciones obvias que se me ocurren para solucionar esto son la rápida y cutre, y lenta pero mejor.

- La rápida y cutre es que en el caracter en el que esté la rana, no se pinta el fondo, sólo la rana y punto.
- La lenta pero mejor es hacer el típico sprite por software: defines una máscara para la rana, y en un buffer temporal de memoria pintas fondo, borras la zona de dentro de la máscara y pintas la rana encima. Luego copias al buffer de pantalla.

También podrías hacer como tercera opción el pre-shift en memoria incluyendo la rana encima, claro que entonces para los elementos que así lo requieran, se duplica el espacio usado en RAM, y de 5,5 kB pasarás a 11 kB...

Bubu

  • T-600
  • Mensajes: 2 598
Estas 2 soluciones \"obvias\" son mortales, no van a funcionar. Tengo que mover demasiados sprites de una vez, cada uno de tamaños, direcciones y velocidades diferentes.

Al menos voy a intentar hacerme un shift online. ¿Alguien sabe qué instrucción usar? (sí, soy mu vago, y me gusta preguntar antes en un foro que guglear por mi cuén...)

Creo que tendría que desplazar 1 bit a la derecha, y el bit de más a la izquierda meterle el acarreo, y el que se sale por la derecha meterlo en el acarreo pal siguiente shift. Recuerdo que se hacía una instrucción del tipo RRC o argo así...
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

Robe_Inie

  • T-600
  • Mensajes: 1 718
Acabo de ver la opción de los troncos amarillos... y tampoco me parece mal, la verdad !! quizás rojo con rosa queda muy forzado.. aunque tampoco me disgusta.

Bubu

  • T-600
  • Mensajes: 2 598
Cita de: \"Bubu\" post=19748
(...) pueden convertirse en 255 colores por sofware, ya que si pones píxeles 1 y 0 muy cercanos entre sí, y los 1 los colores con rojo p.ej. y los 0 con amarillo, obtienes un naranja virtual.
Voy a intentar hacer así los troncos a ver si consigo un color marrón más o menos guay.


Patética mi idea de colorear los troncos de marrón naranja, jiji (rojo + amarillo) ya que entonces el agua de alrededor se vuelve roja... ¡¡el río de la sangre, mwaahahaaha!!

Nada, creo que lo suyo va a ser el color amarillo sin brillo, y la rana verde con brillo, jiji.


Bueno, me encuentro construyendo un motor de scroll horizontal mediante instrucciones RR, que desplazan un byte de memoria, y lo que se sale por la derecha es inyectado al bit de la izquierda del siguiente byte, jiji. Tié buena pinta. Para el río me podría servir...
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!