Jump to content

Photo

wip collision prevention


15 replies to this topic

#1 bogax OFFLINE  

bogax

    Dragonstomper

  • 761 posts

Posted Mon Jun 24, 2013 8:47 PM

This is a work in progress.
Its still buggy.
No provision for sprite animation
or reversals.

Eight pixels for each sprite
one for each possible direction.
Five of the 8 are checked for
a possible move.

Fire selects amongst the sprites.
Starts with player0 and increases
then wraps.

Player0 is just the eight pixels
(and a pixel at 0, 0 which doesn't count)
(player1 also has the 0, 0 pixel)
Think of the 8 pixels as an envelope
or bumper into which the sprite fits.
Player0 is a circle, but it could be
any 8.

Works reasonably well but 8 is not enough
even for (some of) these simple sprites.

I haven't tryed to figure it but it may be too
slow to be really useful.

wip_collision_prevention.bas

#2 Cybearg OFFLINE  

Cybearg

    Dragonstomper

  • 950 posts

Posted Mon Jun 24, 2013 9:27 PM

Wow, that's amazing!

What kind of cycle drain is this? If it's efficient, it seems like a fantastic multi-purpose collision detection engine.

#3 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,689 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Jun 24, 2013 10:15 PM

Can it be adapted to work with any size sprite, like this one from theloon:

Attached File  collision_prevention_partial_cd_2013y_05m_21d_1748t.bin   4KB   51 downloads

Attached File  collision_prevention_partial_cd_2013y_05m_21d_1748t.bas   4.37KB   45 downloads


We really, really, really need something where a newbie can enter the width and height of a sprite and get smooth collision prevention. Then all future games would have collision that is as smooth as an ice cube sliding over oiled glass.

#4 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 761 posts

Posted Mon Jun 24, 2013 11:08 PM

I count about 2400 cycles for the worst case.
but I doubt it goes much above half that most of the time

it's about 800 cycles if there's no collision
and it could test in three directions if its trying
to move diagonaly, although each test will get
cut short of 800 cycles if there's a collision
detected (and it only tests in another direction
if there is a collision detected).

I haven't seen it go over cycles in stella
and I tried.

there's stuff that could be done to speed it up
a little. but I think it really needs to test more
pixels per direction

as far as bigger sprites I don't think that there'd
be any problem with that, except it doubles the
bytes needed per sprite definition now and it
would (possibly) take more than that for bigger sprites

the pixel data is packed now as offsets from
0, 0 relative to the sprite I don't know what the limits
on sprites are. assuming they're limited to 8 pixels
in the horizontal direction, that would 3 bits of the
byte leaving 5 bits or 32 pixels vertically
and now that I think about it I should set it up that way
any way.

but unpacking takes time so one way to speed
things up would be to leave it unpacked but it
only costs about 10 cycles per pixel checked
to unpack so it wouldn't be that much maybe 5%

Edited by bogax, Mon Jun 24, 2013 11:13 PM.


#5 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 761 posts

Posted Tue Jun 25, 2013 10:15 PM

Here I've squeezed out or moved into the tables
everything I could think of and unrolled the loop

I think that gets it down to around 1600 cycles
worst case

But the player pixel tables are three times as big.

collision_prevention.bas

#6 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 761 posts

Posted Wed Jun 26, 2013 12:18 AM

I added playfield bars that show the
number of pixels tested for a move
(or attempted move)

5 is the norm if there's nothing to
collide with

collision_prevention_w_bars.bas

#7 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 761 posts

Posted Thu Jun 27, 2013 8:49 PM

I moved some of the calculation into
the pfread routine which should save
a couple hundred cycles.
It also saves a couple variables.
But it would make the pfread routine
a little harder to use for anything else,
temp variables would have to be set up.

I rearranged the order of the pixels
check which seems to save checking
one or two pixels, that should save
a couple hundred cycles, at least with
these pixels/sprites.

I tryed adjusting the order of the pixel
checking dynamically according to the
direction of movement, but I think it
uses more time than it saves.


edit
added some marks to make it easier to
judge bar length

collision_prevention_13.bas

Edited by bogax, Thu Jun 27, 2013 10:13 PM.


#8 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,955 posts

Posted Thu Jun 27, 2013 9:18 PM

A. Is this dependent on a certain playfield pixel height? One of the big advantages of the multisprite kernel is having 40 pixel tall playfields.
B. How on earth are you changing the top row of playfield pixels?!? One of the BIG limitations of multi sprite is a static playfield :-o

#9 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 761 posts

Posted Thu Jun 27, 2013 9:33 PM

A. Is this dependent on a certain playfield pixel height? One of the big advantages of the multisprite kernel is having 40 pixel tall playfields.

Yes but I don't think it would be hard to make it adaptable.
In that last version its baked into the pfread routine but i think
it would just be a matter defining a constant and making it use that.
although I'm not really sure what it would take. it would certainly
help if it works out to a power of two which seemed to be the case
for 40


B. How on earth are you changing the top row of playfield pixels?!? One of the BIG limitations of multi sprite is a static playfield :-o



heh, look at the code. It's brute force. There's a playfield for each bar length.

Edited by bogax, Thu Jun 27, 2013 9:35 PM.


#10 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 761 posts

Posted Fri Jun 28, 2013 12:07 AM

A. Is this dependent on a certain playfield pixel height? One of the big advantages of the multisprite kernel is having 40 pixel tall playfields.


This is just setup for 40 it doesn't adapt

collision_prevention_40.bas

#11 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,689 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Jun 28, 2013 12:39 AM

Do you think it would be possible to make a program that checks the 4 corners of a sprite, ball, or missile for use with collision prevention? The user would enter the widths and heights in constants and also enter the playfield pixel height in a constant. If possible, I wonder if the user would have to enter a different width if NUSIZx is used or if the program would automatically adjust for the size difference?

#12 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 761 posts

Posted Fri Jun 28, 2013 11:16 AM

Do you think it would be possible to make a program that checks the 4 corners of a sprite, ball, or missile for use with collision prevention? The user would enter the widths and heights in constants and also enter the playfield pixel height in a constant. If possible, I wonder if the user would have to enter a different width if NUSIZx is used or if the program would automatically adjust for the size difference?




In principle it could be done.
You want to put every thing that you
can in tables for speed.
Having to accomodate on the fly changes
will make the tables explode geometrically.

To keep the tables from being unweildy
if not just too damn big would mean
calculating stuff on the fly which might
be too slow.

You might want dedicated routines for
different possibilities (and not just
things that change on the fly) which
could cause the code to explode.

There's an inbetween. Finding a practical
inbetween might get tricky.

How much of what do you want to change
on the fly?

I would expect NUSIZx to change.
that's 32 different possibilites to
accomodate.

I don't think it would be impractical
but I expect it's going to be sensitive
to how much you expect to change on the
fly and how many options you have that
don't change (pfheight for example) what
kernel you're using, stuff like that.

Even just checking or accomodating for
eg player heights and widths is going
to slow you down.

#13 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,689 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Jun 28, 2013 3:54 PM

How much of what do you want to change
on the fly?


Since this would just be a collision prevention 'engine' instead of a demo or tool, the only thing the code would do is perform the four corner conversions based on the object width and height info, NUSIZx info, and pfpixel height (number of rows used) that will be provided by the bB programmer at the beginning of the code (in constants). There would be REM statements telling the programmer what constants to use for the various objects.

#14 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 761 posts

Posted Sun Jun 30, 2013 11:43 AM

What makes more sense?

Individual routines for object type
player, missile, ball

Or a completely general routine that
would check any type based on a paramter.

A general routine would work better if it
could find NUSIZx CTRLPF in ram

Individual routines could be shorter and
faster but, of course, you'd need more of
them (or not if eg your were only using
players) and you'd either need individual
movement routines or a more complicated
movement routine.

If NUSIZx is going to change it/they should
probably be in ram else you have a similar
situation.

Maybe it would make more sense to have both
types of routines available so you could use
whatever the situation called for.

#15 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,689 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Jul 1, 2013 3:08 AM

My guess is that there would be constants set up for each sprite, each missile, the ball, and number of playfield rows. Here's an example of what the default constants might look like:

const _p0_width = 0
const _p0_height = 0

const _p0_double_size = 0 : rem - if you want a double-sized player, use "const_p0_double_size = 1"
const _p0_quad_size = 0 : rem - if you want a quad-sized player, use "const_p0_quad_size = 1"


const _p1_width = 0
const _p1_height = 0

const _p1_double_size = 0 : rem - if you want a double-sized player, use "const_p1_double_size = 1"
const _p1_quad_size = 0 : rem - if you want a quad-sized player, use "const_p1_quad_size = 1"


const _m0_width = 0 : rem - Missile width can be 1, 2, 4, or 8
const _m0_height = 0


const _m1_width = 0 : rem - Missile width can be 1, 2, 4, or 8
const _m1_height = 0


const _ball_width = 0
const _ball_height = 0


const _Number_of_playfield_rows = 12


Now if-thens would be set up to deal with the constants. For example, if _m0_width or _m1_width is greater than zero, the program will set NUSIZx accordingly. If a constant equals zero, that means the bB programmer isn't using that object or option.

After the if-thens figure out what objects or options are being used and how tall a playfield row is (in sprite pixels), more code can then check the 4 corners of objects so we'll get smooth collision prevention.

#16 Lewis2907 OFFLINE  

Lewis2907

    Chopper Commander

  • 231 posts
  • Location:Senatobia, MS

Posted Mon Jul 9, 2018 1:11 AM

Bogax,

 

For your programs collision_prevention_40.bas and collision_prevention_13.bas is it possible to have a version that is 32kSC or 32k. I think this would solve my problems in MultiSprite Version I am working on. I am still playing with the code and your notes on the sprite s well to learn more about. Thanks for sharing this code. 






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users