Codigo Fuente en Txt del Metroid de Nintendo

[Elric]

Pues eso, que navegando por los procelosos mares de internet me encontre este codigo fuente por si a alguien le interesa portarlo (aunque ya se que en el emulador funciona a las mil maravillas pues por si alguien se aburre y quiere pasarlo a la Gp ;) ,yo de programacion no tengo ni idea)

SAcado de la siguiente pagina:

http://www.retrones.cjb.net/

[(_=*ZaXeR*=_)]

Pos pasarlo a la GP es una bestialidad, es mejor hacer el juego desde 0, porque esta completamente escrito en ensamblador de la nes.

Porcierto es muy muy curioso ver como es el codigo fuente de un juego de estas caracteristicas, imaginaros como los programaban, ufff.

[timofonic]

No es el codigo original, es un desensamblado del codigo, y luego reconstruido para que sea igual, lo pone en el fichero ... Y bueno, eso compila, ¿pero donde estan los graficos? ¿Y el sonido? :D

[Karadan]

Lo graficos y el sonido salen de las letras del notepad. ;)

[timofonic]

¿Estas seguro que los sprites y el sonido esta en el ensamblador metido? Se perfectamente que se puede hacer y de hecho se hacia con los cartuchos...

[Diabloman]

jodo, pues a mi me parece muy poco codigo para que todo el metroid con todo su mapeado y los graficos y sonido esten ahi metidos... claro que ya no se hacen juegos como antes y puede estar todo muy bien condensado ahi.

La verdad es que es muy curioso echarle un vistazo.

[(_=*ZaXeR*=_)]

Si es un desensamblado me parece un trabajo de chinos reestructurar eso, es mas facil hacer de nuevo el codigo. Y bueno parece ser que si estan los sprites incluidos, o por lo menos es lo que veo comentado.

[enkonsierto]

De cajón que es un desensamblado.

[(_=*ZaXeR*=_)]

A mi no me parece tanto de cajon. Si es un desensamblado pues vale, pero de cajon nada. Antes cuando programabas no te podias permitir hacerlo en C directamente para hacer un juego de estas caracteristicas para una consola de estas capacidades, hay que usar muchisimo ensamblador para depurar, para que no se genere codigo innecesario que hace bajar bastante el rendimiento de una maquina de este tipo, que son 8 bits. Tanto es asi, que actualmente se sigue usando para depurar, y en los tiempos de la Saturn todavia era algo que se explotaba bastante, cosa por la cual se decia que saturn era dificil de programar (imaginate ensamblador de SH2, y multiplicado por 2 mas el SH1 que tambien tiene).

[CaraMuuu]

Yo he leido q el problema de la saturn esq para utilizar los dos procesadores en paralelo hacía falta programar en ensamblador, y q por ello al final muchos juegos acababan usarndo lo 1 de los 2 SH2 que llevaba
no tengo ni idea del tema, pero eso es lo q he leido

[Segata Sanshiro]

Pues un código desensamblado no creo que sirva para mucho, a mí me gustaría ver el código original, con sus comentarios de los programadores, etc.

[(_=*ZaXeR*=_)]

Basicamente el uso de dos procesadores identicos para lo mismo es problematico sino se hace un SDK potente, aunque tambien se puede dejar a libre eleccion de los desarrolladores, puesto que el dejar la programacion a este nivel hace que sea muy flexible para sacar mucho mayor rendimiento a la maquina repartir los trabajos etc, pero la programacion de multiplica por 5 o mas.

Osea que con tiempo suficiente la Saturn podria haber rendido muchisimo mas de lo que lo hizo, con decir que el Panzer Dragon Saga que es un juego que supera graficamente a muchos juegos de la PSX, y es en 3D, seria solo un minimo de lo que era posible hacerse, pero si se piensa en que los de Andromeda se tiraron muchisimo tiempo para programar este juego...

[Segata Sanshiro]

Vale, cagada, el código está comentadísimo, como dudo que sea el original de Nintendo, enhorabuena al que se lo haya currado tanto (a ver si lo hacen con algún Sonic o Phantasy Star).

Por otro lado tenemos esta rutina gráfica que carga los sprites:



