With your current code, you can only call askYesNo1() from inside main. You can't call askYesNo2().
This is because main hasn't heard about askYesNo2() yet -- it comes after, after all!
You can keep the order you want, and still make main able to call askYesNo2() by forward declaring it higher up, like so:
char askYesNo2(); //Declaration, just lets rest of code know that a function with this signature exists and can be called
char askYesNo2() //Definition, containing the code that will actually run
There are several ways. You can use masking within a pixel to indicate collision or interactable areas, like megadan says.
For the collision issue, you can also solve it using math, in order to figure figure out all kinds of things apart from just "is this tile full-on collision?".
You might have a tile which is flagged as "collision starting from bottom left, going upwards in a 45 degree angle to the right". The actual collision for the tile's pixels can then be determined by a simple linear formula: mx + b, with m being the slope and b being the start offset.
You might also then have collision which is only checked if the player is below (or above, or from the left/right), which would allow you to pass through the collision in some directions. Collision does not need to be "nothing can ever penetrate this square tile" -- although it can be. It depends on what you need/want.
In both cases, you need to do more checking that just on a tile level. You'll want to store and check a more finely detailed position.
How a level is saved will depend greatly on what specific things you need saved, and how the game will interpret them.
One way to solve your specific issue is to store a position and a rotation, either as some floats and some rotation angles or something, or by basically having the entire 4x4 matrix stored in the level's file.
ObjectName = "MyObject"
ObjectType = "AwesomeObject"
ObjectPos = 100.023f, 39.5f, -882.0f
Then, in this example when loading, the editor/game would see a new object block (from the "Object_Start" keyword), would assign its name and type based on the next keywords, and put it in the exact position you wanted it, based on the position data.
Is it me or is L.Spiro assuming that framerate limiting is only done for hardware limitations and not to simplify gameplay logic? (it's much easier to do things like physics if you know the interval between frames is always the same)
While this might only be tangentially relevant, you might want to look at the game SpaceChem. You might find it interesting, and it might give you some ideas in terms of puzzle gameplay with a molecular flavour.