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