gameplan spacemanbow2

Page 1/2
| 2

By norakomi

Paragon (1136)

norakomi's picture

31-07-2005, 17:11

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)
********************************************************

Login or register to post comments

By norakomi

Paragon (1136)

norakomi's picture

31-07-2005, 17:19

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.....

?????

By wolf_

Ambassador_ (10092)

wolf_'s picture

31-07-2005, 17:26

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..

By norakomi

Paragon (1136)

norakomi's picture

31-07-2005, 17:31

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.....

By SLotman

Paragon (1242)

SLotman's picture

31-07-2005, 17:51

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

By Maggoo

Paragon (1217)

Maggoo's picture

31-07-2005, 17:56

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 Smile

By SKiLLa

Expert (115)

SKiLLa's picture

31-07-2005, 23:42

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.

By GhostwriterP

Paladin (683)

GhostwriterP's picture

01-08-2005, 17:24

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.

By ARTRAG

Enlighted (6931)

ARTRAG's picture

02-08-2005, 10:00

@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

By marison

Expert (104)

marison's picture

02-08-2005, 13:06

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

By Maggoo

Paragon (1217)

Maggoo's picture

02-08-2005, 17:47

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...

Page 1/2
| 2