pixel color

[sterlingy]

Is it possible to get the color of a pixel on a bitmap, even if the bitmap is not visible?

~sterling

 

[sorex]

in dummy code it would look like this

for x=0 to enemies.length
 if  check_if_enemy[x]_is_near_player_sprite then
  clear_collision_array
  put_playermask_into_array
  add_enemy[x]_mask_to_array_at_given_offset
  if last_added_pixel_position=2 then collide=1:exit loop/sub 'skip checking other enemies, dead is dead ;)
 end if
next

the "intensive" check only happends on sprites near the player.

that's the only way to get pixel perfect collision I guess.

I don't know if you checked the gameview library? It has collision routines aswell I believe but I don't know if they are pixel perfect or just "box" based.

 

[sterlingy]

GameView does have collision detection, but it's one Rect against another. I want to do a collision check of one Rect against it hitting anything of a specific color, such as white, that the Rect might move over.

-Sterling

 

[basil99]

in dummy code it would look like this

for x=0 to enemies.length
 if  check_if_enemy[x]_is_near_player_sprite then
  clear_collision_array
  put_playermask_into_array
  add_enemy[x]_mask_to_array_at_given_offset
  if last_added_pixel_position=2 then collide=1:exit loop/sub 'skip checking other enemies, dead is dead ;)
 end if
next

the "intensive" check only happends on sprites near the player.

that's the only way to get pixel perfect collision I guess.

I don't know if you checked the gameview library? It has collision routines aswell I believe but I don't know if they are pixel perfect or just "box" based.

Sorry, what is "mask" ? I'm pretty stupid today )

 

[sorex]

the mask is a single color representation of the sprite, like black background and the actual sprite data is colored white.

that makes it easy to check things and compresses very good too.

for example...

let's say your sprite mask is white ffffff and you use for your enemy masks red ff0000 as color

you can just go through the pixels like spritemask[(y*width)+x]-enemy[(y*width)+x]

player on background = ffffff - 0 > ffffff
player on enemy = ffffff - ff0000 > 00ffff > collision!!!
enemy on background = ff0000 - 0 > ff0000

that way you don't have to convert your images to 0 & 1 values which are invisible when viewing them with irfanview or something simular.

ofcourse, you can build arrays of 0 & 1 based on getpixel results but the problem there is that the sprite can have transparent pixels where it can collide aswell,
and it will eat more memory.

 

[basil99]

Got it now
Frankly, I don't like this approach at all. Collisions detection must take into account objects position and their velocities. Let me illustrate this with following pictures:

At the time = 1 Player has its position, It speed = 3 units and a bullet has speed = 4 units:

After a timer tick player and bullet positions changed

as you may see checking around at moment 1 may always bring 0 as collision flag, hit happens inbetween

Solution is to increase timer resolution, but are you sure it will not slowdown app performance ?

 

[Informatix]

For a lot of games, a basic collision detection algorithm ("discrete") is sufficient. In my Space Enemies game (provided with AcceleratedSurface), I don't need a continuous detection because a "tunneling" cannot happen: there are no high velocities and I avoid big jumps if the time interval increases suddenly. I could miss a few pixels in the worst case, but everything is bigger than a few pixels.

That being said, I agree with Basil99. GetPixel is one of the slowest functions at our disposal, so you should avoid calling it. IMHO it's a bad approach in general. It is a lot faster to create a 2D array full of 0 and 1. 1 -> you can move your pixels there. 0 -> you cannot. But that works if there's no tunneling risk.

 

[sorex]

the speed 4 bullit would only mis your player is it is only 3 pixels in width and it was 1 pixel of in the previouw frame, even your stickman is bigger than that.

but you have a point, that's why in most (old) games bullets are not sprites but char/bitmap blocks/tiles since detecting is easier and plotting faster.

 

[Informatix]

the speed 4 bullit would only mis your player is it is only 3 pixels in width and it was 1 pixel of in the previouw frame, even your stickman is bigger than that.

It's not the only parameter. It depends also on the time interval you use and what you do when this interval changes suddenly. Example: you compute the position of your bullet every 1/60 second and it moves about 1 pixel at each computation. A service in the background starts a download, the garbage collector enters in action and the device suddenly slows down. The interval was 16 ms, now it's 160ms (on a phone with a single core, it's not uncommon at all). The bullet, this time, does not advance of 1 pixel, but 10 pixels! And you have a bullet passing through a wall...

 

[sorex]

I would expect to see a slow down instead of skipping 10 frames and 10 collision detections?

 

[Informatix]

I would expect to see a slow down instead of skipping 10 frames and 10 collision detections?

I supposed that you used a speed expressed in pixels/seconds like in most games. The main advantage over a speed expressed in pixels/tick (a tick = each time you enter the computation routine) is that you keep a regular move even when the interval between two computations varies.

 

[sorex]

right, just pixels (movement) by ticks. you can't predict what happends in the background like compared to an old computer / console where you had only your own stuff running.

maybe I should code some easy game to see how these devices behave.

 

[sterlingy]

maybe I should code some easy game to see how these devices behave.

Sorex,

Sounds like a great idea!

-Sterling