Pixel detection

[DrewPee]

I am sure this has been touched on before but here goes anyway . . .

If i have some code that sets up an array of stars and I bounce them around the screen is there any way of 'reading' the tinyptc screen to say whether a pixel is black, white or whatever colour I decide it to be? What I am trying to get at is if the 'stars' bump into each other I want them to rebound? Sorry If I am not making myself very clear. I will post some code if any more info is needed.

Regards
DrewPee

[Shockwave]

It's pretty straight forward to do, you can simply examine the screen array at whatever point you want.

For instance, if you want to return the colour at X = 320  and Y=200 ;

dim as uinteger read_pixel

X=320
Y=200

read_pixel = buffer ( ( Y * XRES ) + X )

Read_pixel will then contain the colour value at that location.

[DrewPee]

Thanks Shockwave - this is how I originally had it set up but for some reason it didnt work.

this is my code at the present time - I want to be able to ascertain whether the swarm has bumped into each other . . .

Code Select Expand


#include once "tinyptc_ext.bi"

const xres = 640
const yres = 480

Dim Shared as Integer sf,a,lpx,lpy,sw,hsc,r,g,b
sf=128:r=255:g=255:b=255

Dim shared as double x(sf),y(sf),x1(sf),y1(sf)

    ptc_allowclose(0)
    ptc_setdialog(1,"Would you like to go Fullscreen?",0,1)
    If( ptc_open( "Swarm 2", XRES, YRES ) = 0 ) Then
    End -1
    End If

for a=0 to sf-1
    x(a)=16+(int(rnd(1)*xres)-16)
    y(a)=16+(int(rnd(1)*yres)-16)
    x1(a)=-1+int(rnd(1)*2)
    y1(a)=-1+int(rnd(1)*2)
    if x1(a)=0 then x1(a)=1
    if y1(a)=0 then y1(a)=1
next

Declare Sub Clr
Declare Sub Swarm
Declare Sub CheckCollision

Dim Shared as Integer sb(xres*yres)
#define pp(x,y,argb) sb(y*XRES+x)=argb

WHILE(GETASYNCKEYSTATE(VK_SPACE)<> -32767 and PTC_GETLEFTBUTTON=FALSE)
    Clr
    Swarm
'    CheckCollision
    ptc_update @sb(0)
Wend

Sub Clr
    for a=0 to xres-1
        for b=0 to yres-1
            pp(a,b,rgb(0,0,0))
        next b
    next a
End Sub

Sub Swarm
    for a=0 to sf-1
        x(a)=x(a)+x1(a)
        y(a)=y(a)+y1(a)
        if x(a)<16 then x1(a)=1
        if x(a)>xres-16 then x1(a)=-1
        if y(a)<16 then y1(a)=1
        if y(a)>yres-16 then y1(a)=-1
        for l=0 to 7
        sw=int(rnd(1)*l)
        pp(x(a),(xres*sw)+y(a),rgb(r,g,b))
        pp(x(a),(-xres*sw)+y(a),rgb(r,g,b))
        pp(sw+x(a),y(a),rgb(r,g,b))
        pp(-sw+x(a),y(a),rgb(r,g,b))
        next l
    next a
End Sub

Sub CheckCollision
    for a=0 to sf-1
'how do i check for objects hitting?
    next a
End Sub


I think it explains it better?

DrewPee

[Jim]

As you've probably realised, it's not just enough to find out if another star is occupying the same pixel, you also need to know which direction they were both going to work out which way they bounce off.
First of all you will need to compare every star with every other star

Code Select Expand


for x = 0 to stars
  for y = x+1 to stars
    do_stars_collide(x,y)
  next
next

Then you need to know if they're colliding.  Let's (for now) assume that means they've ended up on the same pixel

Code Select Expand


do_stars_collide(x,y)
  if star(x).x = star(y).x And star(x).y = star(y.y) then
    do_bounce(x,y)
  end if
end proc

Then you need to bounce them.  Let's (again for now) assume the stars are moving up, down, left, right or diagonally.  That gives us a truth table

Code Select Expand


star A, star B, result
U        U            ?
D        D            ?
L        L            ?
R        R              ?
UL      UL          ?
UR      UR          ?
DL      DL           ?
DR      DR          ?

where the ? are which way you want star A and B to move off.

In practice though, you have a few more problems.  You never gurantee that when you move stars off that they're not going to end up on top of one another - may or may not need extra work.  You might want to deal with more than 8 directions.

Jim

[DrewPee]

Thanks Jim! - I will take a look later when my brain is a little clearer!

[ferris]

An easier method would be to just negate each component velocity, but Jim's is much more correct