demo/proyecto-de-conversión de Wolfenstein3D para Megadrive

los últimos videos colgados en youtube se ven geniales!!!! muchas feliciades!! BRUTAL trabajo

gasega68k eres mi idolo

Felicidades por tu trabajo, eres un crack. Larga vida a la negrita!

Me pregunto cuanto terminara ocupando y si podrá caber en un cartucho.

gasega68k escribió:Hola a todos, acabo de registrarme, no habia visto este foro y ¡en español!, gracias por sus comentarios . Aunque no domino bien el ingles, estoy aprendiendo un poco cada dia, en parte gracias a Google traductor.
De ahora en adelante voy a mostrar las proximas versiones aqui tambien.
Bueno, acerca de wolf3d, la gran parte de uso del cpu esta en el engine(raycast) y en el codigo para dibujar las paredes y sprites(enemigos y objetos), asi que agregar AI a los anemigos no representa una gran carga al cpu, hay que tener en cuenta que este juego originalmente fue programado para que funcionara en una PC 286 de 10MHZ.
Si tienen alguna pregunta, con gusto les estare respondiendo .

ç


Bienvenido y felicidades!!!

gasega68k escribió:Hola, gracias de nuevo por sus comentarios, ahora voy a responder sus preguntas.

naxeras escribió:Tengo una pregunta acerca de los niveles, ¿Como los cargas?, es decir ¿las texturas y esas cosas las va cogiendo del cartucho?, ¿en PC no carga el nivel completo en memoria RAM?, lo digo por las pantallas de carga en PC.

Las texturas y sprites (objetos y enemigos), estan en rom descomprimidos, aunque los sprites estan recortados a un tamaño mas o menos al espacio usado, pero esto no quiere decir que los sprites son mas pequeños, en PC todos los sprites tienen un tamaño de 64x64 aunque la gran mayoria no usan ese espacio. En mi engine los sprites en tamaño "Y" puede ser 32 o 64, y en tamaño "X" puede ser casi cualquiera(64, 62, 60, 58, 56...), yo hice esto asi para ahorrar velocidad al momento de dibujarlos, y ademas para ahorrar un poco de espacio en rom.
En pc todo esta comprimido y se descomprime todo en RAM.

naxeras escribió:¿Cabe cualquier nivel del juego original?
¿Tienes que rehacer los niveles o la estructura se puede poner importar de la version de PC?

Si, la estructura de los niveles esta hecho directamente de la version de PC, aunque estan descomprimidos. Mas adelante voy a hacer que se pueda utilizar los archivos "GAMEMAPS" y "MAPHEAD" del juego original, porque asi ocupa menos espacio.

naxeras escribió:¿Crees que conseguirás los 15 fps estables que garantizan la fluidez de esta versión?

Voy a intentarlo, aunque nunca se puede alcanzar los 15fps si hay tantos objetos/enemigos en pantalla. Desde la ultima version (10 de enero de 2014), ya he optimizado un poco: el codigo para dibujar sprites ahora es de 38 ciclos menos por columna dibujada. Practicamente en cada version he optimizado un poco y todavia se puede optimizar, sobretodo en el engine principal (raycast).

realbrucest escribió:¿A qué se debe que hayas optado por dibujar en VRAM la escena girada 90 grados?
Lo estuve mirando con el gensKmod y me resultó muy curioso al ocurrírseme cuál es la razón para ello.

Los tiles estan ordenados de esa manera por dos cosas: primero porque para dibujar las texturas se hace mas facil, se dibuja de arriba hacia abajo es decir, por columnas(en realidad se dibuja del centro hacia arriba y del centro hacia abajo), segundo para poder hacer uso del DMA para transferir a la VRAM mas rapido, solo se necesitan unas 80 lineas para transferir todo el buffer(16KB).

Perfecto, todo aclarado.

Muchas gracias por la explicación.

Un Saludo.

Creo que no había escrito aun en este hilo, pero lo he seguido desde el principio con mucho interés, ya que creo que es un proyecto increíble y que me deja si palabras. Quizá lo mejor que puedo decir es muchas gracias gasega68k, tu trabajo me parece de lujo y espero, que sigo con entusiasmo este proyecto.

¡Graciaas por todo!

Un saludo.

capitan_link escribió:Me pregunto cuanto terminara ocupando y si podrá caber en un cartucho.

Esta pregunta es muy interesante. Molaría jugarlo en formato físico.

legionpsm escribió:Creo que no había escrito aun en este hilo, pero lo he seguido desde el principio con mucho interés, ya que creo que es un proyecto increíble y que me deja si palabras. Quizá lo mejor que puedo decir es muchas gracias gasega68k, tu trabajo me parece de lujo y espero, que sigo con entusiasmo este proyecto.

¡Graciaas por todo!

Un saludo.

Mas o menos vengo a decir lo mismo. No quería ensuciar el hilo, pero ahora que está escribiendo aquí el autor de ésta maravilla lo menos que puedo hacer es dejar mis felicitaciones y dar las gracias por el esfuerzo y el tiempo invertido.

Yo tengo una pregunta para gasega68k:

¿Existen posibilidades técnicas para pasar todos los enemigos, jefes, sonidos y música para hacer un port completo del juego?

Excelente trabajo, esto puede convertirse en un engine para desarrollos posteriores

Luceid escribió:

capitan_link escribió:Me pregunto cuanto terminara ocupando y si podrá caber en un cartucho.

Esta pregunta es muy interesante. Molaría jugarlo en formato físico.

De momento va por los 8MBits de ROM, hasta 32 no hay problema Aun no lo he pasado al Everdrive... como va en la consola real? impresionante no?

Porque 32 Pier solar no ocupa 64mb???

OsQuiLLa escribió:Porque 32 Pier solar no ocupa 64mb???

mas de 32Mb necesita Mapper y solo el Super Street Fighter II y algunos de 32x creo lo tenia.... el MegaEverdrive si lo implementa pero el Everdrive normal no.

altbrian escribió:¿Existen posibilidades técnicas para pasar todos los enemigos, jefes, sonidos y música para hacer un port completo del juego?

