Add Error message when glfwInit/glfwCreateWindow fail

[deccer]

Check all Application.cpps and fix the following.

Replace

    if (!glfwInit())
    {
        return false;
    }

with

    if (!glfwInit())
    {
        std::cout << "GLFW: Unable to initialize GLFW\n";
        return false;
    }

and

    if (_window == nullptr)
    {
        Cleanup();
        return false;
    }

with

    if (_window == nullptr)
    {
        std::cout << "GLFW: Unable to create a window\n";
        Cleanup();
        return false;
    }

[spnda]

Seeing as Application.hpp and Application.cpp are the same in each project and the class it defines is purely virtual, wouldn't it make more sense to create a extra VC++ project that bundles these files so that they don't have to be copy & pasted and things like this can be added in a single place? If you agree @deccer, I'll happily open a PR in a second to create a Shared target.

[deccer]

We decided against that and just go with individual files. We might have to add functionality into Application further down the road

[deccer]

Hmm or maybe, why not. I was trying to think about what might be added down the road... Some time ago i thought it might be the imgui layer, but given its clusterfucky nature its not as trivial as.

ActualChapterApp |> ImGuiApplication |> Application

Would you create a Framework.vcxproj then? Which lives in Cpp/Framework

[spnda]

The implementation is purely virtual so one could create another AdvancedApplication class that overrides a lot of the implementation. And even then, the code can still be modified at any point and isn't set in stone at any time.

class Application {
protected:
    virtual void Load();
};

class Implementation : public Application {
public: // Previously protected functions/members can even be made public.
    void Load() override;
};

void Implementation::Load() {
    // Do something new here.

    Application::Load(); // We can still call super here.
}

I think that most members of the current Application class should probably be made protected, so that overriding and modifying behavior is possible.

Copying & pasting the same file into each project seems like a unnecessary burden because nothing is set in stone and polymorphism can easily allow us to override and modify behavior of the original Application class. And I doubt any major changes have to be made for multiple chapters, and that instead only perhaps a single chapter needs a slight adjustment or addition, which could probably be added to the original Application class anyway. Seems like a premature jump to a bad solution for an issue that might not even ever happen.

And yes, I'd be happy to do that.

[deccer]

Ye the only impl is Run() and thats pretty much set in stone, there is no point in overriding that in ChapterApplication

[deccer]

But hang on a second you were hijacking this issue :D

This one is about the error output. Let me create a new one which Pulls Application out into a Framework project

[spnda]

Second issue I've hijacked today :D