O.k.
What I have learned with all kinds of programming languages is that you
first write your entire game in words....
How, what, where....

Let me start with this:

I first split screen:

*********************************
Split screen at y=24
*********************************


********************************************************
On the interrupt:
(start at Vblank)

stop Horizontal screen offset reg#18 (in other words, DO NOT SCROLL)
copy new parts of screen to invisible page screen
play music
play sound fx
put 32 sprites on screen
********************************************************


*****************************************
On the splitline:
scroll screen with reg#18 (in other words, SCROLL)
swap page at end of 16 steps
*****************************************



********************************************************
Outside of the interrupt:
Movement ship and options
readout 'm' button (to change direction options shoot at)
readout firebutton
move bullets
interaction bullets-enemies
interaction bullets-foreground
interaction ship-enemies
interaction ship-foreground
timeline
enemy movement patterns (when do enemies come in screen and how do they move)
********************************************************

I want to rewrite all the routines which I have outside of the interrupt..

But especially the one for enemy routine (how do the enemies move etc.)

I found that the routine which does the vdp copies take about 15 horizontal lines
the routine which copies all the sprites in screen take about 10 horizontal line
the routine which move all the bullets (9 when 2 options are in play)
take about 20 horizontal lines...

Which leaves a whole lot of horizontal lines for the enemy routine !!

(I am talking about horizontal lines, but what I mean is, 1 frame is about 212 horizontal
lines and takes 1/60 second)

So within one frame the game runs fluently, it scrolls at 60 frames per second with
1 pix at a time, the borders are masked using the vdp, the ship is moving and shooting
but when more than 4 enemies are in screen, the frametime is exceeded.

Meaning that when 4 enemies are in screen the CPU cannot process them within one
frame....

Terrible programming yes !!!

(I have to rewrite the enemy routine, but I also want to make an overview on paper
first on HOW to do this best !!)

Can someone give me an nice and VERYfast way of having 10 or 20 enemies in screen
all moving and interaction with the bullets you shoot, having the possibility to
change character pattern and color etc.....




?????

