I was wondering... How do MSX 32 Kbytes games can handle those HUGE sceneries and enemy attributes (such as enemy type, where do they appear, etc)?

Take for instance games like Anaza Kaleidoscope Special or Star Soldier. Most probably these games have small chunks of scenery that they keep repeating over and over. The scene data is probably compressed in some way... But how about Zanac?

And anyone has any information about how these games define where in the scenery each enemy will appear?

Thanks in advance,
Leandro Correia.

One possibility is using LRE or other simple compression tecniques,

or using random sceneries and enimy positions in congiunction
with clever rules for posing large building blocks or enemy patterns.

Actually once you choice a generator of random numbers and you
initialize it in a suitable way, you get always the same sequence
of numbers.

This, using good roules, gives huge scenaries at no memory cost.
(you need to set up the rules bytheway...)

Quote:

Actually once you choice a generator of random numbers and you initialize it in a suitable way, you get always the same sequence of numbers. This, using good roules, gives huge scenaries at no memory cost. (you need to set up the rules bytheway...)

I use random numbers to define when a enemy attack wave appear.

The enemys hierarchy is organized in:
- Enemy attack wave.
- Enemy groups.
- Enemy.
- Enemy sprites.

Each attack wave definition have:
- Number of groups that will be simulataneously launched
- Group definition address of each group

Each group have:
- Delay to launch the enemies (the delay should be change by an event, like a enemy be destroyed, a certain enemy-allied distance is reached and others)
- Number of enemy that will be simultaneously launched
- Enemy definition address of each enemy

Each enemy have:
- Number of sprites
- Sprite definition address of each sprite

Each sprite have:
- Shield power (number of supported impacts)
- Type of Y coordinate address (fixed, random, allied based, based in last sprite + offset, etc)
- Y coordinate relative data (according of type)
And so on for X, pattern and color.

- The sprite movement (Y and X treatment) are defined by tables in the same way.
- The sprite animation (pattern and color), equally.
- And finally, the sprite attack pattern (it's sprite based and totally independent)

All sprite movement and animation could be time based. One example:
- In each 10 VDP interrupts the angle of movement will change. This could cause a some type of eliptical movement if the angles are ajusted accordingly.

The sprite independence could permit that a robot have your right arm destroyed and continue walking.

Most of these features are already working!

for zanac there are attack groups that will appear when you select a certain alternative weapon... for example, when you select the shield for the alternative one some slow enemies shooting missiles will appear.

Quote:

One possibility is using LRE or other simple compression tecniques,

Not sure what LRE is, but I think you mean RLE (Run Length Encoding).