Si, y sobre la pregunta del tamaño que ocuparia, yo creo que estaria entre 2 y 3 MB (16 a 24 mbit).
Algo que se me olvido mencionar (incluso en los foros en ingles) es que aun puedes escojer nivel, pero ahora es en la pantalla de seleccion de episodio (mantener START y presionar A).

gasega68k escribió:

altbrian escribió:¿Existen posibilidades técnicas para pasar todos los enemigos, jefes, sonidos y música para hacer un port completo del juego?

Si, y sobre la pregunta del tamaño que ocuparia, yo creo que estaria entre 2 y 3 MB (16 a 24 mbit).
Algo que se me olvido mencionar (incluso en los foros en ingles) es que aun puedes escojer nivel, pero ahora es en la pantalla de seleccion de episodio (mantener START y presionar A).

Buenas,

¿Te va a llevar mucho trabajo que los enemigos disparen?

Otras cosas:

¿En SNES el tamaño de los sprites es menor que en el de PC verdad?
¿Porque es tan vergonzoso el port de GBA siendo mucho más potente y tu has hecho un port a megadrive con una calidad mejor y sin ser un trabajo comercial?

Un Saludo.

Hola, gracias por todos los comentarios y por la bienvenida a este foro.
A responder:

naxeras escribió:¿Te va a llevar mucho trabajo que los enemigos disparen?

Ya no falta mucho.

naxeras escribió:¿En SNES el tamaño de los sprites es menor que en el de PC verdad?

No, los sprites tienen el mismo tamaño, pero las texturas de las paredes tienen un tamaño de 32x32, en vez de 64x64 como el de pc y esta version que estoy haciendo.

naxeras escribió:¿Porque es tan vergonzoso el port de GBA siendo mucho más potente y tu has hecho un port a megadrive con una calidad mejor y sin ser un trabajo comercial?

Quizas fue programado enteramente en C y no en asm, sobretodo para dibujar las texturas(paredes) y sprites, ademas con solo ver el juego se que no usaron el engine original de wolf3d, porque se ven unos pequeños errores en las paredes y se que el engine original no produce estos errores. Si se programa enteramente en asm, estoy seguro que seria mucho mas rapido, quizas nunca bajaria de los 30fps.

gasega68k, en vista de lo bien que se te está dando la conversion de este Wolfenstein3D de PC a megadrive, te veremos en un futuro haciendo alguna otra conversion similar?

bertobp escribió:gasega68k, en vista de lo bien que se te está dando la conversion de este Wolfenstein3D de PC a megadrive, te veremos en un futuro haciendo alguna otra conversion similar?

Spear of Destiny seria facil adaptarlo tambien, ya que usa el mismo engine y casi los mismos graficos, algun otro juego aun no lo se. Tambien quiero seguir experimentando con otro engine de raycast que hice antes para hacer algo diferente(quizas con texturas en el piso/techo y otras cosas mas) y tambien con un engine 3d al estilo starfox.

gasega68k, primero que nada, quiero felicitarte por el trabajo que estas realizando, por portar el wolfenstein3d para megadrive, debe ser una tarea de locos optimazar el engine para que el juego sea 100% jugable , y por casualidad, ¿no programas cosas para la SNES?.
Saludos.

gasega68k, un trabajo fantástico y se agradece que se sigan haciendo estos proyectos.

naxeras escribió:Meto un vídeo donde se puede apreciar sprites de enemigos a saco en la Megadrive:

https://www.youtube.com/watch?v=DW7cL8upBtk

El autor comenta que va a optimizar ya que ha aprendido trucos nuevos.

Es impresionante

Bienvenido gasega68k

Es impresionante el trabajo que has realizado en este proyecto y el resultado luce espectacular!!

gaseka una pregunta....
¿sería difícil hacer un port de tu conversión a Amiga 500?

Yo quisiera preguntar acerca de un detalle que me ha llamado la atención del engine... ¿ese entramado que tienen las paredes/sprites/etc, se debe a motivos de rendimiento?. Si es así, ¿cuánto calculas que consigues ganar gracias a eso?.

Y luego otra pregunta sobre el scaling de los sprites. ¿Crees que es implementable en un juego mas ordinario?... y de nuevo, ¿te ocupa mucho procesador implementar esa rutina?.

Hola aqui estoy de nuevo para responderles.

doblete escribió:gasega68k, primero que nada, quiero felicitarte por el trabajo que estas realizando, por portar el wolfenstein3d para megadrive, debe ser una tarea de locos optimazar el engine para que el juego sea 100% jugable , y por casualidad, ¿no programas cosas para la SNES?.
Saludos.

Muchas gracias, optimizar es una de las partes mas importantes para lograr un buen desempeño del engine, pero tambien puede ser un poco dificil encontrar maneras de optimizar. Cuando mostre por primera vez este demo, en agosto de 2013, yo pensaba que ya no podia mejorarlo mas, pero ya he optimizado varias veces mas este engine, y aun se puede optimizar un poco. No he programado para SNES.

sgonzalez escribió:gaseka una pregunta....
¿sería difícil hacer un port de tu conversión a Amiga 500?

Si es por el codigo seria facil, ya que usa el mismo cpu(68000) y tiene casi la misma velocidad(7.15MHZ), pero no se como funcionan los modos graficos de esta maquina, ya que de esto depende mucho para lograr una buena velocidad a la hora de dibujar sprites/paredes.

Señor Ventura escribió:Yo quisiera preguntar acerca de un detalle que me ha llamado la atención del engine... ¿ese entramado que tienen las paredes/sprites/etc, se debe a motivos de rendimiento?. Si es así, ¿cuánto calculas que consigues ganar gracias a eso?.

Si, es por motivo de rendimiento y ademas para simular mas colores, ya que un pixel son 4bits y un byte equivale a dos pixeles, y en este engine se dibujan por byte. Como solo hay 16 colores, con un byte se pueden combinar dos colores diferentes(dos pixeles de 4bits = un byte) y "simular" mas colores, conectando el sega con un TV, usando video o RF no se notan estas lineas y parece como si hubieran mas colores.
Si tratara de hacerlo pixel por pixel, creo que seria mas del doble de lento para dibujar.

