LÖVE

Is there a central place in Löve's source code where I can enable/disable the inclusion of modules? Or should I just not include the source code of the files from those modules I don't want?

Depending on your platform, it's either disabling the modules in the project file or passing the right flags to the configure script.

Keep in mind some modules depend on other modules, though.

You'll probably also have to prevent love from trying to require the module when it boots up, by commenting it out of this list: https://bitbucket.org/rude/love/src/45b ... ult#cl-398 (and then regenerating boot.lua.h by using the auto.lua script.)

Here's a tough (probably?) question: When I try to compile Löve (love-mobile-common to be precise) using Visual Studio's built-in compiler, I get one error in particular that bothers me: in src/modules/graphics/opengl/Graphics.cpp, there's a line
which throws an error, because the compiler thinks an argument of type "void (__stdcall *) (gladd::GLenum source, glad::GLenum type, glag::GLuint id, glad::GLenum severity, glad::GLsizei, const glad::GLchar *msg, const glad::GLvoid *)" is incompatible with parameter of type "glad::GLDEBUGPROC".

For a couple of days now, I've tried everything I can think of to get it to accept that debugCB is indeed a glad::GLDEBUGPROC-function, but nothing seems to work.

Does this (and other parts of Löve's source code) use something that's specific to CMake? I could try to compile it with CMake but it feels strange that this piece of C++ code doesn't work with this compiler. Any ideas of things I can try would be highly appreciated

On a side note, I just want to mention that I've got all of Löve's important dependencies (ANGLE, SDL, FreeType, OpenAL, Vorbis/libogg, PhysFS and zlib) compiled and working, so I'm getting closer

T-Bone wrote:the compiler thinks an argument of type "void (__stdcall *) (gladd::GLenum source, glad::GLenum type, glag::GLuint id, glad::GLenum severity, glad::GLsizei, const glad::GLchar *msg, const glad::GLvoid *)" is incompatible with parameter of type "glad::GLDEBUGPROC".

That's kind of my bad (and kind of the fault of GLAD), I just pushed a commit which should hopefully fix it: https://bitbucket.org/bartbes/love-expe ... ts/642d605

T-Bone wrote: Does this (and other parts of Löve's source code) use something that's specific to CMake? I could try to compile it with CMake but it feels strange that this piece of C++ code doesn't work with this compiler. Any ideas of things I can try would be highly appreciated

CMake isn't a compiler, it's a build system, and for windows it generates visual studio project files.

T-Bone wrote: On a side note, I just want to mention that I've got all of Löve's important dependencies (ANGLE, SDL, FreeType, OpenAL, Vorbis/libogg, PhysFS and zlib) compiled and working, so I'm getting closer

This is exactly what megasource is supposed to do.

slime wrote:That's kind of my bad (and kind of the fault of GLAD)

I was going to suggest the calling convention, but when I googled for the definition of GLDEBUGPROC I found a header with APIENTRY in it, so I discarded that idea...

bartbes wrote: stuff

Thanks for clearing things up! I misunderstood what CMake is. I assumed I couldn't rely on megasource, since not all of those libraries worked for WinRT (like PhysFS, I had to write the WinRT backend myself, and other like vorbis already had WinRT versions available written by others). But in hindsight, relying on megasource as a starting point would at least helped organizing it a bit.

slime wrote:stuff

I can confirmed that it fixed it! Thanks And now, even if my project fails, I will at least have contributed to Löve by identifying an issue.


I also have another question: Several of Löve's .cpp files share the same name. This makes Visual Studio puke, since they're writing to the same .obj-files. I've tried specifying for each conflict that one of them should write to another obj-file (like "Aduio2.obj" instead of "Audio.obj"), which seems to work... For the most part. The only problem with this seems to be that src/love.cpp and src/modules/love/love.cpp not only share name, but also share some stuff they define (love::VERSION, love::VERSION_CODENAME and love::VERSION_COMPATABILITY).

I did notice that src/love.cpp has all its code within an "ifdef LOVE_BUILD_EXE". Shouldn't then src/modules/love/love.cpp have an "ifndef LOVE_BUILD_EXE" around the conflicting code?

Basically what I'm really wondering if there's a clean solution to this that I'm not aware of. I assume that CMake builds a Visual Studio Project that solves this in a good way, but I can't get CMake to make one for me to look at. If somebody has a Löve Visual Studio solution lying around (like in a .zip or something) I would love to look at it.

I've actually gotten LöveFTW to compile and run now! Crazy

...but it instantly crashes, and shows the familiar blue error screen. Only problem: the error text doesn't show up. And since Visual Studio doesn't show standard console output (seriously?), it took me quite a lot of debugging to find out the error text: "Cannot link shader program object: Precisions for uniform 'TransformMatrix' differ between vertex and fragment shaders". There could be some difference in GLSL for ANGLE and GLSL for regular OpenGL ES... So I wonder: Are any shaders used internally when displaying the no-game screen? If so, where is their source code? Can they be modified? And would compilation errors of said shaders prevent the display of error messages?

T-Bone wrote:"Cannot link shader program object: Precisions for uniform 'TransformMatrix' differ between vertex and fragment shaders".

I just pushed a commit to the 0.9.2 GLES / mobile-common branches (and to the main 0.10.0 code) that should hopefully fix that.

T-Bone wrote:Are any shaders used internally when displaying the no-game screen? If so, where is their source code? Can they be modified? And would compilation errors of said shaders prevent the display of error messages?

Yeah, OpenGL ES 2+ (and desktop OpenGL 3+) require an active shader in order to draw anything, so the GLES love code (and 0.10.0+) uses a 'default' shader if no other shader is active.

It's specified here (for the 0.9.2 GLES code): https://bitbucket.org/bartbes/love-expe ... mon#cl-294
And here (for 0.10.0): https://bitbucket.org/rude/love/src/972 ... ult#cl-234

Also in those files is the code that gets put around the shader code you specify in love.graphics.newShader, to create working GLSL shader stages.

slime wrote:

T-Bone wrote:"Cannot link shader program object: Precisions for uniform 'TransformMatrix' differ between vertex and fragment shaders".

I just pushed a commit to the 0.9.2 GLES / mobile-common branches (and to the main 0.10.0 code) that should hopefully fix that.

Yes, that fixed it! Thanks!