Here is a simpler solution if you think bit-twiddling is too tricky.

Use a canvas of booleans for each "color", where you keep track of the status for each pixel.

Code:

bool[][] upCanvas = new bool[width][height];
bool[][] downCanvas = new bool[width][height];
bool[][] circleCanvas = new bool[width][height];

When you want to "color in" a circle (for example) just set the corresponding pixels in circleCanvas to true.

When you want to check if a pixel has collision, do something like:

Code:

public bool collides(int x, int y) {
   return circleCanvas[x][y] && (upCanvas[x][y] || downCanvas[x][y]);
}

Ah, I didn't realize that your problem was computing the two positions. I could probably have figured out an ugly formula for you, but the one from reddit is really pretty

I think you only need to consider a few cases:

1. A and B do not overlap.
Solution: put C right on top of B.

2. A and B do overlap.
C should be placed as close as possible to A (so that it gets displaced as little as possible (I think?)). The ray intersects two of A's sides, so there are only two possible places to put C (...right?). You can probably afford to test to put C in both these places and pick the one closest to B.

[edit:]

Note: I edited the code in my previous post to use bytes everywhere.

Since I don't know how much you know I'll give you a fairly detailed overview. If you are new to bitwise operations and flag-setting, feel free to ask me for more details.

Code:

// You have a byte-array that is the canvas:
byte[][] canvas = new byte[canvasWidth][canvasHeight];

// For every pixel canvas[x][y] we have one byte to store information in.

// As you hopefully know, each byte consists of 8 bits. So an "empty" byte looks like this:
// 00000000

// We define three different constants (flags), that are bytes as well:
constant byte UP     = 1
constant byte DOWN   = 2
constant byte CIRCLE = 4

// And since numbers are stored as binary strings, those bytes look like this:
// UP     = 1 = 00000001
// DOWN   = 2 = 00000010
// CIRCLE = 4 = 00000100

// So the UP-flag controls the rightmost bit.
// The DOWN-flag controls the second rightmost bit
// The CIRCLE-flag controls the thrid rightmost bit

// We can use these flags to set, unset or read those bits from the bytes stored in the canvas.
// For example using the bitwise XOR operation ^ (which you mentioned in your first post)
// The bitwise operations are explained properly here: http://en.wikipedia.org/wiki/Bitwise_operation

// To set a flag, we use the bitwise OR:
function void set(int x, int y, byte mask) {
   canvas[x][y] |= mask;
}

// Example:
// We want to add the CIRCLE-color to the pixel at x=15, y=92.
// Lets assume that the byte at that position already has the UP-flag set, so the byte looks like this:
// canvas[15][92] -> 00000001
// We send in the mask with the CIRCLE-flag
// mask -> 00000100
// We then use bitwise OR:
//     00000001
//  OR 00000100
//  ------------
//     00000101
//
// Which gives us a result where both the flags are set, and we put that back into canvas[15][92]

// To unset a flag, we first invert the mask by using the bitwise NOT and then use the bitwise AND with that:
function void unset(int x, int y, byte mask) {
   canvas[x][y] &= ~mask;
}

// Example:
// canvas[15][92] looks like this: 00000101
// We want to remove the UP-flag, so mask = 00000001
// First we use bitwise NOT on the mask:
// NOT 00000001
// ------------
//     11111110
//
// Then we use bitwise AND between the pixel-byte and the mask:
//     00000101
// AND 11111110
// ------------
//     00000100
//
// Which gives us back the same result, but with the UP-flag unset.
// Which we put back into canvas[15][93]

// To check if a flag is set, we pick out the relevant flag and cast the result to a boolean.
// I assume here that all non-zero results will be cast to True. It may be different in your language.
function bool isSet(int x, int y, byte mask) {
   return bool(canvas[x][y] & mask);
}

// Example:
// canvas[15][92] looks like this again: 00000101
// we want to check if the CIRCLE flag is set, so mask is: 00000100
// We first use bitwise AND to remove the other flags:
//     00000101
// AND 00000100
// ------------
//     00000100
//
// Then we cast the result to bool and since one bit is set to 1, it returns True.


// To use it we simply call the isSet function for the things we are interested in.
// This returns true if the CIRCLE-flag is set and either of UP or DOWN (or both) are set.
// Which I think is what you wanted.
function bool collide(int x, int y) {
   return isSet(x, y, CIRCLE) && (isSet(x, y, UP) || isSet(x, y, DOWN));
}

edit: fixed the line to say:
// CIRCLE = 4 = 00000100

Wow, this looks super-professional. Thanks for setting it free!

If you're not going to display the hidden canvas, then why use colors at all? If you use bitmasks instead you'll only need a fraction of the space and the computations will be faster. If you only have three "colors" (up, down, circle) you only need 3 bits to store each pixel instead of 32.

But let's be lazy and use 8 bits per pixel (still 75% less than RGBA):

Code: ("Pseudo C-like code")

constant byte UP = 1;
constant byte DOWN = 2;
constant byte CIRCLE = 4;

byte[][] canvas = new byte[canvasWidth][canvasHeight];

function void set(int x, int y, byte mask) {
   canvas[x][y] |= mask;
}