Señor Ventura escribió:Y luego otra pregunta sobre el scaling de los sprites. ¿Crees que es implementable en un juego mas ordinario?... y de nuevo, ¿te ocupa mucho procesador implementar esa rutina?.

Si se puede implementar en cualquier otro tipo de juego, quizas pudiera ser incluso un poco mas rapido, sobre si ocupa mucho procesador, eso depende de cuantos sprites hayan o el tamaño de ellos.

gasega68k escribió:Si, es por motivo de rendimiento y ademas para simular mas colores, ya que un pixel son 4bits y un byte equivale a dos pixeles, y en este engine se dibujan por byte. Como solo hay 16 colores, con un byte se pueden combinar dos colores diferentes(dos pixeles de 4bits = un byte) y "simular" mas colores, conectando el sega con un TV, usando video o RF no se notan estas lineas y parece como si hubieran mas colores.
Si tratara de hacerlo pixel por pixel, creo que seria mas del doble de lento para dibujar.

Vamos, que el detalle es únicamente que el engine dibuja los pixels en grupos de 2, es decir, que para el engine un pixel ocupa dos en pantalla (con el añadido de que se añade un tono negro adicional), y así gana el doble de renidmiento, ¿no?.

Lo que no entiendo bien es lo de simular colores. Si la linea negra es negra, pues es negra... y si se "oculta" en pantallas de tubo, pues no se entremezcla, ¿no?.

gasega68k escribió:Si se puede implementar en cualquier otro tipo de juego, quizas pudiera ser incluso un poco mas rapido

¿Es escalado real?, o simulado. Cuentanos algo sobre el... cuánto ocupa el código, por ejemplo, o si te fijaste en algún ejemplo, cuánto tiempo te llevó idearlo, etc.

gasega68k escribió:sobre si ocupa mucho procesador, eso depende de cuantos sprites hayan o el tamaño de ellos.

Claro, cuantos mas sprites soliciten un cálculo con esa rutina, mas procesador se usará.

Me refiero a cuánto procesador extra es necesario por cada sprite. Vamos, que si es una rutina muy costosa en términos de potencia, algo que hayas controlado en tus pruebas.


P.D: Y una pregunta para los que se interesan por la versión snes. ¿Crees que aplicando el método de dibujar ese entramado de lineas negras, se puede aumentar la nitidez? (al borrar la mitad de los pixels, los que quedan podrían conformar imagenes menos pixeladas, ya que la cantidad de información se quedaría exactamente como estaba antes de aplicar esa técnica, ¿no?).


EDIT: Mira, otra cosa mas. Imagino que la resolución en megadrive es de 320x240... ¿has probdo a reducirla?. O hacer dos versiones para no marginar la idea original.

Me encanta leerte, en este foro hay gente que decía que no se podía portar código de una CPU 68000 a otra y vas y lo desmientes.

¿Toda esa gente que decía que megadrive no tenía ventaja en ports arcade que tenían CPU 68000 (CPS1) y defendían la SNES a muerte en estos ports arcade donde están ahora?

Es increíble ver scaling de sprites en megadrive, en este foro se puso en duda ya que sega siempre usaba el método de meter sprites de diferentes tamaños en la VRAM e irles alternando.

Me encanta el trabajo que has hecho la verdad, se ve además que la mega mueve un montón de enemigos simultaneos.

Que ganas tengo de qe los enemigos disparen!!!.

Hola, aqui estoy de nuevo para responder algunas dudas.

Señor Ventura escribió:Vamos, que el detalle es únicamente que el engine dibuja los pixels en grupos de 2, es decir, que para el engine un pixel ocupa dos en pantalla (con el añadido de que se añade un tono negro adicional), y así gana el doble de renidmiento, ¿no?.

Lo que no entiendo bien es lo de simular colores. Si la linea negra es negra, pues es negra... y si se "oculta" en pantallas de tubo, pues no se entremezcla, ¿no?.

Voy a tratar de explicarlo mejor, en el sega genesis/megadrive un pixel ocupa 4bits y dos pixeles 8bits es decir un byte. Cada pixel tiene un color, pero con la combinacion de dos colores(dos pixeles) se puede simular mas colores, es decir cada pixel utiliza un color de la paleta (uno de 16), por ejemplo, un byte con $27(numero hexadecilmal), el 2 es un color gris oscuro y el 7 es un rojo, con esta combinacion se simula un color rojo mas oscuro, el mejor ejemplo de esto esta en el nivel secreto, que esta formado en su mayoria con el color purpura, pero en realidad este color se hace combinando azules y rojos. De este modo se pueden simular un maximo de 136 colores, pero esto depende de la paleta usada porque algunas combinaciones de colores pueden ser muy similares o iguales, en mi caso son unos 72 colores que son "usables". El engine dibuja por bytes, es decir por cada dos pixeles.

Señor Ventura escribió:¿Es escalado real?, o simulado. Cuentanos algo sobre el... cuánto ocupa el código, por ejemplo, o si te fijaste en algún ejemplo, cuánto tiempo te levó idearlo, etc.

Si es escalado real, cuando se habla de escalado simulado es cuando hay una cierta cantidad de imagenes una por cada "tamaño" del sprite, en este caso no es asi, es la misma imagen que, dependiendo de la distancia del objeto se calcula el tamaño y se dibuja.
En cuanto el tamaño del codigo no se exactamente, pero el escalado son dos: uno para las paredes y otro para los sprites, esto es asi porque en los sprites hay que tomar en cuenta el color transparente(el color 0)para no dibujarlo, creo que entre ambos esta cerca de unos 150KB - 160KB. Para hacer este codigo, en realidad me fije en muchos ejemplos entre ellos esta el Duke nukem 3d de sega genesis, tambien en algunos ejemplos que vi en internet(creo que fue de una computadora que usaba el 68000 tambien, no recuerdo bien), y tambien el wolf3d de SNES, asi que podria decir que es una combinacion de muchos ejemplos, bueno sobre el tiempo que me tomo no podria decir exactamente quizas unos meses.
Sobre cuanto procesador usa, es dificil decirlo, el calculo necesario antes de dibujar cada sprite no es mucho, solo al dibujarlo es que se necesita mas cpu, pero saber exactamente el uso de cpu es dificil, eso depende de muchos factores, por ejemplo si el sprite esta mas cerca, es decir se ve mas "pixelado", por cada pixel dibujado seria mas rapido, pero se dibujarian mas pixeles, tambien si la imagen tiene muchos pixeles transparentes(color 0), el sprite se dibujara mas rapido.

