Primera prueba de integración del player del TriloTracker (http://www.trilobyte-msx.com/) La música no pega ni con cola, pero es la única que tenía a mano :P
El siguiente paso será modificar todas las cargas de disco para hacerlas desde ROM directamente. Hay algunos BUGs pendientes de eliminar, como al disparar agachado, que desaparece el protagonista...
A falta del apartado sonoro y de corregir algunos problemillas estarían completos el menú, la intro y la primera fase (faltan un par de movimientos del diablo de mitad de fase y el giro de las brujas).
Hay objetos que todavía no están implementados, como los cacharros que dan puntos y el resto de armas, pero se irán implementando poco a poco durante el resto de fases. Se han recortado en el video los tiempos de carga, porque de momento está cargando desde disco. La versión final casi seguro que será en cartucho, así que este será más o menos el aspecto durante las cargas. La calidad del video no es muy alta, pero es por la compresión. El título parece pixelado, pero en realidad no se ve así.
Pending sound/music and to correct some problems. Besides that, the menu, the intro and the first phase (missing a few moves of devil and shift of witches) are finished. There are objects that are not yet implemented, as the pots that give points and other weapons, but they will gradually implemented during the remaining phases. Load times have been cut in the video, because currently being loaded from disk. The final version will almost certainly be in cartridge, so this will be about the look for the loads.
Video quality is poor due to compression. The title appears pixelated, but in the game it has more quality.
Usando el mismo Engine que para "Losaben Akel", hemos retomado un proyecto al que empezamos a dar vueltas poco antes de empezar con "Losaben Akel". Antes de intentar retomarlo, necesitaba completar la rutina de scroll multidireccional, y aunque en esta prueba no se aprecia porque solo hay scroll horizontal, está completa. El engine en principio está preparado para funcionar en TurboR, pero refrescando la pantalla una vez cada dos frames (25 fps), creo que puede funcionar bien en un Z80.
Using the same Engine from "Losaben Akel", we did some tests on the idea that we started before "Losaben Akel". We had to complete multidirectional scroll routine before to try this remake. This test only uses horizontal scrolling but the multidirectional routine is complete. This Engine is ready for TurboR, but writing to the screen once every two frames, I think it will be possible to run in a Z80.
El prota solo se mueve hacia los lados y no detecta, todavía, las colisiones, pero es cuestión de incluir unas cuantas líneas de código. Este es el trozo de código que "mueve" al prota:
The protagonist only moves sideways and still does not detect collisions, but a matter of including a few lines of code. This is the piece of code that moves the protagonist:
obj_arthur_mov: ld a,[buffer_teclado8] ;1000 Der Aba Arr Izq Del Ins Home Space and 11110000b cp 11110000b jp z,.parado bit 7,a jr z,.derecha bit 4,a jr z,.izquierda ret .derecha: ld a,[ix+obj_arthur_estado] bit 3,a jr nz,.cambio_dir_d and 00000111b cp 1 ;andando jr z,.andando .cambio_dir_d: ld a,[ix+obj_arthur_estado] and 11110000b or 00000001b ld [ix+obj_arthur_estado],a ld [ix+obj_arthur_retardo_frame],1 ld [ix+obj_arthur_frame],0 res 5,[ix+obj_pat] jr .andando .izquierda: ld a,[ix+obj_arthur_estado] bit 3,a jr z,.cambio_dir_i and 00000111b cp 1 ;andando jr z,.andando .cambio_dir_i: ld a,[ix+obj_arthur_estado] and 11111000b or 00001001b ld [ix+obj_arthur_estado],a ld [ix+obj_arthur_retardo_frame],1 ld [ix+obj_arthur_frame],0 set 5,[ix+obj_pat] .andando: dec [ix+obj_arthur_retardo_frame] jr nz,.nocambia_frame ld [ix+obj_arthur_retardo_frame],8 ld a,[ix+obj_arthur_frame] inc a and 00000011b ld [ix+obj_arthur_frame],a ld hl,obj_arthur_frames ADD_HL_A ld a,[hl] ld b,a ld a,[ix+obj_pat] and 11100000b or b ld [ix+obj_pat],a .nocambia_frame: bit 3,[ix+obj_arthur_estado] jr z,.a_derechas .a_izquierdas: ld a,[ix+obj_x] cp 106 jr nz,.no_limite_izquierda ld de,0x00ff ld [mov_scroll_a],de ld [mov_scroll_b],de ret .no_limite_izquierda: dec [ix+obj_x] ret .a_derechas: ld a,[ix+obj_x] cp 150 jr nz,.no_limite_derecha ld de,0x0001 ld [mov_scroll_a],de ld [mov_scroll_b],de ret .no_limite_derecha: inc [ix+obj_x] ret .parado: ld a,[ix+obj_arthur_estado] and 11111000b ld [ix+obj_arthur_estado],a ld a,[ix+obj_pat] and 11100000b ld [ix+obj_pat],a ret
No está optimizado ni muy limpio, pero ha sido una prueba rápida para poder hacer el video. :P
Me he quedado alucinado al ponerles a mis sobrinos la primera fase de "Losaben Akel" y ver como se han tirado una hora jugando, disfrutando el juego. Es una buena señal, ¿no?
______________________________________________________________________________ English version I've been amazed to see my nephews playing an hour of the first phase of "Losaben Akel", enjoying the game. It is a good sign, right?
El código lo estoy desarrollando con TNIASM 1.0, usando el editor PSPad y unos cuantos ficheros BAT para reunir todos los ficheros de datos y compilar. Los retoques en los ficheros gráficos (recorte, ordenación de la paleta, unión...) los hago con GIMP. Para generar los mapas utilizo un BMP con el mapa completo, y con un programa hecho en Visual FoxPro, genero los ficheros de tiles y datos del mapa. En este programa selecciono el tipo de tile: normal, obstáculo para los personajes, obstáculo para las balas, escalera, etc. Hasta ahora, el desarrollo lo probaba básicamente en el PC con el emulador openMSX, y eventualmente, en el TurboR con una tarjeta GFX9000 real. El problema es que había llegado a un punto en el que en el emulador funcionaba perfectamente, y en el MSX real me hacía extraños a la hora de cargar los sprites (un fichero de 256x576), así que me he tenido que montar este chiringuito para poder hacer pruebas en real más cómodamente:
Los ficheros gráficos que utilizo se convierten de BMP a G9B, un formato gráfico creado por el Team Bomba y que con su librería g9klib, manejar los gráficos en la GFX9000 es un juego de niños. Desde aquí quiero agradecer la ayuda prestada por Patriek Lesparre (GuyveR800) a través del canal de IRC #msxdev, sin la cual este proyecto no estaría tan avanzado ya que las veces que he acudido a él con dudas sobre el funcionamiento de la GFX9000, las ha resuelto perfectamente.
I'm developing with tniASM 1.0, using PSPad editor and a few BAT files to gather all data files and compile. I made the tweaks in graphics files (cut, palette management, union ...) with GIMP. To create maps, I use a BMP file with the complete map, and with a Visual FoxPro program, the tiles and map data are generated. In that program I select the tile type: normal, obstacle for characters, obstable for bullets, ladder, and so on. Until now, test were made in PC with openMSX and eventually, in a real TurboR with a GFX9000 expansion. But at this point, openMSX was working fine (not fine really), but the real one shows some garbage in the sprites. as I use a large file (256x576). I had to mount this desktop for testing more comfortably:
Graphics files are converted from BMP to G9B, a graphic format created by Team Bomba. This files are used in their g9klib library to load graphics in the GFX9000 easily. From here I want to acknowledge the help given by Patriek Lesparre (GuyveR800) through IRC channel # MSXdev. Whenever I asked him something, he has solved the question perfectly.
Para los que no pudieron verlo en la RU, aquí tenéis un video con parte de la primera fase. Solo he grabado un minutejo, pero la fase está terminada a falta de unos pocos ajustes en la posición de los enemigos.
Los sonidos están eliminados del video porque no van muy finos. Falta ajustar la prioridad para que no se machaquen entre sí.
Técnicamente es muy sencilla. Solo se utiliza uno de los dos planos del P1. El scroll utiliza las primeras 256 líneas. Las 20 siguientes (256-276) son para el marcador, que se muestra mediante screensplit.
La velocidad del scroll es lenta, pero se podría mover mas rápido si hicera falta. La rutina inicial era esta:
Permite movimiento en ambas direcciones y a velocidades de hasta 8x. ____________________________________________________________________________ English version
First Video
If you couldn't see it in 42th RU, here you are a video with an excerpt of stage 1. Only a few minutes are recorded, but the level is complete. The level is complete, lacking slightly adjust the position of some enemies.
There is no sound in the video as sounds crush each other. A little bug.
This level is relatively simple. Only one Layer of P1 is used. Scroll uses 256 lines. Next 20 lines (from 256 to 276) are for scoreboard, shown through screen-split.
The scroll speed is slow, but it could be faster if necessary. The original routine was that:
It's possible to move both directions and at 8x speed.
.JPG)
