Portar, continuar o crear, he aquí la cuestión...

Todo sobre la creación, diseño y programación de nuevo software para
nuestro Spectrum

Moderador: Sir Cilve Sinclair

Notapor sromero el Jue Sep 20, 2007 5:18 pm

Ivanzx escribió:No es por llevarte la contraria (que no lo es) Santi, peor en WoS estaban programando un juego de este estilo y no lo veian tan dificil, creo recordar que no iba a ser para +3, y que habian solucionado los problemas que este tipo de juegos podria llevar al Spectrum


Hombre, lo que yo he comentado es matemática pura... Si tienes N localidades y el mapeado de X*Y bytes te ocupa Z bytes por pantalla ... sin compresión, por narices, te ocupará N*Z bytes en memoria.

A menos que, pues eso: cargues el mapa por zonas, uses compresión, tengas un mapeado pequeño, etc etc. Pero entonces, se va MUCHO de lo que es un juego tipo Zelda.

Para que os hagáis una idea:

Mapa del Zelda de Nintendo NES

El mapa del zelda de NES la verdad es que no es muy grande, es de 21x10, la verdad es que con bastante curro se podría hacer algo así ... pero claro, hasta que te das cuenta de que eso es sólo el mapa DEL EXTERIOR (overworld). Ahí no están las mazmorras, ni las habitaciones, casas, etc. El mapa al final es mucho más grande que eso.

Total, que puede ser un pasote de tamaño.

Que no digo que no se pueda hacer, ¿eh? Sólo digo que las aventuras gráficas y los RPGs tienen ESE problema, que tienes que asumir que no va a ser tan grande como un Zelda de hace 20 años.

¿El juego ese de WOS es un "juego tipo Zelda", o un juego con "perspectiva tipo Zelda"? :?
NoP / Compiler
Avatar de Usuario
sromero
Nonamed
 
Mensajes: 1221
Registrado: Mar Abr 17, 2007 12:35 pm
Ubicación: Valencia

Notapor Ivanzx el Jue Sep 20, 2007 6:32 pm

Ahi esta el thread de lo del Zelda, es bastante largo y en ingles pero por si se puede sacar algo aprovechable lo cuelgo :)

http://www.worldofspectrum.org/forums/s ... hp?t=11784
Ivanzx
Nonamed
 
Mensajes: 1186
Registrado: Lun May 07, 2007 12:11 pm
Ubicación: Frankfurt, Germany

Notapor sromero el Jue Sep 20, 2007 7:01 pm

Ivanzx escribió:Ahi esta el thread de lo del Zelda, es bastante largo y en ingles pero por si se puede sacar algo aprovechable lo cuelgo :)

http://www.worldofspectrum.org/forums/s ... hp?t=11784


El mapa del juego es de 8x9 pantallas:

http://www.redballoon.demon.co.uk/stuff/th_map.png

De aquí a las 21x9 pantallas del MUNDO EXTERIOR del Zelda 1 de Nintendo NES, ya va un poco. Y súmale todas las mazmorras interiores del Zelda (que son mapas de gran tamaño).

Hombre:

8*9*192 = 13824 Bytes.

13KB para guardar el mapa del juego, está bien. Pero ten en cuenta que este mapa no es mucho más grande que el del Phantomasa 2, que es un arcade. Y desde luego, bastante lejos del mapa de un Zelda.

Vamos, que no saldrá un juego muy largo, a menos que sea multicarga ... o que no hagan crecer más el mapa.

Algunos apuntes de esa web:

To make this game doable, we need to keep things as simple as possible.

(...)


3. Technical specifications. Obviously its a 128K game, but also we need to know how much memory resources we can spend on each element of the game. eg. game code, bosses, graphics, level data, puzzles, items, quests, text/dialog, music/sound effects.


Multi-loaders are okay if the game breaks down into distinct story chapters, but without a disk system, ideally the whole thing should fit into 128K of memory (which is tough - I was designing for the Spectrum SE which has twice that amount). And that means data compression is essential. I'd go with Bit-Buster extreme. Unless you want things to get comlpicated you've also got to fit everything into a tile-set of 256 tiles or less. Walking around the map is easy enough. I got stuck trying to figure out the line of sight stuff that blocks out tiles you shouldn't be able to see (like when you stand behind a wall).