Señor Ventura escribió:P.D: Y una pregunta para los que se interesan por la versión snes. ¿Crees que aplicando el método de dibujar ese entramado de lineas negras, se puede aumentar la nitidez? (al borrar la mitad de los pixels, los que quedan podrían conformar imagenes menos pixeladas, ya que la cantidad de información se quedaría exactamente como está antes de aplicar esa técnica, ¿no?).

La version de SNES tiene una "area de vision" de 224x160, pero en realidad en termino de pixeles es de 112x80, usa un buffer de 8960 bytes, lo que hicieron fue usar el modo7 para poder "acercar" la imagen a 2x y para poder usar 256 colores, de este modo un byte equivale a 2x2 pixeles en pantalla. El escalado de sprites y paredes esta hecho con puro codigo, el modo7 solo lo usaron para acercar la imagen y de esta forma sea mas rapido, ya que solo hay 8960 "pixeles" para dibujar en pantalla(pixeles de 2x2).

Para aumentar la nitidez en la version de SNES, primero habria que aumentar la resolucion vertical, que en vez de 80, tuviera al menos 128 lineas verdaderas, y para aumentar la nitidez en sentido horizontal, si se usa el modo de 256 colores habria que aumentar la resolucion al doble, pero se necesitaria el doble de memoria, ahora si se usa un modo de 16 colores seria la misma cantidad de memoria necesaria, pero el problema esta en que el modo de 16 colores del snes se implementa lo que se llama el modo "planar", en donde un byte equivale a 8 pixeles de un bit de color, entonces para 16 colores se necesitan 4 planos, uno por cada bit de color, (en el nes hay dos planos, es decir dos bit de color = 4 colores), realmente es muy complicado de explicar mejor este modo, pero lo que es seguro es que se hace muy dificil implementar un raycast (al menos a una buena velocidad). De cualquier forma, para aumentar la nitidez, se necesita aumentar la resolucion, pero seria mas lento, al menos que se usara un chip para aumentar la velocidad.

Señor Ventura escribió:EDIT: Mira, otra cosa mas. Imagino que la resolución en megadrive es de 320x240... ¿has probdo a reducirla?. O hacer dos versiones para no marginar la idea original.

He pensado hacer eso, usar el modo de 256x224 para otras pruebas, ya veremos.

naxeras escribió:Me encanta leerte, en este foro hay gente que decía que no se podía portar código de una CPU 68000 a otra y vas y lo desmientes.

¿Toda esa gente que decía que megadrive no tenía ventaja en ports arcade que tenían CPU 68000 (CPS1) y defendían la SNES a muerte en estos ports arcade donde están ahora?

Es increíble ver scaling de sprites en megadrive, en este foro se puso en duda ya que sega siempre usaba el método de meter sprites de diferentes tamaños en la VRAM e irles alternando.

Me encanta el trabajo que has hecho la verdad, se ve además que la mega mueve un montón de enemigos simultaneos.

Que ganas tengo de qe los enemigos disparen!!!.

Parece que no entendiste lo que se te explicó en el otro hilo y que el mismo gasega68k te ha vuelto a explicar.
Prácticamente lo único que tiene igual la Megadrive con el CPS1 es la CPU ni más ni menos.
Le pregunté a gasega68k si el port a Amiga 500 sería posible por si tenía conocimientos de programación en esta arquitectura y como él bien ha respondido el código ejecutado en la CPU sería casi el mismo pero todo el tema gráfico lógicamente cambiaría.

gasega68k escribió:Voy a tratar de explicarlo mejor, en el sega genesis/megadrive un pixel ocupa 4bits y dos pixeles 8bits es decir un byte. Cada pixel tiene un color, pero con la combinacion de dos colores(dos pixeles) se puede simular mas colores, es decir cada pixel utiliza un color de la paleta (uno de 16), por ejemplo, un byte con $27(numero hexadecilmal), el 2 es un color gris oscuro y el 7 es un rojo, con esta combinacion se simula un color rojo mas oscuro, el mejor ejemplo de esto esta en el nivel secreto, que esta formado en su mayoria con el color purpura, pero en realidad este color se hace combinando azules y rojos. De este modo se pueden simular un maximo de 136 colores, pero esto depende de la paleta usada porque algunas combinaciones de colores pueden ser muy similares o iguales, en mi caso son unos 72 colores que son "usables". El engine dibuja por bytes, es decir por cada dos pixeles.

Entiendo entonces, que si el límite es de 64 colores, a base de mezclarlos en grupos de 2 pixels, consigues una veriedad de 72, ¿no?.

gasega68k escribió:Si es escalado real, cuando se habla de escalado simulado es cuando hay una cierta cantidad de imagenes una por cada "tamaño" del sprite, en este caso no es asi, es la misma imagen que, dependiendo de la distancia del objeto se calcula el tamaño y se dibuja.
En cuanto el tamaño del codigo no se exactamente, pero el escalado son dos: uno para las paredes y otro para los sprites, esto es asi porque en los sprites hay que tomar en cuenta el color transparente(el color 0)para no dibujarlo, creo que entre ambos esta cerca de unos 150KB - 160KB. Para hacer este codigo, en realidad me fije en muchos ejemplos entre ellos esta el Duke nukem 3d de sega genesis, tambien en algunos ejemplos que vi en internet(creo que fue de una computadora que usaba el 68000 tambien, no recuerdo bien), y tambien el wolf3d de SNES, asi que podria decir que es una combinacion de muchos ejemplos, bueno sobre el tiempo que me tomo no podria decir exactamente quizas unos meses.
Sobre cuanto procesador usa, es dificil decirlo, el calculo necesario antes de dibujar cada sprite no es mucho, solo al dibujarlo es que se necesita mas cpu, pero saber exactamente el uso de cpu es dificil, eso depende de muchos factores, por ejemplo si el sprite esta mas cerca, es decir se ve mas "pixelado", por cada pixel dibujado seria mas rapido, pero se dibujarian mas pixeles, tambien si la imagen tiene muchos pixeles transparentes(color 0), el sprite se dibujara mas rapido.

Antes que nada, quería preguntarte si la velocidad del escalado de los sprites afecta mucho al rendimiento. Es decir, si los muñecos simplemente caminasen mas deprisa, ¿supondría un gasto extra de cpu por necesitar implementar el escalado mas deprisa?, o el resultado del cálculo es mas irrelevante en términos de cpu que el propio proceso de cálculo.

Por mi parte, siento curiosidad sobre cuales son tus estimaciones en cuanto a la depuración de estos códigos que has implementado en tu engine, ¿eres optimista de cara a optimizar?, o ya se empiezan a reducir los márgenes de mejora.

Por otra parte, no se si te he entendido bien, pero, ¿has dicho que hay partes del código del wolfenstein de snes que están disponibles?.

gasega68k escribió:La version de SNES tiene una "area de vision" de 224x160, pero en realidad en termino de pixeles es de 112x80, usa un buffer de 8960 bytes, lo que hicieron fue usar el modo7 para poder "acercar" la imagen a 2x y para poder usar 256 colores, de este modo un byte equivale a 2x2 pixeles en pantalla. El escalado de sprites y paredes esta hecho con puro codigo, el modo7 solo lo usaron para acercar la imagen y de esta forma sea mas rapido, ya que solo hay 8960 "pixeles" para dibujar en pantalla(pixeles de 2x2).

Esto me parece impresionante. Básicamente el VDP de snes hace las veces de re-escalador, como el chip HANA de 360, ¿no? xD. ¿Puedes hablarnos de como funciona el proceso de escalado en snes? (me intriga, porque el modo 7 trabaja con la RAM, y no se si esto implica que salgan las imagenes ya escaladas desde ahí, en vez de desde la VRAM).

Y bueno, parece que la cpu de snes tira mas de lo que parece, pero aún así tal vez sea un poco decepcionante que internamente la resolución sea de 112x80. En base a la teoría, ¿que propondrías tu para mejorar el rendimiento obtenido?.

Desde mi punto de vista, observo que va bastante sueltito en cuanto a rendimiento, y me intriga saber si dieron el trabajo por finalizado al conseguir hacerlo funcionar a 112x80/224x160, ¿crees que se conformaron y dejaron de probar cosas, y/o de optimizar?, es que el hardware no se queda corto en ningún momento.

gasega68k escribió:Para aumentar la nitidez en la version de SNES, primero habria que aumentar la resolucion vertical, que en vez de 80, tuviera al menos 128 lineas verdaderas, y para aumentar la nitidez en sentido horizontal, si se usa el modo de 256 colores habria que aumentar la resolucion al doble, pero se necesitaria el doble de memoria, ahora si se usa un modo de 16 colores seria la misma cantidad de memoria necesaria, pero el problema esta en que el modo de 16 colores del snes se implementa lo que se llama el modo "planar", en donde un byte equivale a 8 pixeles de un bit de color, entonces para 16 colores se necesitan 4 planos, uno por cada bit de color, (en el nes hay dos planos, es decir dos bit de color = 4 colores), realmente es muy complicado de explicar mejor este modo, pero lo que es seguro es que se hace muy dificil implementar un raycast (al menos a una buena velocidad). De cualquier forma, para aumentar la nitidez, se necesita aumentar la resolucion, pero seria mas lento, al menos que se usara un chip para aumentar la velocidad.

Lo que comentaba, era que si snes está dibujando 8960 pixels, añadir franjas negras en un principio solo haría aumentar el tamaño del buffer, no el esfuerzo por dibujarlos. Con esto tal vez se pueda expandir la resolución horizontal, hacer una proporción con el ancho y aumentar la resolución vertical. Y es en ese momento cuando los pixels dibujados pasan de dibujar un "dato entero", a dibujar la mitad, pero mas definido (con lo cual, la percepción de todo es de mayor definición, con el mismo número de pixels, sin contar los pixels de las franjas).

gasega68k escribió:

Señor Ventura escribió:EDIT: Mira, otra cosa mas. Imagino que la resolución en megadrive es de 320x240... ¿has probdo a reducirla?. O hacer dos versiones para no marginar la idea original.

He pensado hacer eso, usar el modo de 256x224 para otras pruebas, ya veremos.

No dejes de informarnos sobre tus progresos, las ideas que se te vayan ocurriendo, y demás cosillas que te apetezca contarnos. Creo que aquí somos unos cuántos los que estamos muy entusiasmados con tu trabajo, así que ante todo quisiera darte las gracias, está siendo muy instructivo todo

Hola a todos.

Señor Ventura escribió:Entiendo entonces, que si el límite es de 64 colores, a base de mezclarlos en grupos de 2 pixels, consigues una veriedad de 72, ¿no?.

En realidad son 72 colores de una paleta de 16, el sega genesis/megadrive tiene 4 paletas de 16 colores. En este juego uso las cuatro paletas de esta forma: la primera es para el "area de vision" en la que se dibujan los sprites y paredes(en donde se simulan los 72 colores), la segunda es para el "HUD"(Heads-Up Display, en donde se muestran las vidas puntuacion, etc.) y para los bordes, la tercera paleta es para el arma del jugador y la cuarta paleta es para la cara del personaje.

Señor Ventura escribió:Antes que nada, quería preguntarte si la velocidad del escalado de los sprites afecta mucho al rendimiento. Es decir, si los muñecos simplemente caminasen mas deprisa, ¿supondría un gasto extra de cpu por necesitar implementar el escalado mas deprisa?, o el resultado del cálculo es mas irrelevante en términos de cpu que el propio proceso de cálculo.

No, la velocidad con que caminan los enemigos no tienen que ver con el escalado, la rutina para los movimientos de los enemigos y para el escalado son dos diferentes, es decir primero se hacen los movimientos de todos los enemigos y despues viene la rutina para dibujarlos.

