search

kikito / love-loader

Threaded resource loading for LÖVE
http://love2d.org
MIT License
131 stars 16 forks source link

Compatibility with SLAM #15

Open hollunder opened 8 years ago

hollunder commented 8 years ago

To be honest, I don't know whether to request it here or there (https://github.com/vrld/slam). I tried to simply require slam in love-loader.lua but then it fails to load any audio.

Error: lib/love-loader.lua:205: lib/love-loader.lua:103: bad argument #1 to 'push' (boolean, number, string, love type, or flat table expected)
stack traceback:
    lib/hump/gamestate.lua:89: in function <lib/hump/gamestate.lua:88>
    [C]: in function 'assert'
    lib/love-loader.lua:205: in function 'update'
    states/LOAD.lua:10: in function 'update'
    [string "boot.lua"]:461: in function <[string "boot.lua"]:433>
    [C]: in function 'xpcall'

I tried to debug this but don't know how to get details since the error seems to happen within the thread.

hollunder commented 8 years ago

I managed to work around. Knowing that this works might lead you closer to a solution. newSource does not work, neither for 'static' nor 'stream'. Instead of:

LOADER.newSource(SOUNDS, 'zap', 'snd/zap.wav', 'static')

I can load audio using newSoundData:

LOADER.newSoundData(SOUNDS, 'zap', 'snd/zap.wav', 'static')

And then using this cludge I can play back the same sound simultaneously:

love.audio.newSource(SOUNDS.zap):play()

So the problem is likely somehow related to newSource.

kikito commented 6 years ago

Hi, I have marked this project as deprecated and will close all open issues. Thanks for taking the time to report this.

TannerRogalsky commented 6 years ago

It seems unlikely that I will fix this as SLAM's invasive overwriting of the Love's own APIs aren't a case that I feel like we should cover.

But I'll leave this open if only as a documentation that it exists.