Ver la versión completa : Cadillac and Dinosaurs para Atari STE
masteries
13/07/2022, 14:36
Haciendo pruebas, he descubierto que si sólo emplease una única paleta de color de 16 colores;
a 25 cuadros por segundo podría mover juegos con sprites aún más bestiales...
El problema radicaba, en que sólo 16 colores a la vez son pocos...
Así que me he puesto manos a la obra, para aprender a usar las herramientas de las
Atari Game Tools en su modo de una única paleta de color.
El resultado, con un buen repertorio de sprites y un único tipo de escenario,
con gráficos del juego Cadillac and Dinosaurs es este:
55143
En esta imagen sólo hay 16 colores, el STE podría mover esto con suavidad a 25 fps
junto con el mezclador de audio digital de 3 voces.
Sólo que cada vez que cambie el escenario, tienes que borrar y cargar los sprites con
una nueva paleta adaptada, pues ahora la relación entre colores del escenario y sprites
es mucho más estrecha que antes.
Pero nada que una unidad de disco duro baratita no te permita hacer :)
josepzin
13/07/2022, 14:41
Creo que la pantalla gráfica del ST es como un VGA no? sin sprites ni nada de eso.
Has probado con una paleta genérica como la de dawnbinger?
OscarBraindeaD
13/07/2022, 15:08
Haciendo pruebas, he descubierto que si sólo emplease una única paleta de color de 16 colores;
a 25 cuadros por segundo podría mover juegos con sprites aún más bestiales...
El problema radicaba, en que sólo 16 colores a la vez son pocos...
Así que me he puesto manos a la obra, para aprender a suar las herramientas de las
Atari Game Tools en su modo de una única paleta de color.
El resultado, con un buen repertorio de sprites y un único tipo de escenario,
con gráficos del juego Cadillac and Dinosaurs es este:
55143
En esta imagen sólo hay 16 colores, el STE podría mover esto con suavidad a 25 fps
junto con el mezclador de audio digital de 3 voces.
Sólo que cada vez que cambie el escenario, tienes que borrar y cargar los sprites con
una nueva paleta adaptada, pues ahora la relación entre colores del escenario y sprites
es mucho más estrecha que antes.
Pero nada que una unidad de disco duro baratita no te permita hacer :)
Alucino con lo que consigues hacer... enhorabuena!
Yo soy más de Commodore Amiga pero me encanta ver cómo exprimes hasta el último ciclo de CPU del Atari ST.
Ánimo con ello!
masteries
13/07/2022, 15:36
Has probado con una paleta genérica como la de dawnbinger?
No consigues el resultado de ahí arriba ni por asomo,
es mejor dejar que te genere una paleta personalizada para cada mapeado.
Con los enemigos del ejemplo, ya tienes colorido para otros tantos;
por eso he cogido 4 enemigos y el dinosaurio, para comprobar si
la idea de emplear sólo 16 colores se quedaría corta o no.
Viendo el resultado arrojado por las AGT, éstas se empiezan a coronar
como el mejor software gráfico para coloreado de 4 bits.
El HUD, lo ubicaría en la parte superior, como una franja separada
del scroll, con sus propios 16 colores.
-----Actualizado-----
Creo que la pantalla gráfica del ST es como un VGA no? sin sprites ni nada de eso.
Se dispone de scroll hardware y de un blitter muy eficiente, hablando del STE.
La magia de poder hacer todo esto reside lo optimizado de la librería del blitter.
-----Actualizado-----
Alucino con lo que consigues hacer... enhorabuena!
Yo soy más de Commodore Amiga pero me encanta ver cómo exprimes hasta el último ciclo de CPU del Atari ST.
Ánimo con ello!
Gracias,
Pues los Amigueros y vuestro escaso 1 MB de chip RAM...
para Cadillac and Dinosaurs u otros beat em up que estén por llegar
no se va a recortar ni un fotograma en las animaciones de
los personajes, y eso en 1 MB no cabe.
Estos juegos veo que tienen escenarios sencillos (mejor, se repiten muchos tiles)
y así ocupa mucho menos; pero personajes con animaciones muy buenas.
No consigues el resultado de ahí arriba ni por asomo,
es mejor dejar que te genere una paleta personalizada para cada mapeado.
Con los enemigos del ejemplo, ya tienes colorido para otros tantos;
por eso he cogido 4 enemigos y el dinosaurio, para comprobar si
la idea de emplear sólo 16 colores se quedaría corta o no.
Viendo el resultado arrojado por las AGT, éstas se empiezan a coronar
como el mejor software gráfico para coloreado de 4 bits.
El HUD, lo ubicaría en la parte superior, como una franja separada
del scroll, con sus propios 16 colores.
-----Actualizado-----
Se dispone de scroll hardware y de un blitter muy eficiente, hablando del STE.
La magia de poder hacer todo esto reside lo optimizado de la librería del blitter.
-----Actualizado-----
Gracias,
Pues los Amigueros y vuestro escaso 1 MB de chip RAM...
para Cadillac and Dinosaurs u otros beat em up que estén por llegar
no se va a recortar ni un fotograma en las animaciones de
los personajes, y eso en 1 MB no cabe.
Estos juegos veo que tienen escenarios sencillos (mejor, se repiten muchos tiles)
y así ocupa mucho menos; pero personajes con animaciones muy buenas.
Salvo que este equivocado mi amiga 1200 tiene 2 MB de chip RAM, imagino que hablas del 500 ¿no?
masteries
14/07/2022, 09:58
Salvo que este equivocado mi amiga 1200 tiene 2 MB de chip RAM, imagino que hablas del 500 ¿no?
Si, me refiero siempre al modelo más extendido, el A500 normal.
Yo mismo lo que tengo es un A500 Plus, pero el número de unidades este modelo es bastante pequeño, así como de Amiga 600;
en comparación con la inmensidad que representan los A500 normales.
El A1200, aunque esté limitado a sólo 2 MB de chip RAM (qué ratas, ¿por qué siguieron manteniendo esa limitación?),
tiene un ancho de banda tan grande en el puerto de la fast RAM, que podrías hacer como con las consolas de cartuchos,
cargar y descargar desde fast RAM.
Meter el A1200 en la ecuación, sería como meter el Falcon, estos juegos no serían tan sorprendentes exprimiendo un Falcon;
recordemos que el Falcon de stock puede emular a cosa de un quinto de velocidad a una NeoGeo.
Si puede emularla, entonces mejor hará juegos nativos de ese tipo. El A1200 pues por el estilo,
aunque el Falcon tiene una CPU secundaria de 32 MHz con la que DML ha llegado a mover mapas de Half-Life y Quake 2 a color de 16 bits.
¡Qué grande el colega DML! ¡Y sus Atari Game Tools también!
mola mucho!
pero el atari st normal tampoco mueve esto. no?
Si que lo mueve pero mas lento :P
Lo que me resulta irónico es que tendrías menos problemas en echar a andar este port que Capcom en conseguir los derechos para reeditar el juego :D :llorosa:
¡DotEmu, un Cadillac & Dinosaurs De-extincted ya! :lol:
OscarBraindeaD
14/07/2022, 15:07
Salvo que este equivocado mi amiga 1200 tiene 2 MB de chip RAM, imagino que hablas del 500 ¿no?
Peor aún... el A500 normal, no el plus, sólo tenía 512 de chip RAM... vamos que cosas de este estilo es complicado verlas.
Ademas que para escuchar a un Amiguero decir, es un port de Atari... siempre hay tiempo XD
Si que lo mueve pero mas lento :P
y la europe... digoo, y la ram?
Un ST normal se puede ampliar hasta 4MB como el STE, aunque es mas complicado ampliarlo.
masteries
15/07/2022, 01:49
Trabajando un poco más los colores, he descubierto que las AGT pueden darte los gráficos con y sin dithering, ambos resultados a la vez:
55151
Con sólo 16 colores... acojona lo mucho que se parecen a los sprites de la versión arcade,
en esta ocasión sólo los dos grandullones tienen dithering, y si te lo curras un poco más,
podría evitarse el uso del dithering en estos dos.
Por cierto, que estos resultados no los obtienes con ningún software gráfico de los conocidos ni de coña,
ni con los de pago logras manejarte así de bien en color de 4 bits.
El escenario exige algo más de trabajo, sería conveniente que compartiera más
colores con los sprites, el dithering en el escenario parece un poco excesivo;
en el suelo queda bien, pero en los árboles y las plantas... no me convence del todo.
selecter25
15/07/2022, 10:17
Qué pasada, siempre haciendo honor a tu nick. Si se mueve tan bien como dices va a ser brutal.
Están haciendo una versión para la megadrive:
https://youtu.be/Qims0HW0O9A
¿eres tu también?
masteries
15/07/2022, 12:06
Están haciendo una versión para la megadrive:
https://youtu.be/Qims0HW0O9A
¿eres tu también?
No, por suerte...
¡Ay Señor! Perdónalos porque no saben lo que hacen...
He descargado la ROM y la he analizado; por cierto que no tiene sonido, han colado ahí en el vídeo una música sonando todo perfecta... xD
De hecho, yo mismo estoy estudiando integrar un reproductor de MP3 en el cartucho para la música,
algo así como los de Paprium, pero sin ser tan Pro. Ya entiendo perfectamente a los desarrolladores de WaterMelon.
En cuanto empiezas a pedir muchos gráficos al cartucho, el Z80 se estrangula... y si no le pides mucha tralla, no
sacas juegos tan molones.
cojon**** la idea de SEGA de no integrar un mecanismo DMA para el audio (haber escogido un YM un escalón superior, que si lo lleva integrado),
como si tienen los Amiga y el STE, y la Super Nintendo, y la PC Engine (esta con samples de 10 bits)... ni siquiera tiene interrupciones el Z80,
esto también habría salvado el adaptador de audio.
Volviendo a esta ROM: No saben gestionar los planos de scroll de forma personalizada, y se les merienda un montón de VRAM necesaria;
también han cometido un error de principiante. Están considerando que los personajes son un único sprite completo, incluso cuando golpean...
Los brazos y las piernas, cuando pegan, deben ser un sprite aparte; así los personajes cuando no están pegando, consumen menos pixels por línea.
con 5 sprites se están comiendo los 320 pixels de sprites por línea, de hecho en la demo ya he visto parpadear a los enemigos, cuando he llegado al final del tejado.
Por mi parte, para cuando empiece a hacer un juego de estos para MegaDrive/Genesis; tengo una técnica bajo el brazo para que el personaje principal no consuma
pixels de sprites, y así poder sacar más enemigos.
Para el coloreado... utilizaré ultra paletas geniales producidas con las Atari Game Tools, clarísimo.
Pero termina primero el Metal Slug, alma de cántaro, que lo vas a dejar en una demo en lugar de juego y se te van a tirar encima muchos fans :D
La verdad es que mola ver lo que estás consiguiendo :D Y encima te quejas de que se ve mal el fondo :P A este paso vas a conseguir que funcione la placa de la recreativa directamente en el ordenador, y no vas a estar contento porque el render 3D no admite más de 40 polígonos con textura :D
Los brazos y las piernas, cuando pegan, deben ser un sprite aparte; así los personajes cuando no están pegando, consumen menos pixels por línea.
con 5 sprites se están comiendo los 320 pixels de sprites por línea, de hecho en la demo ya he visto parpadear a los enemigos, cuando he llegado al final del tejado.
Es el coñazo de hacer juegos de peleas, si quieres aprovechar la memoria tienes que hacer que cada personaje este compuesto por varios sprites, a mi casi me motiva mas hacer la herramienta que parta los sprites que hacer el juego XD, con la potencia de calculo que tienen ahora los ordenadores incluso podrías probar a lo bruto distintas configuraciones de tamaños/desplazamientos para generar los sprites mas óptimos.
masteries
15/07/2022, 16:40
Es el coñazo de hacer juegos de peleas, si quieres aprovechar la memoria tienes que hacer que cada personaje este compuesto por varios sprites, a mi casi me motiva mas hacer la herramienta que parta los sprites que hacer el juego XD, con la potencia de calculo que tienen ahora los ordenadores incluso podrías probar a lo bruto distintas configuraciones de tamaños/desplazamientos para generar los sprites mas óptimos.
En este caso (Megadrive) más que memoria, para no comerte las capacidades hardware de los sprites;
por la limitación de 320 píxeles por línea; si tus sprites son un rectángulo que siempre incluye el brazo/pierna golpeando,
pues ese espacio, aunque sean píxeles transparentes, cuentan como píxeles de sprites para esa línea.
El STE lo pone mucho más fácil en este sentido, y es irónico, pues tiene menos rendimiento global, pero mayores facilidades a la hora de trabajar;
los sprites pintados por el blitter sólo consumen las secciones de 16 bits que estén o bien ocupadas por píxeles opacos, o parcialmente ocupadas.
Si en un fotograma coincide que hay unas cuantas líneas con huecos interiores de más de 16 píxeles, esos píxeles se obvian, no son gestionados por el blitter,
el super formato de sprites hace un jump a los siguientes 16 píxeles.
Ahorrando ciclos, cuando limpia el sprite también hace esto mismo.
Esto del jump, lo puede hacer también al principio y final de la línea de un sprite;
puedes tener un sprite con líneas de 90 píxeles que necesitarán al menos de 6 escrituras del blitter,
y otras líneas con unos pocos píxeles, que las pintas con 1 sola escritura (1 en lugar de 3, el formato es tan Pro, que puede detener el trabajo del blitter
para obviar la middle mask y la end mask; ni idea exacta de cómo está implementado todo eso, es la magia de DML) xD
Pero en la consola, hacer eso, es comerte píxeles imprescindibles y por ende, prevenirlo te complica la programación del juego.
¿Y eso se puede usar para lidiar con las limitaciones del número de sprites?
Es que hablas mucho le límite de pixels por línea, pero tengo entendido que los viejos ordenadores tenían un límite en el número de sprites que se podían manejar.
Entiendo que usando esa separación de pixels transparentes, podrías unir dos sprites separados, y no perder ni pixels de la línea ni número de sprites ¿no?
masteries
15/07/2022, 20:31
¿Y eso se puede usar para lidiar con las limitaciones del número de sprites?
Es que hablas mucho le límite de pixels por línea, pero tengo entendido que los viejos ordenadores tenían un límite en el número de sprites que se podían manejar.
Entiendo que usando esa separación de pixels transparentes, podrías unir dos sprites separados, y no perder ni pixels de la línea ni número de sprites ¿no?
En el ordenador no hay límite, salvo que no te pases demasiado o se ralentiza.
Pero como este tipo de juegos los planteo hacer a 25 fps, pues tengo el tiempo de dos fotogramas para dibujar.
De ahí que haya estrujado las herramientas para obtener unos buenos 16 colores, porque a 25 fps no se puede hacer el truco
de conseguir más colores alternando.
La Megadrive puede manejar 80 sprites de 32x32 píxeles, aunque uses 4 sprites por cada enemigo (en un beat em up), eso te da para mostrar 20 en pantalla.
Y si necesitas 5 sprites, siguen siendo 16 personajes grandotes; no tendrás apuros.
Se alcanza antes el límite de los píxeles por línea, comprobado.
Para atenuarlo, yo haría que el protagonista fuese un sprite software, dibujado en el plano B,
esto ya lo he probado en la demo de Metal Slug, con el disparo gigante y con los disparos pequeños.
Asi no te comes los píxeles que ocupa el protagonista, y te cabe un enemigo más en pantalla.
Aunque oigas sprite software, en Mega no es complicado, pues puedes seguir usando el DMA para cambiar su fotograma, y actualizarlo en la pantalla
es tan sencillo como escribir un byte en una matriz, por cada tile de 8x8 del protagonista.
Lo que no me planteo de momento, es hacer blitting;
creo que con liberar al protagonista se puede ir bien servido.
Y cuando el protagonista recoja un arma de fuego, pues los disparos serán también tiles en el plano B,
en lugar de sprites y ¡tan fresco!
MasterGame
20/07/2022, 19:21
La demo para cuando ?
masteries
20/07/2022, 23:00
Cuando esté hecho.
Dijo Miguel Ángel, Carmack, el Hombre Alto y ahora también lo digo yo.
La demo para cuando ?
De demo nada, juego terminado y en edición física :P
Cuando esté hecho.
Dijo Carmack, el Hombre Alto y ahora también lo digo yo.
Y Michaelangelo, no te olvides. Y hay que decirlo tirándole el cubo de pintura al Papa :lol:
masteries
21/07/2022, 13:03
Y Michaelangelo, no te olvides. Y hay que decirlo tirándole el cubo de pintura al Papa :lol:
Fixed.
Muchas gracias, además Miguel Ángel si que es muy buena referencia histórica.
MasterGame
22/07/2022, 12:26
Terminado dice xD lo bueno es el hype inicial despues se convierte en infierno para terminar el juego y lamentablemente todo se queda en bonitas demos tecnicas
masteries
22/07/2022, 13:41
Para eso está el Itchio, para ir pasando y ayudando a hacerlo realidad :)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.