; LoadGFX
; =======
; Y contains the GFX header to fetch from the table above, GFXInfo.

LoadGFX:
lda #$FF
- clc
adc #$07 ; each header is 7 bytes
dey ; advanced to the (end of the) desired header?
bpl - ; if not, advance to the next
tay ; Y is now the index into GFXInfo table (see above)

; Copy header from ROM to $00-$06

ldx #$06
- lda GFXInfo,y
sta $00,x
dey
dex
bpl -

ldy $00 ; ROM bank containing the GFX data
jsr ROMSwitch ; switch to that bank
lda PPUCNT0ZP
and #$FB ; PPU increment = 1
sta PPUCNT0ZP
sta PPUControl0
jsr CopyGFXBlock
ldy CurrentBank
jmp ROMSwitch ; switch back to the "old" bank


Entonces, los gráficos no estarían incluídos en la parte de código sino más alante en el cartucho.

[ilarri]

es un curroi, exo por alguien k kiere muxo a la nes o al metroid ^^

kiero ver el del mario bros 3

[oankali]

En ese código fuente no veo ni los sprites, ni los sonidos, ni las fuentes, ni los mapas, en fin ningún recurso necesario. Solo el código del programa.
Si estuvieran, se verian unas tablas enormes de números probablemente en hexadecimal, y no hay ninguna.
Claro que en un archivo ASCII comentado de 195 KB no puede haber todo eso.

[Segata Sanshiro]

Vale, bien hablé sin saber. Es de un desensamblado, pero con variables (el autor ha averiguado para qué servían ciertas direcciones de memoria en un curro brutal y ha reinventado los nombres de las variables) y comentarios brutales... Entonces no hay duda, no fui el único que opinó sin saber, no? xD Y por supuesto Oankali tiene razón

[(_=*ZaXeR*=_)]

Eso de que tienen que salir tablas inmensas... esta muy bien para un juego actual, pero se trata de un juego de una consola que tenia una resolucion prehistorica, con muy pocos colores, y en los que un grafico se hace con 20 pixels y 3 colores, vamos que con pocas lineas se pueden hacer graficos sin problemas. Yo dejo estas lineas para que se discuta sobre el tema, aunque deberia verse el trozo de codigo completo que es mas grande, para entender lo que hace completamente.



InitTitleGFX:
ldy #$15
jsr LoadGFX
ldy #$00
jsr LoadGFX
lda JustInBailey
beq + ; branch if wearing suit
ldy #$1B
jsr LoadGFX ; switch to girl gfx
+ ldy #$14
jsr LoadGFX
ldy #$17
jsr LoadGFX
ldy #$18
jsr LoadGFX
ldy #$19
jsr LoadGFX
ldy #$16
jmp LoadGFX

InitBrinstarGFX:
ldy #$03
jsr LoadGFX
ldy #$04
jsr LoadGFX
ldy #$05
jsr LoadGFX
ldy #$06
jsr LoadGFX
ldy #$19
jsr LoadGFX
ldy #$16
jmp LoadGFX

InitNorfairGFX:
ldy #$04
jsr LoadGFX
ldy #$05
jsr LoadGFX
ldy #$07
jsr LoadGFX
ldy #$08
jsr LoadGFX
ldy #$09
jsr LoadGFX
ldy #$19
jsr LoadGFX
ldy #$16
jmp LoadGFX

InitTourianGFX:
ldy #$05
jsr LoadGFX
ldy #$0A
jsr LoadGFX
ldy #$0B
jsr LoadGFX
ldy #$0C
jsr LoadGFX
ldy #$0D
jsr LoadGFX
ldy #$0E
jsr LoadGFX
ldy #$1A
jsr LoadGFX
ldy #$1C
jsr LoadGFX
ldy #$19
jsr LoadGFX
ldy #$16
jmp LoadGFX

InitKraidGFX:
ldy #$04
jsr LoadGFX
ldy #$05
jsr LoadGFX
ldy #$0A
jsr LoadGFX
ldy #$0F
jsr LoadGFX
ldy #$10
jsr LoadGFX
ldy #$11
jsr LoadGFX
ldy #$19
jsr LoadGFX
ldy #$16
jmp LoadGFX

