gameplan spacemanbow2

Page 2/2
1 |

By ARTRAG

Enlighted (6285)

ARTRAG's picture

02-08-2005, 18:04

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

By GhostwriterP

Champion (511)

GhostwriterP's picture

02-08-2005, 18:07

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 Tongue

By NYYRIKKI

Enlighted (5401)

NYYRIKKI's picture

03-08-2005, 10:16

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.

By Maggoo

Paragon (1195)

Maggoo's picture

03-08-2005, 10:37

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

By ARTRAG

Enlighted (6285)

ARTRAG's picture

03-08-2005, 10:42

I agree, the VDP sprite managemet is crap.
What about the EC bit?
That bloody EC makes me to rewrite the color definitions
each time the sprite enter the screen!!
What a waste of CPU time, of memory and of mental resources to manage it!!!

By marison

Expert (104)

marison's picture

03-08-2005, 12:38

Preparing to be banished:

Some time ago I saw a technician article about the VIC II, commodore video chip, which have very complete information. Each one of its 8 sprites have in the VIC registers 8 bits to only indicate which sprite collide with each other!

Don't is neccessary any colision detecction mechanism. Only read and interpreter the registers.

Each sprite have a bit to indicate colision with background too.

Each sprite can be magnified in X or Y, indepently.

It's possible to define if the sprite will be in front or back of some graphics bit patterns.

In sprite management, this VDP was an important one to know.

See the article in http://www.minet.uni-jena.de/~andreasg/c64/vic_artikel/vic_article_1.htm.

Claiming for pardon:
I don't have a Commodore 64. I have seen one only once, in the 90's. Your graphics were crap to me in that time, but I was amazed with the sprite management when I see one shoot'em'up.

Page 2/2
1 |