¿En qué lenguajes se programaba para las clásicas?

theelf escribió:

Baek escribió:Por cierto, habría que dejar claro que en ASM también se puede hacer código muy ineficiente,...

Tambien esta en el hardware, puedes escribir buen codigo asm, pero si desconoces propiedades de la arquitectura, o registros del CPU, de seguro el codigo sera ineficiente, o al menos, menos eficiente de el potencial total, aunque sea impoluto en cuanto a calidad

Me alegra que salga el tema, porque programar en ASM implica conocer el hardware para el que trabajas. Si no lo dominas y no aprovechas sus características, puedes tener un código ASM ineficiente. La ventaja de un buen compilador es que no va a generar código ASM ineficiente, digamos que no va a incurrir en "malas praxis", por lo que tu cometido es simplemente optimizar el algoritmo.

Respecto a la mala fama del Java, no estoy de acuerdo: el problema no es el lenguaje, son los programadores. Evidentemente Java no es el lenguaje más optimizado del mundo, no se concibió para ello sino para ser multiplataforma, y en malas manos puede ser tan desastroso como cualquier otro lenguaje.

kusfo79 escribió:No hace falta preguntar, ya se sabe por seguro que solo se usaba ensamblador

Cierto, Yūji Naka ya nos lo dice en un vídeo :

http://www.gamespot.com/videos/acmi-game-masters-yuji-naka/2300-6384581/

Aunque estoy un poco de acuerdo también con los compañeros: el hacerlo en ASM o otro lenguaje de alto nivel dependería de el tipo de juego, el equipo de desarrollo, la compañía, etc.

Es posible que contrataran a gente para hacer un compilador C muy optimizado para una arquitectura o para hacer un tipo de juego concreto. También es posible que usaran C para hacer herramientas de apoyo (para diseño de gráficos, reglas físicas, etc.) y que estas herramientas proporcionaran el código ASM ya optimizado.

Pero claro, supongo que las compañías guardarían bajo llave estas herramientas y compiladores como mucho las intercambiaban con otras compañías por un módico precio.

AxelStone escribió:Respecto a la mala fama del Java, no estoy de acuerdo: el problema no es el lenguaje, son los programadores. Evidentemente Java no es el lenguaje más optimizado del mundo, no se concibió para ello sino para ser multiplataforma, y en malas manos puede ser tan desastroso como cualquier otro lenguaje.

No, el problema no es el lenguaje, es su concepción, da igual lo que se programe, siempre va a ser muy ineficiente en comparación al mismo programa en otros lenguajes.

Yo no considero que aprender Java sea una vergüenza, o incluso que sea sencillo, no creo que se esté diciendo eso, es muy sencillo crear cosas simples y es complicado, por ejemplo, dominar los iteradores, cualquier principiante te crea una tontería en Java, pero pocos te crean un programa verdaderamente complejo, el problema es que ese programa complejo, creador por un verdadero profesional, siempre va a ser ineficiente. Y por eso, tanto en mi opinión como en la de mucha otra gente, debería ser un lenguaje, si no a dejar de usar, sí al menos a limitar a cosas concretas (Java RMI ofrece unas muy buenas y sencillas opciones de sincronismo en red por ejemplo), sin embargo, en este país Java se usa en grandes empresas hasta para programas de gran complejidad que controlan sistemas muy importantes, en algunos casos vistos por mi mismo.

Baek escribió:

Red Ninja Wonder escribió:de hecho yo haré el módulo de desarrollo web o similar porque necesito titulación;.

Como recomendación personal, y me jode darla por que soy muy de C y C++, si te vas enfocar a la programación online y web, empieza a darle con ganas a Java y Java RMI.

No sé si te lo pedirán en el CS, imagino que sí, pero desde luego seguro que te lo exigirán en muchas empresas cuando busques trabajo de eso.

Que es el java rmi?
Para web se usa java2ee y los lenguajes de marcas asociados, jsp, jstl y los frameworks (struts, java server faces, etc) unidos a los lenguajes del lado del cliente.