Señor Ventura escribió:Por mi parte, siento curiosidad sobre cuales son tus estimaciones en cuanto a la depuración de estos códigos que has implementado en tu engine, ¿eres optimista de cara a optimizar?, o ya se empiezan a reducir los márgenes de mejora.

Bueno, por supuesto cada vez es mas difìcil optimizar, pero aun hay ciertas partes que se pueden optimizar, pero aun asi estoy conforme con los resultados obtenidos actualmente.

Señor Ventura escribió:Por otra parte, no se si te he entendido bien, pero, ¿has dicho que hay partes del código del wolfenstein de snes que están disponibles?.

No, lo que pasa es que utilizo emuladores con debugger para "curiosear" en el codigo.

Señor Ventura escribió:Esto me parece impresionante. Básicamente el VDP de snes hace las veces de re-escalador, como el chip HANA de 360, ¿no? xD. ¿Puedes hablarnos de como funciona el proceso de escalado en snes? (me intriga, porque el modo 7 trabaja con la RAM, y no se si esto implica que salgan las imagenes ya escaladas desde ahí, en vez de desde la VRAM).

Y bueno, parece que la cpu de snes tira mas de lo que parece, pero aún así tal vez sea un poco decepcionante que internamente la resolución sea de 112x80. En base a la teoría, ¿que propondrías tu para mejorar el rendimiento obtenido?.

Desde mi punto de vista, observo que va bastante sueltito en cuanto a rendimiento, y me intriga saber si dieron el trabajo por finalizado al conseguir hacerlo funcionar a 112x80/224x160, ¿crees que se conformaron y dejaron de probar cosas, y/o de optimizar?, es que el hardware no se queda corto en ningún momento.

Bueno, sobre el proceso de escalado de sprites y paredes en el snes, como dije antes se hace con puro codigo, es decir no usa el el modo7. Por ejemplo si se usara el modo3 o 4, que tambien tiene 256 colores, funcionaria igual, solo que se veria la imagen pequeña en el centro, con un tamaño real de 112x80.
Aunque creo que la forma en que hicieron este juego sin uso de algun chip, fue lo mejor que pudieron hacer, ya que hicieron uso de algunos "trucos" del hardware que ayudaron mucho a hacerlo lo mejor posible.

Señor Ventura escribió:Lo que comentaba, era que si snes está dibujando 8960 pixels, añadir franjas negras en un principio solo haría aumentar el tamaño del buffer, no el esfuerzo por dibujarlos. Con esto tal vez se pueda expandir la resolución horizontal, hacer una proporción con el ancho y aumentar la resolución vertical. Y es en ese momento cuando los pixels dibujados pasan de dibujar un "dato entero", a dibujar la mitad, pero mas definido (con lo cual, la percepción de todo es de mayor definición, con el mismo número de pixels, sin contar los pixels de las franjas).

Lo que pasa es que seria necesario aumentar la resolucion para hacer esto y asi se necesitaria el doble de memoria, o usar el modo de 16 colores para que de esta forma se use la misma cantidad de memoria, pero en el modo de 16 colores se hace muy dificil como dije antes.

Señor Ventura escribió:No dejes de informarnos sobre tus progresos, las ideas que se te vayan ocurriendo, y demás cosillas que te apetezca contarnos. Creo que aquí somos unos cuántos los que estamos muy entusiasmados con tu trabajo, así que ante todo quisiera darte las gracias, está siendo muy instructivo todo

Ya en este momento los guardias pueden disparar, pero aun no caminan, estoy muy conforme con los resultados obtenidos hasta ahora, ya que esta rutina de los enemigos para disparar era una de la que mas me "preocupaba" de que pudiera causar alguna baja en el rendimiento, pero he comprobado de que aun se mantiene la velocidad. Creo que en esta semana ya tendre los guardias caminando y disparando, despues para los demas enemigos ya sera mucho mas facil, ya que comparten el mismo codigo(caminar, disparar, perseguir, etc).

gasega68k escribió:Ya en este momento los guardias pueden disparar, pero aun no caminan, estoy muy conforme con los resultados obtenidos hasta ahora, ya que esta rutina de los enemigos para disparar era una de la que mas me "preocupaba" de que pudiera causar alguna baja en el rendimiento, pero he comprobado de que aun se mantiene la velocidad. Creo que en esta semana ya tendre los guardias caminando y disparando, despues para los demas enemigos ya sera mucho mas facil, ya que comparten el mismo codigo(caminar, disparar, perseguir, etc).

Que ganas de que lo tengas funcionando.

Una pregunta gasega68k que es lo que nos intrigaba, en tu opinión si te mandaran portar un juego de CPS1 a Megadrive que hardware es más "apto" para dicho port, Megadrive o SNES.

Un Saludo.

Sega does nintendon't xD

No en serio, sera solo curiosidad y no ganas de tocar la moral.

gasega68k escribió:En realidad son 72 colores de una paleta de 16, el sega genesis/megadrive tiene 4 paletas de 16 colores. En este juego uso las cuatro paletas de esta forma: la primera es para el "area de vision" en la que se dibujan los sprites y paredes(en donde se simulan los 72 colores), la segunda es para el "HUD"(Heads-Up Display, en donde se muestran las vidas puntuacion, etc.) y para los bordes, la tercera paleta es para el arma del jugador y la cuarta paleta es para la cara del personaje.

Lo cual implica manejar cuatro planos simultaneos por software, ok.

Visualmente queda adaptado de otra forma, aunque a nivel de software implica el mismo esfuerzo internamente que dibujar cuatro planos de scroll parallax.

gasega68k escribió:No, la velocidad con que caminan los enemigos no tienen que ver con el escalado, la rutina para los movimientos de los enemigos y para el escalado son dos diferentes, es decir primero se hacen los movimientos de todos los enemigos y despues viene la rutina para dibujarlos.

Lo que comentaba era un ejemplo que implicase un zoom muy rápido, vamos, nada que ver con el movimiento de los sprites. En otras palabras... ¿tal vez el tener que aplicar la rutina de escalado mas rápido, necesite de mas rendimiento adicional?.

gasega68k escribió:Bueno, sobre el proceso de escalado de sprites y paredes en el snes, como dije antes se hace con puro codigo, es decir no usa el el modo7. Por ejemplo si se usara el modo3 o 4, que tambien tiene 256 colores, funcionaria igual, solo que se veria la imagen pequeña en el centro, con un tamaño real de 112x80.