InitRidleyGFX:
ldy #$04
jsr LoadGFX
ldy #$05
jsr LoadGFX
ldy #$0A
jsr LoadGFX
ldy #$12
jsr LoadGFX
ldy #$13
jsr LoadGFX
ldy #$19
jsr LoadGFX
ldy #$16
jmp LoadGFX

InitGFX6:
ldy #$01
jsr LoadGFX
ldy #$02
jsr LoadGFX
ldy #$19
jsr LoadGFX
ldy #$16
jmp LoadGFX

InitGFX7:
ldy #$17
jsr LoadGFX
ldy #$16
jmp LoadGFX

; The table below contains info for each tile data block in the ROM.
; Each entry is 7 bytes long. The format is as follows:

; byte 0: ROM bank where GFX data is located.
; byte 1-2: 16-bit ROM start address (src)
; byte 3-4: 16-bit PPU start address (dest)
; byte 5-6: data length (16-bit)

GFXInfo .db $06 : .dw $8000, $0000, $09A0 ; [SPR] Samus, items
.db $04 : .dw $8D60, $0000, $0520 ; [SPR] Samus in ending
.db $01 : .dw $8D60, $1000, $0400 ; [BGR] Partial font, "The End"
.db $06 : .dw $9DA0, $1000, $0150
.db $05 : .dw $8D60, $1200, $0450
.db $06 : .dw $9EF0, $1800, $0800
.db $01 : .dw $9160, $0C00, $0400 ; [SPR] Brinstar enemies
.db $06 : .dw $A6F0, $1000, $0260
.db $06 : .dw $A950, $1700, $0070
.db $02 : .dw $8D60, $0C00, $0400 ; [SPR] Norfair enemies
.db $06 : .dw $A9C0, $1000, $02E0
.db $06 : .dw $ACA0, $1200, $0600
.db $06 : .dw $B2A0, $1900, $0090
.db $05 : .dw $91B0, $1D00, $0300
.db $02 : .dw $9160, $0C00, $0400 ; [SPR] Tourian enemies
.db $06 : .dw $B330, $1700, $00C0
.db $04 : .dw $9360, $1E00, $0200
.db $03 : .dw $8D60, $0C00, $0400 ; [SPR] Miniboss I enemies
.db $06 : .dw $B3F0, $1700, $00C0
.db $03 : .dw $9160, $0C00, $0400 ; [SPR] Miniboss II enemies
.db $06 : .dw $89A0, $0C00, $0100
.db $06 : .dw $8BE0, $1400, $0500 ; [BGR] Title
.db $06 : .dw $9980, $1FC0, $0040
.db $06 : .dw $B4C0, $1000, $0400 ; [BGR] Complete font
.db $06 : .dw $B4C0, $0A00, $00A0
.db $06 : .dw $9980, $0FC0, $0040
.db $06 : .dw $B4C0, $1D00, $02A0
.db $06 : .dw $90E0, $0000, $07B0 ; [SPR] Suitless Samus
.db $06 : .dw $9890, $1F40, $0010

; LoadGFX
; =======
; Y contains the GFX header to fetch from the table above, GFXInfo.

LoadGFX:
lda #$FF
- clc
adc #$07 ; each header is 7 bytes
dey ; advanced to the (end of the) desired header?
bpl - ; if not, advance to the next
tay ; Y is now the index into GFXInfo table (see above)

; Copy header from ROM to $00-$06

ldx #$06
- lda GFXInfo,y
sta $00,x
dey
dex
bpl -

ldy $00 ; ROM bank containing the GFX data
jsr ROMSwitch ; switch to that bank
lda PPUCNT0ZP
and #$FB ; PPU increment = 1
sta PPUCNT0ZP
sta PPUControl0
jsr CopyGFXBlock
ldy CurrentBank
jmp ROMSwitch ; switch back to the "old" bank

; CopyGFXBlock
; =============
; Writes tile data from ROM to VRAM, according to the gfx header data
; contained in $00-$06.