fakemaria escribió:

Baek escribió:

Red Ninja Wonder escribió:de hecho yo haré el módulo de desarrollo web o similar porque necesito titulación;.

Como recomendación personal, y me jode darla por que soy muy de C y C++, si te vas enfocar a la programación online y web, empieza a darle con ganas a Java y Java RMI.

No sé si te lo pedirán en el CS, imagino que sí, pero desde luego seguro que te lo exigirán en muchas empresas cuando busques trabajo de eso.

Que es el java rmi?
Para web se usa java2ee y los lenguajes de marcas asociados, jsp, jstl y los frameworks (struts, java server faces, etc) unidos a los lenguajes del lado del cliente.

http://es.wikipedia.org/wiki/Java_Remot ... Invocation

Se usa bastante en aplicaciones de redes en empresas a nivel interno.

Pero no confundamos, RMI no es una variante de Java, es un mecanismo para poder invocar métodos remotos, como lo pueda ser un WebService. Vamos que en Java normal y corriente puedes ofrecer una interfaz RMI de los métodos que quieras publicar.

Pero bueno, dejemos el Java que nos desviamos del hilo .

@baek Si, había leído lo que era el rmi precisamente en la wiki pero lo he visto como un método más de java, lo veo poco práctico y poco eficiente si lo que vas a hacer es traerte cosas de la bbdd y hacer inserciones-modificaciones, etc

Para un entorno web, nada como los servlets y jpa para las bases de datos. Y para traerte cosas de forma asíncrona ajax

AxelStone escribió:Pero no confundamos, RMI no es una variante de Java, es un mecanismo para poder invocar métodos remotos, como lo pueda ser un WebService. Vamos que en Java normal y corriente puedes ofrecer una interfaz RMI de los métodos que quieras publicar.

Pero bueno, dejemos el Java que nos desviamos del hilo .

En ningún momento he dicho que sea otro lenguaje diferente

Simplemente es algo específico que es importante conocer y es posible que en un CS no lo mencionen, nada más.

@fakemaria díselo a las empresas, no a mi, yo no usaría Java para nada, pero yo no mando.

Es que realmente RMI se usa, al igual que cualquier mecanismo de publicación de métodos, para consultas remotas. Es decir, en local es obvio que debes usar conexión directa a BBDD, pero para proporcionar servicios remotos se hace así. Es por ejemplo el método usado por los operadores de vuelos para que cualquier aplicación pueda consultarlos.

Pero insisto, nos estamos desviando

No te creas, en Java se hacen muchas versiones de juegos clásicos hechas por aficionados que luego suben a diferentes páginas y te puedes descargar, yo mismo hiciera hace mucho tiempo un shooter, y para ir a full speed necesitabas mínimo 1GHz...

icecaap escribió:

kusfo79 escribió:No hace falta preguntar, ya se sabe por seguro que solo se usaba ensamblador

Cierto, Yūji Naka ya nos lo dice en un vídeo :

http://www.gamespot.com/videos/acmi-game-masters-yuji-naka/2300-6384581/

Aunque estoy un poco de acuerdo también con los compañeros: el hacerlo en ASM o otro lenguaje de alto nivel dependería de el tipo de juego, el equipo de desarrollo, la compañía, etc.

Es posible que contrataran a gente para hacer un compilador C muy optimizado para una arquitectura o para hacer un tipo de juego concreto. También es posible que usaran C para hacer herramientas de apoyo (para diseño de gráficos, reglas físicas, etc.) y que estas herramientas proporcionaran el código ASM ya optimizado.

Pero claro, supongo que las compañías guardarían bajo llave estas herramientas y compiladores como mucho las intercambiaban con otras compañías por un módico precio.

Obviamente las herramientas de apoyo podían estar programadas en lo que fuera. Como curiosidad, mira con que hacían gráficos en Sega en 1986:



