Oh that seems pretty nice so far. Are the graphics placeholders or did you plan to use them? I think a star background would be nice. Also do the graphics use rectangles? If that's the case, that's a quite clever, since DIMGROB sprite data is usually incredibly large compared to if sprites are pre-rendered with RECT_P commands.

Btw sorry for not replying sooner, I had a crazy two weeks of work and other activities. >.<

EDIT: Wow this is pretty impressive. I am surprised at the slow on-calc speed, though, considering I had some advanced graphical animations running at over 15 FPS, sometimes much higher (even 3D). I wonder if there isn't some command somewhere that could be slowing the game down considerably or if some for loops could be merged together to reduce the wait (or maybe the amount of bullets on the screen at once reduced to 5-10 max instead of 20)? On the previous firmware, INT() was often the culprit. Or could there be things that could simply be pre-rendered and only updated if necessary? (For example, when you draw the enemy ships, one trick could be to display all of them and all their frames in an extra GROB then instead of drawing each ship individually every loop, you just display the entire GROB in one BLIT command. To update the ship army when one is destroyed or when a  new wave appears, you just do it once an enemy is shot).

Also make sure to remove the WAIT commands for the calc version.

One thing I like a lot is how we can use the touch screen to move the ship and ESPECIALLY the explosion at the end, which is very reminiscent from Axe Parser games .

The graphic is predrawn into G3, so that G3 contains all animations. This takes up less space.
In the end of the gameloop there is a WAIT(0.05), this is entirely for the emulator, since it will run to fast.

The gameloop doe contain a lot of FOR-loops for moving, collision detect and rendering, I Think that it may be possible to optimize by reducing to a few FOR loops.

Star background is a good idea. It could be predrawn i G4 and Blit'ed to the render buffer at the beginning of each render cycle

The graphic is predrawn into G3, so that G3 contains all animations. This takes up less space.
In the end of the gameloop there is a WAIT(0.05), this is entirely for the emulator, since it will run to fast.

The gameloop doe contain a lot of FOR-loops for moving, collision detect and rendering, I Think that it may be possible to optimize by reducing to a few FOR loops.

Star background is a good idea. It could be predrawn i G4 and Blit'ed to the render buffer at the beginning of each render cycle

I think it wouldn't be a big issue to use more space with a larger GROB to store each possible frame of the entire enemy army rather than each ship, since the calculator has over 16 MB of RAM available for the user. Even with the largest possible army it would most likely take 1 MB or less (assuming, for example, that an enemy army takes a 300x200 area and has 8 frames, each pixel taking 2 bytes). The hardest part would probably be to erase destroyed ships, since you would need to apply a RECT_P command on all 8 frames on the destroyed ship, while also updating your matrix data or whatever.

I the worst case scenario, you could always cut down animation frames to save space.

As for the WAIT command, I think a trick would be to use a TICKS command at the start of the frame then another one at the end. Then you just have to use a WAIT command where you substract both resulting ticks value then divide the result, to keep frame rate consistent.

Yeah, there could possibly be some minor slowdown when killing an alien, more noticeable if everything moves very smoothly. However, I noticed that Zelda: Windwaker for the GameCube, which is a commercially aclaimed game, also does it, so I guess it's not too bad unless the lag is extreme.

By the way, how do we use bombs?

Ok thanks. I'll try the new version later.

I think the slowdown comes from the fact the game allows multiple bullets at once on the screen. I changed the game so only 1 bullet is allowed at once instead of 10 and the game goes much faster. However it becomes incredibly hard lol. I don't get why it runs slow, though, consdiering Trailblazer gets 38 frames per second. It might definitively be worth it to post the code, in case someone here can help optimizing. It could be due to a bug too, such as running the same routine 10 times per loop when it could be ran once. Or maybe the collision method used is that slow?

Can't you just make a loop on the number of bullets, detect if there is a pixel (so an alien), then guess which alien it is with the position of the bullet ?