Karoshi MSX Community

Hola de nuevo a tod@s

He estado una sema entera a horas sueltas preparando estas demos en ROM
porque quiero que seais los propios usuarios los que tomeis por votación la decision de como han de compartarse el color de los enemigos en el juego.

Y esta decision os la dejo a vosotros como una encuesta.
Descarga las ROM para MSX aqui. http://www.gigasize.com/get.php?d=4log5dbn89b

Todos o casi todos sabeis que el MSX no soporta mas de 4 sprites en la misma linea.
Asi pues timeout no es un juego preparado para MSX ya que casi todos los enemigos salen en la misma linea
trabajando,pensando y pidiendo ayuda esto es lo que he parido.

1 - Personaje del juego creado con sprites multicolor
2 - Los enemigos creados con tiles con desplazamiento de 2 en 2 pixels, no caracter a caracter para que el movimiento sea fino.

conseguida esta parte me queda SELECCIONAR como sera el color para los enemigos y aqui viene el problema.
y aqui entrais en Juego vosotros.

Aqui teneis las 4 versiones de ROM para que las probeis con vuestro emulador de MSX preferido. Y voteis por vuestra opcion preferida.

OPCION 2 - ROM mascara2.rom - se conserva el fondo - color en blanco
(http://img686.imageshack.us/img686/619/mascara2.png)

OPCION 2a - ROM mascara2a.rom - no se conserva el fondo enemigos con color
(http://img534.imageshack.us/img534/4036/mascara2a.png)

OPCION 2b - ROM mascara2b.rom - se conserva el fondo enemigos con color
(http://img180.imageshack.us/img180/2272/mascara2b.png)

OPCION 2c - ROM mascara2c.rom - se conserva el fondo pero enemigos toman el color del fondo de la pantalla
(http://img688.imageshack.us/img688/7624/mascara2c.png)



Si se os ocurre alguna idema mas, tambien podia ponerse no conservar el fondo pero tomar el color del fondo de pantalla. jejeje
YA PODEIS VOTAR AQUI EN EL HILO y MUCHAS GRACIAS DE ANTEMANO.

Un saludo.

Como no veo la encuesta preparada, y mañana marcho de viaje, respondo aquí:
Opción 2B, es la que más me gusta con diferencia.

El cuadro negro de fondo de la 2a queda muy bruco, y la opción 2 no me acaba de gustar.
La 2c es curiosa, pero algunos colores lo estropean todo.

Saludos

Makinavaja

Vaya trabajazo que te has tomado! No sé, de todos modos, si hacerlo democráticamente será la mejor opción. Antes de descargar las ROMs, mi respuesta es sencilla y técnica: la que consuma menos CPU, que supongo que será la que oculta el fondo directamente.

Una vez probadas, te cuento mis impresiones.

Hola Robs

Que rapido responde la gente asi me gusta.

si son cambios de una version a otra pero no tanto, las rutinas son praticamente las mismas con pequeñas diferencias.
ahora eso si hay 5 o 6 HALT para que la cosa se vea a una velocidad aceptable.

Me gustaria que le dieras un vistazo al source, seguro que le arañas mas ciclos... jejeej

Un saludo.

La que más me gusta es la 2A, considerando que borre el fondo como un mal menor. Las que menos la 2B y la 2C, se confuden el fondo y el personaje demasiado.

Por cierto, que buena pinta tiene todo. Enhorabuena!

A mí la que más me gusta es la 2A.

+1

Y un "thumbs up" por el proyecto.  :)

Con las capturas de pantalla me inclinaba por la opción 2a, pero al ver las ROMs ya no me gusta tanto. Tal vez escogería la 2b, aunque la 2 tambien tiene su gracia. La que no me gusta es la 2c, la veo muy confusa.

hola de nuevo

A que es dificil decantarse....

Todos queremos que nuestro MSX tenga su color en todo su explendor, pero cuando no se puede por cuestiones tecnicas no se puede, si bien la version 2 dentro del color blanco es la que menos molesta a la vista, y que preserve el fondo queda muy bien, el color por supuesto le sienta muy bien al enemigo1 aunque aqui esta el dilema del fondo o dejar el color preservando el fondo y por supuesto la 2c podeis ver que flickea, ya que solo queria que se viese el resultado sin poner mucho empeño en ella.


Asi que la encuesta decidira. 

Yo me decanto por la 2b, que aunque va reajustando los colores creo que es la mejor de todas ;)

Yo he votado 2a.

Yo también voto 2A, las otras opciones me recuerdan a juegos como el Game Over o el Phantis, que se confundían los enemigos con el fondo de pantalla.

Pues a mi las que mas me gustan son la 2 y la 2A

He votado por la 2A.

Por cierto ¿has pensado en una version MSX2? en MSX2 se solucinarian bastante estos problemas

Tb me pasa que la 2A en captura me gusta mas pero al verlo en la ROM.... no sep. Casi prefiero la 2 pelada, que ya estamos acostumbrados a eso...

Son muchos enemigos? Muchos sprites el prota? Es que sino se podria hacer todo sprites y aplicar rotacion de sprites para minimizar el parpadeo. Pero si son muchos... Aunque siendo muchos, no se enmarranaria la pantalla igual? Si que es dificil decision si.
En estos casos lo mejor es... limitar el numero de enemigos :P (por linea, al menos)

Yo me pregunto si son necesarios tantos colores en el protagonista, lo digo porque usando 2 colores para piernas y otros 2 colores para cabeza y tronco, aun quedarían otros 2 sprites para poder colocar en línea, y si por exigencias del juego son más en la horizontal, tirar mano del parpadeo.

De todos modos ánimo con el proyecto.

Si, la 2 es mas rollo spectrum :) a mi tambien me gusta

Yo me quedo con la opción 2 que aunque se ve el recuadro negro (máscara) alrededor del sprite al menos este no pierde detalle ni color en ningún momento sacrificando para ello el fondo.

¿2a entonces, no?  ;)

2a sin duda...que le den al decorado :)

Pues la verdad es que si he pensado que la version MSX2 solucionaria todos los problemas, pero hay que ceder a los dos bandos.



El protagonista esta creado con sprites por hardware y dispone de 4 colores, es por ese motivo que los enemigos y los disparos tienen que ser Sprites por software, enemigos al mismo tiempo tengo pensado unos cuatro en total, mas los correspondientes disparos.. cuenta.

Ese es el verdadero problema.


Si el protagonista ya tiene 4 colores en el sprite no puedes poner ningun enemigo mas en la misma linea porque seria el 5, bajandolo a 2 colores solo me da para otro sprite de 2 colores o 2 de un color, poco color y muy pocos enemigos. hablandod e sprites pror hardware claro.

Por eso pongo un hibrido de personaje creado con sprites bien definido con 4 colores y enemigos con sprites por software.

Este que veis en la imagen no es el protagonista sino un enemigo.


La opcion a la que te refieres es a la 2a modificalo que da a confusion Konamito.



La 2a y la 2b son la misma pero una conserva el fondo y la otra no, pero las dos tienen el mismo color, a mi personalmente no me gusta que pierda el fondo.

A ver si saco tiempo y le mezclo la primera demo a la que podeis mover al personaje, con estas demos que os he puesto para descargar, para que veais el resultado final. lo compilo en ROM y os la subo. ( El problema es que mi tiempo es una cosa muy limitada...)

Un saludo.

P.D. No os fijeis en la fotos es mejor que probeis las ROM.s para verlo en movimiento, asi podeis dar mejor vuestra opinion.

De entre las propuestas, la 2a es la que mejor queda aunque con este tipo de decorado se nota mucho el cuadradote de fondo. Igual se podría plantear dar más peso al colorido de las plataformas sobre las que anda el prota, donde nunca se va a superponer el sprite, y usar tonos más oscuros y más siluetas para el fondo.

En cualquier caso, opino como x_mangel. Se podrían usar tranquilamente dos sprites para colores de piernas y dos para colores de cuerpo de forma que no solaparan en horizontal y quedarían espacio para dos enemigos mono-sprite en linea. Lo que sí podría ser un caracter con fondo negro a lo bruto y moviendose de 8 en 8 podría ser el disparo.

