as i dip my toe in the norns pool, i find myself drawn to learning how the graphics system works.
norns/docs tipped me off to:
display_png (filename, x, y)
display png.
looking for a bit more detail on the filename and expected file formatting.
i assume 128x64 (max) greyscale standard uncompress png.
should the code contain “.png” - and how do i specify path?
are x/y position the top corner of the image, or the center of the image?
This looks like a me question… 
x/y is 0,0 on the display - same as text - top left corner
filename is a full path - so something like
screen.display_png("/home/we/dust/code/thing/thing.png", 0, 0)
screen.update()
and bob’s your uncle.
bigger images will just load into the space of the screen - they won’t resize to fit. (I suppose I should try negative/off-sceen coordinates to see what happens)
color pngs will work fine - cairo is doing the munging here
I don’t remember if I tested with compressed vs uncompressed. I don’t think it matters.
I don’t remember if I did much testing with layering things. I think the png will fill all it can, so try to add text after the display_png call.
this is likely very inefficient to load inside a loop or with heavy refresh rate.
I have some other goofy ideas/experiments for drawing sprites to animate. Let me know if you wanna see any of that (way more convoluted tho)
thanks this is all very helpful!
how about with smaller sprites that don’t fill the screen and run max 12fps?
totally interested! i want to make spritesssss
try it and see? I did zero stress testing on this 
yikes… now I have to go back and remember all the stupid file munging I did way back when. 
It was something along the lines of “create a 2 color png, read that into memory via a python script and create a pixel array in lua - then just fill pixels from the array.”
which is what I’m doing here:
Completely tangential to serious conversation. But reading this made me think it would be really neat to have something, like a little seahorse/frog/crab sprite as the boot up animation, instead of the pixel cloud…adding to that I don’t know if anyone else would like a tamagotchi in their norns, but I definitely would.
been chewing on this very concept for a couple days now
I imagine something you can feed notes and are rewarded with harmony, something that sings in minor keys when it is left alone. If goofy suggestions are on the table…
i’m having trouble implementing… so new to all this!
code:
-- png demo
--
-- specify dsp engine to load:
--engine.name = 'TestSine'
function init()
screen.aa(0)
end
screen.display_png("/home/we/dust/code/we/test/smile.png", 0, 0)
screen.update()
end
error message:
### SCRIPT ERROR: load fail
/home/we/dust/code/we/test/png-test:16: <eof> expected near 'end'
stack traceback:
/home/we/norns/lua/core/norns.lua:185: in function </home/we/norns/lua/core/norns.lua:185>
[C]: in function 'dofile'
/home/we/norns/lua/core/script.lua:140: in function </home/we/norns/lua/core/script.lua:140>
[C]: in function 'xpcall'
/home/we/norns/lua/core/norns.lua:186: in field 'try'
/home/we/norns/lua/core/script.lua:140: in function 'core/script.load'
(...tail calls...)@shellfritsch you need to put the screen functions inside the redraw function
function redraw()
screen...
end
path tip:
you can use path.home for /home/we/dust and path.code for /home/we/dust/code
use .. to glue strings together
so
screen.display_png(path.code .. "we/test/smile.png", 0, 0)
(see others at https://github.com/monome/norns/blob/master/lua/core/config.lua#L19)
i think unfortunaely you want to be really restrained in your usage of a png-rendering function like that from any lua callback.
it is a great example of something that will peg the event loop (file access.)
if you really want to do sprites, we need functions to load a sprite sheet and blit different regions of it to the cairo surface from RAM.
this is also yet another application that would benefit from separate cairo thread and event loop (which is a perffecly straifghtforward concept, and also just a bit of a drag to actually add)
it’d make sense to add an additional frame buffer and a buffer copy… but this adds complexity to the whole system. will have to think about it.
i agree, but i think even more importantly just implemen ‘blit from RAM’ first, ‘blit and swap’ later`
calling the png load multiple times from redraw() is really not great
@tehn @zebra Just found a possible bug - trying to display_png a non-existent file looks like it crashes the display in some fashion (screen goes black, no other script will show anything) - requiring a ;restart
not sure how to get dbug for that though.
Also @shellfritsch sorry I left out the redraw() part of the equation. 