En fin, lo dicho: que tienen que usar 128K, reducir todo lo posible, o hacer multicargas...
NoP / Compiler
Avatar de Usuario
sromero
Nonamed
 
Mensajes: 1221
Registrado: Mar Abr 17, 2007 12:35 pm
Ubicación: Valencia

Notapor TrueVideo el Jue Sep 20, 2007 10:16 pm

Unas cosas sobre el mapeado...

Los cálculos que ha hecho Santi son correctos, pero tremendamente conservadores y para nada realistas. Si bien es cierto que una pantalla completa codificada con bloques de 16x16 ocuparía 16x12=192 bytes, hay que decir que esta no es la mejor forma de construir un mapeado.

Tomemos como ejemplo el mapa de Zelda que se ha mencionado. No hay más que echar un vistazo al mapa original para darse cuenta de que no hay necesidad de codificar uno por uno cada bloque independientemente. Enseguida vemos que la estructura de todas las pantallas está basada en un único bloque "de fondo", por ejemplo las rocas, que se utiliza para delimitar la escena. Cuando aparece p.e. una roca en pantalla, esta es única (con la excepción de las esquinas y rebordes, que presentan variaciones). Sospechoso. Del mismo modo las zonas transitables son áreas que repiten siempre el mismo patrón. Sospechoso también. Por último tenemos otros detalles decorativos que no parecen obedecer a ningún patrón concreto.

Cómo se construye esto? Considerad por ejemplo cada una de esas pantallas simplemente como un fondo predeterminado e invariable (rocas, árboles...) al que se le extraen los huecos correspondientes para construir caminos, etc.. A su vez estos huecos son en realidad combinaciones de unos pocos patrones -fácilmente reconocibles estudiando el mapa- los cuales se incorporan a cada pantalla simplemente con un par de coordenadas y un identificador. De esta forma pueden reutilizarse una y otra vez en diferentes pantallas, o superponerse en la misma para crear nuevos caminos, claros... y siempre con el coste mínimo. Por último los elementos individuales como tumbas y escaleras se codifican uno por uno de forma convencional mediante coordenadas e identificadores.

Resultado: cada una de esas pantallas puede codificarse con muy pocos bytes. Me atrevería a aventurar que algunas necesitan como mucho media docena, ya que con este método el tamaño no es fijo sino que depende de la complejidad de cada escena. Exactamente lo mismo para las mazmorras.

No era mi intención raptar el hilo para convertirlo en una discusión sobre técnicas de mapeado (aunque estaré encantado de comentar las diferentes opciones con quien le interese el tema). Sólo intento demostrar que no hay nada que se haya hecho en una consola de 8 bits que no pueda reproducirse en Spectrum, salvando por supuesto las diferencias técnicas obvias.

Para acabar, un poco de trivia.. No es aplicable al caso que comentamos, pero hace poco leí en RetroGamer que el programador de Pitfall para 2600 codificó 254 pantallas diferentes con sólo 50 bytes utilizando un polinomio. Creo que es un precioso ejemplo de cómo la necesidad agudiza el ingenio.

J
Avatar de Usuario
TrueVideo
Jack The Nipper
 
Mensajes: 195
Registrado: Mie May 23, 2007 8:34 am
Ubicación: BCN

Notapor TrueVideo el Vie Sep 21, 2007 12:06 am

...

Por cierto, se me olvidaba aclarar que el Zelda original de NES es un cartucho de 1Mbit -> 128K.
Avatar de Usuario
TrueVideo
Jack The Nipper
 
Mensajes: 195
Registrado: Mie May 23, 2007 8:34 am
Ubicación: BCN

Notapor sromero el Vie Sep 21, 2007 10:07 am

TrueVideo: hombre, claro, está claro que hay montones de trucos para evitar eso.

Otra posibilidad asumiendo un fondo fijo es, si existen gran cantidad de huecos de fondo "consecutivos", codificar las partes del fondo con RLE, en plan:


tile1, tile2, fondo, fondo, fondo, fondo, fondo, roca, roca, fondo, fondo, fondo, roca

como

tile1, tile2, 192+5, roca, roca, 192+3, roca

Eso implicaría no poder usar más de 192 tiles, pero en tu mapa tendrías definidos todos los fondos como "valores > 192" consecutivos.

Formas hay muchas, pero, vamos, que no es tan trivial como se pretende plantear y que no hay "tanta" memoria como parece.

saludos!
NoP / Compiler
Avatar de Usuario
sromero
Nonamed
 
Mensajes: 1221
Registrado: Mar Abr 17, 2007 12:35 pm
Ubicación: Valencia

Notapor sromero el Vie Sep 21, 2007 10:14 am

TrueVideo escribió:No era mi intención raptar el hilo para convertirlo en una discusión sobre técnicas de mapeado (aunque estaré encantado de comentar las diferentes opciones con quien le interese el tema).


Pues para eso son precisamente los foros, para que salgan discusiones atractivas, y lo que planteas me parece sumamente interesante.

¿Por qué no planteas un hilo sobre técnicas de mapeado en este subforo? Podemos ir aportando todos ideas, algo en plan "Ideas para almacenar mapas en Spectrum", y vamos aportando trucos y maneras diferentes de un mapa raw[ancho*alto] para ahorrar memoria...

Un saludo :)
NoP / Compiler
Avatar de Usuario
sromero
Nonamed
 
Mensajes: 1221
Registrado: Mar Abr 17, 2007 12:35 pm
Ubicación: Valencia

Notapor na_th_an el Vie Sep 21, 2007 3:29 pm

En realidad os estáis obcecando con los mapas y creo que lo que más ocupa de un juego de estos son los textos y, sobre todo, el script que gobierna todas las comprobaciones que hay que hacer y que lleva el flow del juego.

También, el que el cartucho del Zelda sea de 128K no significa que en un Spectrum 128K pudiera hacerse igual por varios motivos:

1.- Sólo puedes paginar los 16K superiores, lo cual es una limitación bastante bestia. O te quiebras mucho la cabeza, o sólo puedes tener todo el código "gordo", "core" o "motor" en los 16K que van desde $8000 a $BFFF e ir paginando de $C000 a $FFFF lo que te vaya haciendo falta. En la NES hay limitaciones parecidas, pero el sistema es mucho más flexible.

2.- Todo el tema gráfico en la NES está solucionado por hardware. No hay que crear rutinas para mover sprites, ni para hacer el efecto flip-screen, ni para dibujar los fondos, ni para nada. Un montón de código que te ahorras, ya que no hace falta ni siquiera prerrotar los gráficos o dejar espacio para hacerlo en tiempo real: de eso se encarga el hardware.

Zelda de NES podría portarse a Spectrum con muchos recortes. Vale, es posible. Pero cuando hablaba de "típico juego Action RPG de GB" tenía en mente algo con la complejidad típica de un juego de GB de principios de los 90, no la del Zelda de NES que es mucho más sencillo y limitado que dichos juegos, por ejemplo los Pokemon, cuyos escenarios no tienen esa repetitividad y donde hay mucha variedad de ambientes y situaciones, además de infinidad de personajes y miles de lineas de diálogo.
Avatar de Usuario
na_th_an
Nonamed
 
Mensajes: 1889
Registrado: Lun May 07, 2007 10:16 am
Ubicación: Andalucía

Notapor TrueVideo el Vie Sep 21, 2007 5:15 pm

na_th_an escribió:También, el que el cartucho del Zelda sea de 128K no significa que en un Spectrum 128K pudiera hacerse igual por varios motivos: (..)


