0.11.0 Update

[rm-code]

Started a branch at https://github.com/love2d-community/love-api/tree/update_to_love0110

TODO:

• love.data.decompress
• love.filesystem.getCRequirePath
• love.filesystem.setCRequirePath
• Image:replacePixels
• Channel:demand
• Channel:supply
• World:update
• love.data.decode
• love.data.encode
• love.data
• RecordingDevice
• Texture:getMipmapCount
• Texture
• Texture:getTextureType
• Texture:getDepth
• Texture:getLayerCount
• Texture:getFormat
• Texture:isReadable
• love.graphics.applyTransform
• love.graphics.replaceTransform
• love.graphics.getFrontFaceWinding‎
• love.graphics.setFrontFaceWinding‎
• love.data.hash
• HashFunction
• ContainerType
• love.math.newTransform‎
• PixelFormat
• love.graphics.transformPoint
• love.graphics.inverseTransformPoint
• love.graphics.setMeshCullMode
• love.graphics.getMeshCullMode
• love.graphics.getDepthMode
• love.graphics.setDepthMode
• SpriteBatch:addLayer
• SpriteBatch:set
• SpriteBatch:setLayer
• Body:isTouching
• ParticleSystem:setEmissionArea‎
• ParticleSystem:getEmissionArea‎
• Texture:getPixelWidth‎
• Canvas:newImageData
• Texture:getPixelHeight‎
• Texture:getPixelDimensions‎
• Texture:getFormat
• Texture:getFilter‎
• Texture:setFilter‎
• love.graphics.getPixelWidth‎
• love.graphics.getPixelHeight
• love.graphics.getPixelDimensions
• Texture‎
• CompressedImageFormat‎
• TextureType
• love.data.compress‎
• love.data.decompress‎
• Source:tell‎
• Source:seek
• Source:getDuration
• love.physics.newRopeJoint‎
• Transform:reset‎
• Transform:clone
• Transform:setTransformation
• Transform:reset
• Transform
• Transform:transformPoint‎
• Transform:inverseTransformPoint‎
• Transform:translate
• Transform:rotate
• Transform:scale
• Transform:shear
• Transform:apply
• Transform:getMatrix
• Transform:setMatrix

[rm-code]

@hahawoo Any idea how we could add this:
https://love2d.org/wiki/PixelFormat

?

[pablomayobre]

The time has come! The wiki is not yet up to date, but by updating love-api we can help with that effort too. I'll be trying to get a few PRs in into that new branch

[pablomayobre]

Unfortunately, PixelFormats are both an Enum and a returned tables of the format of key-boolean pairs. So you need to represent them in two formats

The best way would be to have the format defined once in the love.graphics (or possibly in an enum file) like:

local PixelFormats = {
  type = "table",
  name = "formats",
  description = "A table containing PixelFormats as keys, and a boolean indicating whether the format is supported as values. Not all systems support all formats.",
  table = {
    { type = "boolean", name = "rgba8" },
    ...
  }
}

And use it in both getCanvasFormats and getImageFormats as

  returns = { PixelFormats }

Then there would be a separate PixelFormats enum most likely in sync with this table (through a for loop or something?) that would have only the names of said formats

Does this make sense? I can't think of a better alternative

NOTE: It could be the other way around too, which probably would make sense too

[rm-code]

Are there any wiki pages which use the PixelFormats directly? After a quick search I only found it in love.graphics.getImageFormats as table formats and that's exactly how I'd handle it:

returns = {
	{
		type = 'table',
		name = 'formats',
		description = 'A table containing PixelFormats as keys, and a boolean indicating whether the format is supported as values. Not all systems support all formats.'
	},
	...
}

My question was aiming at the problem, that the enum page itself has multiple sections and a data table for the description of the constants.

[pablomayobre]

The functions that return it as a table are:

• love.graphics.getCanvasFormats (The wiki says that it returns CanvasFormats)
• love.graphics.getImageFormats

The function that return it as an enum are:

• Texture:getFormat
• ImageData:getFormat
• CompressedImageData:getFormat (The wiki says that it returns a CompressedImageFormat)

The functions that take it as an enum parameter are:

• love.graphics.newCanvas (In the settings table)
• love.graphics.newImageData (Not documented in the wiki but basically newImageData(w, h, format))

PS: When the wiki says it returns CanvasFormats and CompressedImageFormat, it should be fixed and use PixelFormat instead since the idea of PixelFormat is to unify all this different enums

[pablomayobre]

So the table is split in three:
1- TextureFormat, mostly used for newCanvas and Texture:getFormat, only four of these can be used in newImageData
2- DepthFormats, used only for newCanvas and it's corresponding getFormat when working with depth buffers
3- CompressedFormats, used only for CompressedImageData:getFormat

One cannot make assumptions about what getImageFormats and getCanvasFormats can return, the safest would be to assume that any of the PixelFormats can be returned by them.

And even though the table is split like I detailed above, it would be best to just unify them for all the cases instead of having it split

[flamendless]

Cant wait for this

[hahawoo]

I've updated it to 11.2 (via wiki scraping, see #84). The PixelFormat information still isn't there though.

[rm-code]

@hahawoo If you want to, we can close this issue.

[pablomayobre]

I'd argue that this should be closed and a new one should be opened with what's currently missing

I'll probably open one for the JUST RELEASED 11.3 version, since there are already wiki entries for some of it and the changelog was recently updated in the main repo.

[hahawoo]

@rm-code @pablomayobre Sounds good!