Couple Suggestions

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
mystadio
Prole
Posts: 8
Joined: Thu Sep 18, 2008 8:00 pm

Couple Suggestions

Post by mystadio » Mon Oct 13, 2008 5:06 am

Hey, I've been messing a lot with LÖVE and I have a couple suggestions:

Add a file browser: it would popup a file browser window that allow the user to select a file. This function should have at least a filter parameter ( "*.map" ) and another one for the file access mode (read or save). This parameter is for security: it would allow this file to be opened only for either reading OR saving purpose. This function has to return the path and the filename or nil if the user cancels. It would also add the selected filename to an "approved file list". We would then be able to include/require/open the file.

Add binary operators: at least 2 functions... something like "love.bit.and(value1, value2)" and "love.bit.or(value1, value2)". These functions would have their registered C functions that should be like this:

Code: Select all

// love.bit.and
static int love_bit_and(lua_State *L)
{
	int n = lua_gettop(L);

	if(n < 1 || !lua_isnumber(L, 1))
		luaL_typerror(L, 1, "number");

	if(n < 2 || !lua_isnumber(L, 2))
		luaL_typerror(L, 2, "number");

	lua_pushnumber(L, int(lua_tointeger(L, 1)) & int(lua_tointeger(L, 2))); // for the OR function, replace & by |
	return 1;
}
One last suggestion is to add backward compatibility: in the conf.lua file we specify a LÖVE version. When registering C functions, you should register only the functions that were available to that version (including now deprecated ones) and also register them in a way that the parameters and return values are what they were for that version.

I think my two first suggestions are the ones that are more important, the last one would just be a cool feature to allow us to play older games.

Thanks for reading and grëät work guys!
Josh

User avatar
rude
Administrator
Posts: 1051
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Couple Suggestions

Post by rude » Mon Oct 13, 2008 8:25 pm