Totalmente cierto. Las 128K de un Spectrum no son comparables a las 128K de un cartucho. Diferente grado de flexibilidad, la RAM se cuenta aparte, está el tema del hardware dedicado.. sólo mencionaba lo de la capacidad del cartucho para poder hacernos una idea aproximada de lo que estamos hablando. La diferencia no es de "muchos megabits", sino que tenemos prácticamente la misma capacidad en las dos máquinas. Cierto que en términos netos la de un Spectrum es inferior, pero no tanto, y ni siquiera en todos los aspectos. Por poner un ejemplo: el tamaño que ocupan los gráficos es bastante menor en Spectrum gracias a que la información de color se codifica por atributos. Sistemas diferentes, formas de medir diferentes.


Zelda de NES podría portarse a Spectrum con muchos recortes. Vale, es posible. Pero cuando hablaba de "típico juego Action RPG de GB" tenía en mente algo con la complejidad típica de un juego de GB de principios de los 90, no la del Zelda de NES que es mucho más sencillo y limitado que dichos juegos, por ejemplo los Pokemon, cuyos escenarios no tienen esa repetitividad y donde hay mucha variedad de ambientes y situaciones, además de infinidad de personajes y miles de lineas de diálogo.


A mi me gusta el ejemplo de Zelda para NES porque nos viene como anillo al dedo. De hecho creo que ya lo había mencionado antes en el famoso hilo de hardware. Sin embargo no lo hice porque sea precisamente un juego con grandes alardes técnicos. Todo lo contrario, se podría decir que es un juego visualmente austero. No hay nada que no se pueda hacer (o que no se haya hecho ya) en Spectrum. No tiene la variedad de ambientes, infinidad de personajes ni mucho menos las miles de lineas de diálogo de los RPG de 16 bits. La verdad es que no recuerdo que haya una sola línea.. Y sin embargo es una obra maestra.

Pongo como ejemplo este juego (o muchos otros de NES) porque nos puede enseñar cosas importantes que obviamos en nuestros juegos y que no tienen nada que ver con la técnica o la capacidad de la máquina: contar una historia sin necesidad de explicar nada, inmersión, la sensación indescriptible de estar descubriendo cosas aunque los escenarios se construyan siempre con la misma roca y el mismo árbol. Cómo lo consiguen? Hay que buscar respuestas a esa pregunta. Estas respuestas se pueden buscar en cualquier juego de cualquier época, pero no hemos de olvidar que al final los resultados se plasmarán en una máquina humilde como el Spectrum. O la NES.

(...)

Lo del mapeado ha sido un paréntesis más que un obcecamiento. El método que se discutía no me parecía en absoluto adecuado y me ha parecido buen momento para bombardear a la audiencia con alternativas. Sólo este tema podría llenar un foro entero!

J
Avatar de Usuario
TrueVideo
Jack The Nipper
 
Mensajes: 195
Registrado: Mie May 23, 2007 8:34 am
Ubicación: BCN

Notapor TrueVideo el Vie Sep 21, 2007 5:28 pm

sromero escribió:TrueVideo: hombre, claro, está claro que hay montones de trucos para evitar eso.

Otra posibilidad asumiendo un fondo fijo es, si existen gran cantidad de huecos de fondo "consecutivos", codificar las partes del fondo con RLE, en plan:


tile1, tile2, fondo, fondo, fondo, fondo, fondo, roca, roca, fondo, fondo, fondo, roca

como

tile1, tile2, 192+5, roca, roca, 192+3, roca

Eso implicaría no poder usar más de 192 tiles, pero en tu mapa tendrías definidos todos los fondos como "valores > 192" consecutivos.

Formas hay muchas, pero, vamos, que no es tan trivial como se pretende plantear y que no hay "tanta" memoria como parece.

saludos!


El mapeado no es el principal problema por lo que respecta a las limitaciones de memoria, siempre y cuando se escoja un método de codificación adecuado como el que he esbozado antes. El tamaño de los gráficos sin embargo sí que es un problema cuando buscamos variedad (precisamente lo que Zelda de NES no tiene), pero incluso para los gráficos hay alternativas muy eficientes sin necesidad de recurrir a la compresión.

J
Avatar de Usuario
TrueVideo
Jack The Nipper
 
Mensajes: 195
Registrado: Mie May 23, 2007 8:34 am
Ubicación: BCN

