Teivaz

Проблема в рабочей директории.
В Project -> Properties -> Debugging -> Working Directory ставим $(TargetDir)
И текущая директория при запуске будет той, где лежит исполняемый файл. Ну или можно использовать абсолютный путь.

Кокос очень сильный движок и сейчас активно развивается

Да, возможно конечно. Я и сам таким занимаюсь сейчас для общего развития.
www.gamedev.ru

И если интересно, то я уже отвечал на пару вопросов о самом процессе разработки игр, вот, например

Данные можно хранить в json. А чтобы парсить есть библиотеки, например lib_json.

Попробуй Cocos2dx. Это версия на С++ довольно популярного игрового движка. Под него есть удобные радакторы, например Cocostudio. Там можно и анимации делать и спрайты нарезать и GUI набросать и сцену собрать. А ещё он кроссплатформенный, так что можно будет и под иос и под андроид собрать без проблем.

Ну и если создавать игру, то очень важно понимать что конретно должно быть в ней. Для этого обычно создают несколько так называемых фейков - картинок с изображением игрового процесса, меню, короче говоря того, как должна будет выглядеть игра. Также важно иметь список фич, которые планируются для первой версии, без него игру можно делать бесконечно и она врядли когда-нибудь будет закончена. Ну и всяческие диаграммы переходов между меню, игровой флоу тоже будут полезны. Всё это нужно для того, чтобы во время программирования точно знать что нужно реализовывать а не распыляться на кучу фич которые было бы круто иметь в будущем.

Шейдером в openGL это решается элементарно.
Передаём в шейдер обе текстуры. Из первой текстуры берём r, g, b. Потом вычисляем яркость второй текстуры в точке и в прозрачку стави один минус это значение.

vec4 tex1 = texture2D(texture1, position);
vec4 tex2 = texture2D(texture2, position);
float luma2 = (tex2.r + tex2.g + tex2.b)/3.0;
gl_FragColor = vec4(tex1.r, tex1.g, tex1.b, 1.0 - luma2);

Следует понимать что именно делает ви;уал студия когда ты просишь скомпилить проект. Три основных этапа:
Создание единиц трансляции
На этом этапе каждый компилируемый файл (*.cpp включённый в проект) обрабатывает препроцессор: подставляет вместо "#include" код из файлов, убирает код в блоках игнорирумых "#if", подставляет все макросы "#define" и удалит комментарии.
Кстати есть интересный финт с препроцессором, который немногие знают:

// words.h
"he", 
"she", 
"it"

// main.cpp
const std::string words[] = 
{
#include "words.h"
};

int main(int, char**)
{
std::cout << words[1];
return 0;
}

в результате будет
>>> she

Компиляция ресурсов. На данном этапе каждая единица трансляции компилируется в объектный файл с расширением ".obj".

Линковка. Она же компоновка. Исполняемый файл начинает выполнение с точки входа. Линковщику можно задать эту точку входа. По умолчанию в консольных приложениях винды это функция "main". Линковщик начнёт с того, что пройдётся по всем объектным файлам, найдёт эту функцию и начнёт с неё создавать ".exe" файл. Потом отыщет все функции, которые используются в программе, добавит их в исполняемый файл, а вызовы их имён заменит вызовами по соответствующим адресам.

Исходя из этого можно предложить несколько вариантов:
Использовать комментарии для переопределения точки входа.
Использовать препроцессор (#if #elif #else #endif).
Использовать разные точки входа линковщика.
Во время исполнения программы отслеживать устройство ввода (клавиатура, файл) и выполнять соответствующий участок кода.

В подобных случаях я разделяю группы условий либо на временные пременные, либо на функции.
Например:

bool CanConsumePoint();
bool IsPointValid(Point pt);

bool pointInsideRectangle = (pointX > rectXMin) && (pointX < rectXMax) && (pointY > rectYMin) && (pointY < rectYMax);
bool pointTypeCompatible = (pointType == compatible) || (pointType == force);
bool pointValid = IsPointValid(currentPoint);
if (pointInsideRectangle && pointTypeCompatible && CanConsumePoint() && pointValid)
{
    ...
}

Так каждую переменную и метод можно отдельно рассматривать и легко понять за что каждая отвечает и при необходимости разобраться с логикой каждого элемента условия не вдаваясь в подробности остальных.

Газовый паяльник не то с чего удобно начинать, если, конечно, не нужно паять медные трубы. Обычный паяльник за 15 баксов в этом плане намного лучше. Газовый паяльник сильно перегревает жало, у него нет нормального механизма поддержания температуры на требуемом уровне. Перегретый припой теряет свои качества, становится матовым. Перегретая канифоль кипит и тоже быстро теряет свои свойства, сильно кипит и брызжет. Перегретое жало быстро окисляется, его нужно постоянно очищать.
У газового паяльника также есть отверстие для выхода продуктов горения, обычно оно на боковой стороне жала (у меня такой же дремель дома, там как раз так), что довольно неудобно так как необходимо следить чтобы при пайке оно не оплавило что-нибудь или не сдуло СМД компоненты (даже припаянные уносит вместе с капельками расплавленного припоя).
Так что идеальный вариант для обычной пайки радиодеталей - простой электрический паяльник ватт на 40, бонусом будут сменные жала. А для начинающего и регулировка температуры особо не нужна.
Газовый паяльник - приятный бонус когда нужно что-то припаять а электричества нет или розетка очень далеко. Ещё у него есть хорошая насадка нож. им очень удобно резать капроновые нити - концы получаются сразу подалвленными и не распускаются.