Por otro lado, hace tiempo se filtró la herramienta de edición de graficos que suministraba sega en los tiempos de la Megadrive, pero era una basura. Seguramente las compañias usaban cosas como el Deluxe Paint II, y luego usaban un programa que lo convertía a asm.

Muy interesante @kusfo79 . Joer pantalla táctil y todo

Por cierto he encontrado otra imagen interesante:



Parece ser sacada de un documental, pero no lo he encontrado

Edit:

Encontrado:

http://www.youtube.com/watch?v=Ym2ve5_YD60&t=6m

Curioso, sintaxis del 8080...

kusfo79 escribió:Seguramente las compañias usaban cosas como el Deluxe Paint II, y luego usaban un programa que lo convertía a asm.

Ni los gráficos ni el sonido hay que convertirlos a ensamblador ni a ningún otro lenguaje, eso no tiene sentido. Solo tienen que estar en el formato que corresponda al cargador de gráficos que tengamos en el código (yo suelo usar una especie de tiff o un iff), y estar almacenados en la rom.Nada más.

Pek escribió:

kusfo79 escribió:Seguramente las compañias usaban cosas como el Deluxe Paint II, y luego usaban un programa que lo convertía a asm.

Ni los gráficos ni el sonido hay que convertirlos a ensamblador ni a ningún otro lenguaje, eso no tiene sentido. Solo tienen que estar en el formato que corresponda al cargador de gráficos que tengamos en el código (yo suelo usar una especie de tiff o un iff), y estar almacenados en la rom.Nada más.

Hombre, lo normal es convertir los graficos a asm, cargar imagenes lo veo medio locura, habria que escribir una libreria especifica para esa funcion

theelf escribió:

Pek escribió:Ni los gráficos ni el sonido hay que convertirlos a ensamblador ni a ningún otro lenguaje, eso no tiene sentido. Solo tienen que estar en el formato que corresponda al cargador de gráficos que tengamos en el código (yo suelo usar una especie de tiff o un iff), y estar almacenados en la rom.Nada más.

Hombre, lo normal es convertir los graficos a asm, cargar imagenes lo veo medio locura, habria que escribir una libreria especifica para esa funcion

Es que creo que ambos hablais de cosas diferentes . Tu estás hablando de lo que podríamos llamar "el modo tile", que es el que usaban las consolas (se nota que le pegas a la MD) y Pek está hablando del "modo bitmap", que podía usarse en ordenadores como el Amiga, de ahí la diferencia de criterios.

El MSX2 puede manejar ambos modos:
- Screen 4 o modo tile. Así funciona como una consola, efectivamente los gráficos se meten directamente en memoria mediante funciones ASM y el acceso a los mismos es muy rápido. No son bitmaps al uso, son datos que se mueven en memoria. Ideal para arcades por la velocidad que proporciona.
- Screen 5 o modo bitmap, que se comporta como describe Pek. Tu cargas imágenes en VRAM y luego necesitas un programa cargador para leerlos, ni más ni menos. Ideal para RPGs por la calidad que proporciona.

Efectivamente, a eso me refiero.

Básicamente siempre codeo en Amiga. Ya me cuesta pensar en tiles y sprites, tiendo mas a los layers y bitplanes. Deformación profesional xD

Ahi mencionaron a la megadrive

Cuando me refiero a asm, me refiero a dejarlo en un formato para que lo puedas ensamblar bien, por ejemplo:
--------------------------------------------------------
.section .rodata

.align 2
gfx_hScroll_player_shots_palette_pal:
dc.w 0x0E0E, 0x0E42, 0x0C84, 0x0CC4, 0x0CCA, 0x0EEE, 0x00EE, 0x00AA
dc.w 0x004E, 0x000A, 0x0006, 0x0002, 0x0CCC, 0x0888, 0x0444, 0x0000

.align 2
gfx_hScroll_player_shots_palette:
dc.w 0, 16
dc.l gfx_hScroll_player_shots_palette_pal