Además, a la hora de programar, usar sprites es muchísimo más simple y más eficiente. Y en caso de problemas, se puede recurrir al parpadeo. O bien diseñar el juego para que nunca pueda haber más de cuatro sprites en línea.

Si lo que se muestra en las imágenes no es el protagonista yo no lo condicionaría a tener multitud de colores, me centraría en que fuese fácilmente diferenciable del fondo, aunque fuera un único color, o un color para la parte superior y otro para la inferior, pero algo más básico, vamos, y después se hacen parpadear, y como dice MrSpock usar caracteres para los disparos, pero de algún color que se diferencie claramente del fondo.

No se si habeis leido mi primer post sobre el timeout donde explicaba lo que paso con este juego alla por los 80, si no es asi os recomiendo que lo leais.


Logicamente como programador original del juego, lo que quiero es recuperar todo aquello que le falto originalmente, y desde luego usando las mejoras del MSX1
si usas dos colores independientemente de que sea la parte de arriba o la de  abajo, esto solo nos deja una opcion un enemigo de dos colores supone 2 + 2 en la misma linea asi pues no nos deja opcion a mas enemigos, o 2 enemigos de un solo color, que es muy poco y colorido cero.

Olvidaros del tema de los sprites y centraros en las preferencias del color. esto no quiere decir que no os escuche....


Espero no tardar en compilaros la demo con el prota y este enemigo para que veais el resultado con la opcion que salga ganadora.

Lo leí, me pareció muy interesante y, como decías, una lástima que el juego no pudiera salir como debía en su momento.


Obviamente todo es cuestión de como tengas el juego en mente, y de hasta que punto quieras aprovechar lo que ya tenías en su momento. Entiendo que si el trabajo hecho usa sprites por soft para los enemigos quieras dejarlo de esa forma.

Aún así, sigo pensando que si quieres usar las mejoras del MSX1, los sprites son una opción a considerar. Mi opinión (y no es más que eso, una opinión muy subjetiva) es que queda mejor un sprite monocromo para enemigos que se mueva al pixel y sin bloques negros de fondo, que un sprite por soft colorido con los bloques negros o el emborronamiento de color. Además, los parpadeos de sprites para más de 4 en línea no son tan malos. Mira el Maze of Galious, o el Golvellius, o el Bolfes.

También es verdad que hay un ejemplo excelente de sprites por soft en MSX1, el The Cure de la dev... 05 o 06, creo. Aunque en el caso de The Cure los fondos eran, en general, más oscuros para que los recuadros no destacaran tanto. Y el hecho de que los enemigos se movieran en bloques de 8 permitía que el recuadro de fondo fuera más pequeño. En cualquier caso, es tu decisión, porque tu eres el que sabe como está el juego al detalle.


Bueno, si das cuatro opciones entenderás que siempre haya algún pesado como yo que opte por la quinta XDD

A grandes rasgos, mi opinión es que lo primero que manda es la jugabilidad. Escojas la opción que escojas, si el juego se mueve rápido y todo se distingue bien del fondo, es más que suficiente.

Por cierto, como ultimamente intervengo poco en los foros y voy un poco a salto de mata, igual mi intervención ha parecido algo brusca. Que sepas que me parece estupendo que retomes el juego, así como tener entre nosotros a alguien que estuvo en activo en el mundillo cuando el MSX se programaba sobre un MSX.

¿Sería posible una mezcla entre 2b y 2c?

Partiendo de la base del 2b, que cuando en un byte haya pocos bits del sprite invadiendo el escenario, sea el color de dicho escenario el dominante.

Hola de nuevo a todos


Como podeis ver en los diferentes comentarios se habla de otra demo anterior del protagonista. con sprites por hardware que es como tengo pensado.

Os subo la primera demo en la que podeis controlar al personaje de izquierda a derecha, si el personaje sale por la izquierda de la pantalla podeis ver como era timeout en el 87, si en esa pantalla el personaje sale por la derecha volveis al timeout del 2010 podeis avanzar y retroceder para ver el cambio.

A ver si saco tiempo y recompilo la demo 2 con el enemigo junto con el codigo de la demo 1 y probais mas como sera el resultado final que tengo en mente.

Aqui teneis la primera demo que le mande a KONAMITO
http://www.gigasize.com/get.php?d=tn7dbn0pchb

Un saludo.

me gustan mas los colores del 87 :P el del 2010 lo veo todo muy brillante, debe ser el contraste de entrar a una u otra pantalla

El prota queda fantastico, lastima que los enemigos no se puedan ver asi de bien :)

Hola a tod@s de nuevo

Animaros a seguir votando, pero viendo como va de momento la encuesta.
la opcion 2a va ganando.

Asi que aqui os dejo una demo nueva con 3 enemigos para que veais el comportamiento de vuestra opcion favorita. http://www.gigasize.com/get.php?d=bvg2gc8oprb


Un saludo.

Y no dejeis de segir votando y virtiendo vuestros comentarios que siempre son muy constructivos.

Está quedando muy bien. Aunque pregunto desde la ignorancia: ¿Es posible hacer que las máscaras se desplacen de forma más suave?. Me refiero a usa un desplazamiento de 2 píxels, en lugar de bloques de 8...

No puedes realizar por cuestiones tecnicas lo que comentas Metalbrain, ya que el color se aplica a un BYTE - 2 colores, uno de fondo y otro de tinta, no puedes poner la mitad del byte del personaje con su color y la otra parte del fondo dejando el color del fondo.

 

No se puede realizar el desplazamiento que comentas xgipe, porque los enemigos estan creados con tiles, osea caracteres de 8x8 bits y el desplazamiento de estos ha de ser de caracter en carater.
son las limitaciones que tenemos impuestas y no podemos saltarlas. (mas que nada porque no se puede)

Un saludo.

Have you seen this?

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

The sprites are tile based and they move of 8 pixels

Hello AR

Indeed I know the game created by Jon, and is a true work of art.

But think that this game is not doing with a new script, I have to inherit from what it was originally, but using the characteristics of MSX not the spectrum.

Thanks

Creo que no me has entendido, así que no me habré explicado bien. En ningún momento trato de superar el número de colores por byte, tan solo de seleccionar que colores se aplican dependiendo de la predominancia entre fondo y personaje.

De hecho, ahora que he visto todos los ejemplos en movimiento (voto definitivamente por 2b), creo que para cualquiera de los métodos sugeridos se puede suavizar el conflicto con el entorno haciendo que la mezcla con el fondo se aplique de forma más inteligente, en lugar de usar siempre 3 caracteres de anchura, ya que el sprite parece tener 14 pixeles de anchura máxima, y esto hace que en un par de posiciones (si lo movemos en pasos de 2 pixels) basten con mezclar 2 caracteres en lugar de 3, y afinando más todavía, las partes más estrechas del sprite tendrían todavía menos casos de mezcla. Lo malo de esto es que se complica la programación y el tiempo de proceso, así que habría que calibrar si estamos apurados o no de t-states para invertirlos en esto, pero creo que podría merecer la pena.

Hola de nuevo Metalbrain

Efectivamente los enemigos tienen 16 pixeles de ancho y 4 frames o animaciones, el tema de que utilicen 24 pixeles es porque cada frame esta desplazado 2 pixeles del frame anterior 2 pixeles por 4 frames = 8 pixeles de esta manera situas en la pantalla al enemigo y vas pintando cada imagen en la misma coordenada pero el enemigo se va desplazando de 2 en dos pixeles, hasta que la animacion se termina y aumentas en uno la coordenada x. Este manera hace mas grande el grafico pero le da un movimiento mas suave y natural

Me estas proponiendo dejar los 4 frames en 16 pixeles y asi minimizar el cuadrado negro alrededor del enemigo?
sacrificado el movimiento suave por un movimiento mas brusco caracter a caracter pero donde se note menos el fondo?

Otra opcion que estoy barajando que igual es a esto a lo que te refieres.
siempre hay tinta negra de fondo con el color que en cada zona tiene el enemigo, la unica forma de mimetizarlo mas seria sustituir la tinta negra del fondo por el color que tenga el fondo, pero sin tocar la tinta principal del enemigo...
voy a hacer una imagen de prueba a ver que tal quedaria.

Un saludo.

