LÖVE

anjo wrote:I'm going to leave the issue of source code encryption for the time being, because protecting source is something that's been talked about for a long time and no one's come up with a definitive solution...
...

2.3MB savings isn't terrible (though, again, whether you can (or should) actually remove the headers from some of the frameworks is dubious), but it's certainly not any sort of amazing LÖVE Lite

Oh, size is only a Mac issue? Are windows/linux distribution files so much smaller?

Thx for reply Anjo. My opinion is that is nice and very noble your effort of trying to keep to use the same file for run and for distribution however that also make things hard to you like the issues of encrypt and size. :/

IMHO would be nice a dedicated "compiler/maker" app that parse the code and would add only the really needed libraries (to avoid at least hello worlds and more basic coding with lot of size). About the PPC code inclusion that could be an option since usual Apple folks are usually people that upgrade a lot (I'm a long PC user and recent switcher but i feel them as usually "early adopters" that want always use last toy), PPC users share should be now very low. I can live with both issues (size in mac and no encryption) for now but i'd love to see someday at least a solution for encrypt code that i think is a bit of essential.

arquivista wrote:Oh, size is only a Mac issue? Are windows/linux distribution files so much smaller?

Those distributions only have to have binaries for one architecture, so yes.

Robin wrote:Those distributions only have to have binaries for one architecture, so yes.

Stop lying, linux has x86 and x64.

arquivista wrote:however that also make things hard to you like the issues of encrypt

That is not related to that, and it's not a priority at all, because after all we're all fans of open-source.
Actually, what we would prefer and actually see as a solution is instead of hiding your code, simply making it unusable with licenses (though we prefer usable code, obviously), another approach would be open-sourcing the code (in the license kind of way) and then use more restrictive copyright for the art.

bartbes wrote:

Robin wrote:Those distributions only have to have binaries for one architecture, so yes.

Stop lying, linux has x86 and x64.

I'm not. Those are separate distributions.

bartbes wrote:

arquivista wrote:however that also make things hard to you like the issues of encrypt

That is not related to that, and it's not a priority at all, because after all we're all fans of open-source.
Actually, what we would prefer and actually see as a solution is instead of hiding your code, simply making it unusable with licenses (though we prefer usable code, obviously), another approach would be open-sourcing the code (in the license kind of way) and then use more restrictive copyright for the art.

I think he meant to prevent spoilers. But no-one is “accidentally” going to read the contents of a ZIP file anyway, so it still doesn't matter.

Robin wrote:

bartbes wrote:

Robin wrote:Those distributions only have to have binaries for one architecture, so yes.

Stop lying, linux has x86 and x64.

I'm not. Those are separate distributions.

bartbes wrote:

arquivista wrote:however that also make things hard to you like the issues of encrypt

That is not related to that, and it's not a priority at all, because after all we're all fans of open-source.
Actually, what we would prefer and actually see as a solution is instead of hiding your code, simply making it unusable with licenses (though we prefer usable code, obviously), another approach would be open-sourcing the code (in the license kind of way) and then use more restrictive copyright for the art.

I think he meant to prevent spoilers. But no-one is “accidentally” going to read the contents of a ZIP file anyway, so it still doesn't matter.

I'm also a big fan of open-source but i have one (free) of my future projects that I don't want the source revelead since the objective of the game is learn how to play it (or die over and over, and yes even die more). So I'd not mind to do race cars, plataforms, shooters in source-code mode but hell no this special roguelike (that people will have to die more than usual) that the secret of the mechanics it's best asset and discovery the pleasure of the game. Also roguelilke players are the most geekier/tech kind of game users (and 75% of them probably coders) avaliable. Some have the ethics to not even save file backup cheating but rogues are so hard that usually people have to cheat in some way. Also it only needs one person to spoil a game launching his mechanics/secrets in web and easily kill the game. So that's why i really needed encrypting on this one.

arquivista wrote:I'm also a big fan of open-source but i have one (free) of my future projects that I don't want the source revelead since the objective of the game is learn how to play it (or die over and over, and yes even die more). So I'd not mind to do race cars, plataforms, shooters in source-code mode but hell no this special roguelike (that people will have to die more than usual) that the secret of the mechanics it's best asset and discovery the pleasure of the game. Also roguelilke players are the most geekier/tech kind of game users (and 75% of them probably coders) avaliable. Some have the ethics to not even save file backup cheating but rogues are so hard that usually people have to cheat in some way. Also it only needs one person to spoil a game launching his mechanics/secrets in web and easily kill the game. So that's why i really needed encrypting on this one.

The thing is, if you want them to be able to run your game, you need to give them both the encrypted code and the key to decrypting it. That's how encryption works: encrypted data + key = great success! Encrypted data + Null = utter failure! At best you may be able to make it a bit more work to get the source, but in the end, the only way to hide your source is to not distribute it at all.

nevon wrote: The thing is, if you want them to be able to run your game, you need to give them both the encrypted code and the key to decrypting it. That's how encryption works: encrypted data + key = great success! Encrypted data + Null = utter failure! At best you may be able to make it a bit more work to get the source, but in the end, the only way to hide your source is to not distribute it at all.

Yah, well, since Love isn't compiled it seem encrypting could be a real problem. I hoped to avoid Xcode and C++ doing Lua but seems I haven't another way since I never found a good way of doing Lua only code in Mac without mess with C++/command line compile. :/

What'd be cool is something that could read LOVE Lua files and then transforming them into pure machine code, which would solve the iPhone licensing problem. However, this would be impossibly hard work.
secret secret

Luiji wrote:What'd be cool is something that could read LOVE Lua files and then transforming them into pure machine code, which would solve the iPhone licensing problem. However, this would be impossibly hard work.
secret secret

Like LuaJit or LuaC?

Like neither. LuaC compiles the code into Lua bytecode, and LuaJIT only just-in-time compiles it. I mean something that could compile it the same way C code is compiled. This would be strenuous unless it turned out LuaJIT could compile the whole thing into a statically linked library or something totally awesome like that.

EDIT ADD: Ahhh! Dude! You messed up the [ small = 10 ] in my post! Now everybody's going to notice the small text! Now it's no fun!