Si, eso es lo que entendí, gracias

gasega68k escribió:Lo que pasa es que seria necesario aumentar la resolucion para hacer esto y asi se necesitaria el doble de memoria, o usar el modo de 16 colores para que de esta forma se use la misma cantidad de memoria, pero en el modo de 16 colores se hace muy dificil como dije antes.

Tambien es cierto que incluso usando el modo de 256 colores, no tiene por qué ser obligado dibujar tiles de semejante profundidad.

Incluso se puede aprovechar que su paleta permite poner un color sin tener que gastar varios para obtenerlo, para que con menos colores se pueda conseguir un resultado muy parecido, y así ahorrar memoria de vídeo para aumentar la resolución.
Precisamente esa es la ventaja de una paleta de colores tan grande: la posibilidad de ahorrar memoria de vídeo prescindiendo de las mezclas.

Solucionado eso... ya todo sería ver como soporta el rendimiento de una mayor resolución, porque ya de por si va muy sobrado (para lo que es), por lo que, quede algo de margen para subir un poquito el nivel.

¿A que frame rate funciona la versión snes?.

gasega68k escribió:Ya en este momento los guardias pueden disparar, pero aun no caminan, estoy muy conforme con los resultados obtenidos hasta ahora, ya que esta rutina de los enemigos para disparar era una de la que mas me "preocupaba" de que pudiera causar alguna baja en el rendimiento, pero he comprobado de que aun se mantiene la velocidad. Creo que en esta semana ya tendre los guardias caminando y disparando, despues para los demas enemigos ya sera mucho mas facil, ya que comparten el mismo codigo(caminar, disparar, perseguir, etc).

Avanzas muy rápido

Me alegro mucho de que te estén saliendo los planes bien... deseando estoy de ver como te queda esa versión definitiva (y mas aún a 256x224, ¡¡tiene que volar eso!!).

¿Crees que podrá ser posible imitar el script de movimientos de la versión pc?, es decir, el zigzagueo, la forma en que te persiguen, la puntería de los enemigos, etc.

naxeras escribió:Una pregunta gasega68k que es lo que nos intrigaba, en tu opinión si te mandaran portar un juego de CPS1 a Megadrive que hardware es más "apto" para dicho port, Megadrive o SNES.

Naxeras, si sigues, te vas a cargar el hilo.

No es tan difícil abrir otro, que digo yo que para tratar un tema clónico en el foro no hace falta destrozar un hilo único e irrepetible como este.

Señor Ventura escribió:No es tan difícil abrir otro, que digo yo que para tratar un tema clónico en el foro no hace falta destrozar un hilo único e irrepetible como este.

En efecto, no es necesario desviar el hilo con un off-topic como ese, que lo solo generaría una polémica completamente innecesaria en este hilo.
En este sentido, ese off-topic ha acabado, aquí, si queréis profundizar sobre esa duda os pediría que abrieses un nuevo hilo, no en este.

Un saludo

Señor Ventura escribió:

gasega68k escribió:En realidad son 72 colores de una paleta de 16, el sega genesis/megadrive tiene 4 paletas de 16 colores. En este juego uso las cuatro paletas de esta forma: la primera es para el "area de vision" en la que se dibujan los sprites y paredes(en donde se simulan los 72 colores), la segunda es para el "HUD"(Heads-Up Display, en donde se muestran las vidas puntuacion, etc.) y para los bordes, la tercera paleta es para el arma del jugador y la cuarta paleta es para la cara del personaje.

Lo cual implica manejar cuatro planos simultaneos por software, ok.

Visualmente queda adaptado de otra forma, aunque a nivel de software implica el mismo esfuerzo internamente que dibujar cuatro planos de scroll parallax.

Te contesto yo que ésta es fácil:

No tiene nada que ver el conteo del número de paletas, que son cuatro en megadrive, con el número de planos. La megadrive por hardware dispone de dos planos, SNES por ejemplo proporciona tres.

Simplemente te está comentando la manera en que asigna las paletas a los elementos de pantalla, pero esto es indiferente al número de planos. Un mismo plano puede contener las cuatro paletas aunque pocos juegos hacen uso de eso principalmente porque sin herramientas es un coñazo diseñar fondos especificando qué tiles (bloques de ocho por ocho pixels que se repiten componiendo el mapeado) estarán vinculados a cada una de las cuatro paletas.

Paletas una cosa, planos otra.

De hecho aunque como digo por hardware megadrive tiene dos planos, es posible "forzarle" un (falso) plano extra conocido como "plano W" o "plano Window" destinado por lo general a mostrar los HUD de los juegos; es realmente una región del plano A que se bloquea con mayor prioridad que cualquiera del resto de elementos (para que aparezca por encima de todos ellos y en una posición fija).

El método que usa gasega68k para dibujar el área de juego es mediante una "técnica" llamada "framebuffer" y no mediante el scroll de mapeados de tiles que se puede ver en la mayoría de los juegos. Piensa en Sonic: las plataformas de primer plano van dibujadas en un plano, el fondo en el otro. El parallax se consigue haciendo scroll de líneas de tiles independientes sobre un fondo. Eso lo hace la consola por hardware.

Para programar un raycaster sin embargo no vale ese sistema clásico de scroll de planos por lo que lo que hay que hacer es componer el gráfico de lo que se desee mandar a pantalla sobre una zona de memoria que generalmente está destinada a alinear la información gráfica de tiles mediante los cuales y consultando un "mapa de tiles" se generarán los fondos scrolleables. En un raycast en esa área de memoria para tiles debes componer la imagen, frame a frame. Luego el código ha de ser lo suficientemente rápido tanto para crear esa imagen en el menos tiempo posible como a la hora de mandarla a pantalla (dibujarla sobre el plano correspondiente).

Ya te explicará gasega68k más debidamente, pero de momento sólo comentarte que te has liado un poco asociando paletas, planos y scroll.

Y aparco por aquí para no offtopiquear el hilo.