CopyGFXBlock:
lda $05
bne GFXCopyLoop
dec $06
GFXCopyLoop:
lda $04
sta PPUAddress
lda $03
sta PPUAddress
ldy #$00
- lda ($01),y
sta PPUIOReg
dec $05
bne +
lda $06
beq ++
dec $06
+ iny
bne -
inc $02
inc $04
jmp GFXCopyLoop
++ rts

[Segata Sanshiro]

Pero Zaxer, creo que eso son direcciones de memoria para acceder a la parte de la ROM donde están los gráficos, no?

[(_=*ZaXeR*=_)]

No estoy muy seguro porque tampoco me he parado a analizarlo, pero con todas las lineas que hay ahi se pueden poner los sprites en pantalla sin problemas con su color correspondiente.

Lo que me quiero referir es que sino estan los graficos no es porque no quepan porque caben de sobra, solo decir que si ese codigo que he incluido es para leer desde otra direccion de memoria para almacenarlo y despues ponerlo en pantalla, eso en ensamblador son mas lineas de codigo que poner un byte (osea pixel de color determinado) en una direccion de memoria (osea la pantalla)

[Segata Sanshiro]

Pues yo me aburro y sí lo he analizado :p xDDD



The table below contains info for each tile data block in the ROM.
; Each entry is 7 bytes long. The format is as follows:

; byte 0: ROM bank where GFX data is located.
; byte 1-2: 16-bit ROM start address (src)
; byte 3-4: 16-bit PPU start address (dest)
; byte 5-6: data length (16-bit)


En este caso son direcciones de memoria, aunque sí que he visto un juego en el que se hacía eso de meter los gráficos en el código, a lo db ff235,f2332,etc. pero es una currada!

[(_=*ZaXeR*=_)]

El hecho de que los graficos esten no esten en ese codigo es meramente anecdotico, osea que se debe a una preferencia de los programadores para facilitar la programacion, pero el decir que no estan porque no caben no es asi, el codigo escrito ahi tiene de sobra para todos los spitres. Mas aun,

GFXInfo .db $06 : .dw $8000, $0000, $09A0 ; [SPR] Samus, items
.db $04 : .dw $8D60, $0000, $0520 ; [SPR] Samus in ending
.db $01 : .dw $8D60, $1000, $0400 ; [BGR] Partial font, "The End"
.db $06 : .dw $9DA0, $1000, $0150
.db $05 : .dw $8D60, $1200, $0450
.db $06 : .dw $9EF0, $1800, $0800
.db $01 : .dw $9160, $0C00, $0400 ; [SPR] Brinstar enemies
.db $06 : .dw $A6F0, $1000, $0260
.db $06 : .dw $A950, $1700, $0070
.db $02 : .dw $8D60, $0C00, $0400 ; [SPR] Norfair enemies
.db $06 : .dw $A9C0, $1000, $02E0
.db $06 : .dw $ACA0, $1200, $0600
.db $06 : .dw $B2A0, $1900, $0090
.db $05 : .dw $91B0, $1D00, $0300
.db $02 : .dw $9160, $0C00, $0400 ; [SPR] Tourian enemies
.db $06 : .dw $B330, $1700, $00C0
.db $04 : .dw $9360, $1E00, $0200
.db $03 : .dw $8D60, $0C00, $0400 ; [SPR] Miniboss I enemies
.db $06 : .dw $B3F0, $1700, $00C0
.db $03 : .dw $9160, $0C00, $0400 ; [SPR] Miniboss II enemies
.db $06 : .dw $89A0, $0C00, $0100
.db $06 : .dw $8BE0, $1400, $0500 ; [BGR] Title
.db $06 : .dw $9980, $1FC0, $0040
.db $06 : .dw $B4C0, $1000, $0400 ; [BGR] Complete font
.db $06 : .dw $B4C0, $0A00, $00A0
.db $06 : .dw $9980, $0FC0, $0040
.db $06 : .dw $B4C0, $1D00, $02A0
.db $06 : .dw $90E0, $0000, $07B0 ; [SPR] Suitless Samus
.db $06 : .dw $9890, $1F40, $0010

ese trozo unicamente sirve para leer el contenido de memoria a la que apunta la parte byte de un varios registro de direcciones, hacia otras direcciones de memoria con tamaño palabra.
Traduccion, equivale a copiar todos los sprites a registros direcciones de la RAM, de donde despues se tienen que volcar a la pantalla, pero en las mismas lineas se puede hacer que en lugar de copiar bytes a la memoria, se haga a la pantalla directamente. Osea que caber cabe.

[(_=*ZaXeR*=_)]

Ese trozo que he escrito tan solo, multiplicado por 2 serian todos los graficos completos en bytes pintados en pantalla. Y con poner una rutina te pueden escribir tantas veces como se quiera en pantalla los mismos graficos.

Basicamente todo se reduce en que los graficos si que caben porque hablamos de un juego de hace 18 o 19 años, el hecho de estar separado del codigo del juego es irrelevante, porque si que caben, es solo por comodidad para el programador a la hora de modificarlos si quiere.

PD: En los juegos desde las consolas de 16 bits hasta ahora (incluso algunos de las 8bits depende del juego), esto de lo que estoy hablando sobre que se pueden incluir los graficos dentro de el codigo fuente sin que haya un cambio de tamaño bestial, es una brutalidad. Repito nunca se hace esto de meter los graficos, pero en consolas tan antiguas los graficos no suponen tanto como para no incluirlos, si no se incluyen es para facilitar el ser modificados.

[oankali]

Vaya, no sabía que mi respuesta te daría tanto trabajo Zaxer :)

Aún entendiendo que el juego es muy viejo, y que no está en 16 bits, pero en 2 (4 colores) bits por píxel, sigo pensando que los gráficos en hexadecimal no cabrían en 195 Kb sabiendo que en estos 195Kb hay el código comentado.
Recuerdo que cuando programaba para el ZX Spectrum 48K (con teclado de goma :) ) en el año 83-84, tenia que entrar una cantidad de líneas DATA que no veas y eso para poner un gráficos monocromos con un octeto especial de atributo.
Un juego comercial como el Metroid, tiene muchos escenarios, sprites diferentes, enemigos, efectos especiales, todo con movimiento o sea que hay que multiplicar todo por el número de frames de cada sprite.

Pongamos un ejemplo rápido para tener una idea de lo que puede representar: Samus, el personaje principal mide 32 octetos de alto por 16 de ancho (más si está de perfil). Por lo que he podido comprobar, el personaje tiene 4 colores (verde, rojo, naranja y trasparente), lo que significa que se representa cada píxel con 2 bits.
O sea, que para representar un solo frame de Samus de cara necesitaríamos 16 * 2 bits para cada línea del sprite o sea 4 octetos. Total 4 * 32 = 128 octetos para representar a Samus de cara.
Pasando todo esto a hexadecimal sabemos que 1 octeto ocupa 2 caracteres ASCII, o sea que 128 octetos serian 256 caracteres. Eso sin contar comas, espacios ni otros caracteres necesarios para representar estos datos en un código ensamblador (como por ejemplo el prefijo $).

Ahí va lo que ocuparía como mínimo Samus de cara en el archivo .txt:

$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,
$0000, $0000, $0000, $0000,

Bueno, pues que sigo pensando que si los gráficos (enemigos, decorados, efectos especiales, items, ...) estuvieran en el archivo .txt, saltarían a la vista las tablas y que el archivo sería sumamente más grande.
Esto sin hablar de los mapas, sonidos, fuentes o de las pantallas de presentación que ocupan mucho.

[enkonsierto]

Como te complicas la vida zaxer, es un descompilado y no están los gráficos ahí.

[(_=*ZaXeR*=_)]

enkonsierto, si esta muy bien que sea un desensamblado, pero yo sigo pensando que aunque no esten los graficos, eso no quiere decir que no quepan en un txt, osea que el decir que no pueden estar los graficos porque no caben no me parece una justificacion para decir que no estan. Osea que sino estan es porque no estan, pero no porque no quepan, esto es lo que yo quiero decir.

oankali si es cierto que un frame de Samus puede ocupar eso, pero tienes que tener en cuenta una cosa, cada los pixeles que se encuentren del mismo color consecutivos en pantalla se puede reducir a una unica intruccion en la que se copia un byte a un rango de direcciones de memoria, si se tiene esto en cuenta, y se tiene en cuenta que se pueden poner rutinas para pintar los bytes incrementando la memoria para el scrolling, pues la verdad es que se reducen los graficos de una forma drastica.

Osea a lo que yo me refiero es a pintar los sprites byte a byte, y por rangos de direcciones de memoria, por lo que no hace falta ninguna tabla ni nada que almacene al detalle el sprite completo, osea que no es una tabla en el txt a lo que me refiero, sino pintar los pixels mediante codigo.

Otro metodo para pintar los sprites tambien podria ser que con una linea de codigo serviria para pintar todos los pixels de color X, solo indicando las direcciones donde deben ir, lo que pasa es que esto seria inviable por el tema de como controlar los elementos moviles, que se convertiria en muchisimas variables.

[oankali]

Zaxer, he tenido que leer tu post dos veces seguidas para estar seguro que entendía bien lo que ponía, y nada, que me has dejado pasmao, no sé que decir, en serio.

Tus ideas son interesantes en cuanto al planteamiento que has debido de seguir para llegar a estas conclusiones, pero según mi punto de vista de programador son extremadamente complicadas y precisan mucho cálculo. En fin que completamente inviables.

De todas formas, aún haciendo lo que dices necesitas tablas a menos que quieras multiplicar por X (un X enorme) el código indicando todas las instrucciones en ensamblador para dibujar un sprite en pantalla con tu sistema. No sé si te das cuenta de lo que estás diciendo. Imagínate lo que costaría preparar todo esto o por ejemplo cambiar el aspecto de un solo sprite.

Por cierto el sistema que comentas en tu segundo párrafo me recuerda el sistema de compresión que se llama RLE (Run Length Encoding) y es el que utilizo en mis fuentes. Solo sirve para almacenar datos, no sirve para dibujarlos en pantalla.

Y para acabar, tengo entendido que la NES se parece a la GB en cuanto a programación o sea que en principio no es el programador el que imprime los sprites en pantalla, sino que lo hace directamente el chip gráfico. Esto significa que antes de poder pedirle al sistema que imprima un sprite hay que preparar unas tablas de sprites a partir de información almacenada en la ROM del cartucho. Esta información puede estar comprimida (y estoy casi seguro que es así), pero esto no te salva de tener tablas.

Y ya que le das mucha importancia a lo de si cabe en un .TXT me parece que no me expresé correctamente. Caber si que cabe, ya que un .TXT no tiene límite. Yo lo que decía es que en ese .TXT de 195 Kb, con el código comentado, pues que no podía caber.

Y nada, que este será mi último post en este hilo porque me parece que no llegaremos a ningún sitio.

Y que conste que no hay ningún mal rollo, solo que me estás dejando alucinado con las soluciones que presentas para demostrar lo que piensas es lo correcto.

Oankali.

[dj syto]

Perdonad mi ignorancia. Pero se supone ke los Tiles. Esos dibujitos ke salen en algunos emuladores, son los graficos no? a eso es a lo que llama el codigo cuando kiere mostrar graficos. Son como unos patrones. por lo que yo creo que la teoria de oankali es correcta. (aunke yo no entiendo mucho, pero he observado un poco)

[(_=*ZaXeR*=_)]

Vamos a ver yo no se como funciona la NES, asi que no se si es necesario o no el tener la tabla, pero todos modos, sigo pensando que si que caben los graficos de un juego como este, porque teniendo en cuenta cuantas lineas dedica a preparar para la lectura de las tablas, el direccionamiento y todo, la verdad es que creo que con el sistema que propongo cabe. Eso si, puede resultar muy chungo hacerlo, no lo niego. Pero la verdad es que esta misma solucion yo ya le he utilizado hace mucho tiempo, cuando no sabia sabia programar y comence de forma autodidacta a programar en basic y ensamblado, como no sabia ni lo que era una tabla, imaginate lo que era utilizarlas, por lo que los graficos los pintaba con rutinas.

Si piensas que esto no lleva a nada, bueno deacuerdo, pero yo creo que es interesante plantear cosas y conversar.

[oankali]

Yo también considero que es bueno conversar pero como yo estoy convencido de que lo que digo es correcto y tu estás convencido de que lo que dices podría funcionar, pues que estamos en un camino sin salida.

Por cierto, las tablas se inventaron para ahorar espacio y trabajo, no para que ocupe más el programa. Unas tablas bien pensadas sean para gráficos o para datos de programas benefícian siempre.
El código suele ser más fácil de leer, és más compacto y los datos más fáciles de mantener.

Y bueno como tu dices, ese sistema lo utilizaste cuando no sabias programar, ahora que sabes, supongo que te habrás dado cuenta que era una barbaridad, ¿entonces como puedes pensar que unos profesionales en programación de juegos hayan utilizado este sistema? Aunque sea hace 15 años.

[Diabloman]

Yo pienso que no se ha utilizado esa tecnica que dice Zaxxer por una razon simple, estamos hablando de una Nes, cuya capacidad de proceso es muy limitada, lo primero que comentas: "cada los pixeles que se encuentren del mismo color consecutivos en pantalla se puede reducir a una unica intruccion " esta es la base de la compresion de imagenes, pero luego para mostrar esas imagenes hay que procesar las instrucciones, imaginate procesar X frames por segundo, si a la Nintendo ya le costaria mostrarlas.

Y lo segundo: "una linea de codigo serviria para pintar todos los pixels de color X" matematicamente habria que crear una rutina muy compleja para pintar por ej los escenarior con esto, que son escenarios enormes y solamente por el trabajo que crearia esto ya me parece inviable, mas dificil me parece todavia como tu tbn comentas lo de tratar los elementos moviles, que por parte del programador serian unos quebraderos de cabeza terribles y por parte de la consola imposible de procesar.

De todas formas a mi me parrece muy instructiva esta conversacion :brindis:

[oankali]

Ei Zaxer que no hay mal rollo en mis respuestas eh!

:brindis:

[Xel_Naga]

Hola soy nuevo por estos foros. Simplemente quería deciros que me ha parecido bastante interesante la conversación que habéis mantenido. Desde mis humildes conocimientos yo también considero inviable el hecho de que se haya incluido el material gráfico en el código fuente. Seguiré leyendo de cerca e intentaré empaparme cada vez más para intentar aportar algo dentro de poco. ;)

[enkonsierto]

bienvenido a estos foros colega....
es logico que los graficos no estén ahí...

[bufalo73]

Zaxxer, lo que tu dices es una compresión RLE (la misma que usa el BMP). Es un método, pero no utilizable en una NES (desgraciadamente). Un 6502 no daba para tanto (lo se, tuve un VIC-20). Lo más normal es que el desensamblado sea de la parte programa, dejando la parte datos fuera (una lástima, podría estar todo y así estaría [aún] más fácil versionear) :)

[timofonic]

Yo creo que si lo metes en el codigo fuente, estaria todo amasijado, mas dificil de volcar a vram, porque de la otra forma como han dicho, es mas facil cambiar los graficos y esta separado, por lo cual es mas facil pegar los volcados a la vram, vamos, creo yo, casi no se de programacion y muchisimo menos de programacion grafica :)

[enkonsierto]

yo creo que más facil es jugarlo...

[Segata Sanshiro]

lo se, tuve un VIC-20 Tío yo también!!! Qué recuerdazos xDDDDD Qué pena que mi hermana se cargara el cassette! Todavía recuerdo cuando escribía en BASIC, y la tecla Commodore, y los colores, etc. Buah.....

[(_=*ZaXeR*=_)]

Escrito originalmente por bufalo73
Zaxxer, lo que tu dices es una compresión RLE (la misma que usa el BMP). Es un método, pero no utilizable en una NES (desgraciadamente). Un 6502 no daba para tanto (lo se, tuve un VIC-20). Lo más normal es que el desensamblado sea de la parte programa, dejando la parte datos fuera (una lástima, podría estar todo y así estaría [aún] más fácil versionear) :)
Vale mi error fue suponer que la NES podia, que se le va a hacer.
Es una lastima que no pueda hablar mucho porque toy de examenes.

PD: bufalo73 killo pasate por ñ-joy que a ti se te ve participativo, y como estamos Gaijin y yo de examenes la cosa estara muy parada. Apelo a tu sabiduria para darle vidilla en este mes al foro.
Un saludo colega.