Muchas gracias por tus explicaciones.  :)
Es un placer seguir estos hilos para aprender (aunque sea un poco) cómo funcionan nuestros MSX.

Hola de nuevo
 
Esta visto que el hilo me esta dando mucho de si, pues otra de las opciones que se habia barajado y que aqui os muestro
la que podria ser la opcion 2D pero que tampoco me convence y no voy a poner la ROM

PANTALLA NORMAL
(http://img265.imageshack.us/img265/2506/pantalla1.png)
ENEMIGOS CON OPCION 2D
(http://img33.imageshack.us/img33/9192/mascara2d.png)


Como podeis ver apreciando las dos imagenes
Ahora la tinta del color del personaje queda intacta tal cual la tiene el enemigo pero la tinta del tile del fondo pasa a ser la tinta del fondo del enemigo generando esta nueva opcion que veis.

Personalmente mi favorita es la 2b, aunque la 2a es la que sigue ganando.

Solo me queda hacerlo de 2 caracteres de ancho y mover a los enemigos de 8 en 8 haber que tal queda.

Un saludo y seguir posteando vuestras opiniones.

No, no hablo de tocar el movimiento, sino de que las zonas de este gráfico que he marcado con magenta, podrían ser totalmente transparentes (acabo de ver que me he dejado por poner transparente un byte bajo el pie del cuarto frame):

(http://s2.subirimagenes.com/imagen/4731830timeouttrans.png)

La última columna en los dos primeros frames está totalmente vacía, así como la primera en el cuarto frame. El resto de transparencias que son más a nivel de byte en lugar de caracteres, tal vez queden peor, o sean demasiado costosas en procesamiento para merecer la pena, pero lo de usar siempre 24 bits de fondo negro (por ejemplo usando la técnica 2a), cuando en 3 de 4 frames basta con 16, lo veo excesivo.

Metalbrain's study is very good, but I have also another proposal: use both sprites and tiles!!

The simplest way is to use black sprites to outline the borders of the characters and Metalbrain's proposal where instead of black you leave one of the background main colors.

It seems doable, what you think?

The problem using sprites is that the main character already uses sprites, and there will be several enemies, all in the same lines where the main character appears. So the 4th sprite rule will soon make its appearance, and most sprite improvements will be lost.

Hola de nuevo

Metalbrain, creo que voy a probar tu propuesta, no solo con la opcion 2a, sino tambien con la 2b ya que emborronara menos el fondo que es lo que afea a esa opcion. si bien la mascara siempre ocupa un poco mas si se puede reponer en la zona magenta los colores del fondo.

a ver como modifico la rutina principal de impresion de graficos para que realize esto.

Y ya os posteo.

Un saludo.

Puestos a elegir, me quedo con la opcion 2b, pero con la solución propuesta por Metalbrain. Recuerdo el juego Goody, que en alguna pantalla salía un fantasma hecho con sprites por soft. Se movía suavemente y el fondo se "contagiaba" según se iba moviendo, pero de manera a como dice Metalbrain y no quedaba mal.

Personalmente yo probaría a solucionar el porblema de coloreado de otra manera: usa sprites por hardware tanto como puedas. Ya que el coloreado es en horizontal y las máscaras son en negro, usaría patrones para la máscara y sprites para las zonas coloreadas. Esto te obligaría a hacer los fondos de 1 color + negro, para evitar contagios. Si te fijas bien, podrías usar varios sprites "apilados" en vertical y apenas tendrías desaparición.

Ten en cuenta que a los sprites que desaparecen, solo les desaparecen las líneas donde efectivamente se alinean 4 o más sprites, no desaparece todo el sprite.

Hola de nuevo a tod@s

Aqui vengo para liberar la demo3 del Nuevo TimeOut en la que trae novedades importantes. (que no os desvelo sin que la probeis)

En esta demo estaba trabajando con las balas, por eso disparando se produce un sonido, para ir comprobando los disparas, pero no se visualizan las balas porque estoy trabajando en las tablas de los enemigos y disparos que todo lo mueve la misma rutina.

Y aqui esta todo el meollo del juego, por lo que tardare tiempo ya que lo voy haciendo a ratos sueltos y esto se alargara mas en el tiempo.

Aqui os dejo la demo3 para descargar y probar.
http://www.gigasize.com/get.php?d=7j3g3vdxr0b

(http://img804.imageshack.us/img804/2743/salto.png)
Aqui ya podeis saltar agacharos y vereis 6 pantallas del mismo nivel.

Espero que para la proxima demo4 ya podais disparar a los enemigos en pantalla.

Un saludo.

P.D. Postearme vuestras opiniones que siempre son muy constructivas.

Tiene muy buena pinta.
Solo un detalle: mueve la cabeza del marcador 2 pixeles a la derecha y el pelo le quedará perfecto.  ;)

(Jeje, tenía que decirlo)

Tranquilo mohai que en lo nuevos tiles ya esta arreglado lo de la cabeza.
Esta compilacion todavia no tiene los tiles nuevos. ( pero es algo que yo tambien habia visto.)

Un saludo.

Algunos detalles que me han llamado la atención:

- En el gesto de saltar, parece que el personaje se acuclille antes de iniciar el salto. Lo que sucede es que pese a ello, el personaje sigue desplazándose lateralmente, con lo cual produce la impresión de deslizarse más que caminar o saltar.

- Si el salto se realiza sin desplazamiento horizontal, es mucho más rápido que cuando sí hay desplazamiento y scroll. En este sentido, está claro que los cálculos que realizas para el scroll hacen que pierdas frames. Si a esto falta añadirle muchos cálculos más para enemigos, disparos y sonido, podría no funcionar demasiado bien. Además, sucedería lo mismo con los disparos: se acelerarían al no haber scroll y se frenarían al haberlo. Muy incómodo para el jugador.

Aparte de esto, te sugiero que hagas un salto un poco más "físico", ya sabes, simulando el efecto de la acelaración, etc. Si el juego no va a tener plataformas, es decir, si toda la acción transcurre a la misma altura, es muy sencillo conseguir una buena simulación de un movimiento parabólico.

Por lo demás, muy notable el trabajo gráfico y el colorido del que has conseguido dotar a la demo. En este sentido, danos más pronto para que podamos seguir relamiéndonos ;)

¿No esta el cielo muy vacio?. No se, igual es que luego van a ir enemigos y movidas, pero parece que toda la accion transcurre en un tercio de la pantalla y el resto esta negro. Igual es solo porque no hay enemigos.  ::)

El salto parece de olimpiadas. Me da que es muy largo. :o

Me gusta el color, sigue con ello que la cosa gana enteros.  8)

