|
Imanok
|
 |
« Respuesta #105 : 07 de Febrero de 2011, 11:28:45 pm » |
|
Tiene buena pinta la demo... pero como ya se ha dicho, queda muchísimo por delante para hacer el juego completo. Si lo conseguís, entonces vendrán las flores  Ánimo con ello!  |
|
|
|
|
En línea
|
|
|
|
|
toniman
Visitante
|
|
« Respuesta #106 : 07 de Febrero de 2011, 11:50:28 pm » |
|
Bueno Imanok, a no ser que salga un programador que quiera continuar la demo hasta hacerla juego, no podre terminarlo, los graficos si los tendria hechos todos, porque es mi parte, pero la parte del codigo ya no depende de mi. Ya sabes habras leido que Artrag solo va a programar la demo, que otro tiene que continuar desde este scroll con el personaje corriendo. Yo ya tengo bastante trabajo de graficos con DEVA y varios proyectos mas para MSX1 y 2. Tambien estoy contento, porque aunque no se haga el juego completo, se demuestra que MSX2 puede hacer scroll suave sin consumir casi nada de CPU, en screen5. Ademas tendreis el codigo fuente de este, para usarlo en lo que querais  Ahora estoy tambien preparando algunos graficos de Street Fighter 2 para comprovar que entran los movimientos de un personaje mirando a los dos lados en una pagina de 256x256. Pronto lo vereis. |
|
|
|
|
En línea
|
|
|
|
|
ARTRAG
Visitante
|
|
« Respuesta #107 : 08 de Febrero de 2011, 12:37:57 am » |
|
new version at https://sites.google.com/site/testmsx/Home/smooth-horizontal-scrollingI moved all the sprites I/O in the ISR avoiding to write to vram while #R18 is set It seems to be a VDP glitch (not emulated) that caused the black snow effect you was looking at I tested teh new code on my TR: on real HW, in z80 mode, everithing looks good In r800 mode some blocks in the tileset are not loaded correctly from disk I'll investigate BTW note that all the files have to stay on a disk on in a root of a CF partition They cannot stay in a subdirectory as disk I/O in HTC is based on CPM and it does not support msxdos2 features |
|
|
|
|
En línea
|
|
|
|
|
Jon_Cortazar
|
|
« Respuesta #108 : 08 de Febrero de 2011, 08:14:31 am » |
|
Toni/programadores: ¿y nadie se ha planteado desensamblar los ROMs del arcade de Konami? El core de la placa es un Z80, así que en cuanto a código no hay que hacer ningún cambio excepto con las rutinas de IO... Realmente el juego tiene 8 ROMS de 16KB cada uno (equivale a 1 MegaROM MSX), tiene alguno más, pero no parecen relevantes, por lo poco que ocupan. A lo que voy, es que ya tenemos el Green Beret programado para Z80 y en un hardware de video que permite sprites hardware y con una resolución válida para la conversión, solo hay que coger ese código y meterle mano. De esta forma, (y parcheando las rutinas de sonido, video y controles con las de ARTRAG, of course) tendríamos exactamente el mismo juego con la misma lógica. (hint: tamaños, CRCs y offsets de los ROMs del arcade de Green Beret aqui) |
|
|
|
« Última modificación: 08 de Febrero de 2011, 08:17:29 am por Viejo_archivero »
|
En línea
|
Jon Cortázar Abraido (aka El Viejo Archivero) RELEVO Videogames [Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.] [pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.] |
|
|
|
toniman
Visitante
|
|
« Respuesta #109 : 08 de Febrero de 2011, 09:17:02 am » |
|
¡¡¡¡Manuel Pazosssss!!!! Where are you?  Viejo, tu idea es muy buena, a ver si algun programador se anima a hacerlo |
|
|
|
|
En línea
|
|
|
|
|
Mortimer
|
|
« Respuesta #110 : 08 de Febrero de 2011, 09:29:52 am » |
|
Viejo, la idea es buena, y podría salir un copia casi perfecta, pero creo que sería harto complejo desenmarañar el código simplemente debugueando, a no ser que los chicos de Konami hayan sido muy organizados y se puedan ir encontrando rutinas, además de que habría que conocer bien el hardware del arcade para saber que está haciendo. ¿Alguien ha trasteado alguna vez con el depurador del MAME? ¿Cómo es potente?
|
|
|
|
|
En línea
|
|
|
|
|
Jon_Cortazar
|
|
« Respuesta #111 : 08 de Febrero de 2011, 09:53:37 am » |
|
@Mortimer: lo que habría que saber es todo lo relativo a INs y OUTs, digo yo. El código, que es Z80, se lo traga el MSX de la misma: sabiendo cómo se organizan los ROMs en memoria, y el inicio de ejecución, se puede ir trazando la ejecución ya incluso desde MSX. Cuando llegue una rutina de IO (me da que en estos arcades no hay rutinas de BIOS), se parchea por lo equivalente en MSX.
Ojo, no digo que sea fácil, en ningún momento: sólo digo que tenemos un código disponible, para un hard basado en Z80 y con muchas similitudes en su entorno con un MSX2, y que alguien valiente y con conocimientos podría utilizarlo. Hay quienes adaptan de Colecovision y consolas antiguas de SEGA: por qué no tirar de ports directos de hardware más avanzado, aunque sea únicamente para aprovechar el core del juego?
|
|
|
|
|
En línea
|
Jon Cortázar Abraido (aka El Viejo Archivero) RELEVO Videogames [Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.] [pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.] |
|
|
|
ARTRAG
Visitante
|
|
« Respuesta #112 : 08 de Febrero de 2011, 10:01:08 am » |
|
I do not think it is really a good idea.
MSX2 HW sprites are so crap that in order to use them you have to live with tons of limitation on the game logic that the original HW for sure does not have.
Moerover, honestly, the original game does not seem to have evolved AI for enemies or any exotic features.
Most of the time enemies are randomly generated, enter in the screen from one side and walk to the other.
Sometimes they cast a bullet or jump.
IMHO reproducing something similar that takes into account msx2 sprite limitations is probably by far simpler than working on the original code (that runs on an unknow HW, has to be disassembled, studied and modified).
Anyway, this is my view. If someone willing to do the full game feels confortable to start from konami's roms, he/she is wellcome
[EDIT]
Coleco, old SEGA and msx1 all have the same family of VDP
This is why you can do direct ports
I'm sure that the arcade has a VDP totally different by MSX2 (and by far more efficient)
|
|
|
|
« Última modificación: 08 de Febrero de 2011, 10:12:15 am por AR »
|
En línea
|
|
|
|
|
pitpan
|
|
« Respuesta #113 : 08 de Febrero de 2011, 10:02:21 am » |
|
El problema principal es distinguir entre el código Z80 del núcleo principal del juego y todas las rutinas de apoyo que probablemente haya que reescribir desde cero. En mi opinión, puede ser técnicamente muy complejo por los siguientes motivos:
- El arcade original dispone de un hardware que permite algún tipo de scroll, muy probablemente al estilo del scroll de la NES.
- La RAM que utiliza puede invadir zonas "reservadas" en el MSX, por lo que habría que muy probablemente remapear todas las variables y buffers.
- Todo el hardware de vídeo es diferente, con accesos diferentes, correspondencias diferentes entre VRAM y pantalla, diferente ancho de banda y muy específico para el juego - recordemos que en aquella época las recreativas disponían de hardware prácticamente ad-hoc. El proceso de conversión puede ser durísimo.
Lo digo porque en su momento intenté hacer algo parecido con el PAC-MAN original de Namco, que también es Z80 puro, pero pese a su sencillez, la gestión gráfica no se parece en absoluto a la del MSX, por lo que al final opté por implementar desde cero el comportamiento final de la recreativa. También estuve evaluando la posibilidad de hacer algo así con el SPACE INVADERS de recreativa, que sería muy sencillo en realidad, pero luego la necesidad de remapear en tiempo real todo acceso gráfico haría injugable la conversión (mucho peor que las de spectrum, prometido).
Pero me parece que algunos de los chicos brasileños que desarrollan para Coleco y MSX sí consiguieron hacer algo así, precisamente, con el PAC-MAN, MS. PAC-MAN y creo que PAC-MAN JR. No sé nada más.
¿Algún valiente?
|
|
|
|
|
En línea
|
|
|
|
|
Jon_Cortazar
|
|
« Respuesta #114 : 08 de Febrero de 2011, 10:27:34 am » |
|
@ARTRAG, @pitpan: it seems the vdp is the 005849 (a Konami custom chip). And indeed it seems to be advanced. Of course, you can just play the game, analyze how things work, and redo it again (and MSX2 dedicated). The fact I was playing around with was just to extract the inner game logic for the game to generate enemies and handle character moves, etc, just like the arcade (as it seems there is not yet a coder for the project). Of course I agree with you on the video stuff, but the gamemaps, how they are decoded, the enemy maps and definitions, and how this is managed (enemy frequency, them behaviours, etc)... that's what I think it can be shared from the arcade code. Anyway, hey, just wanted to throw some possibilities here: it will be a pity that this remake/port/conversion die without a coder  An, and just in case someone finds interesting to take a look deep inside the arcade inners, Operation Manual and, most important, Schematics . ROM dumps are available everywhere... |
|
|
|
« Última modificación: 08 de Febrero de 2011, 10:36:25 am por Viejo_archivero »
|
En línea
|
Jon Cortázar Abraido (aka El Viejo Archivero) RELEVO Videogames [Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.] [pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.] |
|
|
|
ARTRAG
Visitante
|
|
« Respuesta #115 : 08 de Febrero de 2011, 08:07:17 pm » |
|
The problem on msx2 is that the sprite colors have to be loaded by the z80 to vram virtually at each change of frame in the sprite animation. In GB enemies are 32x16 with 3 colors per line. This implies the use of 4 sprites per enemy. Each sprite has 16 bytes in VRAM for its color profile. As a consequence, any time an enemy changes frame in its animation, the z80 should update 4x16=64 bytes in VRAM for colors plus the 4x4=16 bytes for X-Y positioning => 80 bytes to update an enemy! Add the outs needed for pointing the VRAM addresses, you get not less than 84-86 bytes per enemy per frame. Moreover due to the scrolling, all sprites need to be moved every frame and all the I/O has to be done during vblank or you will note the raster on sprites Note that in GB a good part of the vblank time is already taken by the code for scrolling. So, it is not very likely that the old code can be adapted to this environment. The tricks and the limits that have to be overcame on msx2 make the port a true challenge as it were on msx1, only the result could look nicer. |
|
|
|
|
En línea
|
|
|
|
|
mesiasmsx
|
|
« Respuesta #116 : 08 de Febrero de 2011, 09:19:57 pm » |
|
Adelante con ello, toni y compañía! Hay ganas ya de jugarlo!! ...por otro lado... ¿a nadie más le apena que sea una versión exclusiva MSX2 y no vaya a funcionar en MSX?  A mi no  MSX2/2+/Tr Rules Pero tambien amo los juegos de MSX1 |
|
|
|
« Última modificación: 08 de Febrero de 2011, 09:24:40 pm por mesiasmsx »
|
En línea
|
|
|
|
|
Jon_Cortazar
|
|
« Respuesta #117 : 08 de Febrero de 2011, 09:52:20 pm » |
|
A mi no MSX2/2+/Tr Rules Put0 mesiaaaaaas!!! Pero tambien amo los juegos de MSX1 Ah, vaaale! ;-) |
|
|
|
|
En línea
|
Jon Cortázar Abraido (aka El Viejo Archivero) RELEVO Videogames [Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.] [pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.] |
|
|
|
pitpan
|
|
« Respuesta #118 : 09 de Febrero de 2011, 12:07:50 am » |
|
Por cierto: si cogéis la ROM del GREEN BERET para MSX y ponéis el emulador al doble de velocidad, veréis que es un juego completamente diferente. Haced la prueba con el openmsx. Abrís la consola con F12 y le ponéis un feliz set speed 200 Y veréis que aunque siga sin acercarse al original, por faltarle elementos como el cambio de nivel de los enemigos, resulta muchísimo más jugable. |
|
|
|
|
En línea
|
|
|
|
|
guantxip
|
|
« Respuesta #119 : 09 de Febrero de 2011, 08:18:37 am » |
|
|
|
|
|
|
En línea
|
|
|
|
|