.align 2
gfx_hScroll_player_shots_animation0_frame0_sprite0_tileset_tiles:
dc.b 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x22, 0x23, 0x22, 0x23, 0x33, 0x45
dc.b 0x00, 0x02, 0x22, 0x23, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
dc.b 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x34, 0x44, 0x40, 0x55, 0x55, 0x55, 0x54
dc.b 0x33, 0x34, 0x44, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
---------------------------------------------------------------

Esto es lo que generamos con nuestra herramientas para el Antarex, pasamos una imagen en un formato gráfico actual, y la paletizamos y quantizamos, y se exporta a este formato.

kusfo79 escribió:Cuando me refiero a asm, me refiero a dejarlo en un formato para que lo puedas ensamblar bien, por ejemplo:
--------------------------------------------------------
.section .rodata

.align 2
gfx_hScroll_player_shots_palette_pal:
dc.w 0x0E0E, 0x0E42, 0x0C84, 0x0CC4, 0x0CCA, 0x0EEE, 0x00EE, 0x00AA
dc.w 0x004E, 0x000A, 0x0006, 0x0002, 0x0CCC, 0x0888, 0x0444, 0x0000

.align 2
gfx_hScroll_player_shots_palette:
dc.w 0, 16
dc.l gfx_hScroll_player_shots_palette_pal

.align 2
gfx_hScroll_player_shots_animation0_frame0_sprite0_tileset_tiles:
dc.b 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x22, 0x23, 0x22, 0x23, 0x33, 0x45
dc.b 0x00, 0x02, 0x22, 0x23, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
dc.b 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x34, 0x44, 0x40, 0x55, 0x55, 0x55, 0x54
dc.b 0x33, 0x34, 0x44, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
---------------------------------------------------------------

Esto es lo que generamos con nuestra herramientas para el Antarex, pasamos una imagen en un formato gráfico actual, y la paletizamos y quantizamos, y se exporta a este formato.

Eso es el modo tile que he descrito 2 mensajes más arriba . En las consolas, donde priman los arcades, es el pan de cada día. Lo que me pregunto es si los RPGs se hacían también en modo tile, porque sería un currazo, o por el contrario las consolas también soportan modo bitmap (que es lo razonable a pensar).

Hombre, yo creo que el modo Tile aún se ajusta más a los RPG's que otros generos...

Pero respondiendo a tu pregunta, ni Nes, ni Master, ni Mega, ni Super, ni PC Engine ni Neo Geo soportan modo bitmap.

Aunque es posible simular un modo bitmap, usando un grupo de tiles como framebuffer, pero normalmente los chips de video no permiten el acceso a nivel de pixel individual, con lo que resulta poco eficiente usar ese modo (aparte que en la master y la Nes, no hay suficiente VRAM como para llenar toda la pantalla a la vez, has de reusar tiles obligatoriamente).

Pero las imágenes no se convierten a asm, sino que se convierten a lo que sea para que sean utilizables de una u otra forma mediante asm. No estoy hablando de aspectos técnicos, sino de pura semántica. Las imágenes son datos binarios, simplemente, ¿no? Entiendo entonces que no se pueden convertir a ensamblador, porque es un lenguaje de programación, no un formato de guardado de datos.

javierator1981 escribió:Pero las imágenes no se convierten a asm, sino que se convierten a lo que sea para que sean utilizables de una u otra forma mediante asm. No estoy hablando de aspectos técnicos, sino de pura semántica. Las imágenes son datos binarios, simplemente, ¿no? Entiendo entonces que no se pueden convertir a ensamblador, porque es un lenguaje de programación, no un formato de guardado de datos.

El cual, puede traducirse a uno que entienda el ASM sin medio de intérpretes.

En mis tiempos mozos transladé un ejemplo en basic a un cpc 6128+. Un juego de 300 y pico líneas de código (de 10 en 10, unas 3000 y pico) en el que un icono que representaba a un perro guardian, ladraba... y además sonaba muy bien a ladrido.

