/prog/ 2012 challenge

Brothers and sisters,

As the end of the year comes closer, and we reflect on what has happened on /prog/ this last year, we have to admit that we did not accomplish very much. Perhaps in our private lives, yes, but here on /prog/ we have spent the majority of the year trolling, meta-trolling, complaining about it and going nowhere in particular. If we look at our community I'm going to say we have very little to be proud of: /prog/ kinda sucks.

I say we change all that. I say in 2012 we band together and prove that /prog/ is better than it has ever been before just by making it so. That we can come to /prog/ with an expectation of lulz and wisdom. I'm willing to make the effort, who's with me?

ITT post your new years resolutions for /prog/, I'll start:

* If I have nothing substantial to say I will sage it.

>>13

yeah, which one is more optimal would probably depend on how complicated the paint patterns where. For the geometric approach, you would need to store polygons of paint on the faces of the object. If I was going to implement this, I'd probably do something like:

See if object A has collided with object B:
  If so, find the point at which the collision occurred on A and B.
  The point of collision is either on a vertex, the edge of a line, or in the middle of a face.
  If the point of collision is on a face, then change the coordinates of the collision point to 2D with respect to the face.
  See if the 2D collision point on the face is within one of the pain polygons.


If you were doing the texture based approach, then that last step would probably be a lot faster:

  Round the 2D collision point on the face to pixel coordinates and see if it is on a painted pixel or not.

You'll have to store all those cells, but it'll probably be cheaper anyway, especially if you are going be painting on top of painting on top of painting. Using geometry for that would require overlaying the polygons, and you would have to merge them together if you wanted to save memory and speed. So doing the texture based approach would probably save a lot of work, go faster, and not introduce weird effects.