Gasega, fenomenal trabajo y de nuevo gracias también por responder siempre tan atentamente. Suerte con el remate de la faena!

salvor70 escribió:En este sentido, ese off-topic ha acabado, aquí, si queréis profundizar sobre esa duda os pediría que abrieses un nuevo hilo, no en este.

Creo que el aviso era bastante claro e incluía cualquier polémica a este respecto.

En este sentido, naxeras, si crees que algún mensaje no cumple las normas o no es adecuado o que nos ha escapado al revisar un hilo , lo reportas, ya nos encargaremos desde moderación.

Desde luego, vamos a dejar de calificar de troleada o no los comentarios.

Hola a todos, primero responderé a algunas preguntas y despues... ¡buenas noticias!.

Señor Ventura escribió:Lo que comentaba era un ejemplo que implicase un zoom muy rápido, vamos, nada que ver con el movimiento de los sprites. En otras palabras... ¿tal vez el tener que aplicar la rutina de escalado mas rápido, necesite de mas rendimiento adicional?.

Aun cuando el zoom sea mas rápido será siemple igual los calculos, porque siempre se dibuja a la misma velocidad, por ejemplo cuando el juego tiene 15 fps significa que se actualizará 15 veces por segundo el buffer de la imagen (sprites y paredes), sin importar la velocidad de los enemigos o del "zoom".

¿A que frame rate funciona la versión snes?.

No lo se, pero lo que si se es que la mayoria de los emuladores no muestra la velocidad real(funciona mas rapido de lo normal), por ejemplo, yo tengo los juegos de Starfox y Doom en cartucho y comparandolos con los emuladores, funcionan a un framerate mas bajo, sobretodo Doom, creo que no llega ni a los 10fps. Creo que el emulador Bsnes si funciona a la velocidad correcta, no estoy muy seguro.

¿Crees que podrá ser posible imitar el script de movimientos de la versión pc?, es decir, el zigzagueo, la forma en que te persiguen, la puntería de los enemigos, etc.

Si, todo quedará igual a la versión de pc.
Sobre los planos, ya lo explico muy bien realbrucest, solo queria agregar que en realidad el snes tiene 4 planos, en el modo0, pero en este modo solo soporta 4 colores por tile (como el nes), creo que ningun juego usó este modo, en el sega genesis/megadrive algunos juegos simulan un tercer plano usando sprites.

Bueno sobre la noticia que queria darles, es que ya los guardias caminan, disparan, y persiguen, y pueden matar al jugador, ahora estoy agregando algunas cosas mas y probablemente mañana (sábado) estaré publicando la nueva version.

Edit:
Hola, aqui estoy de nuevo con una nueva actualizacion de la rom.
Ahora todos los movimientos de los guardias estan completos, disparar, caminar, perseguir, y tambien puede matar al jugador, ¡ahora sí es un juego!.
Tambien he corregido algunos errores, por ejemplo en la animacion del arma/manos del jugador, por un error se saltaba el frame1(pasaba del frame 0 al 2), ahora ya esta corregido.
Ademas he optimizado un poco la rutina de dibujado de sprites, ahora es 38 ciclos mas rapido por columna,(ya lo habia comentado aqui en este foro).
Aqui esta la nueva version(espero la disfruten ):
http://www.mediafire.com/download/j9a44 ... emo_b6.rar

A que os había pasado a muchos lo mismo que a mí, que con el edit de gasega68k al no ubicarse el mensaje en los hilos de arriba se os pasó por alto lo que hay justo encima de esta frase que he dejado escrita

Ahora sí, ya no es demo técnica sino beta de juego!!

GRANDE gasega68k!!!

Impresionantes avances gasega68k!

Apenas tenga oportunidad lo probaré en mi Everdrive. Espero sorprender a varios con esa demostración en la reunión de retrogamers que harán en mi ciudad

Grande es poco

gasega68k escribió:Hola, aqui estoy de nuevo con una nueva actualizacion de la rom.
Ahora todos los movimientos de los guardias estan completos, disparar, caminar, perseguir, y tambien puede matar al jugador, ¡ahora sí es un juego!.
Tambien he corregido algunos errores, por ejemplo en la animacion del arma/manos del jugador, por un error se saltaba el frame1(pasaba del frame 0 al 2), ahora ya esta corregido.
Ademas he optimizado un poco la rutina de dibujado de sprites, ahora es 38 ciclos mas rapido por columna,(ya lo habia comentado aqui en este foro).
Aqui esta la nueva version(espero la disfruten ):
http://www.mediafire.com/download/j9a44 ... emo_b6.rar

Brutal!!! ahora si empieza la diversion!!!

probando en 3 2 1... xD

Me parece genial tu trabajo Saludos

Hola a todos de nuevo.
He estado trabajando en los otros enemigos(dibujandolos), pero mientras tanto voy a mostrar una nueva version. He agregado la opcion "control" para escojer el tipo de control y para poder configurarlos, ademas he hecho unos cambios aquí, ahora para entrar al menú sera solo con Start, y para configurar los controles estas son las opciones:
Para el controlador de 3 botones, solo se puede asignar A, B, o C, para Run, Fire, o Open, Open siempre estara junto con Strafe, y Weapon será sera Run + Start, es decir, si Run esta asignado al Botón A, entonces será A + Start, si esta asignado al Botón B, entonces será B+Start, etc.
Para el control de 6 botones, se puede asignar A, B, C, X, Y, Z y M(mode), para cualquiera de las 5 acciones: Run, Fire, Open, Strafe y Weapon.
Al iniciar el juego estará en el modo de 3 Botones, Yo no se si sería mejor que se escogiera automáticamente el mode de 6 Botones si esta presente.
Tambien agregué las rutinas para "pallete shift", que se usa cuando el jugador recibe daño(se torna red) y cuando agarras un item(se torna blanco/amarillo), tambien he agregado la rutina para que cuando el jugador muere, éste gira para mirar al atacante, tambien he corregido algunos errores.
Aqui esta la version 6.3:
http://www.mediafire.com/download/9zgty ... o_b6.3.rar

A probarla voy ahora mismo.
Gracias.

Impresionante, lo probaré esta tarde.

De nuevo, gracias por tu esfuerzo, se agradece D: