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.![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
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
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).
![[ok]](/images/smilies/nuevos2/okis.gif "ok")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[tadoramo]](/images/smilies/adora.gif "Adorando")
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.
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.
Aun no lo he pasado al Everdrive... como va en la consola real? impresionante no? altbrian escribió:¿Existen posibilidades técnicas para pasar todos los enemigos, jefes, sonidos y música para hacer un port completo del juego?
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).
naxeras escribió:¿Te va a llevar mucho trabajo que los enemigos disparen?
naxeras escribió:¿En SNES el tamaño de los sprites es menor que en el de PC verdad?
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?
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?
, y por casualidad, ¿no programas cosas para la SNES?.![[bye]](/images/smilies/nuevos2/adio.gif "adios")
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
Saludos.
No he programado para SNES.sgonzalez escribió:gaseka una pregunta....
¿sería difícil hacer un port de tu conversión a Amiga 500?
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?.
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?.
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.
gasega68k escribió:Si se puede implementar en cualquier otro tipo de juego, quizas pudiera ser incluso un poco mas rapido
gasega68k escribió:sobre si ocupa mucho procesador, eso depende de cuantos sprites hayan o el tamaño de ellos.
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?.
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.
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?).
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.
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!!!.
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.
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.
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).
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.
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.
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?.
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.
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.
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?.
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.
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).
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
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.
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.
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.
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.
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).
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.
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?.
¿A que frame rate funciona la versión snes?.
¿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.
): ![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
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
