LÖVE

Awesome! Thanks for the hard work!

I pressed F5 to build and the build was ready before I could release the button. Holy shit, this is insanely fast!

Congrats! I've been waiting for this one for a long time!

Great work guys!

A little advice on compilation in windows.

You can avoid having "msvcr110.dll" in your folder in 2 ways.

1. Say to people that they should download Visual C++ Redistributable (i.e. this: http://www.microsoft.com/en-us/download ... x?id=40784). Which of course is a bad idea.

2. Compile Love in this way:

Set to Multi-Threaded (/MT flag) instead of Multi-Threaded DLL (/MD flag). Multithreaded DLL links the libs dynamically (i.e. the need for msvcr110.dll), but /MT links needed libs statically (no need for msvcr110.dll). Also make sure that all of the dependencies are compiled in the same way.

If you get "function already exists" errors (depends on a program) you can fix those by either putting /NODEFAULTLIB:MSVCRT or /NODEFAULTLIB:LIBCMT linker flags. I've been using /NODEFAULTLIB:MSVCRT and because of it I never have the need to bundle Visual C++ redistributable together with my Visual C++ application.

Thanks, but we don't want to statically link to the C runtime libraries on Windows I think.

"Also make sure that all of the dependencies are compiled in the same way." - LÖVE itself can be a dependency to another program (via love.dll), and/or a different Lua library (or SDL, etc.) can be used without recompiling everything.

Compiling with /MT won't magically link all of your other libraries statically. /MT will ONLY statically link windows C runtime libraries. Compiling other libraries with /MT flag will make them compatible with main program, because, even if you compile your program with an /MT flag, linking other libraries which are compiled with /MD flag will not remove the need for msvcr110.dll. :/

Well, it's all about preference. Myself, I like to have as small number of DLLs as I can (possibly zero).

arekusanda1 wrote:Compiling with /MT won't magically link all of your other libraries statically. /MT will ONLY statically link windows C runtime libraries.

Yeah, this isn't something we want.

The reason being, if my memory serves me, is that the dynamically linked lua then has to statically link to the runtime as well, and can't be replaced as easily. In particular I remember i/o failing if there was a mismatch, or even if they were both statically linked.

Lovely1 Thanks for the release!!

Thank you for the hard work !

My two cents though :
this post misses a GIF or static image of the no-game screen. They are always so lövely !

monsieur_h wrote:Thank you for the hard work !

My two cents though :
this post misses a GIF or static image of the no-game screen. They are always so lövely !

Take your pick...

Left: 30 frames, jerky framerate, smaller <1MB file size, 32 colors, 400x300
Right: 61 frames, smooth framerate, larger >1.7MB file size, 32 colors, 400x300

I am amazed at how perfectly it loops. Gotta love those sines and cosines.

Any hints as to why there was no instructions included in the no-game-screen?
"No game" is a step forward, but there has been a lot of discussion about whether to add more information (how to load a game, where to get games, links to the website, maybe even the vapor project etc) in the no-game-screen, but now the devs decided to only put in the no game animation. Why so?