Scaling en megadrive :)

El hilo logicamente lo he leido, y claro que demuestra que es programable, como todas las consolas, hasta el amstrad hace virguerias por soft.

En el caso de la megadrive igual, no deja de ser efectos por soft, por hard no lo hace.

En MD se usaban muchos truquitos, cosa que demuestra que sus programadores no eran ni mucho menos unos inutiles, sabian muy bien como engañar el ojo del usuario de la consola .

\hilo (esto es una coña, que parece que aqui las bromas las justas )

O´Neill escribió:\hilo (esto es una coña, que parece que aqui las bromas las justas )

Aqui solo los patos tienen el visto bueno

O´Neill escribió:\hilo (esto es una coña, que parece que aqui las bromas las justas )

No tío, lo que te estoy diciendo es que nadie ha insinuado en todo el hilo que megadrive escalara por hardware.

ok ok ;P

SonicWAVE escribió:

Ralph escribió:

SonicWAVE escribió:ESTO --> http://68000.web.fc2.com/bin/zoom_bg2.bin es scaling.

¿Que es?.

Es una demo. Funciona de maravilla en cualquier emulador.

¿Alguien se tomo la molestia de probarlo?
Porque está bastante bien

Ralph escribió:

sgonzalez escribió:El ejemplo del Turrican 3 de rotaciones, se puede ver claramente con un emulador que son sprites que hacen el giro de 360º, igual que los dragones del Flink, usad un emulador y lo comprobaréis.

¿Y un giro de 360º no es una rotación?

Que rotacion quieres hacer en 2d sin un plano Z. Eso es una rotacion de coordenadas x-y

puch666 escribió:¿Alguien se tomo la molestia de probarlo?
Porque está bastante bien

Si, claro. Como efecto está muy bien, y bueno, 4 naves simultaneas en pantalla mas la del jugador...


Es una curiosidad, pero sin datos de cuanto se está aprovechando el hardware, y cuanta potencia sin usar queda, poco se puede decir.

bertobp escribió:Que rotacion quieres hacer en 2d sin un plano Z. Eso es una rotacion de coordenadas x-y

¿Y como quieres llamarlo entonces?, ¿giro?.

Una rotacion en las coordenadas X-Y es una rotacion al fin y al cabo ¿o no?

Rotacion es el giro de un objeto sobre un punto fijo, donde todas las coordenadas se mantienen equidistantes a ese punto.
Existen rotaciones en el plano (2d) y en el espacio (3d), las primeras estan basadas en coordenadas cartesianas (x,y) y en las segundas se usan coordenadas vectoriales (x,y,z)
En las primeras solo se cambia las coordenadas de los puntos x e y, en las segundas ademas de eso varia el angulo del eje Z

Ralph escribió:

sgonzalez escribió:Los dos están hechos con Raster (por consiguiente chip de vídeo) y son un plano de MD, busca información acerca de la demo.

Entonces, ¿no son sprites?, ¿cuanto mantiene ocupado al motorola esa rutina?.

sgonzalez escribió:Ralph lo del juego comercial de Amiga era por ponértelo fácil, pero ya veo que tienes poco conocimiento acerca de la máquina.

A mi hablame de msx... no, bueno, ni por esas

...

Desconozco la cantidad de ciclos de CPU que se utilizan para la rutina, habría que buscar información, el tema es que es raster de un plano... por lo tanto se podría hacer sobre un plano, no lo podríamos hacer sobre sprites.

El escalado que hace el Deluxe Paint utiliza toda la potencia a Full del 68000 del Amiga. Ten en cuenta que es una rutina de software, por cierto no recordaba, pero también se podían rotar y deformar gráficos... y pasaba lo mismo dependiendo del tamaño de éste tardaba más o menos en hacerlo, pero nunca en tiempo real.

Tened en cuenta que en el System 16, la placa de la recreativa en la que se supone que está basada Megadrive los escalados se hacen mediante el chip de video, nunca con el 68000. Y los ingenieros de SEGA lo harían así por algo ¿no?.

La Sega Megadrive podía hacer deformaciones en tiempo real (ahí está el video que he puesto de Soleil con el boss de lava), y teniendo menos potencia que la Amiga imagino que esta también podría

Ralph escribió:Alguien puso una vez un gif de todoh haciendo scaling (sin escenario ni nada, solo el personaje, ampliado, y en camara lenta). La rutina de escalado es un pelín rudimentaria, pero deja ver la suavidad con la que escala los sprites... simular eso a base de superponer sprites, significa repetir al menos 15 veces cada sprite, en todos y cada uno de los movimientos de todos y cada uno de los personajes... quizás no sea el equivalente a un juego de 200 personajes... sino de 400

Además, en zoom-out se nota la "pérdida de información", es decir, hay partes de los sprites que "desaparecen". Si fuera redibujado, el detalle sería máximo en todo momento.

Si alguien tuviera a mano ese gif, se acabaría la discusión. Es scaling, y es un 65816, en un juego comercial (IA's, musicas, sonidos, 50/60 frames según región, I/O, etc).

kume escribió:Comparación del scaling en un luchador del art of fighting:
SNES (tamaño real)

NeoGeo (tamaño real)

SNES aumentado 3 veces y Neogeo aumentado 2 veces para poder comparar con un tamaño similar:

A mi me parece que la SNES lo escala por software porque hay partes del luchador que no cambian (antebrazo, cara, etc...), pero ¿la mega no podria haberlo hecho también?

Lo encontré

Con tan pocos frames es imposible decir si escala o no.

Yo creo que están usando otro truco: como los sprites de mayor prioridad se superponen sobre los de menor, creo que como el escalado es tan pequeño hacen que los de los extremos del personaje (como el antebrazo que mencionas, cuyos sprites tendrán mayor prioridad) se superponga sobre el cuerpo (que tendrán unos sprites con una prioridad asignada menor) de forma que éste reduzca (aparentemente) de tamaño

kume escribió:Lo encontré

Joder, ¿donde estaba?


@Socram, eso estaba pensando yo, que es un truco, pero bueno, no deja de ser lo que indicaba antes hace unos mensajes, que hay maneras y maneras de hacer scaling... y la rutina de SNES es rudimentaria, si, pero válida al fin y al cabo.

No hace que "aparentemente" reduzca su tamaño, hace que desaparezca información de la imagen. Una curiosa manera de hacer scaling, pero si tenemos en cuenta que el escalado real da como resultado una pérdida de información(por la resolución, no por la rutina en si misma), lo que se ha hecho aquí es forzar directamente la pérdida de información, ahorrandose un montón de pasos intermedios (implementar la rutina de escalado real), con el consiguiente ahorro de ciclos de CPU que supone.


Yo tengo claro que es una simulación de scaling, pero joder, es que lo han clavado, parece scaling, y debería haberse usado en mas juegos, porque da el pego totalmente.

Ralph escribió:

kume escribió:Lo encontré

Joder, ¿donde estaba?


@Socram, eso estaba pensando yo, que es un truco, pero bueno, no deja de ser lo que indicaba antes hace unos mensajes, que hay maneras y maneras de hacer scaling... y la rutina de SNES es rudimentaria, si, pero válida al fin y al cabo.

No hace que "aparentemente" reduzca su tamaño, hace que desaparezca información de la imagen. Una curiosa manera de hacer scaling, pero si tenemos en cuenta que el escalado real da como resultado una pérdida de información(por la resolución, no por la rutina en si misma), lo que se ha hecho aquí es forzar directamente la pérdida de información, ahorrandose un montón de pasos intermedios (implementar la rutina de escalado real), con el consiguiente ahorro de ciclos de CPU que supone.


Yo tengo claro que es una simulación de scaling, pero joder, es que lo han clavado, parece scaling, y debería haberse usado en mas juegos, porque da el pego totalmente.

Efectivamente es un truco donde eliminan trozos de sprite para simular scaling.

Es muy pero que muy ingenioso y da el pego jajaja.

Para mi si es scaling, claramente. No calcula en tiempo real cómo escalar los sprites, pero el efecto es el mismo.

Si da el pego, si, de hecho, creo que hasta se puede contar el numero de sprites con los que está hecho todoh. Parecen ser 9, mas los del contrincante, las magias, etc... la verdad es que un 1 vs 1 no explota nada la capacidad de mover sprites de las 16 bits... el límite está en la memoria de los cartuchos, y la ram de video.

¿Alguien puede arrojar luz sobre el scaling de los dragones del flink?

Ya, es scaling pero muy limitado. Ingenioso es, pero intenta reducir el tamaño algo mas de unos pocos pixeles y veras que no sirve.

socram8888 escribió:Ya, es scaling pero muy limitado. Ingenioso es, pero intenta reducir el tamaño algo mas de unos pocos pixeles y veras que no sirve.

Es que el tamaño original de los sprites tampoco da margen para mucho zoom, antes de que dejen de parecer personas, para empezar a parecer churros con piernas. Con un cartucho mas grande, y sprites mas grandes, se podría conseguir un zoom mayor, obviamente.

¿Cual es la pega de esta técnica?, que no sirve para aumetar el tamaño de los sprites a mas del 100%.


¿Se podría simular algo parecido a una duplicación de pixels, pero sin entrar en la complejidad de una rutina de escalado real?.

Si claro. Duplicar sprites. Pdrias multiplicar hasta 1 pixel extra por sprite

socram8888 escribió:Si claro. Duplicar sprites. Pdrias multiplicar hasta 1 pixel extra por sprite

Pero ya serían dos procesos totalmente diferentes, uno para hacer zoom out, y otro para hacer zoom in, ¿no?. Si necesitas escalar una imagen desde el 50% de su tamaño real, hasta el 150%, al llegar a su tamaño en mitad del zoom, ¿podría notarse el "cambio de rutina"?, o eso depende de la pericia del programador.


Digo esto, porque en raycasters aparecidos en las 16 bits, esto es lo que sucede con los sprites... o quizás aquí si hablemos de scaling real

hoy e jugado a flink en mi megadrive y se ve tan fluido que parece scaling, como los juegos de system 16

Es que lo del flint es otra técnica distinta a la de AOF SNES.

El AOF de snes hace zoom in mientras que el flint hace un zoom out impresionante, bueno cuando sale el muñeco volando hace las 2 cosas.

Creo que flint hace scaling real por software sin trampa ni cartón pero despues de ver el truco de AOF me hace dudar si no hacen otro truco aún mejor.

Un Saludo.

lo importatne es el resultado final y la impresion que da

SUPER_ARU escribió:lo importatne es el resultado final y la impresion que da

EXACTO!!!!
Como nos engañen los programadores para hacernos ver lo que queremos es otra historia

Yo estoy convencido de que si... ahora, dependerá de la complejidad de cada escena que se pueda, o no. Hay juegos que ya de por si, se nota que poco margen dejan para tanto proceso, pero hay juegos, que con un diseño inteligente de los niveles, y del propio juego, si podrían permitirlo.

Tengo curiosidad por saber si podría escalar un fondo, y los sprites de dos personajes ... si, pienso en el aof, no se me ocurre un mejor ejemplo de potencia.

De momento el programa lo estoy haciendo con límite de con imágenes de entrada hasta 512x512 y hasta un escalado de x256 (256 veces la entrada)

Que lo pueda mover la consola o no ya es otra cosa xD

Es un poco ineficiente en temas de tamaño. De momento, sólo con las rutinas que le indican las líneas a duplicar o a eliminar son unos 1024 bytes. Aunque eso sí, de eficiencia en cuanto a ciclos lo estoy haciendo al mínimo posible

socram8888 escribió:De momento el programa lo estoy haciendo con límite de con imágenes de entrada hasta 512x512 y hasta un escalado de x256 (256 veces la entrada)

Que lo pueda mover la consola o no ya es otra cosa xD

Es un poco ineficiente en temas de tamaño. De momento, sólo con las rutinas que le indican las líneas a duplicar o a eliminar son unos 1024 bytes. Aunque eso sí, de eficiencia en cuanto a ciclos lo estoy haciendo al mínimo posible

1024 bytes me parece muy asequible, por muy poco optimizado que esté el tamaño. Vamos, que si se encuentra la manera de hacerse optimamente (en cuanto a rendimiento), por mi como si ocupa un megabit enterito. Compensa.

¿Que te queda?.

Todo xD

Los calculos ya estan hechos, pero ahora hay que procesarlos. Y esa imagen de bitmap hay que pasarla a tiles :S

Bueno, no necesitas procesar el equivalente a una demo. ¿Que tienes pensado?, ¿solo sprites?, ¿de que manera?.

Venga, a darle caña

De momento, fondos que es lo mas facil de hacer. Los sprites se guardan de otra forma algo mas compleja :S

Up, que me interesa el tema xD.

Vamos socram, ánimo ya

Si alguien quiere ayudar... xD

socram8888 escribió:Si alguien quiere ayudar... xD

uuuuuh... no pueeede, no pueeeede

fuera bromas
estoy ancioso por ver es scaling

Socram, yo ensamblador no pero puedo hacerte alguna cosilla en C para probar el codigo, con sus tiles ya en un fondo o lo que necesites

La pc-engine tiene el mismo 6502 y mira si chutaba...

¿te preparo algo en c entonces?¿que necesitas?

socram8888 escribió:Voy a dejar el programa este de la NES con el que estaba y me pongo con el scaling a ver...

PD: ¿Cómo puñetas consiguieron hacer juegazos con un procesador tan limitado como el 6502? Porque he intentado hacer dos chorradas y me he matado :S

¿Estas intentando hacer algo en NES? Mira que una vez me puse a ello pero con todos los manuales en ingles y tal, no me aclaraba mucho, tan solo conseguí hacerme una idea de su complejidad.

Realmente, opino que sabiendo cuatro trucos buenos del 6505 ya puedes hacer juegazos muy interesantes. Solo es imaginación.

Esta 2 demos de c64 me siguen impresionando

Fanta in space.

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

- 4 channels of 8-bit samplerate, digi playback
- 2 channels of SID synth sound
- You can filter both SID channels AND SAMPLES!
- And you have enough rastertime to not being forced to turn off the screen, and can actually do something with it

Y la Deus ex Machina del mismo PC

http://www.youtube.com/watch?v=XEjXGIkQCcI Parte 1

Y la parte 2

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

socram8888 escribió:El problema del 6502 para mi es el tener solo tres registros. Yo me llevo bien con uno solo tipo PIC o muchos tipo 68000, pero intermedio no :s

Jo, pues como te agradecería que abrieses un hilo de programación para NES tal y como hay para el de Mega Drive, que mola un huevo.

Poner un fondo de un color, varios colores, con gráficos, un sprite, mover un sprite... etc... y ya con eso muchísima gente se animaría ha hacer algo

socram8888 escribió:Ahora cuando acabe el diseño de mi consola ya abrire un hilo de programación

Cuentanos eso, ¿no?. No estaría mal que fueses posteando tus progresos, y como los vas alcanzando


Algún día yo me fabricaré una SNES, tal y como fué diseñada desde un principio... (aunque luego no funcione ).


P.D: ¿Y lo del scaling, que?, al final te vas a dispersar demasiado, ya verás.