Issue #1282 closed

wrong bitmapfont rendering since löve 0.10.2

created an issue

It seems the problem has todo with font:getWidth and also with extraspacing.

For uneven fonts you can't use it and font:getWidth seems to return wrong values.

Test (same for all löve versions): First string uses a calc. x and y position depending on fontsizes Second string uses a fixed x,y position

Until love 0.7.2, 0.8.0, 0.9.2 everything is correctly rendered. Since love 0.10.x, bitmapfonts are crippled.

read more:

Comments (5)

  1. Alex Szpakowski

    I simplified your code and added some lines to show where things should show up, and I don't see any problem. Maybe your hard-coded constants were incorrect? Also be sure to only give integer values to the x and y parameters of print if you want things to look sharp (hence the math.floor in my code).

    -- loading
    local newfont_uneven_alt_img = love.image.newImageData("newfont_uneven_alt.png")
    local newfont_uneven_alt =,
        ' abcdefghijklmnopqrstuvwxyz' ..
        '0123456789' ..
        '.,:;\'!?-+/()%*_&#=[]"{}', 1)
    local teststring = 'This is my little Test for slime :). Font:getWidth seems to be broken in love 0.10.x !?'
    function love.load( args ) newfont_uneven_alt )
    local function setColor(r,g,b,a)
        if love._version_major < 1 and love._version_minor < 11 then
  *255, g*255, b*255, a ~= nil and a*255 or nil)
    function love.draw()
        local gw, gh =,
        local x, y = math.floor(gw/2), math.floor(gh/2)
        local f =
        setColor(0, 0.8, 0, 1), y, gw, y), 0, x, gh)
        setColor(1, 0.5, 0.5, 1), x - (math.floor(f:getWidth(teststring)/2)), y - math.floor((f:getHeight(teststring))/2))
    function love.keypressed(key)
        if key == 'escape' then
            love.event.push('quit') --for 0.8.0
            love.event.push('q')    --for 0.7.0
  2. SiENcE reporter

    Hi Alex,

    sure I can do this. But nevertheless since 0.92 you have changed this behaviour and it's nowhere documented. Before 0.10.x you did an implicite math.floor, but now it seems not.

    If you add this line to the draw code..., x - (math.floor(f:getWidth(teststring)/2)) +0.5, y - math.floor((f:getHeight(teststring))/2) +20)

    It's correct until 0.92 ... but for 0.10.x and later it's crippled.

    You may add this implicite math.floor keep compatiblity with gui libraries aso.

  3. Alex Szpakowski

    The 0.10.0 changelog does list this: "Updated and to no longer automatically round the x and y position arguments."

    It might be helpful to people who haven't updated their code in 1.5 years to put that note on the wiki page, but print and printf were the only functions to ever round their position coordinates in the first place (they were inconsistent with the rest of, and the rounding change was a user request in the first place, so it didn't cross my mind at the time of 0.10.0's release to document the change in the page describing current behaviour (most wiki pages don't do that either).

    The implicit rounding was removed because the pixel snapping behaviour it creates is sometimes unwanted but impossible to prevent if love does it internally. It also never worked properly - if you used and friends, the rounding would not apply correctly.

    I also pointed out the change in the forum thread you created, before you created this bug report, FWIW.

  4. Log in to comment