Post-0.10.0 feature wishlist

[HDPLocust]

folder dialog box.

https://bitbucket.org/rude/love/issues/ ... g-function

I mean
love.filesystem.getDirectoryItems('global path') for custom folder dialog boxes,
love.graphics.newImage('global path') for load image, also music and other.

Now i use FFI (<dirent> lib) for folder listing,
and my fs-lib with standart io for loading images/music/fonts etc:

Code: Select all

	function fs:loadImage(p)
		assert(love.filesystem, 'LOVE2d method only')
		assert(love.image and love.graphics, 'Image and graphics modules required')
		self.assertion(p, 'string')
		local path = self:getPath(p)
		local formatList = {'png', 'tga'}
		assert(self.checkFormat(path, formatList), 'Available image formats: '..table.concat(formatList, ', ')..'.')	--check img format
		if not self.absCheck(p) then return love.graphics.newImage(p), 'success' end	--if path not global, load it directly
		local file = io.open(path, 'rb');
		if not file then
			return _, 'Image does not exists' 
		end
		local str = file:read('*a')	file:close()
		love.filesystem.write( 'tmpFile', str)					--copy file to temp
		local image = love.graphics.newImage('tmpFile')			--load img from temp
		os.remove(love.filesystem.getSaveDirectory()..'/tmpFile')	--remove temp
		return image, 'success'
	end

A lot of unnecessary operations: read, copy, delete and so on.

[Ref]

love.graphics.setMode was changed to love.window.setMode.
Was wondering why love.graphics:getWidth() etc wasn't changed to love.window:getWidth()?
Any plan for this to be changed for consistency?

[slime]

love.graphics.getWidth/getHeight/getDimensions get the size (currently always in pixels) of the graphics framebuffer inside the window. It may have a different coordinate system than what the window's dimensions are in, especially on retina/highdpi-capable screens.

You can use love.window.getMode to get the width and height of the window in its coordinate system, if you really need to.

There used to be a separate love.window.getWidth/getHeight/getDimensions, which returned the same values as love.graphics.getMode does, but they were removed because they could easily be misused since the graphics coordinate system is not the same as the window's coordinate system. So it's more consistent now than it was before.

[DavidOliveiraSilva]

I have searched in the forums for information about how to add ads to an mobile app (how to integrate the sdk from one of these services.. u know).
i made my game there is already a lot of downloads (13), and I receive a lot of e-mails (3) offering me to add their ads services (through a sdk). maybe my post is just useless, I am really lost. I just want some information. thank you

[Linkpy]

*take a shovel and dig into this post* Sorry for this.

Something useful can be to expose the transform matrix used in the C++ part of Love2D, like something like this :

Code: Select all

matrix = love.math.newMatrix( .. default values ..)
matrix:translate (X, Y)
matrix:scale (X, Y)
matrix:origin (X, Y)

-- Vector
local_x, local_y = matrix:toLocal(global_x, global_y)
-- and
global_x, global_y = matrix:toGlobal(local_x, local_y)

-- Graphics
-- Apply the matrix on the coordinate system
matrix:apply()
-- Do the reverse
matrix:unapply()

This can be very useful (mainly for scenegraph, for example) and more efficient as a Lua implementation (since all computation are done in C++).

[cval]

Having project with sometimes 100+ of particle effects drawn on screen simultaneously (along with other game logic calculations) i wish there will be some sort of ParticleSystem:bindToSpriteBatch(). So then instead of calling separate ParticleSystem:draw() for each emitter, i can bind a hundred of them and draw in one SpriteBatch:draw() call. ParticleSystem will only manipulate sprite data in that SpriteBatch it is bound to in its update call (e.g. instead of generating its own particles, it will use sprites in SpriteBatch it is bound to, and when it is bound to one, it will reserve a number of sprite ids for itself to manipulate).
Now, obviously both SpriteBatch and ParticleSystem must have same texture atlas (but ParticleSystem can have it's own quad set?) and latter must have buffer size less or equal to SpriteBatch's buffer size. And quite obvious that it puts limitations on draw order - you will not be able to draw emitters that are bound to one spritebatch on different layer level relatively to some other entities that you want to place inbetween them, but it's not important, for, say, drawing up to hundred of wall fire torches, for example.
And no, animation-rendered-to-canvas as a texture for a spritebatch is not an option. It doesn't give enough uniquieness to each emitter. I also mentioned a suggestion about emitter burst modes, where you can define how many particles will be emitted on each tick. That way it can generate few particles on all emitter area (AreaDistribution), for example, in one tick. Yes, it is kinda possible to do that by using emitter that flies around the level and emits stuff on each tick, but, you know...

[SiENcE]

I wished the löve2d framework had more convenient functionality to make commercial games.

I know that there is ffi and löve modules and löve can load dlls...but doing everything yourself takes a lot of time.

What löve need, in my opinion, to create more commercial games:
- maintained and updated plugin for Steam
- Ads integration for GoogleAds and iOSAdds
- a maintained packaging tool
- a maintained particle editor
- and ... maybe ... a 2d worldeditor like Overlap2D...but i know this is our of scope .

[Someguynamedpie]

Steam integration libraries being publicly released would be a breach of the steam partner agreement iirc.
And why would you need ads/particle editor/world editor for a commercial game? But on topic:
I'd love to see proper non-function required stencils; .10 came close but still requires functions:(

[SiENcE]

Steam integration libraries being publicly released would be a breach of the steam partner agreement iirc.

I do not aggree, a ffi sample integration is possible. It would also make steam publishing more easy.

You can't do everything on your own. A well made and maintained set of "tools" for löve would be "great". It's no need...and should not be in the engine...but i could support the popularity of Löve! It's a way too hard when you start with löve to find the right set of tools.

At least an official list of supported libs and tools for a dedicated Löve Version would be nice. Most stuff is outdated and for older löve version.

And why would you need ads/particle editor/world editor for a commercial game?

Why would you need ads in a commercial game? Just curious...but do you think you know what you are talking about?

Ads integration to earn money (commercial!) ?

A particle editor and world editor...maybe you want to create your game and don't want to first code this editors to start doing you game?

[Someguynamedpie]

Steam integration libraries being publicly released would be a breach of the steam partner agreement iirc.

I do not aggree, a ffi sample integration is possible. It would also make steam publishing more easy.

You can't do everything on your own. A well made and maintained set of "tools" for löve would be "great". It's no need...and should not be in the engine...but i could support the popularity of Löve! It's a way too hard when you start with löve to find the right set of tools.

At least an official list of supported libs and tools for a dedicated Löve Version would be nice. Most stuff is outdated and for older löve version.

Whether or not you agree with it doesn't make it not true. The NDA prevents distributing of the SDK (which would be pretty much whats delivered in an FFI implementation) to any non partners. Also, I don't consider a ad-supported free game to be commercial. If you want a particle editor/world editor, use external libraries for its out of scope of love to have included in it (as I have learned).