Hardware fixeado soluciona Soft mal programado?

emerald golvellius escribió:@Señor Ventura he leido lo que comentaste de que podrian haber solucionado esto del Flickering en la One Chip Snes,eso solucionaria esos problemas en los juegos ya cerrados?o ademas se deberia parchear el pograma o algo?

No, no, cuidado. Me preguntaba si no se podría haber hecho, ignoro que hay debajo del encapsulado como para saber si se rehizo todo, o que pasa.

Pero vamos, que pese a que estas máquinas tienen un tope para evitar que se joda todo el scanline si intentas dibujar mas allá del límite (en snes directamente no funciona xD), nada impide que puedas mejorar esa función por software a base de cpu... por ejemplo no dibujar mas de 32 tiles de sprites por línea, o además de eso no dibujar tampoco las tiles que queden ocultas debajo de otros sprites.

Lo primero es super fácil de implementar, pero para lo segundo hay que idear una rutina que sepa ver cuando un sprite queda totalmente tapado, o en su defecto, cuando queda tapado a un cierto nivel.

emerald golvellius escribió:en SNES no existe eso de Overclock,por lo que en que consistiria la solucion?,molaria que con un Fix al Hard se pudieran solucionar los problemas de Soft.

La cpu no admite overclock, la razón no la se.

Y además el sistema parece ser bastante sensible a esas asimetrías, por eso cuando la cpu quiere leer de la wram o escribir en ella debe bajar hasta la frecuencia de esta.

@Señor Ventura Me resulta curioso esto de " estas máquinas tienen un tope para evitar que se joda todo el scanline si intentas dibujar mas allá del límite"
cuando el Artista en cuestion estaba dibujando imagino que en la estacion o el Kit utilizado que solian entregar a los desarrolladores...le saldria un aviso o algo?,he visto muchas fotos y videos de estas cosas,cuando estan dibujando Sprites,incluso creo que vi un video en el que se veia como desde el Ordenador lo ejecutaban en la Consola...

tipico Kit de esos que conectan la Consola con la estacion via ROM,y me imagino que hay van probando lo que funciona y lo que no...,lo que hace que el programa se corrompa etc,un tema interesante.

debe ser un puzzle complicado esto de meter ahi todo y revisar que funcione,seguro que en ocasiones parecera que todo funciona pero al testear cierto punto este o aquel Sprite al conincidir deben dar quebraderos de cabeza.

@emerald golvellius No es que les salga un aviso, es que el generador de imágenes anula automáticamente los sprites que excedan el límite, pero como puedes comprobar tanto en snes como en megadrive, muy bien no es que funcione. En snes directamente hay un bug que elimina los sprites mas prioritarios en lugar de los menos prioritarios.

Pero vamos, que por software puedes controlarlo, y a otra cosa.

emerald golvellius escribió:debe ser un puzzle complicado esto de meter ahi todo y revisar que funcione,seguro que en ocasiones parecera que todo funciona pero al testear cierto punto este o aquel Sprite al conincidir deben dar quebraderos de cabeza.

No hace falta revisar todo. Basta con poner a prueba lo que por diseño sabes que va a ser lo mas demandante de recursos, y cuando estés seguro que eso funciona, todo lo demás va a funcionar también... si no, menuda locura ^^u

@Señor Ventura Pero de ahi vienen los Bugs no?
esas cosas como que tal objeto si colisiona con tal Sprite genera un Error catastrofico,vienen de no probarlo todo todo.

por ejemplo eso de en Vendetta de Konami si aguantas el cubo que al lanzarlo a cualquier Sprite le cambia la cabeza por el cubo,no lo programaron con el Mid Boss,entonces al contactar crea un Error grave que cuelga el juego...

esas cosas seran por temas de testeo y ahi alguna rutina no se creo o alguien no dibujo lo que tenia que dibujar o algo asi,me imagino que debe ser algo asi.

por ejemplo en Solid Snake de MSX2 comento uno de sus programadores creo que era Okada,que al parecer poner en pantalla todos los detalles que les exigian era muy dificil por las limitaciones de RAM etc,asi que utilizaban trucos,para liberar memoria y asi utilizarla...

comentaba el programador que utilizo trucos que ponian en riesgo el programa si se realizaba cierta accion en cierto lugar etc,no queria dar detalles por que obviamente nadie quiere mostrar fallos en su labor...

por lo que entendi quizas si Snake fuma o se agacha o realiza ciertas acciones en un cierto momento o lugar,o ambas cosas...tendriamos un CRUSH,me parecen interesantes todas estas cosas.

emerald golvellius escribió:@Señor Ventura Pero de ahi vienen los Bugs no?
esas cosas como que tal objeto si colisiona con tal Sprite genera un Error catastrofico,vienen de no probarlo todo todo.

por ejemplo eso de en Vendetta de Konami si aguantas el cubo que al lanzarlo a cualquier Sprite le cambia la cabeza por el cubo,no lo programaron con el Mid Boss,entonces al contactar crea un Error grave que cuelga el juego...

esas cosas seran por temas de testeo y ahi alguna rutina no se creo o alguien no dibujo lo que tenia que dibujar o algo asi,me imagino que debe ser algo asi.

por ejemplo en Solid Snake de MSX2 comento uno de sus programadores creo que era Okada,que al parecer poner en pantalla todos los detalles que les exigian era muy dificil por las limitaciones de RAM etc,asi que utilizaban trucos,para liberar memoria y asi utilizarla...

comentaba el programador que utilizo trucos que ponian en riesgo el programa si se realizaba cierta accion en cierto lugar etc,no queria dar detalles por que obviamente nadie quiere mostrar fallos en su labor...

por lo que entendi quizas si Snake fuma o se agacha o realiza ciertas acciones en un cierto momento o lugar,o ambas cosas...tendriamos un CRUSH,me parecen interesantes todas estas cosas.

No, en este caso estamos hablando dibujar sprites, lo que el programa haga con ellos no tiene nada que ver con el line buffer. Hablamos de que el propio código pediría que no se dibuje, pero no que deje de aplicarle las normas que haya establecido el programa.

Un sprite tiene sus rutinas asociadas (IA, físicas, colisiones, etc), e incluso las que impliquen interactuar con otros objetos, pero pedirle al line buffer que no dibuje el sprite en este fotograma porque ya hay 32 dibujándose en ese scanline, no hace que dejen de tenerse en cuenta sus rutinas con respecto a las normas del juego. Es decir, un sprite invisible no es realmente invisible para el programa, solo para tus ojos.


P.D: Eso no significa que un bug en una petición para no dibujar el sprite no pueda involucrar y comprometer al resto del programa, pero ya hablaríamos de meter la pata muy profundamente, porque son cosas que no tienen nada que ver per se.

@Señor Ventura Interesante,hay algunos juegos con unos Bugs muy raras,por ejemplo en Salamander dependiendo de algunas Scrore y algunas acciones se puede lograr buggear el juego,que ciertos enemigos no funcionen bien,que el programa tenga fallos que lo hacen mas facil,aunque tengo que reconocer que son cosas que las he visto en videos y luego a mi no me salen,si que alguna vez me sucedio alguna cosa rara en algun Boss sin saber por que,y segun lei el juego tiene una serie de Bugs y se comenta que estan asocioados a Score y comportamiento del jugador.

por ejemplo en Dogyuun Toaplan cometio un fallo muy gordo,si juegas a dos player y uno de los players se pone el la parte izquierda de la pantalla sin parar de disparar anula los ataques enemigos,los enemigos no se comportan bien,no lanzan balas y el juego queda roto.

podrias pensar que lo hicieron a proposito,pero yo lo dudo mucho,es un tragamonedas y eso no era buen negocio...

hay tanto Bugs por ahi,vi una vez un video de Black Tiger con unas atravesadas de paredes que me quede alucinado,pero nunca he conseguido encontrar otra vez ese video,de todas formas se unas cuantas posiciones en el juego en las que el personaje entra en partes del escenario que no estan destinadas a tal uso,me iamgino que testera toda parte de los escenarios seria una tarea imposible.