I have returned to code a MSX1 shooter game called Cosmic Battle. I have stopped more than ten years ago.

Initial link
www.msx.org/newspost1860.html

Dowload:
www.msx.org/modules.php?op=modload&name=Downloads&file=index&req=visit&lid=472

I will post in this thread whenever I got an advance or if I have problems to continue.

Thanks,

Marison

Yesterday, 20:30 (8:30pm) in my local time I finally have success in convert my 2 16KB binary files in one .rom 32KB file. I have to relearning coding in Z-80 assembly and that was my first test!

As I already had responded to the newspost: WAY COOL! Good to see the first step was succesful, on to the next one! I'm sure your knowledge of Z-80 will come back as you progress (and ask people around here if needed ^_^)

And now, this "Cosmic Battle" will participate at MSXdev05 contest!. Check the status of this entry and all MSXdev05 incoming entries here. Good luck finishing your game, marison, it looks promising!

Thanks, viejo_archivero and snout. I hope you will like my game in the time of launch.

I have almost completed the core of the enemy's movement and animation routine. Maybe for a rest of this type of programming, certain for a desire and need for some sound in my tests, I ask:
- Which is the soft recommended to create PSG sound effects?
- Which is the soft recommended to create PSG music?
- Are there a sound bank free of charge (obviously I will credit the creators)?
- Are there free PSG music good for a shoot'em'up?

I will prefer that both music and sound effects be played by a player routine that don't is incorporated in the sound format, i.e. each music and sound is only a sequence of data that will be read by a unique routine.

Thanks in advance!

I finally have concluded (yesterday) the core of the enemy movement and animation routines.

The enemys are organized in:
- Enemy attack waves, with various groups
- Groups of enemys that are simultaneously launched
- Enemys that could be formed by various sprites with attributes totally indepents, Y and X movements, pattern and color animation.

This will be a base to a enormous enemy variation. Be prepared to a good shoot'em'up.

Cool, I'm looking forward a final release!. Keep on!

Great work, Marison! Looks like development is going very rapidly now

And now, my sweet shoot'em'up is already a racing game. I have implemented the colision detection yesterday! Only allied with enemy ships, but the rest is in the way.

In Cosmic Battle every enemy could be defined with more than 1 fire to be destroyed. The allied bullets will have multiple power levels too.

And more: the enemys could be destroyed by independents parts, and maybe with presentation of problems related to the part destroyed. Understandable?

Snout,

I have wasted around 4 months to convert my fonts from Mega Assembler to M80. The first tryings will work if:
- I've recreated some tables from 7A00H to 7FFFH;
- and have noted that the scroll didn't work in the M80 compiled version because the scroll table pointer was 0CC00H. The game in the 2 .bin files version was loaded by basic in 9000-0CFFFH. I have to change 1 byte: 0CCH to 0BCH to my routines works again, but I guesseds other problems in the time.

Now, my temporaly racing game shoot'em'up is a shoot'em'up again!

The allied bullets destroy the enemys for the very first time. The entire routine should and will be refined and improved, but already work!

I'm so happy! More than ten years ago I have worked during two years in this game. Finally, it's playable!

Abandoned projects hurts a lot. Success in a abandoned project is gratefull!

Recently I did changes in my Screen 2 (tile based similar to Screen 4 that don't exists in MSX1, only sprites differs) scroll routine to diminish the time to run it.

Before, the way I got my vertical scroll was:
- The previous line before the last line is copied from the VRAM to a buffer in RAM
- The buffer is copied to the positition of the last line.
- The proccess is repeated for the lines above until the first line.

Another routine writes de first line with values from a table.

Two access to VRAM per byte of the tile table.

Now, inspired by the hardware scroll of VDP 9938 and some videogames, I got the same effect in this way:
- One buffer, mirror of the tile table is stored in RAM.
- A variable contains the first virtual line in the buffer.
- Its initial value points to the last line of the buffer.
- Another routine is called to writes the first line of the screen in the first virtual line buffer position.
- The tiles codes are copied from the first virtual line to the VRAM until the phisical end of the buffer.
- The remained tiles codes are then copied from the first phisical line buffer .
- The variable that points the first virtual line is decremented. If it reaches the first phisical line buffer, the routine reset its value to the phisical end of the buffer.

It seems more complicated, but the fact that just one access for tile is necessary compensates all.

Uses more memory, too. In the first method, only 32 bytes for the full screen scroll. In the last, 768 bytes are needed.

Correction

In a previous post:
convert my fonts from Mega Assembler to M80.

Read:
convert my sources from Mega Assembler to M80.