I'm working on a pixel-based physics engine for my python game, and I've run into a problem. My initial tests were on a TI-84+SE, where the pxl-test() function is readily available. I have not had such luck with python.

Is there any way besides an edge detection algorithm that I could use to get the rgb values of a single pixel in python?

I'm using Pycap (the python port of popcap's framework) for this project, if it matters any.
Sigfig wrote:
I'm working on a pixel-based physics engine for my python game, and I've run into a problem. My initial tests were on a TI-84+SE, where the pxl-test() function is readily available. I have not had such luck with python.

Is there any way besides an edge detection algorithm that I could use to get the rgb values of a single pixel in python?

I'm using Pycap (the python port of popcap's framework) for this project, if it matters any.


I am not sure about any way to do exactly what I think you are looking for, however, try keeping a 2d or 3d (depending on if you need more than one value per pixel to store the data) array of what is onscreen. If you can't do that you will need to rely on any provided functions in your specific graphics library (at least if what I understand about how python works is correct).
It depends on what GUI toolkit you are using and if they support it.

Honestly though, such a method is terrible and needlessly wastes time.

If you want per-pixel 2d collision detection, do it on the sprite level. First use bounding box collision detection as it is far faster. If the two sprites' bounding boxes collide, then check for pixel collisions using a mask of each sprite (which you should generate on level load or similar). This all happens well *BEFORE* you ever draw it to the screen.

You really should never need to get a pixel value from the screen.

EDIT: Oh, and fair warning. Per-pixel collision detection written in python is going to be horrendously slow (even if you are a python guru and know all the speed tricks for iteration - which I highly doubt). I would recommend sticking to box and circle collision and just try to get it close enough, or use a library that supports per-pixel sprite collision (or write your own in C).
I'll just write something to generate an array from an image, then.

A quick note: "no" isn't an answer to "how". I've already decided on this method.
A quick note: Don't be a douche. You seemed really cool from your introduction topic; don't ruin that now. He suggested a better alternative. If you don't want to do it, that's perfectly fine, but don't be an ass about it.
foamy3 wrote:
A quick note: Don't be a douche. You seemed really cool from your introduction topic; don't ruin that now. He suggested a better alternative. If you don't want to do it, that's perfectly fine, but don't be an ass about it.


He caught me off guard. Smile
Sigfig wrote:
A quick note: "no" isn't an answer to "how". I've already decided on this method.


I answered how. Its "it depends on the library you are using to do the drawing".

If you don't want to bother reading the documentation of the library you are using, then you might as well just give up on your idea.
Don't worry. If Kllr's brutal methods catch you off guard, it just means you are a relatively normal human. Unless you are a very confused alien or something...
Kllrnohj wrote:


I answered how. Its "it depends on the library you are using to do the drawing".

If you don't want to bother reading the documentation of the library you are using, then you might as well just give up on your idea.


Oooh, argument time! This should be fun.

I was actually referring to the main message of your post: "It's a bad idea you should do something else."

I'm actually hoping to add some basic particle dynamics in the future so a pixel-based system would, in my opinion, make that particular task a bight lighter.

For the truth: I don't fully grasp the concepts behind a BB system. Simulating with what you actually see feels more intuitive to me.
BB == Bounding Box? I don't know that it makes it more intuitive per se so much as easier and less computationally-intensive.
KermMartian wrote:
BB == Bounding Box? I don't know that it makes it more intuitive per se so much as easier and less computationally-intensive.


I understand that it's more computationally-intensive to test every pixel, but coding a bounding-box system would require a lot more math than I actually know how to implement.

The extent of my education in mathematics is Algebra I. This is part of the reason I'm not very good at coding.
Sigfig wrote:
I understand that it's more computationally-intensive to test every pixel, but coding a bounding-box system would require a lot more math than I actually know how to implement.

The extent of my education in mathematics is Algebra I. This is part of the reason I'm not very good at coding.


Bounding boxes are very very easy. And the math is not at all complicated. Its only like 4 checks to see if two rectangles overlap.
Kllrnohj wrote:

Bounding boxes are very very easy. And the math is not at all complicated. Its only like 4 checks to see if two rectangles overlap.


Could you direct me to some webpage with information on it? (the math) I haven't been able to find anything.
Hmm, this doesn't have much math, but it's still helpful: http://en.wikipedia.org/wiki/Collision_detection#Video_games

here's something else: http://www.morrowland.com/apron/article/gl/boundingbox/index.php
Or if you want something else to try you could use pygame, they include a function just for pixel detection. http://www.pygame.org/docs/ref/surface.html#Surface.get_at
Maybe I'm an idiot, but I'm still not fully understanding 3D collision detection. I think I know enough to attempt a 2D collision detection module, though.

I'll look into pygame. I've heard of it used but I never really decided to play with it.
If you decide on pygame check out this ebook http://www.netbks.com/programming/python-programming/beginning-game-development-with-python-and-pygame-from-novice-to-professional_283.html
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement