love2d / love Goto Github PK

Original report by Luiji Maryo (Bitbucket: luiji, GitHub: luiji).

We should be able to detect when the mouse moves so that we can implement hover-over items.

function love.mousemove (x, y)
  if 50 < x < 100 and 50 < y < 20 then
    MyMenuItem::hoverover ()
  end
end

Original report by Linus (Bitbucket: thelinx, GitHub: thelinx).

Original report by Robin Wellner (Bitbucket: gvx, GitHub: gvx).

In love-hg, latest revision, letters are displayed as boxes, with the same proportions as the letters would be (some sort of bounding boxes).

This happens with every .love, and even when passing a wrongly-packages .love.

For some reason, with the font Space uses, the u and n display normally, but all the other characters are boxes.

Original report by Bill Meltsner (Bitbucket: bmelts, GitHub: bmelts).

There are known issues with WAV playback in LÖVE as of 0.6.2, because we use libmodplug for WAV decoding and it doesn't seem to really work all that well. I don't know where the fault lies in this case, but libmodplug is definitely much better suited as a tracker player.

I propose we switch to another library for WAV playback. libaudiofile looks promising (and adds AIFF support) but doesn't look to be able to read from memory; I'm not sure how to do that with libsndfile either, plus libsndfile has issues with compiling Universal binaries on Mac OS X. Anyone who can come up with any alternatives, please suggest them.

Original report by rmn_rmn (Bitbucket: rmn_rmn, ).

Hello,
I face strange behavior of love.audio while playing audio files: when I use the keyword "static", for instance,

#!lua
src1=love.audio.newSource("sample.ogg","static")
love.audio.play(src1)

everything is ok, but without "static" song refuses to run after first launch. After changing song it plays for the first time and then stuck again. I tried both .ogg and .mp3 with the same results.
My OS is Ubuntu 10.04, LOVE v.0.6.2, Lua 5.1.4

Original report by Luiji Maryo (Bitbucket: luiji, GitHub: luiji).

I think it would make more sense to replace love.filesystem.setIdentity with an identity propery in conf.lua.

function love.conf(config)
    config.identity = "myuniqueidentity"
end

I think this would be more fitting for a property that is only to be set once during the execution of the program.

Original report by Luiji Maryo (Bitbucket: luiji, GitHub: luiji).

Currently LOVE can only detect button clicks, but not hat movement. This makes it so targeting most modern joysticks really hard.

Original report by Mark Thompson (Bitbucket: theburrito, GitHub: theburrito).

Make functions such as love.physics.newPolygonShape return whether or not it succeeded, rather than ignoring failures or having popup error messages.

Original report by Robin Wellner (Bitbucket: gvx, GitHub: gvx).

When LÖVE can't set the correct video mode, it silently rolls over and dies.

Not very good, considering this could happen in a correctly written game, simply because some gamer didn't have a fancy enough graphics card or whatever.

FSAA is the worst offender.

Possible solution: check before setting video mode. If it doesn't work, do the sensible thing and pick the closest one (and auto-disable FSAA, in many cases).

Original report by Linus (Bitbucket: thelinx, GitHub: thelinx).

The LoveUpdate-powered version of LoveSpin (1.2) fails to download the large files (pictures and bgm) on Windows, but works flawlessly on Linux and Mac.

The files are downloaded with http.request and a ltn12 file handle sink.

For reference:
http://github.com/TheLinx/LoveUpdate/blob/master/main.lua#L92 to line 97 is the part that's failing on Windows.

Original report by Robin Wellner (Bitbucket: gvx, GitHub: gvx).

Like the title says. It's implemented, but not exposed.

Original report by Danny Fritz (Bitbucket: dannyfritz, GitHub: dannyfritz).

Be able to change the playback speed of a midi file. Good for "time almost up" music without audio file duplication.

Original report by Anonymous.

Love shows white boxes instead of images

Original report by Parke Bostrom (Bitbucket: parke, GitHub: parke).

./configure generates a faulty src/Makefile on Ubuntu 10.04.

Specifically, src/Makefile's LIBS variable is missing the following:

-lFLAC -lFLAC++

(Or perhaps only one of them is needed, I haven't tested that.)

As a result, make generates 40 or so "undefined reference" errors when trying to link love.

For example:
./modules/sound/lullaby/FLACDecoder.o: In function ~FLACDecoder': /home/hack/love/love-20100303-db7cd0682883/src/modules/sound/lullaby/FLACDecoder.cpp:47: undefined reference to FLAC::Decoder::Stream::finish()'

Adding "-lFLAC -lFLAC++" to LIBS allows love to link successfully.

Original report by Luiji Maryo (Bitbucket: luiji, GitHub: luiji).

In older versions LÖVE used to say "no game", which was highly explanatory as to the fact LÖVE only runs games. Now, "tank you" has caused many users to inquire as to why LÖVE "does not work". I suggest that the next version reaquire the simple "no game" message, but keep on using stuff like the tank.

Original report by Anonymous.

When I do Image:setFilter('nearest', 'nearest') and then call love.graphics.setMode the image filters are reset to 'linear'. Now that ought to be a bug.

Original report by Anonymous.

(Windows XP)

Starting up LOVE will set the current working directory returned with love.filesystem.getWorkingDirectory() to the same as the user directory, effectively making the actual working directory (where LOVE / the game is) unreachable unless you know the path.

Example, starting LOVE from F:\LOVE\ with F:\LOVE\Test as the "game":

CurrentDir: C:/Documents and Settings/Username

AppdataDir: C:/Documents and Settings/Username/Application Data

SaveDir: C:/Documents and Settings/Username/Application Data/LOVE/test

UserDir: C:\Documents and Settings\Username\

Original report by FelipeBudinich (Bitbucket: FelipeBudinich, GitHub: FelipeBudinich).

It would be pretty nice if we could get the user's desktop resolution this way (or something like that):

t.screen.width = "desktop"
t.screen.height = "desktop"

I propose that we call SDL_GetVideoInfo before calling SDL_SetVideoMode, that way it gives the current desktop values.

This way, we could failproof the fullscreen mode, (it would fail only if the user is using a dual or triple monitor setup, but that is an SDL shortcoming), and also we could easily letterbox our games if we don't want stretching.

Original report by Anonymous.

offtopic - site
http://love2d.org/
is down

Original report by Anonymous.

love.draw()

mousem = 400 - love.mouse.getX();
love.mouse.setPosition(400, 300);
love.graphics.print("Movement: ".. mousem .. " - getX: ".. love.mouse.getX(), 10, 590);

end;

This will result in some pretty bizarre effects (at least under Windows) -- the cursor will move, but it acts as if the mouse isn't moving at all 80% of the time, leading to very sporadic and prone-to-failure movement tests.

As there's no way to lock the mouse somewhere and get the delta, this kind of makes keeping it positioned in a way that movement in any direction is possible somewhat difficult.

Original report by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

We definitely need framebuffer objects, and we should look at the link below when implementing it, might be a good starting point.

http://love2d.org/forums/viewtopic.php?f=3&t=1616

EDIT: Rephrase, I'm talking about FBOs

Original report by Anonymous.

Exactly what the title says: Vista's Data Execution Prevention halts LOVE engine from running, which prevents those who don't have admin access from using the software, and is inconvenient (and a little unnerving!) for those of us who do have admin access.

Plus, I'm always a little leery about anything that triggers antivirus measures, but doesn't explain why that happens...

Original report by Anonymous.

Reported on the old tracker, but I don't know if it ever got fixed. Spritebatches are unaffected by just about every global graphics modifier I've tried.

Original report by Anonymous.

http://en.wikipedia.org/wiki/Blend_modes

Specifically subtract so I can clear the screen with alpha (motion blur) and not leave artefacts, but others would allow for some really lovely effects.

Original report by Luiji Maryo (Bitbucket: luiji, GitHub: luiji).

It would be awesome if we could do something like:

-- MyGraphicDown will contain MyGraphic upside-down (90 degree flip)
love.graphics.rotateBlit(MyGraphic, MyGraphicDown, 90)

This would be very useful to dynamically create more images from a limited set at load time, so that transform blits won't have to be used since they are slower (due to one transform every time).

I'd be happy to implement functionality like this for you as soon as I finish reading the Mercurial manual.

Original report by arquivista (Bitbucket: arquivista, ).

The inclusion of tutorial wikis sources and resources in distribution could help a lot in Love learning.

Original report by Anonymous.

Be able to change the playback speed of a sound source. Good for "time almost up" music without audio file duplication. (Reposting)

Original report by Anonymous.

Handling the border/chrome of a window, and maybe some limited access to spawning new viewports, or message boxes.

Original report by Anonymous.

it would be great to be able to use the distribution's box2d ( currently 2.1.x ), so its necessary to port löve to be able to work with the new api and then kick the bundled box2d out.
thanks already!

Original report by Luiji Maryo (Bitbucket: luiji, GitHub: luiji).

So, I downloaded PASSION and PASSION-DEMOS from Kikito's GitHub repositories. As supposed to copying PASSION three times, I created symbolic links in each game to the PASSION Git checkout. This should have theoretically worked, however:

LOVE doesn't love symbolic links.

LOVE doesn't seem to be able to follow symbolic links, leading to the problem that LOVE says that passion/init.lua doesn't exist, even though there is a symbolic link to it.

This problem would probably effect all Unix-based operating systems, including Linux, Mac OS X, and the BSDs.

Original report by Aaron Isaksen (Bitbucket: aisaksen, GitHub: aisaksen).

In Love 0.6.2 (running on Mac OSX): This works:

	bodies[1] = love.physics.newBody(world, 100, 100, 1, 0)
	shapes[1] = love.physics.newRectangleShape(bodies[1], 0, 0, 10, 10)
	bodies[1]:setFixedRotation(true)
	bodies[1]:setMassFromShapes()

But swapping the order of setFixedRotation and setMassFromShapes doesn't work:

	bodies[1] = love.physics.newBody(world, 100, 100, 1, 0)
	shapes[1] = love.physics.newRectangleShape(bodies[1], 0, 0, 10, 10)
	bodies[1]:setMassFromShapes()
	bodies[1]:setFixedRotation(true)

In the second case, its as if setFixedRotation is never called.

Original report by Andrzej Giniewicz (Bitbucket: giniu, GitHub: giniu).

I was just browsing trough changelog, and though - "hey, next release will be quite something", then "hmm... how long it was from last release?" but I had to travel around the page to find some details on it - so - how about adding simple "(released [date])" to each "Love [version]" line in changelog (it would also tell people who are browsing, that 0.7 or whatever will be current isn't released yet, because it would lack the date near the heading line)? It would be nice adition I think for people browsing the changelog - but I'd say it's extremely low priority thing :)

Original report by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

Because the world doesn't shrink or grow when you change the scale using setMeter.

Original report by Pygy (Bitbucket: Pygy, GitHub: Pygy).

These modules are really small and they all fulfill a similar role.

I think it would make sense to merge them all.

I haven't checked the font API, but for sound and images, they could almost be merged as is. audio.newDecoder would have to be renamed data.newSoundDecoder, and that's all.

No worries for backward compatibility. If you need it, you can always alias love.data to love.image/sound (plus a special case for newDecoder), and it will work as in 0.6.2.

Original report by Jasoco (Bitbucket: Jasoco, GitHub: Jasoco).

I think it would be neat if we could capture what happens when you click an option in the menubar. Like the Quit, Minimize, etc. These are OS-related menus, but should still let us decide what happens when we click them.

For instance Quit. On OS X it's under the love menu, on Windows under the icon in the title bar and is called "Close". Right now, it just quits the app outright. Shouldn't it be capturable? So we can show "Are you sure?" dialogs and save the game first, etc.

And Minimize. Well, it'd be smarter if we could detect when the game window was minimized. In case we want to pause the action so it doesn't keep playing in the background.

I guess I'm proposing some functions like love.menuOnQuit(), love.menuOnMinimize(), love.menuOnRestore(), (To go with Minimize) and on OS X, love.menuOnHide() and love.menuOnShow().

Original report by Robin Wellner (Bitbucket: gvx, GitHub: gvx).

The current syntax for conf.lua seems a bit over the top:

function love.conf(t)
    t.title = "My awesome game"
    t.screen.width = 400
    -- etc.
end

Wouldn't it be better (considering Lua's origins as a configuration language, to make t the environment for conf.lua, so one can use:

title = "My awesome game"
screen.width = 400
-- etc.

It also makes it a bit easier to generate a write-dir version of conf.lua, so users can change the default resolution in-game, etc.

I'll write a patch for this if necessary.

Original report by Andrzej Giniewicz (Bitbucket: giniu, GitHub: giniu).

I was looking around and made simple patch. It is I think easiest solution that does not touch api (i.e., without adding function to filesystem that reads file and returns FileData instead of its content like filesystem.read). I tested and it seems to be working, i.e., now

#!lua

  t = love.thread.newThread("thread name", love.filesystem.newFileData(love.filesystem.read("filename.lua")))

and

#!lua

  t = love.thread.newThread("thread name", "filename.lua")

gives same result, which seems intended (looking at string clause that was already there).

Original report by Anonymous.

Be able to record mic input to SoundData and also be able to probe live information from mic input (dB and frequency in mono or stereo).

Original report by Anonymous.

http://love2d.org/wiki/love.image.newEncodedImageData

It should really support more than just bmp and tga because they're both annoyingly big.
How about png, jpg, png, gif or at least png?

Like, I'm trying to take screenshots every now and then because I believe it'll be nice for the user to look at them, but I don't want to store hundreds of potential megabytes in a folder the user will maybe never know exists.

Original report by Danny Fritz (Bitbucket: dannyfritz, GitHub: dannyfritz).

Currently when I put a utf-8 string such as さびしい it displays "????" in the window title.

I would like Japanese character support in LOVE.

Bonus: I don't know any of the implications, but utf-8 strings everywhere in LOVE would be grand.

Original report by Luiji Maryo (Bitbucket: luiji, GitHub: luiji).

How about a callback called love.quit that is called after the "q" event? I don't know of a way to handle such an event without creating my own love.run at the moment, and I'd prefer to use the default love.run so that when LOVE upgrades I get the latest and best love.run loop.

It appears that overwriting love.handlers would not work, since the "q" event quits before love.handlers can be called.

I need this functionallity for a game engine I'm working on to automatically save the game settings on close.

-- Example of how it would work on the game developer's side.
function love.quit()
  -- Due some stuff.
  print "BOO!  Quitter."
end



-- Example of how love.run would look:
-- ... love.run code ...
if e == "q" then
  if love.audio then
    love.audio.stop()
  end
  -- <<< Added Code >>>
  love.quit()
  -- <<< End of Added Code >>>
  return
end
-- ... rest of love.run code ...

Also, why I'm here, any idea when the next release will be out?

On that note of off-topicing, what's the difference between an enhancement and a proposal?

Original report by Anonymous.

I saw in the source code of love that e.g. w_Source_setPosition(lua_State * L) is already written in wrap_Source(modules\audio) but is not included in the luaL_Reg functions[] at the bottom. Why are these not functions registered?

This would be a great feature to have since the setPosition/setOrientation/setVelocity for the listener can already be used(example http://love2d.org/wiki/love.audio.setPosition) and this would make no sense without the corresponding functions for the sources

Original report by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

Yeah, that, we need to fix that, probably some issue with subclassing and the infamous type enum.

Original report by Danny Fritz (Bitbucket: dannyfritz, GitHub: dannyfritz).

The OSX universal binary files should be availible in such a way Windows and Linux users can also read. This is so they can provide OSX distributions of their game without an OSX computer at hand.

It was extremely easy to do once I had the OSX binary in a readable format. http://love2d.org/forums/viewtopic.php?f=4&t=1666&start=20#p16678

Original report by Sean Donno (Bitbucket: [Sean Donnellan](https://bitbucket.org/Sean Donnellan), ).

This is a feature request for a way to set the icon on the window.

I propose love.graphics.setIcon( image )

Like SDL_WM_SetIcon in SDL.

Reason for it is makes identifying your LOVE game in Task Switcher (Alt+Tab) easier and nicer.

Original report by DMB (Bitbucket: textmode, GitHub: textmode).

The default PRNGs supplied as part of the stdlib (and thus, the one lua exposes in math.*) are implementation defined (aka, no assurance of consistency between systems), and usually rubbish to boot.

While games are generally non-critical, the tendency of games to both make the results of individual random numbers apparent to the user, and the tendency to make randomised decisions based on other randomised decisions tends to exasperate and highlight the flaws in the PRNGs they use, often resulting in statistical aberrations up to and including (in rare cases) the //effective removal// of decision branches due to the mathematical impossibility of the PRNG in generating the required sequence of numbers! +

While PRNGs //can// be implemented in pure lua, its often a tedious process beyond the skills of the lovers who actually need them, while producing a PRNG that runs far slower than the native rand. ++

Adding a decent PRNG implementation to Love would improve both the quality and inter-platform consistency of the psudorandom numbers available to lovers.

Exactly which PRNG you add I'm not overly concerned with. While LHF has a mtwister implementation on his site, and certainly its a safe and common choice, Wikipedia suggests there might be better PRNGs with similar or superior performance.

^^ + For a time there, it seems like a right-of-passage for a rogue-like project to find just such a bug.

^^ ++ One pure-lua PRNG I tried was about //10x// slower. and supposedly it was one of the faster ones.

Original report by An00biS (Bitbucket: An00biS, GitHub: An00biS).

Hello.

I just tried to install LOVE from source tarball (love-20100303-db7cd0682883) on my Fedora13. However, the configure script stopped, telling me:

checking for library containing FLAC__metadata_chain_new... no
configure: error: Can't LÖVE without FLAC++

This happened though everything is installed as it should be.

Installed Packages
flac.i686                      1.2.1-6.fc12    @rawhide/$releasever 
flac-devel.i686                1.2.1-6.fc12    @fedora/12
---------------------------------------------------------------
[an00bis@hpnx6310 lib]$ ll | grep FLAC++
lrwxrwxrwx.  1 root root       18 Mar 12 23:13 libFLAC++.so -> libFLAC++.so.6.2.0
lrwxrwxrwx.  1 root root       18 Nov  9  2009 libFLAC++.so.6 -> libFLAC++.so.6.2.0
-rwxr-xr-x.  1 root root   101384 Jul 25  2009 libFLAC++.so.6.2.0

I assume this is a bug in the config script ;-)

Original report by Anonymous.

There are //many// times when LÖVE decides to decode audio for about half a second, and then roll over and die. Literally, of course.

Original report by arquivista (Bitbucket: arquivista, ).

This tutorial should have the required demo PNG files (tile0.png ... tile3.png) for speedy learning.

Original report by Luiji Maryo (Bitbucket: luiji, GitHub: luiji).

Joystick button mappings are so different, that it is fairly hard to create a globally compatible joystick system, so a game programmer would usually have to resort to adding a configuration system in-game. It would be awesome if LOVE provided a dialog that could help you map your joystick more appropriately if a game gets the initial mapping wrong.