|
mesiasmsx
|
 |
« Respuesta #60 : 15 de Octubre de 2010, 11:05:36 am » |
|
Otra pregunta, en el Franky no me iban los juegos de más de 2 megas en el Turbo R porque necesitaba memoria externa y ésta no respondía en un Turbo R. (En msx2 sí).
Entonces ahora con Playsoniq ¿funcionan todos los juegos en Turbo R?
Deduzco que si por lo que he estado "leyendo" en el MRC en ingles. Al final me parece que voy a acabar comprando playsoniq, por que como dices para franky se necesita el doble de memoria para cargar un juego, con lo cual solo puedo cargar los de 256 kb en el Turbo R. Ademas si se pueden cargar los juegos sin parchear es mucho mejor,mas todo lo que le han añadido, pues eso. |
|
|
|
|
En línea
|
|
|
|
|
Madonna Mk 2
Visitante
|
|
« Respuesta #61 : 15 de Octubre de 2010, 11:11:44 am » |
|
El pequeño problema de la paleta de 512 son los oscuros, apenas hay un negro absoluto y tres colores más cambiando el tono RGB. Sí que es verdad que los tonos oscuros quedan bastante empobrecidos con una paleta de 512 colores, pero hay que tener en cuenta que esa misma configuración (16 colores de 512) es la que usa el Atari ST, y la verdad es que se han hecho verdaderas maravillas gráficas con ella. Un truco que se usaba mucho en tal plataforma era una distribución uniforme de todas las luminancias, con ligeras variaciones cromáticas apasteladas y algun que otro color suelto más saturado (sobre todo rojizos/azulados). En eso los Bitmap Brothers eran los amos. Si ripeáis alguna de sus paletas veréis lo versátiles y resultonas que son  |
|
|
|
|
En línea
|
|
|
|
|
Dioniso
Visitante
|
|
« Respuesta #62 : 15 de Octubre de 2010, 11:33:25 am » |
|
La GFX9000 está genial; aunque no he trasteado con ella, la tengo por aquí tirada ... Si te limitas a trabajar con patrones o los BITMAP hasta SCREEN 8, pues genial, pero si te metes en resoluciones más altas, con más de 256 colores, etc, etc ... pues estamos casi en las mismas. Pero un juego en "SCREEN 4" para la GFX9000 tiene que ser un trallazo de los buenos!!!!!!!!!!!!!!!!!!! 512k de VRAM y con ese reloj ... JANDERL!!! En modo P1: 125 sprites definibles, 16 sprites en horizontal, 21.5mhz, 256x212 píxels, 2 layers, 30 colores simultaneos (4 paletas de 16 colores), ...  |
|
|
|
|
En línea
|
|
|
|
|
pitpan
|
|
« Respuesta #63 : 15 de Octubre de 2010, 11:44:50 am » |
|
Pues a la vista de los datos que apuntas, Dioniso, este modo gráfico está pidiendo a gritos un shoot'em-up a más puro estilo de recreativa: vista zenital, scroll vertical, muchísimas armas, muchísimos disparos, muchísimos enemigos y todo moviéndose a la vez, con un layer próximo (nubes, elementos, enemigos finales) y uno lejano (fondos, terreno). Y si alguien pica, pues perfecto. Eso sí, para realizar todos los cálculos de trayectorias y no perder frames igual sí hace falta tirar un poco del R800, por aquello de usar de vez en cuando alguna multiplicación |
|
|
|
|
En línea
|
|
|
|
|
Madonna Mk 2
Visitante
|
|
« Respuesta #64 : 15 de Octubre de 2010, 12:15:49 pm » |
|
Pues a la vista de los datos que apuntas, Dioniso, este modo gráfico está pidiendo a gritos un shoot'em-up a más puro estilo de recreativa: vista zenital, scroll vertical, muchísimas armas, muchísimos disparos, muchísimos enemigos y todo moviéndose a la vez, con un layer próximo (nubes, elementos, enemigos finales) y uno lejano (fondos, terreno). Exacto. 125 sprites, 16 en línea y los 2 layers = YUM, YUMM y RE-YUMMMM  Y si alguien pica, pues perfecto. Eso sí, para realizar todos los cálculos de trayectorias y no perder frames igual sí hace falta tirar un poco del R800, por aquello de usar de vez en cuando alguna multiplicación ¡No hombre no! No te rindas tan rápido a la vorágine de la velocidad de la CPU. Que por muchos sprites que muevas por frame, nada te impide programar un secuenciador rápido de enemigos a base de encadenar tablas precalculadas y bucles desenrollados. Y en el caso de que necesitases alguna multiplicación extraña, también puedes usar tablas de multiplicación. Ten en cuenta que incluso los shoot 'em ups más recargados suelen tener comportamientos de sprites bastaste programación-friendly. Lo que hay que evitar en estos casos es el planteamiento inocentón "enyín de física", típico de n00bz flipaos. Eso ya pertenece más al terreno de las consolas 3D, empaquetadas de MEGAFLOPS. En ordenatas de 8 bits hay que tirar del ingenio e hincar codos  |
|
|
|
|
En línea
|
|
|
|
|
Madonna Mk 2
Visitante
|
|
« Respuesta #65 : 15 de Octubre de 2010, 12:20:51 pm » |
|
Ah, y tal como hacía Joffa Smith, según qué cálculos (e incluso algún movimiento concreto) no hace falta hacerlos CADA FRAME Multiplexación rulez  |
|
|
|
|
En línea
|
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #66 : 15 de Octubre de 2010, 12:41:45 pm » |
|
Ah, y tal como hacía Joffa Smith, según qué cálculos (e incluso algún movimiento concreto) no hace falta hacerlos CADA FRAME Multiplexación rulez Yo siempre aplico una de las máximas de la programación funcional: la EVALUACIÓN PEREZOSA. Sólo hay que calcular las cosas cuando se van a necesitar, ¿para qué antes? ¡Funciona de miedo aplicado al ensamblador! |
|
|
|
|
En línea
|
|
|
|
|
pitpan
|
|
« Respuesta #67 : 15 de Octubre de 2010, 12:43:05 pm » |
|
Evidentemente, Bresenham para casi todo. Con eso y unas buenas tablas de seno / coseno en punto fijo de 16 bits puedes conseguir *cualquier* cosa con un tiempo de proceso mínimo. Incluso en un modesto Z80 a 3,5 MHz. Y a 50/60 Hz, porfaplís. Nada más triste que perder frames por el camino o tener que jugar a 1/2 o 1/3 de refresco. Entre bonito y ágil, me quedo con ágil, bien programado y, sobre todo, adictivo. NAMCO forever!
|
|
|
|
|
En línea
|
|
|
|
|
MsxKun
|
|
« Respuesta #68 : 15 de Octubre de 2010, 12:45:58 pm » |
|
Ah, y tal como hacía Joffa Smith, según qué cálculos (e incluso algún movimiento concreto) no hace falta hacerlos CADA FRAME Multiplexación rulez Yo siempre aplico una de las máximas de la programación funcional: la EVALUACIÓN PEREZOSA. Sólo hay que calcular las cosas cuando se van a necesitar, ¿para qué antes? ¡Funciona de miedo aplicado al ensamblador! Eso es lo que hago yo, programacion perezosa, con mucha vagancia...  Ah que no era eso... |
|
|
|
|
En línea
|
--  She Bops! |
|
|
|
guantxip
|
|
« Respuesta #69 : 15 de Octubre de 2010, 12:59:32 pm » |
|
Dioniso, en ese modo estaba yo liado. Y sí, digamos que los motores serían como los shooters, scroll vertical y horizontal con 2 planos y muy colorista.
Otra cosa que me gustaría saber desde mi ignorancia. Por ejemplo, juegos ya hechos con turbobasic como los de Kai, No Name, Nuts ... ¿podrían cambiarse a powerbasic cambiando la sintaxis? Podrían ir realmente suaves y ahorrar muchas cargas aprovechando la Vram del gfx9000. No me refiero a usar el modo dualplane, tal como está hecho pero acelerandolo.
|
|
|
|
|
En línea
|
|
|
|
|
Madonna Mk 2
Visitante
|
|
« Respuesta #70 : 15 de Octubre de 2010, 01:00:11 pm » |
|
Yo siempre aplico una de las máximas de la programación funcional: la EVALUACIÓN PEREZOSA. Sólo hay que calcular las cosas cuando se van a necesitar, ¿para qué antes? Para que no te pille el rayo Como necesites actualizar una coordenada de un sprite que está a punto de visualizarse y te tengas que liar a hacer cálculos, estás perdido Na, que ya te entiendo  Eso está muy bien, tan sólo has de tener cuidado de que no se produzcan picos en el juego con una gran demanda de cálculos en un sólo frame. Ahí es donde puedes tener frame dropping. Yo prefiero multiplexar y hacer cada cálculo en el frame que le toca, pero siempre, se necesite o no, tal como lo hace el hardware. Así consigo un timing del frame más o menos estable y no me llevo sorpresas. En el Retaliot de la dev no tuve tiempo de estabilizarlo, por eso a menudo se ralentiza  Pero bueno, está ya subsanado en la versión Deluxe |
|
|
|
|
En línea
|
|
|
|
|
Madonna Mk 2
Visitante
|
|
« Respuesta #71 : 15 de Octubre de 2010, 01:04:56 pm » |
|
Con eso y unas buenas tablas de seno / coseno Eso, eso... con unos buenos SENOS Y crucial: pasando del sistema clásico de 360 grados... con 256 mola más XDDDDDDDDDDDDDDDDDD Y a 50/60 Hz, porfaplís. Nada más triste que perder frames por el camino o tener que jugar a 1/2 o 1/3 de refresco. Entre bonito y ágil, me quedo con ágil, bien programado y, sobre todo, adictivo. NAMCO forever! ¿Estoy leyendo bien? ¿Hay alguien que piensa igual que yo en ese aspecto Y NO SE LE ECHA NADIE ENCIMA?  En EMS casi me comen vivo |
|
|
|
|
En línea
|
|
|
|
|
guantxip
|
|
« Respuesta #72 : 15 de Octubre de 2010, 01:05:25 pm » |
|
En modo P1: 125 sprites definibles, 16 sprites en horizontal, 21.5mhz, 256x212 píxels, 2 layers, 30 colores simultaneos (4 paletas de 16 colores), ... ¿Me puede explicar alguien bien lo de las 4 paletas? Yo he usado una paleta distinta por plano y me gustaría saber si los sprites que ponga encima tienen que tener la misma paleta del plano correspondiente o puede ser otra diferente. |
|
|
|
|
En línea
|
|
|
|
|
Madonna Mk 2
Visitante
|
|
« Respuesta #73 : 15 de Octubre de 2010, 01:05:53 pm » |
|
Eso es lo que hago yo, programacion perezosa, con mucha vagancia... Ah que no era eso... LMAO |
|
|
|
|
En línea
|
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #74 : 15 de Octubre de 2010, 01:27:57 pm » |
|
Y a 50/60 Hz, porfaplís. Nada más triste que perder frames por el camino o tener que jugar a 1/2 o 1/3 de refresco. Eemmm... salvo los sprites (que sí van a 50/60hz) el scroll del QBIQS va a 25/30hz y no se nota Me fastidió bastante tener que hacerlo así, pero no quedó otra... |
|
|
|
|
En línea
|
|
|
|
|