Are you using screencopies for your enemies? If yes: use sprites, but no more than 8 on a row (or 4 "2sprite-sprites", sprites are fast..

yes i use sprites,
allmost all of them are 2 sprites combined.

The routine for a sprite is something like:

call check dead (is enemy hit, then skip all routines below, and show explosion)
call movement (move the sprite)
call check bullet (is sprite being hit)
call check enter/leave screen (use blanking sprite to blank when sprite enters/leaves)
call change pattern (if enemies appearance change)
call change color (if necessary)

and some more....

All these routines are called for each enemy (when 10 enemies are in screen this takes
a lot of time, and cannot be processed in 1 frameperiod, due to bad programming
I guess,
But I have much difficulties speeding up this process
How should I handle this... and I know that a lot of you have written routines
like this, (games in which 10/20 enemies appear which interact with the player
are quite common).... so maybe someone can send me some example files
I can study.....

Try doing it all on a buffer on RAM, and then copying all to VRAM in one pass. That should speed it up

Quote:

yes i use sprites, allmost all of them are 2 sprites combined. The routine for a sprite is something like: call check dead (is enemy hit, then skip all routines below, and show explosion) call movement (move the sprite) call check bullet (is sprite being hit) call check enter/leave screen (use blanking sprite to blank when sprite enters/leaves) call change pattern (if enemies appearance change) call change color (if necessary) and some more.... All these routines are called for each enemy (when 10 enemies are in screen this takes a lot of time, and cannot be processed in 1 frameperiod, due to bad programming I guess, But I have much difficulties speeding up this process How should I handle this... and I know that a lot of you have written routines like this, (games in which 10/20 enemies appear which interact with the player are quite common).... so maybe someone can send me some example files I can study.....

How many lines do you think your enemies treatment routine is taking at the moment ?
I ran in pretty much the same issue with VScreen, reading the enemy data list (using stupid slow IX,IY based instructions) and treating them one by one...

There are a few things you can do to optimize your code:

* It might not be necessary to refresh all the sprites animation at every frame. See if you can skip the process and for example refresh half your sprites graphics in on Vblank and the other half at the next one. The sprite positions will need to be refresh at every Vblank tho to avoid jerky movements.
* Reserve some sprites for bullets. Most of the time those are not animated (not sprite changes), and the color is always the same. Thus you only need to refresh the position. It involve some constraints but can save a lot of CPU time.
* One way to animate sprites is also to have the different animations already set in the different sprite graphic tables in VRAM and change the base address to animate them.
* For larger sprites, it might be faster to use a VDP copy command in the sprite table instead of using OUTs...

Just some ideas. If you find other tricks to save CPU time, I'd be interested to hear about them also

You might wanna move the 'sprite business logic' out of interrupt at all. On the interrupt just write the (new) values to the VDP.
In other words: try to pre-calc as much as possible before the VBlank starts and only write the (new) VDP values (or do the copies) in sync.
Always try to do as much as possible in the 'non-critical' time between the end & start of the (next) VBlank/splitlines.

Quote:

But I have much difficulties speeding up this process How should I handle this...

Keep the bullets/enemies/playerbullets all sorted in seperate lists by x or y.
Checking for hits can be done a lot faster that way, due the fact you do not have
to compare all objects. Example if the player is not hit by a bullet wich has a larger y (y sorted list)
the next bullet or bullets do not need comparing because their y will be even bigger.
Some time will be lost to keep the lists sorted but with an hundred bullets it will definitely make
a difference.
Another way is so split things up. Compare ship with enemies+bullets odd interrupts, an enemies
with playerbullets the even interrupts.

@GhostP

Comparing the Y (or the X) for collisions using orderd lists is a Great Idea!
Do you use a list with pointers?
The best way to sort the objects without phisically moving the list when
you need to insert new objects, is to use a dynamic list of records chained
by pointers.

The record should look like this:

dw point_next_record
dw point_previous_record
dw Y
dw X
dw attrib1
dw attrib2
ecc.

where point_next_record = 0 means end of the list
and point_previous_record = 0 means start of the list

and the records are sorted by ascending Y

I think this subject deserves a separated topic. It will be useful for so much people. Someone have this routine working correctly?

Quote:

I think this subject deserves a separated topic. It will be useful for so much people. Someone have this routine working correctly?

Check Vscreen source code, it's pretty much working as described here above. Could use a lot of optimization though.

Anyone knows how enemies and collision detection is coded in the original Space Manbow ? It's handeling quiet a lot of objects...

No idea, but you can gain a lot of time using HW detection of the collision.
Follow the new tread on the subject www.msx.org/forumtopicl5128.html

Quote:

Anyone knows how enemies and collision detection is coded in the original Space Manbow ? It's handeling quiet a lot of objects...

30 Hz works miracles

Using sorted sprite table is good idea also, if you plan to make sprite splits. (I think, spritesplits were used in original SpaceManbow)

Usually it is good idea to take sprite out of table, find a correct gap for the sprite and insert it back to table every time you move it.

If you move same sprite many times before screen refresh (e.g. you want the game to run in same speed regardless of 50/60Hz mode) you can also place all the moved sprites to start of the table and in screen refresh execute as many bublesort rounds from start of table as you have moved sprites.

Quote:

No idea, but you can gain a lot of time using HW detection of the collision. Follow the new tread on the subject www.msx.org/forumtopicl5128.html

Agreed, there might be CPU time saving using HW detection. I'll look into it.

Another common issue is the time taken to refresh the display of the sprites (truly WTF where they thinking when they designed the VDP sprites handling system ?) and when you got to manage display and collision detection with something that's bigger than 16x16. Makes all the routines a lot more complex to write (and slower too).