Hey.
  • File browser: That's a good idea. I hadn't though of that. It would, however, require some sort of GUI-library, and I want to avoid such dependencies at all cost.
  • Binary operators: LuaBit isn't good enough for you? I'm not going to prioritize this, buf if you want to create love.bit in C, I'll be happy to include it.
  • Backward compatibility: That sounds very cool in theory, but we have nowhere near that much control of exposed functions (most of the wrapper code is SWIG'd).
^_^

mystadio
Prole
Posts: 8
Joined: Thu Sep 18, 2008 8:00 pm

Re: Couple Suggestions

Post by mystadio » Wed Oct 15, 2008 5:35 am

File browser: There's no need to use the "official" file browser provided by the OS. It could be done inside the game.
Here is what an idea of a way to do it: when calling the function love.filesystem.browse (just an example) the LÖVE engine would either hide or display a transparent gray overlay to make a disabled effect and draw a simple file browser over the fixed background image. That file browser should only use "ls"/"dir"/ etc. command to reach the desired file.
Also, the programmer could personalize the file browser box by setting its border color, background color/image, etc.

Binary operators: I took a look at LuaBit's code and it's really well done for a lua script. But the main issue is that it is written in lua... Bit manipulation is not easily done using only lua (they have to store each bits in a table and than apply the operator over 2 tables). It is slower than calling one C function that doesn't a really simple and native operation.
Last edited by mystadio on Wed Oct 15, 2008 5:54 am, edited 1 time in total.

mystadio
Prole
Posts: 8
Joined: Thu Sep 18, 2008 8:00 pm

Re: Couple Suggestions

Post by mystadio » Wed Oct 15, 2008 5:46 am

You should also add a link on the top left image to go back to the homepage while in the doc. I hate having to scroll down to the bottom of the page to click the small "Visit homepage" link.

User avatar
cag
Citizen
Posts: 65
Joined: Sun Jun 29, 2008 5:09 am

Re: Couple Suggestions

Post by cag » Wed Oct 15, 2008 4:39 pm

Well, here's my thoughts on the file browser: it's a very high-level operation, so introducing it in the API would be a bit like giving the API a trojan horse (in the classical Trojan War sense).
As of right now, LOVE is designed as a game engine that gives you the lower-level tools to make your own higher-level tools. Notice the excellent LOVE console was coded entirely in lua/love, and it works pretty awesomely.
Making a bona-fide file browser would no doubt cause a rather large inconsistency in the API, given every other operation is well defined, relatively small, and in it's own little module. That produces the possibility that people would want more such module-mixing high-level functions in the API, so poor LOVE devs would have to keep up with developing those things instead of spending time slowly improving LOVE.

The binary thing is ok to me, though personally, I'd probably never end up using any of these functions anyways. Because I'm lazy, and LOVE devs are, um...
Well, apparently they are crazy. But I don't think they've found a pressing need to use binary operators yet. Perhaps an argument might prove me wrong?

Anyways, I don't want to entirely discount the file operations notion. Perhaps LOVE devs should consider adding some sort of command line/config option to allow the use of lua's native file operations? Because that way, tool devs can code a LOVE file browser, and game devs could just choose not to use the extended file functionality in their game. Or thoughts... actually this may have been suggested before by somebody else.

surtic
Citizen
Posts: 74
Joined: Sat Jul 12, 2008 12:18 am

Re: Couple Suggestions

Post by surtic » Wed Oct 15, 2008 7:13 pm

I quite like the simplicity of clicking on a .love attachment and running it without wondering which files are going to be overwritten this time (or read and sent over the net using LuaSocket...)

Of course, we have many programs that write to files and we don't expect them to ask "are you sure?" before every file operation. It's just not something I'd expect from a game - having it sandboxed is actually a good thing.

I can imagine a game distribution system (as was discussed before in a different thread), where people can download (casual) games and just have a go. As hobby games they're not going to go through any strict examination, and it would be nice to know that the games can't actually harm the computer.

mystadio
Prole
Posts: 8
Joined: Thu Sep 18, 2008 8:00 pm

Re: Couple Suggestions

Post by mystadio » Wed Oct 15, 2008 9:06 pm

The goal of the file browser is to let the user choose which files the program can use. The program will only have access to files selected by the user (if any) and won't be able to overwrite a file which has been selected in an "open file...".

Here is an example:

Code: Select all

local filepath, filename = love.filesystem.filebrowser("*.map", love.fileaccess_read);
if not filepath then
  -- user canceled
else
  -- open the file, read it and load the map.
end
The different access mode would be:
  • love.fileaccess_read: the programmer can only open the file for reading purpose.
  • love.fileaccess_save: the programmer can only open the file for writing purpose.
  • love.fileaccess_all: the programmer can open the file for reading and writing purpose.
The access mode requested for the file would be displayed in the file browser title to let the user know the program's intention. ("Open file...", "Save as...", etc)

For even more security, the love.filesystem.filebrowser function would return only a fileId (to hide the filepath) and the programmer would have to open a file using the fileId as a parameter instead of the filename .. filepath.

User avatar
rasjani
Prole
Posts: 22
Joined: Sun Sep 21, 2008 12:38 pm
Location: Finland
Contact:

Re: Couple Suggestions

Post by rasjani » Thu Oct 16, 2008 7:44 am

Like few people mentioned allready, i dont see any reason why such feature (filebrowser) should be incorporated into love itself. Infact, for image/pr purposes i'd suggest against such feature. Love should be as "hidden" as much as possible for "serious" people to consider it as a viable development/deployment platform..

However, it would nice if there would be some sort of cooperation that would produce base widgets that could lead to such highlevel functionality to be implemented.. One of the reasons why python/perl have been successfull is the 3rd party libraries and central repositories build them and i dont see why we wouldn't be able to do the same with love/lua ..

surtic
Citizen
Posts: 74
Joined: Sat Jul 12, 2008 12:18 am

Re: Couple Suggestions

Post by surtic » Thu Oct 16, 2008 5:25 pm

I was responding more to cag, really.

There's a problem here: on the one hand a file browser doesn't sounds like a feature consistent with the rest of the API. On the other hand, allowing developers to write such a feature means that there's some way to load/save files (even if has to be enabled in the config file), which is dangerous.

Personally I don't see any way out of it except for writing tools in another environment (maybe with a LÖVE library that provides the interaction side). I don't think love.exe as it is distributed today should become a "dangerous" application just to allow people to write tools. However, it's not up to me, really. I can only share my opinion that so far I haven't been reluctant to open .love files, and I like it that way.

User avatar
rude
Administrator
Posts: 1051
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Couple Suggestions

Post by rude » Thu Oct 16, 2008 5:43 pm

cag wrote:Making a bona-fide file browser would no doubt cause a rather large inconsistency in the API, given every other operation is well defined, relatively small, and in it's own little module. That produces the possibility that people would want more such module-mixing high-level functions in the API, so poor LOVE devs would have to keep up with developing those things instead of spending time slowly improving LOVE.
You're pretty much spot on here, cag. It would involve mixing graphics, filesystem and input internally, which should be avoided if possible.
surtic wrote:I can only share my opinion that so far I haven't been reluctant to open .love files, and I like it that way.
*Ehehehe*, yeah ... ^.^)'' about that ... the io library is still available. You all knew that, right? We've planned to remove it several times, but Mr. Strange keeps stopping us with his clever arguments and doomsday predictions.

Post Reply

Who is online

Users browsing this forum: AlexYeCu and 2 guests