Me quedé muy sorprendido, porque claro, lo único que había hecho era teclear, no digitalizar sonidos, y sin embargo se estaba escuchando perfectamente como el chucho hacía sus cosas de chucho (ladrar a las pobres personas que solo quieren entrar en una casa a robar).

En definitiva, que si hubiese que cargar un interprete en memoria, y usar ciclos de cpu en reproducir el ejemplo de sonido, lo único que ganas es dar mas vueltas, y perder potencia. Si tienes una manera de traducir esos sonidos al amasijo de datos en ASM que hacen exactamente lo mismo (reproducir un sonido, puesto que al final todo son bits), pues todo eso que te ahorras.


Tal vez me equivoque, no se xD

kusfo79 escribió:Hombre, yo creo que el modo Tile aún se ajusta más a los RPG's que otros generos...

Pero respondiendo a tu pregunta, ni Nes, ni Master, ni Mega, ni Super, ni PC Engine ni Neo Geo soportan modo bitmap.

Bueno depende, en MSX2 hacer un RPG en modo bitmap es más accesible que en modo tile. Los gráficos los metes en VRAM directamente desde el editor gráfico y luego los lees a bloques. En el modo tile existen restricciones de color que no existen en modo bitmap.

javierator1981 escribió:Pero las imágenes no se convierten a asm, sino que se convierten a lo que sea para que sean utilizables de una u otra forma mediante asm. No estoy hablando de aspectos técnicos, sino de pura semántica. Las imágenes son datos binarios, simplemente, ¿no? Entiendo entonces que no se pueden convertir a ensamblador, porque es un lenguaje de programación, no un formato de guardado de datos.

El modo de trabajar cambia radicalmente. En modo tile los gráficos son realmente "direcciones de memoria" y tu juegas a moverlas de unos sitios a otros. En modo bitmap tu guardas en VRAM una imagen "real", vamos que puedes visualizarla como si se tratara de un visor de imágenes, y lo que haces es copiar selectivamente a la página activa (visualización) lo que te interesa. Más lento pero más potente.

AxelStone escribió:

kusfo79 escribió:Hombre, yo creo que el modo Tile aún se ajusta más a los RPG's que otros generos...

Pero respondiendo a tu pregunta, ni Nes, ni Master, ni Mega, ni Super, ni PC Engine ni Neo Geo soportan modo bitmap.

Bueno depende, en MSX2 hacer un RPG en modo bitmap es más accesible que en modo tile. Los gráficos los metes en VRAM directamente desde el editor gráfico y luego los lees a bloques. En el modo tile existen restricciones de color que no existen en modo bitmap.

A ver, en Mega también "troceas" los gráficos desde el editor para colocarlos luego en la VRAM, y por otro lado cargas el tilemap.

Las restricciones de colores te las encuentras igual tanto en un modo como en otro. El mítico 13h de PC era un modo bitmap con 256 colores, y la super tenia modos con más colores y era con Tilemap.

javierator1981 escribió:Pero las imágenes no se convierten a asm, sino que se convierten a lo que sea para que sean utilizables de una u otra forma mediante asm. No estoy hablando de aspectos técnicos, sino de pura semántica. Las imágenes son datos binarios, simplemente, ¿no? Entiendo entonces que no se pueden convertir a ensamblador, porque es un lenguaje de programación, no un formato de guardado de datos.

El trozo que he pasteado antes, son los datos en formato ensamblador, para que puedan ser ensamblados:
.align 2
gfx_hScroll_player_shots_palette:
dc.w 0, 16
dc.l gfx_hScroll_player_shots_palette_pal

.align 2
gfx_hScroll_player_shots_animation0_frame0_sprite0_tileset_tiles:
dc.b 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x22, 0x23, 0x22, 0x23, 0x33, 0x45
dc.b 0x00, 0x02, 0x22, 0x23, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
dc.b 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x34, 0x44, 0x40, 0x55, 0x55, 0x55, 0x54
dc.b 0x33, 0x34, 0x44, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00