- Esto se puede cambiar pero mi idea es que el se agacha para tomar fuerza para impulsarse, pero vamos no cuesta nada hacer que este de pie y empiece el salto unos pixels mas arriba.



es la misma rutina la encargada del salto, estando quieto el salto se produce pixel a pixel y con scroll va de 3 en 3 la subida y la bajada.
para que que la realice mas rapido, en cuanto a tiempos para el resto de cosas sobra, has probado la otra rom donde he quitado los 8 halt que hay en el scroll. sin olvidarnos de los caracteres que avanza el prota con el scroll en horizontal.


Aqui si que es verdad que puedes realizar una aceleracion progresiva de 112233 pixeles y generar una parabola mas bonita, para eso estais vosotros para damer mejoras y sugerencias.


Asi lo ire haciendo Robs

P.D. me gustaria que el asmsx al final la compilacion me diera datos de dir. inical del codigo y final de compilacion.
aunque esto lo puedas ver en el .sym

Hola kabish

En la primera parte del juego hay mucho cielo porque es tipo desertico
pero dentro de una pantalla mas ya entras al pueblo y las casas cubren los 3 tercios.
(http://img442.imageshack.us/img442/9641/pueblo.png)

Un saludo.

¿Sigue avanzando este proyecto?

Hola WYZ

Este y otros proyectos siguen avanzando... ya sabes como somos los progrmadores encima del poco tiempo que nos deja la vida laboral y familiar nos ponemos con varias cosas al mismo tiempo. pero se terminaran. menos mal que lguna son por entregas.

Te mandare un privado.

Doy fe de lo que dice Pepe ;)