wip collision prevention

[bogax]

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

[Cybearg]

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.

[+Random Terrain]

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

 

collision_prevention_partial_cd_2013y_05m_21d_1748t.bin

 

collision_prevention_partial_cd_2013y_05m_21d_1748t.bas

 

 

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.

[bogax]

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 June 25, 2013 by bogax

[bogax]

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

[bogax]

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

[bogax]

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 June 28, 2013 by bogax

[+Gemintronic]

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

[bogax]

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

 

 

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

Edited June 28, 2013 by bogax

[bogax]

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

[+Random Terrain]

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?

[bogax]

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.

[+Random Terrain]

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.

[bogax]

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.

[+Random Terrain]

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.

[+Lewis2907]

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.

[+Gemintronic]

I hear two solutions so far:

 

1. Read playfield variables

2. Read a tilemap (playfield collisions as array)

 

What about a third option in using, say, the ball to test for the next possible collision? If the ball collides where the player wants to go then don't move the player sprite.

 

This option has problems since the ball will be playfield pixel colored. But, I wonder if there is a way to mitigate that.

[+Lewis2907]

I tried the ball and missile in the DPC experiments with Pac Man Eat n Run. It worked somewhat in DPC but not too well in the Multisprite. Plus my programming level eats are lot of space up. If Bogax can make these 2 current programs 8 banks. I think others can adapt it to work.

Edited July 24, 2018 by Lewis2907

[+Gemintronic]

I tried the ball and missile in the DPC experiments with Pac Man Eat n Run. It worked somewhat in DPC but not too well in the Multisprite. Plus my programming level eats are lot of space up. If Bogax can make these 2 current programs 8 banks. I think others can adapt it to work.

 

Here's a demo of that kind of collision working in multi sprite. The pumpkin (player) doesn't jump. When you press FIRE a spell launches. When the spell hits a wall it warps the player there.

 

ballcoldemo.bin

[+Lewis2907]

That's pretty cool. Do you mind posting the code. That's is how I have been learning and using and giving credit in my remarks, thanks.

[+Gemintronic]

That's pretty cool. Do you mind posting the code. That's is how I have been learning and using and giving credit in my remarks, thanks.

 

My "in progress" code gives Random Terrain hives. Lemme clean it up a bit as a more complete example. But, at least you see that using the ball to detect collisions and mitigate sprite jitter is possible. Better the ball waffle back and forth after a collision than yer sprite

[+Lewis2907]

Okay thanks. Plus we don't want RT to go back in the "Squishy Bed" with the hives. For giggles randomly place the dim here and there out of order to work a nerve with him lol.

[Lillapojkenpåön]

I've been wondering about some semi-related stuff..

I remember reading that the DPC+ kernel had built-in virtual player hit detection and that the Y-value of the hit player was in temp4 after drawscreen but that the value could be a little bit wrong,

is that still implemented in the kernel? I've never seen anybody use it so just seems unnecessary if it is.

 

And I've never tampered with playfield collisions so I don't know how it's done but could you use the same technique for a moving sprite to get a hitbox that's exactly or closer to the sprites shape instead of a square?

Edited July 25, 2018 by Lillapojkenpåön

[+Lewis2907]

From what I understand part of the issue is the mirrored playfield and there is not pfpixel as a reference point to have detection the easy way. From what I am reading and seeing using a combo ASM and Bb to get a desired effect. Waiting to see what the others can produce as a blueprint hopefully with 32k / 8 banks.

[iesposta]

I've been wondering about some semi-related stuff..

I remember reading that the DPC+ kernel had built-in virtual player hit detection and that the Y-value of the hit player was in temp4 after drawscreen but that the value could be a little bit wrong,

is that still implemented in the kernel? I've never seen anybody use it so just seems unnecessary if it is.

 

And I've never tampered with playfield collisions so I don't know how it's done but could you use the same technique for a moving sprite to get a hitbox that's exactly or closer to the sprites shape instead of a square?

 

I don’t know about the y-value being in temp4,

but this bB DPC+ code I wrote turns 7 virtual Players into a lot more using double and triple copy, and collision works with all of them:

 

http://randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_shooting_nusiz