function void unset(int x, int y, byte mask) {
   canvas[x][y] &= ~mask;
}

function bool isSet(int x, int y, byte mask) {
   return bool(canvas[x][y] & mask);
}

function bool collide(int x, int y) {
   return isSet(x, y, CIRCLE) && (isSet(x, y, UP) || isSet(x, y, DOWN));
}

// Usage:
if (collide(x, y)) {
   // Do collide
} else {
   // Do not collide
}

It would be pretty simple to get it down to 4 bits per pixel by storing two pixels in each byte.

Just let the player collide with multiple colors. That way you can choose your colors based on what looks good and combine the colors in any way you want.

Code:

  collidableColor1 = combine(Color#1,  Color#2)
   collidableColor2 = combine(Color#1, Color#3)

   if(color==collidableColor1 OR color==collidableColor2) {
      // do collide
   } else {
      // do not collide
   }

It's generally a good idea to keep game-logic and display-logic separated even more than this, though.

That made absolutely no sense to me, sorry. Do you have an example image or something?

How do you define color summation in this case?

If you simply add the byte values:


Color #1 + Color #3 = Color #4
Color #1 + Color #2 = Color #4
Color #4 + Color #3 = Color #2

=>

Color #2 = Color #3

=>

Color #1 + Color #2 = Color #4
Color #4 + Color #2 = Color #2

=>

Color #4 = 0

=>

Color #1 + Color #2 = 0

And since colors can't be negative and we don't allow integer overflow:

Color #1 = 0
Color #2 = Color #3 = 0


So all colors are 0 (i.e. black)

...

If we allow integer overflow, then Color #1 and Color #2 can be other values.

Assuming that each color component is in the range 0 to 255, it must hold that:
R1 + R2 = 256
G1 + G2 = 256
R1 + R2 = 256
A1 + A2 = 256

(So that summing Color #1 and Color #2 results in 256 for each component, which wraps around to form Color #4)

For example:
Color #1 = 0x01020304
Color #2 = Color #3 = 0xFFFEFDFC
Color #4 = 0

Added you at position 4 in the high score list!

Sorry for the half year delay

Some notes from a free-software/cross-platfrom perspective:

C# is pretty problematic since it's a Microsoft language. Mono is allowed to exist for now, but Microsoft has a history of fucking such projects over. Many parts of the sort-of-standard-library (.net-stuff) can't be implemented on other platforms, as it depends on Microsoft owned patents and Windows-specific stuff.

Unity is highly problematic. You can't release games as free software if they depend on proprietary engines or libraries.

Java is a bit problematic, but to a much lower extent. The reference implementation of the Java runtime (OpenJDK) is free software, which means that it's possible to get the Java runtime on pretty much any platform. Courts have also ruled that Google is allowed to have it's own Java implementation (Dalvik). Oracle did manage to kill the Apache's Harmony project though, so it isn't problem free.

C/C++ aren't problematic in themselves, but it can be difficult to write code that runs on multiple platforms and get everything to compile. But it's definitely something you can learn to do.

Many script languages like Python, JavaScript and Lua are free and work perfectly cross-platform. They generally don't have the same performance as other languages, but they are probably fast enough for most indie-uses.

Slick2D wraps LWJGL, if you plan to do 2D.

A good place to start would be to dig around in an existing project. For example this fork of Mojang's Catacomb Snatch: https://github.com/Maescool/Catacomb-Snatch

Getting the source from github would also be a good way to learn git, if you don't already know it. Version control software is an absolutely necessary tool for any developer, even in your own weekend hobby projects. (git/mercurial have no overhead, just use them on absolutely everything.)

Unfortunately Catacomb Snatch is not properly open source, because Mojang is absolutely clueless when it comes to the use of licenses. So you can't reuse any code from it (except the pieces written by me), but it can still be valuable to mess around with an existing game.

I would also discourage the use of Unity, due to it's proprietary nature.

[edit:]

Ugh, spent 3 hours on a bug, which was caused by making a typo of 'uses-permission' as 'user-permission'. XML's attitude of 'ignore it if you don't know it' made null pointers pop up everywhere.

Are you talking about typos in the XML file or in the code that was reading the XML content?

If you use XML schemas (like XSD or RELAX NG) you will at least be protected from typos in the XML file. If you use an editor with XML schema support (like Eclipse with the XML plugin) you'll get warnings for XML elements that don't comply with the schema. But be warned, writing schemas can be a pain.

edit: if your parser has schema support then you should also be protected when you try to read invalid content.

[edit:]

Um. No.

edit:

Dacke is a fanatic, something something

I have the ambition to make the world a better place, yes. That makes me an idealist but not a fanatic.

But Linux is also the best programming platform in many cases, due to it's *nix roots, package management, open sourceness and server power.

It is also the best choice for many casual users as it is secure (no problems with viruses/malware/etc.), is cheap to use (I only buy some games) and it treats you like a user rather than a consumer.

The move happened for Android (which is Linux based). The same thing can happen with either the Ubuntu-family or something new (like Steambuntu, maybe). People declaring Linux dead/killed, even though it keeps getting better and more alive, is getting to be a tiresome meme.