开发者

Collidable color Java/Android game

开发者 https://www.devze.com 2023-01-23 02:15 出处:网络
I\'m trying to develop side scrolling game for android involving many many textures so I was thinking if I could create a separate layer, all a single uni开发者_JAVA技巧que color (very similar to a gr

I'm trying to develop side scrolling game for android involving many many textures so I was thinking if I could create a separate layer, all a single uni开发者_JAVA技巧que color (very similar to a green screen effect) make a collidable and make it invisible to the player.

(foreground layer) visual Image

(2nd layer)collidable copy of foreground layer with main character

(3rd layer)Background image

I not sure if this is possible or how to implement it efficiently, the idea just came to me randomly one day.

Future regards, Thanks


I assume your game is entirely 2D, using either bit-blits or quads (two 3D triangles always screen-aligned) as sprites. Over the years there have been lots of schemes for doing collision detection using the actual image data, whether from the background or the sprite definition itself. If you have direct access to video RAM, reading one pixel position can quickly tell if you've collided or not, giving pixel-wise accuracy not possible with something like bounding boxes. However, there are issues greatly complicating this: figuring out what you've collided with, or if your speed lands you many pixels into a graphical object, or if it is thin and you pass through it, or how to determine an angle of deflection, etc.

Using 3D graphics hardware and quads, you could potentially change render states, rendering in monochrome to an off-screen texture, yielding the 2nd collidable layer you described. Yet that texture is then resident in graphics memory, which isn't freely/easily accessible like your system memory is. And getting that data back/forth over the bus is slow. It's also costly, requiring an entire additional render pass (worst case, halving your frame rate) plus you have all that extra graphics RAM used up... all just to do something like collision-detect. Much better schemes exist, especially using data structures.

It's better to use bounding boxes, or even a hierarchy of sub-bounding boxes. After that, you can determine if you've landed on the other side of, say, a sloped line, requiring only division/addition operations. Your game already manages all the sprites you're moving, so integrate some data structures to help your collision detection. For instance, I just suggested in another thread the use of linked lists to limit the objects you must collision-detect against one another.

Ideas like yours might not always work, but your continual creative thinking will lead to ones that do. Sometimes you just have to try coding them to find out!

0

精彩评论

暂无评论...
验证码 换一张
取 消