Si lo exportara en binario directamente, seria algo del tipo:

0383BD38A8329C332B987F38A8329C33232B987F38A83C332B987F38A8329C33232B98
232B987F38A83C332B987F38A8329C33232B980383BD38A8329C332B987F38A82B987B
0383BD38A8329C332B987F38A8329C33232B987F38A83C332B987F38A8329C33232B98

Ojo, es una manera de representar esos datos que están el formato propio de la consola destino (datos planos RGB de 9 bits en el caso de megadrive).

kusfo79 escribió:A ver, en Mega también "troceas" los gráficos desde el editor para colocarlos luego en la VRAM, y por otro lado cargas el tilemap.

Las restricciones de colores te las encuentras igual tanto en un modo como en otro. El mítico 13h de PC era un modo bitmap con 256 colores, y la super tenia modos con más colores y era con Tilemap.

Tranquilo entiendo lo que dices, el modo tile del MSX2 funciona así. De todos modos lo de las restricciones de color bueno, no se bien cómo irá en MD, pero en MSX2 por ejemplo hay diferencias entre SC4 (modo tile) y SC5 (modo bitmap). En modo tile cada tile de 8x8 solo puede tener 2 colores horizontales en una misma línea, en modo bitmap no hay esa restricción, por eso se usaba mucho en los RPG.

AxelStone escribió:Tranquilo entiendo lo que dices

qué suerte

Na en serio, me suena a chino todo lo que decís, pero es un gustazo leeros. Adelante

AxelStone escribió:

kusfo79 escribió:A ver, en Mega también "troceas" los gráficos desde el editor para colocarlos luego en la VRAM, y por otro lado cargas el tilemap.

Las restricciones de colores te las encuentras igual tanto en un modo como en otro. El mítico 13h de PC era un modo bitmap con 256 colores, y la super tenia modos con más colores y era con Tilemap.

Tranquilo entiendo lo que dices, el modo tile del MSX2 funciona así. De todos modos lo de las restricciones de color bueno, no se bien cómo irá en MD, pero en MSX2 por ejemplo hay diferencias entre SC4 (modo tile) y SC5 (modo bitmap). En modo tile cada tile de 8x8 solo puede tener 2 colores horizontales en una misma línea, en modo bitmap no hay esa restricción, por eso se usaba mucho en los RPG.

Ah vale, tampoco tengo un especial conocimiento del MSX2 . Creo que es por que los modos tileables son heredados del MSX, no?
En todo caso, en máquinas mixtas, solía ser al revés, los modos tileables tenían más colores ya que requerían menos VRAM

kusfo79 escribió:Ah vale, tampoco tengo un especial conocimiento del MSX2 . Creo que es por que los modos tileables son heredados del MSX, no?
En todo caso, en máquinas mixtas, solía ser al revés, los modos tileables tenían más colores ya que requerían menos VRAM

Ni idea, pero intuyo que las consolas funcionan como el MSX2 en modo tile. De hecho las consolas pueden ir muy escasas de RAM y VRAM porque usan el cartucho para leer datos en tiempo real. El MSX2 también tenía cartuchos, y sus juegos cartucheros destilan un olorcillo consolero curioso, mientras que sus juegos en disco se nota que son productos más "de ordenador".

oh, una cosa que comentas, que tienes toda la razón, es que cuando tienes un sistema de tiles, aunque potente, necesitas una manera muy rápida de recargar el tileset y el tilemap, lo que es posible si los datos están en ROM, e impracticable si estos están en disco...

1985a escribió:Aquí, tienes varias vías para aprender a programar ASM,
https://github.com/vhf/free-programming-books/blob/master/free-programming-books.md#assembly-language
He visto y algunos y tienen buena pinta.

Le he echado un ojo y hay bastante material ahí. Me viene de lujo.
¡Gracias!