Formulario de Pedido GnG

Estado actual "Losaben Akel"

Después de darle un empujoncito al proyecto, ya estan listos todos los bloques de datos:

- Mapas (7 fases, divididas algunas de ellas en subfases, en total, 19 subfases): 49KB
- Imágenes (logo, pantalla título, intros): 128KB
- Sprites (4.486 sprites de 16x16): 186KB
- Tiles: 151KB


El engine (MSLOOPX) y el codigo de la fase 1 finalizado y fase 2 casi finalizado, ocupan 48KB.

Una vez completo, espero que todo quede en unos 750KB.

El desarrollo sigue su curso, lento, pero sigue...



After giving a boost to the project, all data blocks are ready:


- Maps (7 stages, some of them divided into sub-phases, a total of 19 sub-phases): 49KB

- Images (logo, title screen, intros): 128KB

- Sprites (4.486 16x16 sprites): 186KB

- Tiles: 151KB

The engine (MSLOOPX) and complete code of Phase 1 and Phase 2 almost complete, occupy 48KB.

Once complete, I hope everything stays in about 750KB.

The development continues, slow but steady ...

Empaquetador v1.0

---English version below---


Me encanta programar generadores de código:

Hasta ahora estaba usando una hoja de cálculo para organizar los slots del fichero ROM. Cada uno de los archivos de datos los colocaba en una columna junto a su tamaño en bytes y con algunas formulas calculaba manualmente en que slot colocarlo: Comparaba el tamaño del fichero con el primer slot con hueco suficiente.

El problema es cuando el programa empieza a crecer y los archivos cambian de tamaño, al hacer retoques de gráficos o en los mapas. Una organización inicialmente válida, puede no ser válida después de retocar.

Por eso he programado "EL EMPAQUETADOR", que se encarga de localizar todos los archivos (tiles, sprites, mapas y letras), comprobar su tamaño y repartirlos en slots, optimizando el espacio.

Hecho el reparto, genera archivos ASM para incluirlos en el codigo fuente. Así solo tengo que ejecutar el empaquetador antes de compilar sin preocuparme de donde van colocados los ficheros.

Genera 4 archivos diferentes:

-DATOS.ASM                                                                    
Indica en que posición de memoria dentro de que slot está cada fichero.

 phase 0x8000
inicio_codigo_slot_38:
til32a4: incbin "tiles\til32a4.g9b" ; 0x8000
til32a7: incbin "tiles\til32a7.g9b" ; 0x80DA
til32a8: incbin "tiles\til32a8.g9b" ; 0x8158
til34a4: incbin "tiles\til34a4.g9b" ; 0x822E
til36a4: incbin "tiles\til36a4.g9b" ; 0x82FF
til37a4: incbin "tiles\til37a4.g9b" ; 0x83F4
til42a5: incbin "tiles\til42a5.g9b" ; 0x84E9
til53a4: incbin "tiles\til53a4.g9b" ; 0x85D3
til71a1: incbin "tiles\til71a1.g9b" ; 0x8690
map21a0: incbin "mapas\map21a0.dat.exo.opt" ; 0x8731
map34b2: incbin "mapas\map34b2.dat.exo.opt" ; 0x87FE
map41a1: incbin "mapas\map41a1.dat.exo.opt" ; 0x887A
map42a1: incbin "mapas\map42a1.dat.exo.opt" ; 0x88D3
map52a3: incbin "mapas\map52a3.dat.exo.opt" ; 0x899D
map52a4: incbin "mapas\map52a4.dat.exo.opt" ; 0x8A5F
map61a1: incbin "mapas\map61a1.dat.exo.opt" ; 0x8AFE
map62b1: incbin "mapas\map62b1.dat.exo.opt" ; 0x8BD6
 ds 0xa000-$
 if ($>0xa000)
  error "Slot_38 overflow"
 endif
 dephase
fin_codigo_slot_38:

-BLOQUES_MAPAS.ASM                                                                    
Es una estructura con la información de cada mapa: número de bloques a cargar, y por cada bloque el slot donde está y la dirección.


Se carga con:

ld hl,bloques_mapas_fase_32
call inicializa_mapas

bloques_mapas_fase_32:
 db 4 ;número de bloques
 ;Capa a
 db 42; 0x2A
 dw map32a0 ; 0x8D7C

 db 41; 0x29
 dw map32a1 ; 0x8A57

 ;Capa b
 db 44; 0x2C
 dw map32b0 ; 0x8769

 db 41; 0x29
 dw map32b1 ; 0x8C5B

-BLOQUES_TILES.ASM / BLOQUES_LETRAS_Y_SPRITES.ASM                                           

Tiene estructuras con la información de los gráficos. 

Los dos ficheros tienen el mismo formato, pero al haber fases divididas en subfases, están divididos para poder cargar los sprites y letras (comunes a todas las subfases) por un lado y los tiles de cada subfase por otro.



Es una estructura con la información de cada gráfico: número de bloques a cargar, y por cada bloque los siguientes datos:

-Slot ROM

-Dirección de memoria

-Bytes Bajo y medio de destino en VRAM

-Byte alto de destino en VRAM


-Posición de la paleta (16 colores*4 bytes [solo se usan 3]* numero de paleta)

Se carga con:

ld hl,bloques_tiles_fase_51
call carga_bloques_tiles

bloques_letras_y_sprites_fase_10:
 db 3 ;número de bloques

 db 40; 0x28     slot
 dw let10 ; ; 0x9E58
 dw 0xe000 ;hl
 dw 0x0003;iy, solo se usa iyl
 db 16*4*2

 db 55; 0x37     slot
 dw spr10e ;Todos los enemigos de Knightmare ; 0x8000
 dw 0xd000 ;hl
 dw 0x0000;iy, solo se usa iyl
 db 16*4*3

 db 49; 0x31     slot
 dw spr10p ;Todas las poses de Paulo Knightmare ; 0x8000
 dw 0x8000 ;hl
 dw 0x0000;iy, solo se usa iyl
 db 16*4*2




Todo este follón es necesario ya que estamos tratando,de momento, 170 ficheros de datos, a falta de incluir los ficheros de música y sonido y los gráficos de las intros.







Actualmente el juego está metido en una ROM de 512KB, pero espero poder dejarlo finalmente en 256KB. Todos los datos se descomprimen en RAM porque el acceso a ROM en el TurboR es más lento que a RAM. Si fuera necesario, he pensado en comprimir además el código de cada fase, dejando en ROM solo sin comprimir el engine del juego.









I love programming code generator:


Until now I was using a spreadsheet to organize ROM file slots. Each of the data files was placed in a column next to its size in bytes and with some formulas manually calculated the slot, comparing file size with the first slot with enough space.



The problem began when the program gets bigger, with every change in map files or graphics files. A initial valid configuration becomes unusable.



"EL EMPAQUETADOR" (The packer) searchs for the files (tiles, sprites, maps, chars), and then fits them in slots, optimizing the total space.




When the files are located, the program generate ASM files to include in the source code. I only need to execute the packer without worries about where are the files.


It generates 4 diferent files:


-DATOS.ASM                                                                    
This file reports in which slot and memory address are each file.









 phase 0x8000
inicio_codigo_slot_38:
til32a4: incbin "tiles\til32a4.g9b" ; 0x8000
til32a7: incbin "tiles\til32a7.g9b" ; 0x80DA
til32a8: incbin "tiles\til32a8.g9b" ; 0x8158
til34a4: incbin "tiles\til34a4.g9b" ; 0x822E
til36a4: incbin "tiles\til36a4.g9b" ; 0x82FF
til37a4: incbin "tiles\til37a4.g9b" ; 0x83F4
til42a5: incbin "tiles\til42a5.g9b" ; 0x84E9
til53a4: incbin "tiles\til53a4.g9b" ; 0x85D3
til71a1: incbin "tiles\til71a1.g9b" ; 0x8690
map21a0: incbin "mapas\map21a0.dat.exo.opt" ; 0x8731
map34b2: incbin "mapas\map34b2.dat.exo.opt" ; 0x87FE
map41a1: incbin "mapas\map41a1.dat.exo.opt" ; 0x887A
map42a1: incbin "mapas\map42a1.dat.exo.opt" ; 0x88D3
map52a3: incbin "mapas\map52a3.dat.exo.opt" ; 0x899D
map52a4: incbin "mapas\map52a4.dat.exo.opt" ; 0x8A5F
map61a1: incbin "mapas\map61a1.dat.exo.opt" ; 0x8AFE
map62b1: incbin "mapas\map62b1.dat.exo.opt" ; 0x8BD6
 ds 0xa000-$
 if ($>0xa000)
  error "Slot_38 overflow"
 endif
 dephase
fin_codigo_slot_38:








-BLOQUES_MAPAS.ASM                                                                    

This file has structures with information of each map: numbers of blocks to load and foe each block, the slot and memory addres.






The structure is loaded with:





ld hl,bloques_mapas_fase_32

call inicializa_mapas




bloques_mapas_fase_32:
 db 4 ;número de bloques
 ;Capa a
 db 42; 0x2A
 dw map32a0 ; 0x8D7C

 db 41; 0x29
 dw map32a1 ; 0x8A57

 ;Capa b
 db 44; 0x2C
 dw map32b0 ; 0x8769

 db 41; 0x29
 dw map32b1 ; 0x8C5B









-BLOQUES_TILES.ASM / BLOQUES_LETRAS_Y_SPRITES.ASM                                           

They have structures with graph data.




Both files have the same format. As some stages have many sub-stages, the files are divided to load the sprites and character (common to all substages), and the tiles independently.



The structure is: number of blocks to load, and blocks. Each block is:

-ROM Slot

-Memory address

-Low and medium byte of destination VRAM addres

-High byte of destination VRAM address


-Palette position (16 colors*4 bytes [only 3 are used 3]* palette number)







The structure is loaded with:



 ld hl,bloques_tiles_fase_51

 call carga_bloques_tiles











bloques_letras_y_sprites_fase_10:
 db 3 ;número de bloques
 db 40; 0x28     slot
 dw let10 ; ; 0x9E58
 dw 0xe000 ;hl
 dw 0x0003;iy, solo se usa iyl
 db 16*4*2

 db 55; 0x37     slot
 dw spr10e ;Todos los enemigos de Knightmare ; 0x8000
 dw 0xd000 ;hl
 dw 0x0000;iy, solo se usa iyl
 db 16*4*3

 db 49; 0x31     slot
 dw spr10p ;Todas las poses de Paulo Knightmare ; 0x8000
 dw 0x8000 ;hl
 dw 0x0000;iy, solo se usa iyl
 db 16*4*2


All this mess is necessary because we are using, so far, 170 data files, without include music and audio files and intros.










Currently the game fits into a 512KB ROM, but I hope to finally fit in 256KB. All data is decompressed in RAM because accessing the TurboR ROM is slower than RAM. If necessary, I thought further compress the code of each stage, leaving only uncompressed the game engine.

Bendito Dropbox

---English version below----


Hoy no voy a hablar del desarrollo de los juegos que llevamos entre manos, aunque podría. Y podría hacerlo porque todavía tengo todas las fuentes tal cual las tenía antes de que el disco duro de mi ordenador muriera.

No es que se haya cascado Windows ni que un virus lo haya infectado y no haya forma de usar los programas que hay,lo que pasa es que ha reventado.

Un chispazo se llevó por delante la fuente, la placa y el disco duro. Disco duro muerto, frito, caput, inaccesible.

Por suerte tenía una copia relativamente reciente de las fotos que en definitiva es lo único que no se puede recuperar después de un desastre de este tipo.

Las fuentes de los programas siempre se pueden volver a crear, aunque después de una pérdida como esa, poca gente tiene ganas de volver a empezar un desarrollo medianamente grande.



Por suerte, hace algún tiempo que uso Dropbox y entre otras cosas, tengo ahi el directorio SOFT_MSX donde guardo todo lo relacionado con el desarrollo para MSX.

Para el que no conozca este programa es un sistema de almacenamiento en la famosa NUBE, pero que mantiene actualizados los archivos en modo local, así que trabajar con esos archivos no supone ningún tipo de ralentización.

La idea es sencilla, con el programa instalado todo lo que copies en la carpeta del programa se almacena en un servidor quien sabe donde. Cualquier cambio es actualizado automáticamente.
Todos los dispositivos que tengan el programa configurados con tu cuenta actualizan esos cambios en local en cuanto estén conectados a internet.

Si se modifica el mismo fichero en dos ubicaciones diferentes, Dropbox deja una copia como original y otra como "Conflictiva". No es especialmente cómodo para que trabajen varias personas con los mismos ficheros, pero sí para una sola persona que pueda trabajar en un sitio u otro.


Aparte de eso, Dropbox permite:
-Localizar, usar y restaurar versiones previas de cualquier archivo, aunque se haya eliminado.
-Sirve como copia de seguridad automática.
-Permite acceder a nuestro directorio "en la nube" desde cualquier navegador.
-Puedes compartir las carpetas que quieras con otros usuarios de Dropbox y utilizar su espacio como si fuera tuyo. Si tienes 2GB y compartes una carpeta con alguien que tiene 10GB, podras usar 12GB (10GB maximo dentro de esa carpeta).
-Puedes indicar qué carpetas no quieres sincronizar en algún dispositivo para ahorrar espacio en esa ubicación.

Y lo mejor de todo es que es gratuito. 2 GB de almacenamiento gratuito que puede crecer hasta 18 GB invitando a mas personas: conseguimos 500MB por cada usuario al que recomendemos el programa y lo instale.

Yo me estoy planteando pillarme una versión de pago para tener hasta 100GB y tener todos mis documentos ahí, y evitarme más sustos como este.




Ahora seguiré trabajando en el desarrollo de "Losaben Akel" y el remake del "Fantasmas y Duendes" PORQUE NO HE PERDIDO NADA.




____________________________________________________

Today I won't talk about the development of the games that we are developing, although I could. And I could do it because I have yet all sources such as we had before the hard drive on my computer died.

Not that Windows is cracked and that a virus has infected and there is no way to use the programs out there, what happens is that has burst.

A spark swept away the power, motherboard and hard drive. Hard drive died, fried, caput.

Luckily had a relatively recent copy of the photos that really is the only thing that can not be recovered after a disaster of this kind.

The sources of the programs can always be re-created, but after a loss like that, few people are looking forward to start a fairly large development.


Luckily, some time ago I use Dropbox and among other things, I have there SOFT_MSX directory where I keep everything related to the development for MSX.

For those who do not know this program is a storage system in the famous CLOUD, but keeps current files in local mode, so working with these files does not pose any slowdown.

The idea is simple, with everything installed, the program stores all files on a server. Any changes are automatically updated.
The program updates all changes in local when they are connected to the Internet.

If you modify the same file in two different locations, Dropbox leaves a copy as original and another as "Conflict". Not particularly comfortable to work several people with the same files, but for a single person who can work in one place or another.


Other than that, Dropbox allows you to:
- Locate, use and restore previous versions of any file, even if it is deleted.
- Serves as automatic backup.
- Allows you to access our directory "in the cloud" from any browser.
- You can share folders with other users who want Dropbox and use their space as your own. If you have 2GB and share a folder with someone who has 10GB , you can use 12GB ( 10GB maximum within that folder).
- You can specify which folders you want to sync on some device to save space in that location.

And best of all, it is free. 2 GB of free storage that can grow up to 18 GB inviting more people: get 500MB for each user you we recommend the program and install it.

I 'm considering a paid version to have up to 100GB and have all my documents there, and avoid me more scares like this.





Now I will continue working on the development of "Losaben Akel" and the remake of "Fantasmas y Duendes" BECAUSE I HAVE NOT LOST ANYTHING.

Últimas unidades a la venta de M-TANKS

   M-TANKS es un juego de combate de tanques para MSX en el que se pueden jugar hasta con cuatro jugadores simultáneos, ya sean controlados por el ordenador o con el teclado y/o joystick.

   Tiene 5 modos diferentes de juego:

• Destrucción total
• Destrucción por equipos
• Capturar la bandera
• Entrenamiento de puntería
• Entrenamiento de movimiento

   Este juego quedó tercer clasificado en el concurso MSX-Dev'11.

   Aunque el juego se puede descargar gratuitamente desde la página oficial con este enlace, la versión en cartucho contiene algunas mejoras respecto a la versión presentada a concurso. Las mejoras incluídas son las siguientes:

• Corrección de algunos fallos en la selección de arenas.
• Se ha acelerado el movimiento de los tanques, aunque desde el menú de configuración se puede volver a la velocidad original.
• 2 áreas nuevas de juego.
• Un nuevo tema musical, como homenaje a konami.
• Mejora significativa de la Inteligencia Artificial de los tanques controlados por ordenador.

   Si quieres una de las últimas copias disponibles en cartucho, envíame un correo electrónico a assembler@hotmail.es para concretar.

   El precio es el mismo al que lo he vendido en las RUs, 18€, aunque en este caso habría que incluir los gastos de envío.

¡Larga vida al MSX!

Assembler

Scroll Multidireccional

Me estaba complicando mucho la vida con la rutina de scroll hasta que, después de leer un artículo de k0ga, he descubierto el principio KISS (Keep It Simple Stupid) y casi he rehecho la rutina con la mitad de líneas. No está tan optimizada como pretendía con la idea inicial, pero esta funciona perfectamente. Ya habrá tiempo de optimizaciones.
Antes tenía una rutina teóricamente óptima  y que no funcionaba. Ahora tengo una rutina no tan óptima, pero que funciona perfectamente.

Lo que falta por hacer es la posibilidad de mover el mapa a diferentes velocidades, desde 1/8 hasta 16px (con eso creo que será suficiente, aunque se podría aumentar si hiciera falta). Para este mapa no haría falta. Se utilizará a partir de la fase 3 de "Losaben Akel", donde cada uno de los planos se moverá a diferente velocidad.

-----------------------------------------------------------

I was greatly complicating life with scroll routine until, after reading a k0ga article in his blog, I discovered the KISS principle (Keep It Simple Stupid) and I have redone the routine with half the lines.  It's not as optimized as intended with the initial idea, but this works perfectly. There will be time for optimizations.
I had a routine theoretically optimal that not work. Now I have a not optimal routine, but it works perfectly.

What remains to be done is the ability to move the map at different speeds from 1/8 ​​to 16px (with I think that will be enough, but could be increased if required). For this map would not need. Be used from the phase 3 in "Losaben Akel", where each of the planes will move at different speeds.

ASM en MSXRio'13

Aprovechando que Tecnobytes ha desarrollado la V9990 Powergraph, una tarjeta compatible con la GFX9000, les hemos enviado las demos jugables de "Losaben Akel" y "FyD" para que las incluyan en el CD que acompañará a la tarjeta.

Los siguientes videos han sido grabados durante la MSXRio'13 que se celebró el día 1 de Junio.

FyD

Losaben Akel

Integración Player SCC en el Engine MSLOOPX

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...

Remake FyD MSX: Pantalla de título, Intro y Fase 1 casi completa

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.

Prueba Fase 1 FyD

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

Crisis Alma - Videogame Series - Retro Crisis vol 1

Crisis Alma ha liberado el album de versiones Heavy de juegos de Konami que presentó en la 40ª RU en Barcelona:

Los temas incluídos son:

1. Salamander - Operation Seedleek (Prologue BGM)
2. Salamander - Power of Anger (Stage 1 BGM)/Poison of Snake (Boss BGM)
3. F-1 Spirit - F-1 Shuffle (Title BGM)/F-1 Spirit (F-1 BGM)
4. Gradius 2 - Return (Ending demo 1 BGM)
5. King's Valley 2 - Start menu BGM/Stage 1 BGM
6. Gradius 2 - Stage 1 BM
7. F-1 Spirit - Hot Summer Riding (Stock Car & F-3 BGM)
8. Salamander - Departure Again (Ending Demo 1 BGM)

https://dl.dropbox.com/u/19247044/Crisis-Alma-Videogame-Series-Retro-Crisis-Vol.-1.zip

Beta-testing

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?

Entorno de desarrollo

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.

_________________________________________________________________________________

English Version


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.

Video de la primera fase

Primer Video

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.

Losaben Akel, en pleno desarrollo.

Juego en desarrollo

Título: Losaben Akel
Plataforma: Msx TurboR / GFX9000
Estado actual: 
    -Engine para modos bitmap y P1: 100% operativo
    -Logo inicial: 99% operativo
    -Menú: 50% operativo
    -Fase 1: 100% operativo
    -Fase 2: 75% operativo
    -Fase 3-1: Pantalla, marcador y sprites: 100%
    -Fase 3-2 a 3-7: Gráficos 100%
    -Fases 4 a 7: Graficos 100%
    -Presentación inicial, animaciones de presentación de cada fase y final: Gráficos 100%
    -Sonidos: 5%
    -Música: Salvo imprevistos, se usará el chip SCC y el programa Trilotracker.

A S M

ASM es un grupo de reciente creación. Comenzó a formarse durante el desarrollo de M-TANKS gracias a la mediacion de MesiasMSX que se encargó de reunir a los integrantes.

Crisis Alma: Música y sonido

Guantxip: Gráficos

Assembler: Código

Este blog lo hemos creado para ir informando sobre los desarrollos que tengamos entre manos. 

Actualmente estamos desarrollando un juego para TurboR con GFX9000. Básicamente es un juego formado por pantallas de juegos diferentes, con su historia por medio que se encarga de unirlos entre sí para dar lugar a un conjunto coherente. Hay pantallas con scroll vertical, de plataformas, de naves con scroll horizontal... de todo un poco.

Aunque pueda parecer complejo, se empezó a desarrollar el juego con esa idea en mente y hemos creado un engine que permite con total libertad mezclar diferentes formas de juego sin complicar que interfieran unos con otros. Igualmente permitiría, llegado el caso, hacer un juego con todas sus fases "iguales".

Este engine trabaja de forma parecida a la Programacion Orientada a Objetos, que simplifica mucho el desarrollo. 

Lo he llamado MSLOOPX: Something Like Object Oriented Programming, con la M y X inicial y final para "integrarlo" con la palabra MSX.