search

love2d-community / love-api

The whole LÖVE wiki in a Lua table.
http://love2d-community.github.io/love-api/
299 stars 47 forks source link

0.11.0 Update #54

Closed rm-code closed 4 years ago

rm-code commented 6 years ago

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

TODO:

rm-code commented 6 years ago

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

?

pablomayobre commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

The functions that return it as a table are:

The function that return it as an enum are:

The functions that take it as an enum parameter are:

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 commented 6 years ago

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 commented 6 years ago

Cant wait for this

hahawoo commented 4 years ago

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

rm-code commented 4 years ago

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

pablomayobre commented 4 years ago

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 commented 4 years ago

@rm-code @pablomayobre Sounds good!