Notapor sromero el Sab Sep 22, 2007 9:58 am

TrueVideo: estoy de acuerdo en todo lo que comentas.

Si te animas, sería muy instructivo lo que te comentaba, el crear un hilo en este subforo de Nuevos desarrollos donde discutir técnicas de mapeado u otros aspectos videojueguiles.

Podría ser un hilo interesante, y si lo iniciaras con tus ideas o apreciaciones (por ejemplo, como lo que has comentado del mapeado del Zelda y los "caminos pregrabados en algún formato"), podría saber un debate muy chulo y un hilo para guardar.
NoP / Compiler
Avatar de Usuario
sromero
Nonamed
 
Mensajes: 1221
Registrado: Mar Abr 17, 2007 12:35 pm
Ubicación: Valencia

Notapor TrueVideo el Dom Sep 23, 2007 7:19 pm

sromero escribió: Si te animas, sería muy instructivo lo que te comentaba, el crear un hilo en este subforo de Nuevos desarrollos donde discutir técnicas de mapeado u otros aspectos videojueguiles.

Podría ser un hilo interesante, y si lo iniciaras con tus ideas o apreciaciones (por ejemplo, como lo que has comentado del mapeado del Zelda y los "caminos pregrabados en algún formato"), podría saber un debate muy chulo y un hilo para guardar.


Me parece bien. En cuanto tenga algo de tiempo abriré un hilo para proponer de forma detallada un método alternativo de mapeado. Siempre y cuando haya gente interesada, claro.

J
Avatar de Usuario
TrueVideo
Jack The Nipper
 
Mensajes: 195
Registrado: Mie May 23, 2007 8:34 am
Ubicación: BCN

Notapor Benway el Dom Sep 23, 2007 8:03 pm

TrueVideo escribió:Me parece bien. En cuanto tenga algo de tiempo abriré un hilo para proponer de forma detallada un método alternativo de mapeado. Siempre y cuando haya gente interesada, claro.

J


Apúntame entre los interesados y agradecidos lectores! ;)
Un saludo.
Imagen - Imagen - Imagen
Benway
Manic Miner
 
Mensajes: 215
Registrado: Lun May 07, 2007 7:43 pm
Ubicación: Madrid

Notapor zxbruno el Dom Sep 23, 2007 9:16 pm

Me gustaría mucho poder ver la finalización de los proyectos que se quedaron incompletos. Animo a todos los que tienen el conocimiento para hacer tal cosa. Hace un par de semanas visité aquella página que muestra gráficos para Castlevania ZX y otros, y la verdad es que me da tristeza al saber que nunca se terminó. Pero tengo esperanza. :)
Avatar de Usuario
zxbruno
Freddy Hardest
 
Mensajes: 584
Registrado: Dom Jun 03, 2007 3:28 am
Ubicación: Anaheim, California, USA

Re: Portar, continuar o crear, he aquí la cuestión...

Notapor Benway el Jue Sep 27, 2007 10:11 pm

sromero escribió: Eso, contar una historia, es algo que se puede hacer perfectamente en el Spectrum. Que te cuenten (vía texto, o imágenes) algo al principio del juego, y que conforme vas derrotando bosses o cambiando de mapas te completen esa historia, es un añadido que puede dar un punto extra a lo que es el juego. Eso no depende, como dices, ni de bits, ni de Mhz, tan sólo es una cosa que ahora es "estándar" pero antes, en tiempos del Spectrum, no lo era. Y se lo podemos agregar a los juegos, que cuenten algo, sin problemas.


Esta mañana, pensando en esto... me vino a la mente el Jumping Jack y su poema que se iba componiendo al ir pasando niveles :lol:
Un saludo.
Imagen - Imagen - Imagen
Benway
Manic Miner
 
Mensajes: 215
Registrado: Lun May 07, 2007 7:43 pm
Ubicación: Madrid

PrevioSiguiente

Volver a Programación y nuevos desarrollos

¿Quién está conectado?

Usuarios navegando este Foro: No hay usuarios registrados visitando el Foro y 1 invitado